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 <sfdf@???>"
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 <sfdf@???>"
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
