Hello,
>From section 3.5:
The OpenBSD project does not digitally sign releases. The above
command only detects accidental damage, not malicious tampering.
If the men in black suits are out to get you, they're going to
get you.
It seems the men in black /are/ out to get everyone after all.
Anyway... we have signfiy now and the FAQ still says otherwise.
Index: faq3.html
===================================================================
RCS file: /cvs/www/faq/faq3.html,v
retrieving revision 1.83
diff -u -p -r1.83 faq3.html
--- faq3.html 1 Nov 2013 22:59:01 -0000 1.83
+++ faq3.html 14 Mar 2014 09:01:53 -0000
@@ -33,9 +33,10 @@
<li><a href= "#ISO" >3.3 - Does OpenBSD provide an ISO image for
download?</a>
<li><a href= "#Download" >3.4 - Downloading via HTTP, FTP, RSYNC or AFS</a>
-<li><a href="#Verify" >3.5 - Verifying your download</a>
-<li><a href="#SelectHW" >3.6 - Selecting Hardware</a>
-<li><a href="#FirstSys" >3.7 - What is an appropriate "first system"
+<li><a href= "#Verify" >3.5 - Verifying your download</a>
+<li><a href= "#Trust" >3.6 - But how can I trust the public keys!?</a>
+<li><a href= "#SelectHW" >3.7 - Selecting Hardware</a>
+<li><a href= "#FirstSys" >3.8 - What is an appropriate "first system"
to learn OpenBSD on?</a>
</ul>
@@ -161,22 +162,130 @@ CD is always closer than any mirror. Acc
<h2>3.5 - Verifying your download</h2>
<p>
-In the same directory as the installation sets, each mirror includes a file
-named SHA256 which contains checksums of the various installation files. You
-can confirm that none of the downloaded files were mangled in transit using
-the sha256(1) command:
+The OpenBSD project wrote
+<a href=
"http://www.openbsd.org/cgi-bin/man.cgi?query=signify&sektion=1";>signify(1)</a>
+to cryptographically sign all releases, packages, and firmware.
+In the same directory as the installation sets, each mirror includes two files
+named SHA256 and SHA256.sig which contain the checksums of the various
+installation files, and are cryptographically signed by the private key of the
+corresponding release.
+
+<p>
+The signify(1) utility was first introduced in OpenBSD 5.5, however it has also
+been backported to older OpenBSD releases, as well as other operating systems
+such as Mac OS X to be able to verify OpenBSD (and anything else that uses
+signify) without already having an OpenBSD system.
+
+<p>
+There are several ways to get the public keys. If you already have a machine
+running OpenBSD 5.5 or later, the public keys for the release can be found in
+/etc/signify/openbsd-XX-base.pub, where XX is the version of the release you
+wish to verify. If you do not already have a trusted post-5.5 OpenBSD system,
+you need some way to bootstrap your trust.
+
+<p>
+A great way to get the keys is by
+<a href= "http://www.openbsd.org/orders.html";>buying a CD set</a>.
+
+<p>
+Another way if you already trust the ssh fingerprint of the main CVS server
+is with something like:
+
+<table border=0 width="90%"><tr><td nowrap bgcolor="#EEEEEE"><pre>
+ $ <b>cvs -d [email protected]:/cvs get src/etc/signify</b>
+ cvs server: Updating src/etc/signify
+ U src/etc/signify/openbsd-55-base.pub
+ <i>[...]</i>
+ $ <b>sudo mv src/etc/signify/openbsd-*.pub /etc/signify/</b>
+</pre></td></tr></table>
+
+<p>
+Once you have the signify utility, the public key, a file you want to verify
+(for example install55.iso), and its corresponding SHA256.sig, verifying it
+would look something like:
<table border=0 width="90%"><tr><td nowrap bgcolor="#EEEEEE"><pre>
- $ <b>sha256 -c SHA256</b>
+ $ <b>signify -C -p /etc/signify/openbsd-55-base.pub -x SHA256.sig
install55.iso</b>
+ Signature Verified
+ install55.iso: OK
</pre></td></tr></table>
-The OpenBSD project does not digitally sign releases. The above command only
-detects accidental damage, not malicious tampering. If the men in black suits
-are out to get you, they're going to get you.
+<p>
+Please refer to the
+<a href=
"http://www.openbsd.org/cgi-bin/man.cgi?query=signify&sektion=1";>signify(1)
man page</a>
+for more information and other usage.
+
+<p>
+Note that you need only verify the authenticity of the checksums manifest (via
+SHA256.sig) with signify(1). You can manually (visually) compare the actual
+checksum of the file to be verified (for example a recently-downloaded bsd.rd
+on some remote server you're about to upgrade) against the known-good signed
+checksum as verified by signify(1) on your trusted computer to achieve the
+same measure of authenticity.
+
+<p>
+To compute the raw SHA256 checksum of a given file (for example bsd.rd), simply
+type:
+<table border=0 width="90%"><tr><td nowrap bgcolor="#EEEEEE"><pre>
+ $ <b>sha256 bsd.rd</b>
+ SHA256 (bsd.rd) =
d3db7e7dca79f133665f0e8ef5eaabbf17269673dcd2ca6698c74c57892ad0be
+</pre></td></tr></table>
+
+<p>
+<a name= "Trust"></a>
+<h2>3.6 - But how can I trust the public keys!?</h2>
+
+<p>
+This question is often phrased as "Why don't you just use GnuPG?"
+
+<p>
+No matter what, you always need to make <i>some</i> assumption of trust
+eventually. To what extent you should go to verify your install depends only on
+how much effort you're willing to make, how realistic you perceive the risk of
+tampering to be, and how paranoid you're feeling at the time. If you haven't
+already read (and seriously considered the implications of) Ken Thompson's
+Turing Award lecture entitled
+<a href= "http://cm.bell-labs.com/who/ken/trust.html";>Reflections on Trusting
Trust</a>,
+now would be a good time to do so.
+
+<p>
+You may have noticed the distinct lack of any concept of a verified identity
+associated with the signify key system. You may be crying out "What about the
+web of trust!" As with any other part of the system, OpenBSD's philosophy is
+to strive for the simplest, cleanest, most elegant solution to a given problem,
+because the simpler something is, the easier it is to audit and reason about,
+and the more likely it is to be correct, bug free, secure, etc.
+
+<p>
+signify(1) provides the minimum functionality required to have a
+cryptographically verifiable guarantee that your data is genuine. After that
+you can add whatever measures of real-life verification you see fit. If you
+just feel the need to fetch the key from a bunch of different mirrors while on
+a bunch of different networks, then do that. If you want to gpg-sign what you
+see as the public key and post it everywhere to cross-verify with your friends,
+then do that. If you want to
+<a href= "http://www.openbsd.org/orders.html";>buy a CD set</a>
+with the key on it (or three at different times shipped to different places),
+then do that. If you want to fly your trusted courier to calgary to verify the
+key in person and then get it tattooed onto your face for all to see and
+compare against... then... maybe you might want to reconsider your threat
+model.
+
+<p>
+If you really want to be all buzzword compliant, signify and whatever you
+choose to couple it with (if anything) provide excellent <i>trust agility</i>.
+If you are so inclined you can even create your own private signify key that
+you keep under your own personal physical security policy and use it to re-sign
+everything, distribute the corresponding public key in whatever tamper-proof
+method you choose, and have all your developer-friends compare the copy of the
+checksums you signed against what they consider their golden copy to be. If you
+want to, you can think of signify(1) as a building block; a very cleanly
+implemented building block that provides all the functionality you really need
+to get the job done.
<p>
<a name= "SelectHW"></a>
-<h2>3.6 - Selecting Hardware</h2>
+<h2>3.7 - Selecting Hardware</h2>
<p>
Selecting appropriate hardware to run your OpenBSD system on is
@@ -254,7 +363,7 @@ when used on slower speed networks, due
</ul>
<a name="FirstSys"></a>
-<h2>3.7 - What is an appropriate "first system" to learn OpenBSD on?</h2>
+<h2>3.8 - What is an appropriate "first system" to learn OpenBSD on?</h2>
While OpenBSD will run on a smaller, older and less powerful computer
than just about any other modern OS, if you are just getting started with
OpenBSD, using too little machine can be frustrating.
