So this is a bit messy. My last patch gets us close to what we need, but turns out, I didn't fully understand what the ramifications of my options were in the last patch here: http://mailman.archlinux.org/pipermail/pacman-dev/2011-July/013856.html
* The Package/Database/(implicit all) stuff is fine. * The optional/required stuff is fine (for the most part). * Not so great is the marginal and unknown OK stuff.
Basically, there are three facets to every signature that we can examine.
* Validity: Is this signature signing the data it says it is? This is basically three-valued- good, bad, or unknown. In GPGME, the unknown case comes up if we don't have a copy of the public key in our keyring, for instance. * Trust: Do we trust this key? Note that this is very different than the above "is this signature valid" question. This brings in the whole web of trust business, the blackhole discussions regarding CACert, signing each other's keys, etc. * "Timeliness" (not sure what to call it): aka is this signature expired, key expired, or key revoked.
So the important fact that my prior implementation did not handle above was the missing public key. I'm thinking we should not allow for this case, and attempt to tell the user to import the key (or prompt them to do so, or something). Regarding "Optional" signature level, if we find a sig, we should not proceed if we cannot verify.
As far as options go, here is what is likely worth providing: * Validity- nothing. The signature has to be good if it exists, nothing else is valid. * Trust- nix what we had before. I think just one coarse-grained option would be good here, and that is 'AlwaysTrustworthy' (naming suggestions welcome if that isn't clear, came from gpgv man page). This would replace the AllowMarginal/AllowUnknown options and basically cover the bases of both. With this option, we will trust every key *except* those marked "never trust"; without it the web of trust will kick in and the key will need to have a certain level of trust that way. This basically replicates what the stripped-down gpgv does. * Timeliness- I'm not totally sure what to do here. Maybe we shouldn't even worry about this yet, and go with reasonably sane defaults: - expired signature: don't allow. Since sigs have infinite lifetime by default, there is probably a good reason to not allow one that has gone sour. - expired key: allow it (as long as the above expired sig case doesn't apply too). Many keys are created with expiration dates, but this doesn't make valid signatures created with them immediately invalid. - revoked key: obviously don't allow it.
Thoughts? I'm just going to go ahead with this scheme unless I hear vastly different ideas on this.
-Dan
Sounds good; thank you very much for working on this.
-Kerrick Staley On Jul 28, 2011 4:53 PM, "Dan McGee" dpmcgee@gmail.com wrote:
So this is a bit messy. My last patch gets us close to what we need, but turns out, I didn't fully understand what the ramifications of my options were in the last patch here: http://mailman.archlinux.org/pipermail/pacman-dev/2011-July/013856.html
- The Package/Database/(implicit all) stuff is fine.
- The optional/required stuff is fine (for the most part).
- Not so great is the marginal and unknown OK stuff.
Basically, there are three facets to every signature that we can examine.
- Validity: Is this signature signing the data it says it is? This is
basically three-valued- good, bad, or unknown. In GPGME, the unknown case comes up if we don't have a copy of the public key in our keyring, for instance.
- Trust: Do we trust this key? Note that this is very different than
the above "is this signature valid" question. This brings in the whole web of trust business, the blackhole discussions regarding CACert, signing each other's keys, etc.
- "Timeliness" (not sure what to call it): aka is this signature
expired, key expired, or key revoked.
So the important fact that my prior implementation did not handle above was the missing public key. I'm thinking we should not allow for this case, and attempt to tell the user to import the key (or prompt them to do so, or something). Regarding "Optional" signature level, if we find a sig, we should not proceed if we cannot verify.
As far as options go, here is what is likely worth providing:
- Validity- nothing. The signature has to be good if it exists,
nothing else is valid.
- Trust- nix what we had before. I think just one coarse-grained
option would be good here, and that is 'AlwaysTrustworthy' (naming suggestions welcome if that isn't clear, came from gpgv man page). This would replace the AllowMarginal/AllowUnknown options and basically cover the bases of both. With this option, we will trust every key *except* those marked "never trust"; without it the web of trust will kick in and the key will need to have a certain level of trust that way. This basically replicates what the stripped-down gpgv does.
- Timeliness- I'm not totally sure what to do here. Maybe we shouldn't
even worry about this yet, and go with reasonably sane defaults:
- expired signature: don't allow. Since sigs have infinite lifetime
by default, there is probably a good reason to not allow one that has gone sour.
- expired key: allow it (as long as the above expired sig case
doesn't apply too). Many keys are created with expiration dates, but this doesn't make valid signatures created with them immediately invalid.
- revoked key: obviously don't allow it.
Thoughts? I'm just going to go ahead with this scheme unless I hear vastly different ideas on this.
-Dan
pacman-dev@lists.archlinux.org