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" <ji...@devio.us> 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
>
>
