releng/tickets

Fork 2

Replace clearsigned checksum files with detached signatures. #13177

New issue

Open

opened 2026-01-20 14:29:30 +00:00 by rombobeorn · 9 comments

rombobeorn commented

2026-01-20 14:29:30 +00:00

Describe the issue

For verifying downloaded ISO files and other installation images, the Fedora Project offers *-CHECKSUM files where a hash is signed with a so-called cleartext signature. These checksum files should be replaced with detached signatures.

Why cleartext signatures should not be used

It has long been known that cleartext signatures are full of pitfalls. They're called "clear" because you can read the text without running it through a crypto program first – but the text you see might not be the text that was actually signed. There are various ways to trick a non-expert or a script into accepting an unsigned piece of text as signed and trustworthy. Now https://gpg.fail/notsoclear adds to the pile, showing a way to construct a malicious text that looks virtually indistinguishable from a genuine clearsigned text even to an experienced user.

Verification of a cleartext signature must be done exactly right to be secure. The intuitive way is not the secure way. Pretty much everybody gets it wrong. And the secure way negates the cleartext aspect, making the whole clearsigning concept pointless.

Werner Koch also tells you to avoid cleartext signatures:
https://gnupg.org/blog/20251226-cleartext-signatures.html

Unnecessary complexity

A PGP signature is a signature of a hash of the data. The added sha256sum step makes it a signature of a hash of a hash of the ISO file. Double hashing is unnecessary. Users have to do two verification steps instead of one for no good reason.

What to do instead

Instead of hashing an ISO file and signing the hash, make a detached signature of the ISO file. Detached signatures are much easier to verify correctly. The basic command is:

gpg --detach-sign Fedora-Server-dvd-x86_64-43-1.6.iso

(Or use some equivalent Sequoia command.) Keep the same --keyring or --local-user or whatever options that are currently used to specify the signing key.

The verification instructions on the website will become simpler and safer. Instead of telling users to do

gpgv --keyring ./fedora.gpg --output - \
  Fedora-Server-43-1.6-x86_64-CHECKSUM \
  | sha256sum -c --ignore-missing

the website will tell them to do

gpgv --keyring=./fedora.gpg \
     Fedora-Server-dvd-x86_64-43-1.6.iso.sig \
     Fedora-Server-dvd-x86_64-43-1.6.iso

That's easier for the user, with much lower risk of getting it wrong in insecure ways.

It's acceptable to also present a hash value for users who want to disregard security but check for accidental file corruption. The hash should not be signed, because users who want security should verify the ISO file with the detached signature.

When do you need this?

Preferably next time some installation images are released. Would that be F44 beta? Otherwise, the next release after that, and so on.

When is this no longer needed or useful?

N/A

If we cannot complete this, what is the impact?

The Fedora Project continues to participate in the cargo cult of clearsigned checksum files. Verifying downloads continues to be unnecessarily difficult, which causes security risks for users.

Checklist

I have checked existing issues for duplicates
I have filled out all the fields above
I have provided relevant links or references (if applicable)

## Describe the issue For verifying downloaded ISO files and other installation images, the Fedora Project offers *-CHECKSUM files where a hash is signed with a so-called cleartext signature. These checksum files should be replaced with detached signatures. ### Why cleartext signatures should not be used It has long been known that cleartext signatures are full of pitfalls. They're called "clear" because you can read the text without running it through a crypto program first – but **the text you see might not be the text that was actually signed**. There are various ways to trick a non-expert or a script into accepting an unsigned piece of text as signed and trustworthy. Now https://gpg.fail/notsoclear adds to the pile, showing a way to construct a malicious text that looks virtually indistinguishable from a genuine clearsigned text even to an experienced user. Verification of a cleartext signature must be done exactly right to be secure. The intuitive way is not the secure way. Pretty much everybody gets it wrong. And the secure way negates the cleartext aspect, making the whole clearsigning concept pointless. Werner Koch also tells you to avoid cleartext signatures: https://gnupg.org/blog/20251226-cleartext-signatures.html ### Unnecessary complexity A PGP signature is a signature of a hash of the data. The added `sha256sum` step makes it a signature of a hash of a hash of the ISO file. Double hashing is unnecessary. Users have to do two verification steps instead of one for no good reason. ### What to do instead Instead of hashing an ISO file and signing the hash, make a detached signature of the ISO file. Detached signatures are much easier to verify correctly. The basic command is: ``` gpg --detach-sign Fedora-Server-dvd-x86_64-43-1.6.iso ``` (Or use some equivalent Sequoia command.) Keep the same `--keyring` or `--local-user` or whatever options that are currently used to specify the signing key. The verification instructions on the website will become simpler and safer. Instead of telling users to do ``` gpgv --keyring ./fedora.gpg --output - \ Fedora-Server-43-1.6-x86_64-CHECKSUM \ | sha256sum -c --ignore-missing ``` the website will tell them to do ``` gpgv --keyring=./fedora.gpg \ Fedora-Server-dvd-x86_64-43-1.6.iso.sig \ Fedora-Server-dvd-x86_64-43-1.6.iso ``` That's easier for the user, with much lower risk of getting it wrong in insecure ways. It's acceptable to also present a hash value for users who want to disregard security but check for accidental file corruption. The hash should not be signed, because users who want security should verify the ISO file with the detached signature. ## When do you need this? Preferably next time some installation images are released. Would that be F44 beta? Otherwise, the next release after that, and so on. ## When is this no longer needed or useful? N/A ## If we cannot complete this, what is the impact? The Fedora Project continues to participate in the cargo cult of clearsigned checksum files. Verifying downloads continues to be unnecessarily difficult, which causes security risks for users. --- ## Checklist - [x] I have checked existing issues for duplicates - [x] I have filled out all the fields above - [x] I have provided relevant links or references (if applicable)

