Wipe (some) secrets from memory after use

[hg]

While not a panacea, this is considered to be a good practice which doesn't cost us much.

The cryptographic libraries we're using are already doing that for some of their own data structures. This should additionally cover EC keys, a few strings potentially containing passwords, and various temporary key buffers.

---

I finally remembered to add libgcrypt to CI. This is not related to the main PR, but is bundled here to avoid creating even more conflicts.

[hg]

Good idea, thanks. I also added explicit_memset() since NetBSD decided to be a special snowflake in that regard. Now the fallback shouldn't be used by anything.

---

Another drive-by question: I've been updating man pages recently, and not having had the chance to write roff in the past, it's been… a bit of a rough ride. Macro names are really non-obvious, whitespace rules are somewhat arcane, and there are basically no modern tutorials for those who don't like to read (colorful, glossy, and and ridden with emoji, like you'd expect in the 21st century).

Now, I don't care about that much (most of the pain has been overcome by now), but if we hope to attract more contributors in the coming years, maybe it makes sense to look for more modern alternatives?

Like scdoc, which provides markdown-ish syntax, compiles into roff, is written in C (and is tiny), and available everywhere.

I mean, compare this to this or this (or even this, since it resembles markdown enough that GitHub markdown renderer mistakes it for one).

Now, markdown can be converted into man pages, but that requires something like pandoc, which is pretty heavy, while scdoc binary package on my system is around 30 KBs.

The downside is obvious — it adds another build dependency (although we can write scdoc, convert it to roff, and add that roff to the source tree).

Yes/no?

[gsliepen]

Looks good!

---

Tinc uses the mdoc macros, which is already a higher level than pure roff, and intends to convey semantics instead of just how you want to style things (think LaTeX vs. TeX). In the past I was not too happy with the existing manpage generators, but perhaps they are better today.

As for scdoc, it looks cute, but whether it is tiny or not doesn't make much of a difference to someone who needs to install it as yet another dependency. I personally also find it very irritating that it's almost Markdown but didn't just go all the way. OTOH, I see scdoc is available in many package managers, which is great. If we go this route then maybe we can consider writing the manual in Markdown or something similar as well. Even more ideal would be to avoid the duplication of the documentation of command line and config file options.