un-trusting MD5 in gpg

[Daniel Kahn Gillmor]

On 05/06/2009 03:42 PM, David Shaw wrote:
> I like this basic idea (though don't like the name "weak" for reasons I
> mentioned earlier).  The analogy to personal-digest-preferences is a
> good one: this is the personal-digest-anti-preferences.  Instead of the
> algorithms the user likes and wants to use when possible, these are the
> algorithms the user dislikes and won't accept.

--unacceptable-digest-algos maybe?  Your point about "weak" is a good
one, i think.  i was unaware that WEAK_KEY had a specific technical meaning.

Or what if we framed the option the other way: --acceptable-digest-algos
(and it would default to the full set)?

> We can't really do that because the meaning of personal-xxx-prefs is "I
> like these best", not "I will only accept these".  People tend to do
> stuff like "personal-digest-prefs sha256" to favor sha-256, which would
> immediately lock out every other hash.

yeah, that's what i meant by "modifies the semantics of --p-d-p"  that'd
be a Bad Thing.	  I just wanted to raise the idea, though.  If we were
designing gpg from scratch today with no installed userbase, i'd push
hard to have it work like this, just for the sake of minimizing the
configuration space and presenting a simpler interface.  Having the two
options allows for some weird (and unnecessary) configurations, like:

 --unacceptable-digest-algos MD5 --personal-digest-preferences MD5

wherein you would only make signatures that you would never believe were
valid.  The answer of course, is Don't Do This, but it's unfortunate to
give the user that much rope.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090506/d9d2cfa9/attachment.pgp>