ngompa commented

2026-01-20 14:35:35 +00:00

Member

I don't think there's anything wrong with also signing the CHECKSUM files. But yes, signing the actual images makes sense.

These should be relatively easy to do since Sigul is supposed to support detached signatures. I believe @jcline has this working with siguldry.

I don't think there's anything wrong with also signing the CHECKSUM files. But yes, signing the actual images makes sense. These should be relatively easy to do since Sigul is supposed to support detached signatures. I believe @jcline has this working with siguldry.

rombobeorn commented

2026-01-20 15:21:10 +00:00

Author

@ngompa wrote in #13177 (comment):

I don't think there's anything wrong with also signing the CHECKSUM files.

It's bad because it promotes the notion that all the cool kids do clearsigned checksum files. Everybody should stop clearsigning.

I suppose detached signatures of checksum files wouldn't hurt, but what would anyone use that for if there's a signature of the image file itself?

@ngompa wrote in https://forge.fedoraproject.org/releng/tickets/issues/13177#issuecomment-264600: > I don't think there's anything wrong with also signing the CHECKSUM files. It's bad because it promotes the notion that all the cool kids do clearsigned checksum files. Everybody should stop clearsigning. I suppose **detached** signatures of checksum files wouldn't hurt, but what would anyone use that for if there's a signature of the image file itself?

kevin commented

2026-01-21 00:56:54 +00:00

Owner

There's no need to wait for siguldry... sigul as it is supports it:

$ sigul sign-data --help
Usage: client.py sign-data [options] input_file

Create a detached signature

Options:
  -h, --help            show this help message and exit
  -o FILE, --output=FILE
                        Write output to this file
  -a, --armor           Enable GnuPG armoring of the result

We need to make sure there's no gotchas/investigate why this wasn't done a long time ago...

There's no need to wait for siguldry... sigul as it is supports it: ``` $ sigul sign-data --help Usage: client.py sign-data [options] input_file Create a detached signature Options: -h, --help show this help message and exit -o FILE, --output=FILE Write output to this file -a, --armor Enable GnuPG armoring of the result ``` We need to make sure there's no gotchas/investigate why this wasn't done a long time ago...

jcline commented

2026-01-21 18:49:49 +00:00

@kevin wrote in #13177 (comment):

There's no need to wait for siguldry... sigul as it is supports it:
$ sigul sign-data --help
Usage: client.py sign-data [options] input_file

Create a detached signature

Options:
  -h, --help            show this help message and exit
  -o FILE, --output=FILE
                        Write output to this file
  -a, --armor           Enable GnuPG armoring of the result
We need to make sure there's no gotchas/investigate why this wasn't done a long time ago...

