[Cryptech Core] The Cryptech wiki is dead, long live the Cryptech wiki

[Rob Austein]

Not sure how often folks check https://wiki.cryptech.is/, but if you
do you will notice a change: it's not Trac anymore.  Trac has been on
life support for years now, but the last straw was an Apache
vulnerability that was the start of a domino chain of upgrades which
made it impractical to keep on with Trac.

While the trigger was a bit abrupt, it had been clear for a while that
something like this would happen eventually (Trac has been on life
support for a while now), so I'd done some work on a replacement.
Given various constraints, I elected to split Trac's former functions
into two separate jobs:

1. Web access to the Cryptech git repositories

2. Web access to some wiki-like web site where developers could post
   stuff as needed using a simple markup language.

Task (1) is now handled by cgit, see https://git.cryptech.is/.  All of
the old git access URLs still work, this just provides a low-overhead
web viewer on top of what we already had.  cgit has been up for about
six months now, not sure anybody but me noticed :)

Task (2) was a bit more complicated, in part because the only real
parser for Trac's Wiki syntax is in Trac itself.  MoinMoin is close,
but not close enough for automatic translation.  So the obvious first
step was to translate the wiki content into something more portable,
to wit, Markdown.  But this still left the question of how to present
the resulting Markdown.   The best approach I found turned out to be a
"static site generator", ie, basically a tool that compiles a
collection of Markdown files and attachments into a web site.  There
are a bunch of these, each with its own theme and plugin system.  What
we have now uses Pelican with the m.css theme and plugins.

Write access to the wiki-like thing is via a git repository,
https://git.cryptech.is/wiki, with the usual ssh-based access for the
developers and world read access via HTTPS.  The repository is
configured to compile the Markdown automatically on git push.  So
basically, one just edits, commits, pushes, done.  Not exactly a
"wiki", but I for one prefer this model anyway (web browsers make
really bad text editors, particularly when something crashes half an
hour into editing a long document...)

OK, so at this point folks might be wondering why not Github or a
Github-like solution like Gogs or Gitea?  Several reasons:

1. Our git repositories have a particular hierarchical structure,
   which doesn't map well into a flat Github-like user/repo namespace.
   The repository hierarchy is wired into the build system in several
   places, and we've been using repository URLs that reflect that
   structure for years, so it's not something to change trivially.

2. While it would not have been obvious to anybody but me, supporting
   dynamic content has been a bit of a pain: we've gone through
   periodic bouts of what appear to have been unintentional DoS
   attacks due to badly configured web spiders.  Yeah, Trac is
   particularly bad about handling this sort of thing, but I wanted to
   move in the direction of only using dynamic content for things that
   really require dynamic content.  So a static site generator was
   very appealing on those grounds, and cgit, while still a form of
   dynamic content, has a built-in caching mechanism which reduces the
   impact of the kind of web spider problems we've had in the past.

3. I also wanted to get rid of the password-based logins to the web
   site.  We use ssh keys for commit access to git, and pgp keys to
   sign the commits, and that's all very good, but web login
   interfaces still just use passwords.  Yeah, we could have gone to
   something where we issued our own X.509 client certificates or
   magic tokens or... but that's a lot of overhead for something that
   I wanted to make simpler, not more complicated.  The git-based
   setup described above allows us to piggyback our existing
   git/ssh/pgp infrastructure and remove password-based logins
   entirely, which seems advisable.

4. Although we've had many discussions on the subject, as far as I can
   tell there is no clear consensus among the Core team to move to
   Github, and I certainly was not going to do that unilaterally.
   Some of the reasons for this are technical: AFAIK there is no way
   to enforce our current restriction that all commits must be signed
   if we move to Github, and at least some of us think that's
   important.

So, with all that said: the current solution preserves the old wiki
content, seems usable, and allowed me to get the site back up fairly
quickly (downtime was about 48 hours).  If folks want to start a
discussion about some other thing I should have done, have at it, but
at least the site is back up while you all tell me I was wrong. :)

[I did float the Trac -> cgit+pelican plan with some of the developers
several times over the last year, response was uniformly "crickets",
and as of Wednesday night I had an emergency to deal with wearing my
sysadmin hat, so I make no apologies for the abrupt change, but if the
group manages to achieve consensus that we should be heading in some
other direction I will of course honor Core's decision]