Hi, The design draft has been significantly reworked since then. A security discussion was written. Please review.
See bellow answers to the questions and remarks Robert sent us a while ago. Robert Ransom wrote (02 May 2012 17:27:12 GMT) : > *Everything* which the update downloader needs to authenticate must > be in the *contents* of the file whose signature is checked. > Currently, an update's product name, build target, and intended > update channel are not authenticated. > You must include the *hashes* of other files which are part of the > update in the file whose signature is checked. Verifying that other > files have, at some point in the past, been signed as a component of > an update is not enough to verify that those other files are part of > the update you want users to install. Thanks a lot. I think the current design draft fixes this. >> * questions to refine the idea, the requirements, whatever >> difficulty I may have missed... > Include the specific command line that you plan to use to verify the > signature on an update-description document. Please see the new "signature verification" paragraph (this is 5.3.f at the time I am writing). > Specify terms/phrases to be used to describe (a) the YAML file that > describes the update, (b) the whole set of files included by > reference into an update, and (c) any file included by reference > into an update, and stick with those terms/phrases. Done. (This is section 2 at the time I am writing.) Now come the signature verification tests you suggested. Note that I have run the signature verification tests against full-blown gpg, not gpgv, since GnuPG::Interface wraps the former, not the latter, and they have incompatible interfaces. If there are significant advantages in doing so, it is doable to point G::I at a wrapper that runs gpgv and exposes gpg's --verify syntax, though. Thinking how these results mix with our current time syncing system is left to be done. > How does gpgv react when the system clock is set to before the time > at which the signature claims to have been produced? amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: Good signature from "sdfsdfs <s...@dsffs.com>" amnesia@amnesia:~$ echo $? 0 > How does gpgv react when the system clock is set to before the time > at which the signature-verification key claims to have been > produced, amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: key C77B4F91 was created 384178991 seconds in the future (time warp or clock problem) gpg: Can't check signature: timestamp conflict amnesia@amnesia:~$ echo $? 2 > or after it is set to expire? amnesia@amnesia:~$ gpg --verify bla.asc bla gpg: Signature made Fri 04 May 2012 12:09:45 PM UTC using RSA key ID C77B4F91 gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Good signature from "sdfsdfs <s...@dsffs.com>" gpg: Note: This key has expired! Primary key fingerprint: F780 5DA6 39FB 05D2 C403 1500 0F9C 869C C77B 4F91 amnesia@amnesia:~$ echo $? 0 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
