This text is not ready yet

How to bootstrap a VCS

Why bootstrapping a VCS is so important:

A VCS is an easy way to give others an easy to follow upgrade path to new versions of your software. To compile from a distribution the first time often is very painful, as you have to create a lot of settings, you have to ./configure etc.

After this has been done the first time, upgrading any open source project shall be an easy task. This task shall be less than 4 commands like:

• wget; gtar xfz; make; sudo make install
  
• cvs update -d; ./configure; make; sudo make install
• For a web based system, this shall be less than 5 clicks, including login.

Examples of things done right:

• Debian: apt-get update; apt-get upgrade (possibly answering 1 or 2 questions)

To provide your users with such an easy upgrade path is most easily done by giving your users access to a VCS. However if you plan this to do, then you shall be aware, that not all users are able to use the VCS you have chosen. Therfor it is important to choose the right VCS.

If you have a lot of users with elder systems (like TOR), you shall abstain from complex SVN which is nealy impossible to bootstrap (like SVN) on elder systems, as you then lock out others from an easy upgrade path.

Here are the minimum requirements for such a VCS.

Development environment

If you create a new VCS, it shall be easy to compile. There can be prerequisites, but those must be moderate, such that a typical elder system can get around it. It would be ideal, if your VCS would be able to bootstrap on any Unix like system from 1990 onward (for example, you can use awk, but no gawk features).

• If you need C, allow it to compile on an C89 compliant ANSI-C compiler with standard libraries, and if you need C99 features, state that clearly!
• If you need C++, allow it to compile on any ISO/IEC 14882:1998 compliant C++ compiler with it's Standard C++ library. If you need ISO/IEC 14882:2003 compatibility, then state this clearly! If you need STL state this clearly. Try to stick to the 1994 version, if you need a later version, then state this clearly.
• If you need Python, allow it to run on Python 2.0. If you need a later version, then state this clearly. Try to abstain for Python release which are younger than 5 years.
• If you need Perl, allow it to run on Perl 5.0. If you need a later version, then state this clearly. Try to abstain from Perl releases which are younger than 5 years.

If you need other libraries, provide a full download and make environment. This is "wget", "tar xf", "make". This then can call "configure".

This is true for VCS, which are implemented in a language other than C or C++. In this case, distribute the complete language make environment, which is able to run your VCS. The support for elder machines for this environment must come from you then.

Systems to support from out of the box

If you design a VCS, create a complete bootstrap archive, which is able to cleanly compile and install for following systems:

• FreeBSD 3.5.1: ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/3.5.1-RELEASE/
• SuSE 5.3: (URL not found)
  
• CygWin: cygwin.com/
  

Note that CygWin is a special thing, as in CygWin you need no support for elder versions. In the contrast, you always must support the newest version of CygWin, as CygWin runs in a Microsoft Operating System, which means, it is likely that people must upgrade CygWin after a Microsoft patch. CygWin itself does all the support for elder Microsoft Operating Systems, so the only thing you have to do is to support the newest CygWin release.

Your bootstrapping TAR shall be one big single file which contains everytyhing to get it compiled on any of the systems noted above (so no different TAR for different systems. Just one big huge TAR). All sufficient to compile shall be "make". All needed to install shall be "sudo make install". Perhaps you need some README, too, which explains all the setup steps you must do before you install.

The bootstrapping "make" must run as any ordinary user without root access. Only the "make install" is run as root. Therefor you need these two commands.

If you are good, create a "make update" or likewise to keep the VCS bootstrap archive updated to the latest version. This, however, must be secured by some cryptographical extension. You cannot rely on GPG for this, as this might not be on the system you use. For now I have no good idea how to support this.

Also remember that there are systems which are offline. This means, if you cannot connect to the update site, print instructions how to download and install the update manually. As before, try to stay below 5 commands, like:

• wget -r -np URL; copy to stick; copy from stick; make manual-update

Do not forget to include every step needed in detail, this is, include example directory names. So do not say "copy it to the target system", tell them from where and to where. Give a complete example.

And remember:

• There are still 1.2 MB floppys around, so best is to give people an easy way to split the download into a number of smaller parts.
• Do not think people have access to a graphical JavaScript driven browser on some graphical OS like MacOS-X or Windows.
• Do not think people have more than a typewriter TTY, that is, no curses driven things, please.
• Best is to even do not think that people are able to do interaction at all, so provide suitable batches which can run completely unattended.

Requirements to a cryptographic backend

If you cryptographically secure downloads, please think of following needs:

• The system checking the signature can be offline. So the signature check must succeed offline, too.
• You can go offline. So the signature check must not need additional downloads. Everything needed to check must be contained in the single download! (This means: No .sig files, please!)
• The PKS use must be secured against any form of compromise (except from the PKS being hacked itself), such that people, who trust a previous version can trust the later version as well.
• There must not be any holes in the security chain.
• There must be an easy way to start to trust the first download as well. This perhaps is the most crucial thing at all.

How to create initial trust

Gaining initial trust is the most difficult thing in the world. However there are some ways to do it. And there are some ways not to do it.

Things which can be used to check initial trust

Initial trust is manually verified. Therefor you can rely on features, which are not available on the target system. For example, you can rely on the fact, that somebody can run an md5sum command, even if this is not available on the target system. md5sum or sha1sum is available under CygWin as well (try to abstain from other .exe types on windows). If you later need something like an md5sum command, include it in your bootstrap archive!

