Defaults to SHA256

[xsuchy]

Default hashalgo is SHA1
https://github.com/openSUSE/obs-sign/blob/master/sign.c#L50

It can be changed to SHA256 using -h. What about setting the default to SHA256?

If you agree I can prepare PR.

[Conan-Kudo]

I think this makes sense, but wow this is going to have some serious ramifications for OBS and Copr systems.

@mlschroe, is there a way to trigger resigning of all packages and repositories in a private OBS instance?

@xsuchy, is there a way to do this with COPR instances?

[xsuchy]

@xsuchy, is there a way to do this with COPR instances?

https://pagure.io/copr/copr/issue/2106

[xsuchy]

I do not think [*] we need to re-sign everything. IMHO it is fine to have some packages signed with SHA1 and some with SHA256 in the same repo.

[*] I really want to verify this.

[adrianschroeter]

sign must not behave incompatible (and it would also break when using dsa), so please set a new default in the calling code (like bs_signer) instead.

[mlschroe]

There's actually a technical reason: old rpm versions only supported DSA with SHA1 hashes, so we can't change the default. (OBS knows the pubkey, so it checks the pubkey algorithm and calls sign with '-h sha256' for rsa.)

[xsuchy]

SHA1 (and sha256,sha384,sha512) are recognized since rpm-4.4.2 (including this release).Which has been already included in RHEL 5.0. And that version has been EOLed 5 years ago.
Do you know of any distribution still actively in use which is not capable of using SHA256 ?

FYI the relevant commit in rpm git is 1a42537124a5e6804821ddb17a63a0ee86724b5a

[mlschroe]

That's not what I wrote. The rpm crypto code (the nss glue code to be specific) does not support DSA with hashes other than sha1.

[mlschroe]

Panu once tried to fix it, but later had to revert it:

commit e2659684b4a7b4dd767093a7b6101461780bfd38
Author: Panu Matilainen <pmatilai@redhat.com>
Date:   Mon May 19 15:39:49 2014 +0300

    Revert back to DSA-1 only support for NSS
    
    - This essentially reverts commit fe5a1e5dfa93f15b7beda59e193832577143a4d9
      which apparently causes intermittent failures with DSA-1. Look at
      DSA-2 again on some sunnier day...

The sunnier day never came. On the bright side, digest_nss.c is gone since last year.

[xsuchy]

Now I am confused. From which version rpm supports SHA256?

[Conan-Kudo]

Based on what @mlschroe says here, RPM has supported it with crypto backends other than NSS. That means SUSE was fine, but Red Hat is not. RHEL 8 was the first RHEL version with RPM using non-NSS crypto backend (it uses OpenSSL). So for compatibility for everyone still using the broken (but now gone) NSS backend, we're stuck.

[praiskup]

What about Mageia?

[Conan-Kudo]

Mageia followed Fedora (its RPM package spec is derived from Fedora's), so it had the same problems until Mageia 7, where it switched to OpenSSL with RPM 4.14.

[Jakuje]

Who needs DSA in 2022? The DSA specification is broken for years so anyone depending on this broken algorithm should have rotated to something else.

[tabowling]

Hello OBS and SUSE friends! I thought I might add a little context to help as you consider this challenge.

Regarding RH signing with OpenSSL instead of NSS, I think (but am not an expert here) that is part of the effort for crypto consolidation to reduce the number of components to maintain and submit for the (very expensive) security certifications such as NIST/FIPS/CommonCriteria and similar.

We recently identified this as a problem with our own Leapp upgrades from RHEL 8 -> 9, where a SHA-1 signed package from COPR prevented the upgrade process. With RHEL 9, the default crypto policy will no longer permit usage of SHA-1 for reading/validating signatures. While setting it to the LEGACY crypto policy would enable it to work, it sets the system-wide behavior of not following security recommended practices. Some would argue that if signing with SHA-1, you might as well not sign at all. While that could be debated, RH encourages the most secure recommended practices as possible.

So, as you consider OBS as an important public build service and toolchain in the EL-clone/related ecosystem (Rocky, Alma, AmazonLinux), it may be worth considering the importance of building packages that will work, and be upgradeable, in those ecosystems.

Thank you and here are some related docs providing additional background.

• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#disabling-sha-1-by-customizing-a-system-wide-cryptographic-policy_using-the-system-wide-cryptographic-policies
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/9.0_release_notes/overview#overview-major-changes
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/considerations_in_adopting_rhel_9/assembly_security_considerations-in-adopting-rhel-9

[mlschroe]

OBS is not an issue here, it always uses sha256 for RSA keys.