Hey Ola. On Mon, 2016-06-06 at 23:28 +0200, Ola Lundqvist wrote: > Thank you for your report, and sorry for a late reply. No worries :)
> I have done some testing and the hash depends on the version of gpg > you have and what key you have generated. > > If you have at least the version of gpg in jessie (I tested on > jessie) > and a 4096 bit RSA key then the default hash is SHA256 which from > what Hmm I actually suspected that first, and created all new keys (upload and repo keys), RSA4096 primary for C only and another RSA4096 signing subkey (and all of the binding/user signatures with SHA256)... but it didn't help. The signatures on the repo files were still made with SHA1 (and I'm running on sid, with the gpg of that). > In addition to that the algorithm is configurable in > ~/.gnupg/gpg.conf > The statement to use is (without the quotes): > "personal-digest-preferences SHA256" > or whatever hash you would like to use. Hmm I think that's the reason why it worked for you (and I forgot about that). What I did, was making keys with SHA256,... but these aren't the digest preferences (and apparently gpg doesn't automatically set the digest- prefs of the key based on the algos used for it's creation). What you set above is exactly that,... i.e. what digest to use when signing content (not keys/UIDs), > Based on this I do not think this is a bug in at least jessie and > later and thus this should not be seen as a grave bug. Or for that > matter a bug at all in current stable and later. Therefore I'm > closing > this bug now. I'd agree,.. but I think it would be worth to EITHER include the above in the documentation of debarchiver (since it will probably take some time until gpg changes its default to >SHA1)... OR, one could possibly make a check for debarchiver, to see whether something better than SHA1 was already used and (*only*) if not, set that manually when signing. But such a check would be actually a bit tricky, because it would need to find out which UserID is actually used for signing, and check the preferences of that. TBH, I'm not sure whether apt even just checks for the signature algo strength of the actual data signature (i.e. Release file, etc.) or whether it also checks for the UID/subkey binding signtures on the key. > I could probably accept that is a documentation bug for an upgrade > case, or that it should be clarified that 4096 bit keys should be > used > when signing the archive. If you think I should document this better, > please re-open the bug with a non-grave severity. I'd probably tend to call it a documentation wishlist/improvement idea... but I have no strong opinion. > For wheezy this is a bug, but I do not think it is severe enough to > issue a DLA. If you object I'm happy to help out with that (I happen > to know that drill :-) ). No that's fine :) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