Also you can rely on some command like gpg being installed. However you cannot rely on this at later times. As GPG has a high risk of having holes (just read the update history on GnuPG), you shall abstain on relying on a GPG infrastructure. So do not include GPG in your bootstrap archive. This is especially important, as things like GPG itself may be illegal in some countries (like France), because it is capable to create strong crypto. However cryptographical signing (and checking such signatures) is allowed in all countries (if I err there, these countries need not to be supported, as they are prone to cyber-attacks and thus must destroy all their computer environment in the next decades anyway).

So from the initial trust there must be a way to stay in the trusted environment after updates. This trust must already be built into the bootstrap distribution. It must not depend from any external source.

Things not to do

• Do not provide a .sig file which relies on a keyserver. Keyservers are inherently insecure. They are often running unattended for years. It is likely that a clever compromosed keyserver will go undetected for centuries. Keyservers are no way to create any initial trust.
• Do not provide plain unprotected public keys on your website. If you have a public key, let some others sign it. These must be people, who can create trust themself. Have those others provide their public key on their website, too. If you do not know such people (like me, I do not know anybody who uses PKI), buy some certificate from a CA. Use this certificate to (indirectly) sign your own certificate. Tell people how they are able to check this signature.
• Do not think you are done. Certificates quickly time out (a decade is quickly in this respect). This is, after some years from now (say 200 years) nobody will be able to check your initial signature again. Therefor have a way to publish your signature in a way which cannot be altered easily. This is, for example, in something like an "Ewiges Logfile" or make archive.org catch your PK.
• If you think you ever might drop your support, do not rely on yourself. As humans are prone to death, this means, you must have an escape route, such that others can take over. Best is to already provide such "others" in your update. These "others" are not authoritative, as long as you support your application, so you always can "override" it with a new update. It is like a dead men switch, so if you stop updating your signature, those others become valid.
• Do not rely on revocations. Only nerds know about revocations. Normal people do not understand revocations. Revocations are plainly unusable. Period.
• Do not use signatures with a long validity status. A long validity status (this is longer than 1 year) gives too much time to break the encryption and thus the signature. Therefor you must re-sign everthing at least each year.
• Do not rely on a single signature. Best is to require the newest two signatures to be valid all time and at least 3 signatures to match. Also signatures must have a different signing key. So there is one "old" signature, one "current" and one "new". The "old" signature will soon time out, the "new" signature is freshly created. The newest one must be valid and all the others must match, too (even that they are timed out). In case a distribution key is compromised the attacker can just create one single compromised update, but then the attack stops, as the attacker cannot create a new distribution key. As new signatures with a new distribution key automatically superseed elder signatures, just publishing a new distribution key gets rid of the compromised version.

Things to do

• Rely on validity dates, not on revocations. This lessens the impact in offline situations.
• Do frequent updates. Frequent means "at least one every year" or "a third of the time the used certificate is valid". (See dead men switch as well.) So if you do not change anything, an update is provided which just contains a newly signed signature.
• Keep your key secure. This means, do not store it on a system which is ever connected to the Internet. Do not store it on your USB stick used for travelling, too. You do not need to use your key to sign packages directly. All you need is to sign distribution master keys with it. This can be done offline. This signed distribution master key then is published with the distribution and used to sign the distributon.
• Keep your distribution master key relatively secure. It can be stored on a system which has Internet connection (like your Intranet VCS server), but not on a system which is on a network which provides services to others (like on DMZ or Extranet). The distribution master key is used to automatically create distribution keys. These can be uploaded on demand to the servers which need them.
• Use one distribution key with each distribution. You can store the distribution keys on the machine which is used to create distributions. If one gets compromised, this only compromises one archive. As there is a requirement for distribution keys never to sign more than one distribution (including the update) this is not such a big problem.

The scopes of the three keys are all different: Main key is kept as secret as possible, it is valid for several years. Distribution master key is kept relatively secure, and it is valid only for 1 year. Distribution keys are stored insecurely and are only valid for one single distribution (plus update).

The certificate chain is followed by following the distribution keys. The distribution keys are also validated with the master keys, and all master keys are signed by the main key.

Create initial trust

To create initial trust you need two things:

• Well known 3rd parties, which say, your keys are good.
• Spread your information such, that nobody can compromise all this information.

Remember: If some attacker gains access of your ISP, it is likely that the attacker gains access to your servers, to your eMail and to your domain (DNS) as well. So an attacker is literally able to change and control every aspect of information you publish.

However such an attacker still has no control over information shown by archive.org, over other people's web pages citing your software and not over the google search results citing old releases of you stored by somebody else.

So if you are a web collaboration platform (like a forum), spread your keys and instructions with each public installation. Some people will disable this feature, but many will keep it online. (As many people do not want to share version numbers for security, this page shall be mostly independent.)

The other way is to use a search engine to create trust. If there is a chain you can follow from old releases to the current one, and you can find a start of such chain in a search engine, then you can be nearly sure, that nothing is compromised. And if you want to be sure that the last distribution key is not compromised, you can just stay behind one distribution (and perhaps check the latest patch set manually).

To sum it up:

• If somebody trusts some package, this shall be published using a cryptographical hash of the signature. The signature then validates the package including the keys used for this package.
• If you happen to find such a start value there must be a way to follow the certificate chain up to the current package.
• If somebody finds some compromized keys, this can be as well be published through a search engine. There shall be some standard to mark such suspect keys (with a keyword). It is right that some idiots out there can try to break the certificate chain by telling others that the key is suspect, however usually such false information quickly is found and those idiots are hunted down by several groups. So this is no problem.

The important part is, that if somebody finds something suspect in a package, this information shall travel fast. You later then can sort things out. This way you get informed quickly about possible compromizations more quickly. And if this information is wrong, no real harm is done (except for some really weird cases, these can be handled in future).

-Tino, 2008-09-10