reopen 825123 severity 825123 important thanks Hi Christoph
You were perfectly correct in your suspicion about my config file. I did have the hash algorithm specified there. I just did not know that myself... It was changed in 2014. I can not tell if I did that or some upgrade script. I really hope it was me. I had: cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed default-recipient-self keyserver pgpkeys.mit.edu personal-digest-preferences SHA256 default-key XXX I have checked and "personal-digest-preferences SHA256" is the one to use. cert-digest-algo and default-preference-list do not have an effect to this case. I several options here: 1) Document this clearly. I think I tend to prefer this alternative. 2) Use some option. I think --pgp7 could do the trick potentially. 3) Introduce some option to give the digest preference with default to SHA512 (and with the possibility to disable that gpg command preference). 4) Combination of 1 and 2. 5) Combination of 1 and 3. See further below. On Mon, Jun 6, 2016 at 11:44 PM, Christoph Anton Mitterer <[email protected]> wrote: ...CUT... >> 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). My test was flawed. See above. >> 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). Indeed it was. > 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)... I do not think they will change anytime soon unless a vast majority of other implementations change and have done that for a long while. See the phpN options for more details. > 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. Yes that would indeed be very tricky. I think it is better that people find this out by the fact that apt tools do not accept it. > 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'm not 100% sure either. I'm not even sure that apt do not accept SHA1 keys. What I do know is that apt check the signing key against the keyring. But default against the standard debian keyring and that keyring no longer have any SHA1 keys as all maintainers had to replace it with a 4096 key (I know as I was forced to do that myself). >> 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. Let it be important for now. > ...CUT... Best regards, // Ola -- --- Inguza Technology AB --- MSc in Information Technology ---- / [email protected] Folkebogatan 26 \ | [email protected] 654 68 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
