Avoid RSA-SHA1 in self-tests

[jas4711]

Hi. In Debian we ship both https://github.com/digitorus/pkcs7 and https://github.com/fullsailor/pkcs7 and neither seems maintained any more, so I'm considering exploring if your project may serve as a replacement. However all these forks suffer from self-test failures because they use RSA-SHA1 signatures in example certificates:

    sign_test.go:130: test SHA1-RSA/SHA1-RSA/SHA1-RSA: cannot add signer: pkcs7: certificate signature from parent is invalid: x509: cannot verify signature: insecure algori
thm SHA1-RSA
--- FAIL: TestSign (0.00s)

Can you fix these problems in your fork?

Do you have any general thoughts around using your project as a replacement for the other forks? Are there are any known incompatibilities between them which may bite Debian?

/Simon

[jas4711]

A patch that SKIP the relevant self-tests that trigger RSA-SHA1 signatures is here:

https://salsa.debian.org/jas/golang-github-smallstep-pkcs7/-/blob/debian/sid/debian/patches/skip-rsa-sha1-tests.patch?ref_type=heads

[hslatman]

Hey @jas4711,

Yeah, I've seen those SHA1 failures happen too, but we've been working around that with the GODEBUG=x509sha1 environment variable so far. With Go 1.24 this option is no longer there, so it causes issues. I think we'll need to split some test cases to only run on older Go versions, and need some new test fixtures using SHA256 replacing the old certificates. I haven't checked how many would fail, and whether they're from an external source meant to do some specific "integration testing", so it might take some work to ensure proper coverage.

Somewhat related, we're tracking a future v2 with potential breaking changes in #31.

W.r.t. our fork replacing https://github.com/digitorus/pkcs7 or https://github.com/fullsailor/pkcs7: you can definitely use our fork instead of the latter, as our fork is based on https://github.com/mozilla-services/pkcs7, which is itself an (unmaintained) fork of the fullsailor one. We've pulled in some changes from open PRs on the fullsailor repo, amongst others. I'm aware of digitorus/pkcs7, which is also a fork from the mozilla-services one, but I haven't gone through its history to be able to say if it's better than our current one or not. I can tell that it's not being updated as frequently as ours, but that doesn't tell the whole story. I would say we're open to include changes that are available in digitorus/pkcs7 if there's a need for them.

[cedws]

Will this library support SHA1 signature verification going forward? I realise that support for it has been removed from stdlib, but they seem to have forgotten that some of us don't get to choose the algo and need to support existing systems outside our control...

[jas4711]

Will this library support SHA1 signature verification going forward? I realise that support for it has been removed from stdlib, but they seem to have forgotten that some of us don't get to choose the algo and need to support existing systems outside our control...

Is verification of RSA-SHA1 really removed from Go stdlib? That seems a bit silly since implementation of a RSA-SHA1 verify operation is useful even when that algorithm is completely insecure (which practically it already is). Of course, people need to be careful to not trust it for anything security relevant, which is probably where things get complicated if it is supported by default.

For as long pre-Go1.24 is supported, I think one way forward is to make the support conditional: if stdlib provides RSA-SHA1 use it, otherwise don't use it. Self-checks shouldn't fail on this with Go 1.24.

However maybe that is just complexity for little gain. I could sympathize with removing the functionality completely. People shouldn't depend on it for secure operations -- RSA-SHA1 should have died many years ago.

[jas4711]

W.r.t. our fork replacing https://github.com/digitorus/pkcs7 or https://github.com/fullsailor/pkcs7: you can definitely use our fork instead of the latter, as our fork is based on https://github.com/mozilla-services/pkcs7, which is itself an (unmaintained) fork of the fullsailor one. We've pulled in some changes from open PRs on the fullsailor repo, amongst others. I'm aware of digitorus/pkcs7, which is also a fork from the mozilla-services one, but I haven't gone through its history to be able to say if it's better than our current one or not. I can tell that it's not being updated as frequently as ours, but that doesn't tell the whole story. I would say we're open to include changes that are available in digitorus/pkcs7 if there's a need for them.

Thanks for support!

Now your package is in Debian and will hopefully be in trixie: https://tracker.debian.org/pkg/golang-github-smallstep-pkcs7

However we didn't manage to migrate the dependencies to use it, so unfortunately we will also ship https://github.com/digitorus/pkcs7 and https://github.com/fullsailor/pkcs7 too. Here is the current dependency structure in Debian trixie, subject to change before release, which is simulated by attempting to removing each package and getting errors:

Checking reverse dependencies...
# Broken Depends:
golang-github-containers-ocicrypt: golang-github-containers-ocicrypt-dev
golang-github-smallstep-certificates: golang-github-smallstep-certificates-dev

# Broken Build-Depends:
gitlab-ci-multi-runner: golang-github-fullsailor-pkcs7-dev
golang-github-containers-image: golang-github-fullsailor-pkcs7-dev
golang-github-containers-ocicrypt: golang-github-fullsailor-pkcs7-dev
golang-github-foxboron-go-uefi: golang-github-fullsailor-pkcs7-dev
golang-github-smallstep-certificates: golang-github-fullsailor-pkcs7-dev
podman: golang-github-fullsailor-pkcs7-dev

Checking reverse dependencies...
# Broken Depends:
golang-github-digitorus-timestamp: golang-github-digitorus-timestamp-dev
golang-github-sigstore-timestamp-authority: golang-github-sigstore-timestamp-authority-dev
sigstore-go: golang-github-sigstore-sigstore-go-dev

# Broken Build-Depends:
golang-github-digitorus-timestamp: golang-github-digitorus-pkcs7-dev
golang-github-sigstore-timestamp-authority: golang-github-digitorus-pkcs7-dev

Checking reverse dependencies...
# Broken Depends:
golang-github-smallstep-scep: golang-github-smallstep-scep-dev

# Broken Build-Depends:
golang-github-smallstep-scep: golang-github-smallstep-pkcs7-dev

[cedws]

People shouldn't depend on it for secure operations -- RSA-SHA1 should have died many years ago.

I don't want to start a debate because this isn't the place, but if you are integrating with another system you have no influence over, verifying a SHA1 signature is better than verifying no signature. Since Go has dropped SHA1 support in cert verification, I'm being forced into the latter, which is a downgrade in security.

SHA1 is still robust enough to protect from all but the most sophisticated and resourced attacks.

I understand this was done to nudge people in the right direction, but it's a very idealistic world view that suddenly all systems are going to be upgraded to modern crypto and we'll never need SHA1 signatures again.