Related issue and PR by RMPR: #3, !2
Workaround:
Create deeplists.tex
file for example for 9 heading levels:
\usepackage{enumitem}
\setlistdepth{9}
\setlist[itemize,1]{label=$\bullet$}
\setlist[itemize,2]{label=$\bullet$}
\setlist[itemize,3]{label=$\bullet$}
\setlist[itemize,4]{label=$\bullet$}
\setlist[itemize,5]{label=$\bullet$}
\setlist[itemize,6]{label=$\bullet$}
\setlist[itemize,7]{label=$\bullet$}
\setlist[itemize,8]{label=$\bullet$}
\setlist[itemize,9]{label=$\bullet$}
\renewlist{itemize}{itemize}{9}
\setlist[enumerate,1]{label=$\arabic*.$}
\setlist[enumerate,2]{label=$\alph*.$}
\setlist[enumerate,3]{label=$\roman*.$}
\setlist[enumerate,4]{label=$\arabic*.$}
\setlist[enumerate,5]{label=$\alpha*$}
\setlist[enumerate,6]{label=$\roman*.$}
\setlist[enumerate,7]{label=$\arabic*.$}
\setlist[enumerate,8]{label=$\alph*.$}
\setlist[enumerate,9]{label=$\roman*.$}
\renewlist{enumerate}{enumerate}{9}
And add -H deeplists.tex
option to pandoc CLI when generating the PDF.
Example:
![ImgPlaceholder](img/placeholder-image-300x225.png)
The path can be:
- any absolute path
- relative from the working directory
- relative from
./src
folder - relative from
/usr/share/osert/src
folder - relative from any (relative or absolute) path you provide with
--resource-path
, e.g.ruby osert.rb generate -r /tmp/mycert
For possible options, see pandoc options.
Puts default
as a language for all code blocks which don't have a language set.
E.g.
```default
raw code
```
In osert.rb
, markdown
is used as --to
formatter for pandoc
which means it will use Pandoc markdown (similar to GFM [1] [2].) Else other syntaxes (commonmark, GFM, MultiMarkdown, PHP Markdown Extra) are supported too, see pandoc options. If you want to use another syntax you can generate your report using the manual command.
The longest recommended line length in code blocks is 126 characters for the first line and then 122 characters for the following lines. This is because of limitations in pandoc that doesn't break very long lines, such as Base64 blobs that easily get very long. The easiest thing to do is to include a space at these points.
Issue tracking:
Pandoc supports those languages,
to list them you can use pandoc --list-highlight-languages
.
XL-SEC made a one-liner to quickly generate a dummy code block for each language:
$ (for f in $(pandoc --list-highlight-languages); do echo "\`\`\`$f"; echo '$ echo "some output from '$f'"'; echo "some output from $f"; echo "# whoami"; echo "root"; echo "\`\`\`"; echo ""; done;) > highlight-languages.md
Then testing all syntax highlight styles for all languages:
$ for s in $(pandoc --list-highlight-styles); do pandoc --template eisvogel --highlight-style $s -o highlight-$s.pdf highlight-languages.md; done;
This is a known and open issue with pandoc. A simple hack is to create a file called disable_float.tex
with the following content:
\usepackage{float}
\let\origfigure\figure
\let\endorigfigure\endfigure
\renewenvironment{figure}[1][2] {
\expandafter\origfigure\expandafter[H]
} {
\endorigfigure
}
Then add -H path/to/disable_float.tex
to your pandoc
command when rendering the report. This will force pandoc
to render the images in the order that they appear in the original Markdown file while also preserving their captions. Source.
When Offensive Security says you have to highlight the changes you made to the exploit, they mean you have to show / explain what you changed in the code but your are free to choose how to do that.
Unfortunately, unlike AsciiDoc, Markdown is more limited and doesn't allow highlighting a line in a code block.
Alternatively what you can do is:
- Take a screenshot and add a red rectangle and arrows, then include the image in Markdown
- Make a diff between the original exploit and the one you modified, then create a code block with
diff
as a language for syntax highlight - Write paragraphs and illustrate with short code blocks including the lines you changed
- Using a more complex solution with Lua filters to introduce a markup for line highlight, e.g. jgm/pandoc#7743