Our lists are so full of helpful smart people who think chains of trust are magical pixie dust coming from root-provider-fairylands where the root cert faires live in castles of uncompromising fortitude that are never full of government plants and are whose certificates are magically transported into operating systems and placed in that special place in our hearts where no file could ever be modified... They also suggest we should move the machines that generate the releases into of those same castles where power is cheaper to save money...
I think I'll make sure to advertise the next OpenBSD Foundation funding campaign by suggesting that you're not actually not real people, but a helpful-suggestions-posting-bot sponsored by the NSA.. Or maybe it's that they've infiltrated our educational systems... Please get our your tinfoil hats kids. On Wed, Jan 22, 2014 at 5:39 AM, Bob Beck <[email protected]> wrote: > Yeah. Ok mister chicken before egg.. We should validate this thing shipped > in a release using dnssec with a root of trust depending on root certs > shipped with the release... Love that idea.. But maybe I'll just buy a > CD. > > On 22 Jan 2014 05:13, "Jiri B" <[email protected]> wrote: >> >> On Wed, Jan 22, 2014 at 11:28:50AM +0000, Stuart Henderson wrote: >> > The model is: only the specific keys placed in /etc/signify are trusted. >> > >> > The plan is to include the public keys used for signing release n+1 in >> > release n. So once you trust a particular key, by verifying signatures >> > on sets which you download+install, you can have a chain of continuity >> > for future keys. >> > >> > You still need to get your initial key from somewhere that you >> > trust. If you are worried about sources of this, you can at least >> > check and compare the 55*.pub files from a few sources e.g. those in >> > downloaded sets against those in anoncvs/cvsweb ("cvs -d $CVSROOT get >> > -p src/etc/signify/55base.pub" to display on stdout). Of course when >> > the next release is done they'll be on CD. >> > >> > (IIRC somebody suggested printing keys on the tshirts, not sure if print >> > resolution on fabric is really up to that without making the text so >> > big as to be horribly ugly, posters may work though.) >> > >> > Given sufficient space to download tgz before unpacking, the install >> > ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk >> > - signify/ed25519 is small, and yes: please test and report on any >> > problems!). >> > >> > If you're fetching a new installer (ramdisk kernel, install55.iso, >> > floppy*.fs, etc) you can verify the signature of that file before using >> > it. Also it should go without saying, if you use the "untar sets on a >> > running system" method, checking those sets is your responsibility, >> > see signify(1)'s EXAMPLES section for information about how to do this. >> >> What about as TXT record for dns (in combination with DNSSEC) as >> alternative >> for getting the key? :) >> >> jirib >> >
