Skip to main content

More Colors For My Blog

As I wrote in a previous post I am now very pleased with the syntax coloring for console transcripts in my blog posts. As a reminder, the resulting HTML color is not derived from the color information in the original output but rather added after the fact by the Pygments Python library to plain text transcripts.

Although the solution looks nice and allows me to keep the terminal transcripts right within the source files for the posts, it is not a full replacement for including terminal output with ANSI color escape sequences directly in the blog posts. This solution is required to reproduce terminal transcripts for programs that have individual colored output just like the script described in the checksec post.

In lack of another method I took screenshots of the terminal output and included the graphics rather than text with attributes. Again this is unfortunate as it renders the text in the graphics inaccessible for example to web search engines - or at least I currently believe that most of them don’t do OCR on arbitrary images.

Since I formulated this exact problem as the final sentence in the previous syntax coloring post, it kept nagging at me and so I decided to spend yet some more time on colored output.

At first I was optimistic that Pygments would simply have an "ansi-color" lexer and would thus allow to reuse the mechanics already explored in the previous post, but it turned out that such a thing is not part of the standard Pygments distribution. I did find pygments-ansi-color installable by pip but I could not make it work from within AsciiDoc in Nikola and so I continued to look for different solutions.

It was not long until I ran across the aha tool which is able to take a transcript with the ANSI escape sequences and turn it into HTML. This was certainly the core of the problem but requires a method to pass HTML directly through the AsciiDoc (or ReST) Nikola front-end. After a few exploratory attempts I found a workable solution with the help of the triple plus pass-through and the include directive. The included file "checksec.html" was itself generated with "aha -n" from a session transcript recorded with the script tool:

++++
<pre><code>
include::files/typescript/checksec.html[]
</code></pre>
++++

This was certainly what I was looking for, but the steps to get there were certainly more involved than what I originally hoped for. First I had to start "script" to record a session, then executed the commands to record under its regime and after closing the "script" shell the header and footer with timing information had to be removed from the typescript. The result of all this was then converted with "aha -n" into an HTML file ready for inclusion in Nikola.

Doable but not good enough.

Some more digging finally lead me to the elegant solution of simply copying the content from Gnome Terminal by selecting "Copy as HTML" from the context menu and immediately paste it into the blog post inside the pass-through. This takes the external "script" and "aha" tools out of the picture and leaves me with a streamlined and elegant work flow.

If you use Emacs, for this to work you have to call "M-x clipboard-yank" manually to insert the contents. The usual "C-y" yank command always inserted only the text without HTML for me.

With this in place, it is now pretty straight forward to insert arbitrary colored output from Gnome Terminal into my blog posts. Below is a re-run of "checksec.sh" on Debian 10 (Buster):

dzu@krikkit:~$ checksec.sh --kernel
* Kernel protection information:

  Description - List the status of kernel protection mechanisms. Rather than
  inspect kernel mechanisms that may aid in the prevention of exploitation of
  userspace processes, this option lists the status of kernel configuration
  options that harden the kernel itself against attack.

  Kernel config: /boot/config-4.19.0-8-amd64

  Warning: The config on disk may not represent running kernel config!

  GCC stack protector support:            Disabled
  Strict user copy checks:                Disabled
  Enforce read-only kernel data:          Disabled
  Restrict /dev/mem access:               Enabled
  Restrict /dev/kmem access:              Enabled

* grsecurity / PaX: No GRKERNSEC

  The grsecurity / PaX patchset is available here:
    http://grsecurity.net/

* Kernel Heap Hardening: No KERNHEAP

  The KERNHEAP hardening patchset is available here:
    https://www.subreption.com/kernheap/

dzu@krikkit:~$ 

Comparing this to the results from running checksec.sh on Debian 9 I really wonder why two of the protection mechanisms were disabled. For today I will leave this for a future post or maybe you, my dear reader, can shed some light on this.

Comments

Comments powered by Disqus