Indeed, and it definitely works (see, for example, #13176). W just need to wire it up in robosignatory to happen automatically. I could probably slap something together if someone with write access to https://pagure.io/robosignatory/ is open to merge it.

@kevin wrote in https://forge.fedoraproject.org/releng/tickets/issues/13177#issuecomment-333709: > There's no need to wait for siguldry... sigul as it is supports it: > > ```text > $ sigul sign-data --help > Usage: client.py sign-data [options] input_file > > Create a detached signature > > Options: > -h, --help show this help message and exit > -o FILE, --output=FILE > Write output to this file > -a, --armor Enable GnuPG armoring of the result > ``` > > We need to make sure there's no gotchas/investigate why this wasn't done a long time ago... Indeed, and it definitely works (see, for example, https://forge.fedoraproject.org/releng/tickets/issues/13176). W just need to wire it up in robosignatory to happen automatically. I could probably slap something together if someone with write access to https://pagure.io/robosignatory/ is open to merge it.

kevin commented

2026-01-21 21:32:45 +00:00

Owner

Well, we currently do not autosign CHECKSUM files, we only sign them when there's going to be a release using them.

That uses this script:
https://forge.fedoraproject.org/releng/tooling/src/branch/main/release-process/staging/stage_release_checksum_sign.sh

My worry here is that sigul has to transfer the entire image over to generate the signature and thats a lot of data to sling around.

Well, we currently do not autosign CHECKSUM files, we only sign them when there's going to be a release using them. That uses this script: https://forge.fedoraproject.org/releng/tooling/src/branch/main/release-process/staging/stage_release_checksum_sign.sh My worry here is that sigul has to transfer the entire image over to generate the signature and thats a lot of data to sling around.

jcline commented

2026-01-21 22:17:01 +00:00

@kevin wrote in #13177 (comment):

Well, we currently do not autosign CHECKSUM files, we only sign them when there's going to be a release using them.

That uses this script: https://forge.fedoraproject.org/releng/tooling/src/branch/main/release-process/staging/stage_release_checksum_sign.sh

My worry here is that sigul has to transfer the entire image over to generate the signature and thats a lot of data to sling around.

Even easier, then. Yeah. It'll definitely be slow, but I didn't spot any obvious gotchas (it should stream the image to a temporary file and so on). I've got a CI setup for sigul so I can test it if you've not got an easy test environment available; obviously it'll all be local but that should give you an idea of how it'll perform.

FWIW I believe this won't be a problem with siguldry as I've implemented a PKCS11 module for siguldry that hashes the content client-side. It just sends the digest over the network, and in theory Sequoia is getting support for signing via PKCS11 so you'll be able to sign directly with the sq CLI.

@kevin wrote in https://forge.fedoraproject.org/releng/tickets/issues/13177#issuecomment-336794: > Well, we currently do not autosign CHECKSUM files, we only sign them when there's going to be a release using them. > > That uses this script: https://forge.fedoraproject.org/releng/tooling/src/branch/main/release-process/staging/stage_release_checksum_sign.sh > > My worry here is that sigul has to transfer the entire image over to generate the signature and thats a lot of data to sling around. Even easier, then. Yeah. It'll definitely be slow, but I didn't spot any obvious gotchas (it _should_ stream the image to a temporary file and so on). I've got a CI setup for sigul so I can test it if you've not got an easy test environment available; obviously it'll all be local but that should give you an idea of how it'll perform. FWIW I believe this won't be a problem with siguldry as I've implemented a PKCS11 module for siguldry that hashes the content client-side. It just sends the digest over the network, and in theory Sequoia is getting support for signing via PKCS11 so you'll be able to sign directly with the `sq` CLI.

kevin commented

2026-01-22 22:20:26 +00:00

Owner

If you have a setup easily able to test that would be great!

jcline commented

2026-01-23 16:39:56 +00:00

@kevin wrote in #13177 (comment):

If you have a setup easily able to test that would be great!

Okay, I wrote a quick test and checked this. You'll need to change the server configuration for max-file-payload-size (which is set in bytes and defaults to 1GB). It's horribly slow, a 4GB file took 284.295s, but the CI environment turns on debug level logs for the server and it definitely spent a large amount of effort writing logs.

@kevin wrote in https://forge.fedoraproject.org/releng/tickets/issues/13177#issuecomment-343064: > If you have a setup easily able to test that would be great! Okay, I wrote a quick test and checked this. You'll need to change the server configuration for `max-file-payload-size` (which is set in bytes and defaults to 1GB). It's horribly slow, a 4GB file took 284.295s, but the CI environment turns on debug level logs for the server and it definitely spent a large amount of effort writing logs.

kevin commented

2026-01-23 19:30:18 +00:00

Owner

Yeah, it's going to be slow and a compose has... a lot of large images, etc.

I guess the next test would be to test signing a large image in our infra and see how bad it is there.

@jnsamyak can you do that?

Yeah, it's going to be slow and a compose has... a lot of large images, etc. I guess the next test would be to test signing a large image in our infra and see how bad it is there. @jnsamyak can you do that?