Hi, I just learn the hard way that gnupg2 had this change;
--force-v3-sigs --no-force-v3-sigs --force-v4-certs --no-force-v4-certs These options are obsolete and have no effect since GnuPG 2.1.
The problem is that these options are used by signd perl script from obs-signd. Those options are silently ignored now. However, when --files-are-digest is then used it errors with: "files-are-digests doesn't work with v4 sigs"
Latest working gpg is 2.0.x. If you have your own instance of OBS be careful when upgrading to not upgrade gpg2.
Does anybody started investigating or even writing support for files-are-digest for v4 sigs?
Dne 20.1.2016 v 13:59 Miroslav Suchý napsal(a):
Does anybody started investigating or even writing support for files-are-digest for v4 sigs?
Michal Novotny from my team will work this week on this issue and hopefully we will have patch for obs-sign soon.
On Mon, Feb 01, 2016 at 11:41:47AM +0100, Miroslav Suchý wrote:
Dne 20.1.2016 v 13:59 Miroslav Suchý napsal(a):
Does anybody started investigating or even writing support for files-are-digest for v4 sigs?
Michal Novotny from my team will work this week on this issue and hopefully we will have patch for obs-sign soon.
I can do this as well if you guys need it. But what's wrong with v3 signatures? We do v3 because old rpm versions don't understand v4, why do you need v4 sigs?
Cheers, Michael.
Dne 2.2.2016 v 10:45 Michael Schroeder napsal(a):
I can do this as well if you guys need it. But what's wrong with v3 signatures? We do v3 because old rpm versions don't understand v4, why do you need v4 sigs?
Because as I stated in original email - recent version of gnupg removed v2 support. The options are still there, but are silently ignored and gnupg create v4 signature.
Which version of rpm cannot handle v4 sigs?
Mirek
On Tue, Feb 02, 2016 at 11:11:53AM +0100, Miroslav Suchy wrote:
Dne 2.2.2016 v 10:45 Michael Schroeder napsal(a):
I can do this as well if you guys need it. But what's wrong with v3 signatures? We do v3 because old rpm versions don't understand v4, why do you need v4 sigs?
Because as I stated in original email - recent version of gnupg removed v2 support. The options are still there, but are silently ignored and gnupg create v4 signature.
Well, the easiest way is to just use V3 if files_are_digests is used. I.e. force sig->version to 3 in gpg's write_signature_packets() function.
We can also work around this in the sign binary, but adapting the files_are_digest patch is probably the easiest way.
Which version of rpm cannot handle v4 sigs?
I think the code was fixed in 2005. Dunno what version that was.
Cheers, Michael.
Dne 2.2.2016 v 12:00 Michael Schroeder napsal(a):
Well, the easiest way is to just use V3 if files_are_digests is used. I.e. force sig->version to 3 in gpg's write_signature_packets() function.
But the code is not there anymore. See "Removal of PGP-2 support": https://www.gnupg.org/faq/whats-new-in-2.1.html and the actual code of pgp2. While it is technically possible to return the code back to gpg2 and maintain it as part of files_are_digest patch, it would mean that the patch will be much bigger -> much harder to maintain.
I think the code was fixed in 2005. Dunno what version that was.
I investigated it a little bit and RHEL5 (rpm-4.4.2.3) and older are unable to work with v4, while RHEL6+ (rpm-4.8.0) can work with v4 signs. IIRC the SLES 12 use rpm-4.11.2 and SLES 11 use rpm-4.4.2.3. So until RHEL5 is outdated (31 March 2017) and SLES 11 is outdated (31 Mar 2019) we need to use v3 signs.
It makes sense to me start working on v4 support so we have some time for testing. And hopefully support v3 and v4 in parallel and in 3 years move to v4 only.
If you Michael can rebase files_are_digest to gnupg2 and return there v3 support then it would be awesome. In the mean time we will continue working on v4 support.
Mirek
On Tue, Feb 02, 2016 at 01:23:05PM +0100, Miroslav Suchy wrote:
Dne 2.2.2016 v 12:00 Michael Schroeder napsal(a):
Well, the easiest way is to just use V3 if files_are_digests is used. I.e. force sig->version to 3 in gpg's write_signature_packets() function.
But the code is not there anymore. See "Removal of PGP-2 support": https://www.gnupg.org/faq/whats-new-in-2.1.html and the actual code of pgp2.
What code is no more? gnupg-2.1.10 still has a write_signature_packets function AFAICS. You just need to change the code from
if (duration || opt.sig_policy_url || opt.sig_notations || opt.sig_keyserver_url) sig->version = 4; else sig->version = pk->version;
to
if (duration || opt.sig_policy_url || opt.sig_notations || opt.sig_keyserver_url) sig->version = 4; else if (opt.files_are_digests) sig->version = 3; else sig->version = pk->version;
Untested, though. Maybe duration is set, in that case you need to move the opt.files_are_digests check.
I investigated it a little bit and RHEL5 (rpm-4.4.2.3) and older are unable to work with v4, while RHEL6+ (rpm-4.8.0) can work with v4 signs. IIRC the SLES 12 use rpm-4.11.2 and SLES 11 use rpm-4.4.2.3. So until RHEL5 is outdated (31 March 2017) and SLES 11 is outdated (31 Mar 2019) we need to use v3 signs.
Yes, seems like there were some problems with 2048/4096 bits and v4 sigs (https://bugzilla.redhat.com/show_bug.cgi?id=436812). So yes, rpm-4.8 should be ok for v4 sigs.
Cheers, Michael.
Dne 2.2.2016 v 13:46 Michael Schroeder napsal(a):
What code is no more? gnupg-2.1.10 still has a write_signature_packets function AFAICS.
It is there, but other functions which this one call and to which is version of signature passed, are cut of. E.g. compare:
gnupg 2.0: static void hash_sigversion_to_magic (gcry_md_hd_t md, const PKT_signature *sig) { if (sig->version >= 4) gcry_md_putc (md, sig->version); gcry_md_putc (md, sig->sig_class); if (sig->version < 4) { u32 a = sig->timestamp; gcry_md_putc (md, (a >> 24) & 0xff ); gcry_md_putc (md, (a >> 16) & 0xff ); gcry_md_putc (md, (a >> 8) & 0xff ); gcry_md_putc (md, a & 0xff ); } ...
gnupg 2.1: static void hash_sigversion_to_magic (gcry_md_hd_t md, const PKT_signature *sig) { byte buf[6]; size_t n;
gcry_md_putc (md, sig->version); gcry_md_putc (md, sig->sig_class); gcry_md_putc (md, sig->pubkey_algo); gcry_md_putc (md, sig->digest_algo); ....
An if you grep the old code for 'sig->version < 4' then you will find lots of part, which are there and which are missing in the new code. Yes, I did not tested it, but IMHO the format is so different that it cannot work when you just change the version number.
Mirek
On Tue, Feb 02, 2016 at 08:14:46PM +0100, Miroslav Suchy wrote:
Dne 2.2.2016 v 13:46 Michael Schroeder napsal(a):
What code is no more? gnupg-2.1.10 still has a write_signature_packets function AFAICS.
It is there, but other functions which this one call and to which is version of signature passed, are cut of. E.g. compare:
gnupg 2.0: static void hash_sigversion_to_magic (gcry_md_hd_t md, const PKT_signature *sig) { if (sig->version >= 4) gcry_md_putc (md, sig->version); gcry_md_putc (md, sig->sig_class); if (sig->version < 4) { u32 a = sig->timestamp; gcry_md_putc (md, (a >> 24) & 0xff ); gcry_md_putc (md, (a >> 16) & 0xff ); gcry_md_putc (md, (a >> 8) & 0xff ); gcry_md_putc (md, a & 0xff ); } ...
gnupg 2.1: static void hash_sigversion_to_magic (gcry_md_hd_t md, const PKT_signature *sig) { byte buf[6]; size_t n;
gcry_md_putc (md, sig->version); gcry_md_putc (md, sig->sig_class); gcry_md_putc (md, sig->pubkey_algo); gcry_md_putc (md, sig->digest_algo); ....
An if you grep the old code for 'sig->version < 4' then you will find lots of part, which are there and which are missing in the new code. Yes, I did not tested it, but IMHO the format is so different that it cannot work when you just change the version number.
Well, hash_sigversion_to_magic mustn't get called for files_are_digest anyway, as we already provide the "final" hash.
(And I wonder the upstream did the correct thing when they changed hash_sigversion_to_magic. If you have a v3 pubkey, the code seems to still set sig->version to 3, which will result in a broken signature.)
Cheers, Michael.
Dne 2.2.2016 v 13:46 Michael Schroeder napsal(a):
else if (opt.files_are_digests) sig->version = 3; else
Michal Novotny tested that and it really work. So this is sufficient for now. He continues investigating options to generate real v4 sigs though.
buildservice@lists.opensuse.org
-
Michael Schroeder -
Miroslav Suchy -
Miroslav Suchý