Bug 2022904 - GnuPG 2.3 crashes with --file-is-digest option
Summary: GnuPG 2.3 crashes with --file-is-digest option
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnupg2
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2025727 (view as bug list)
Depends On:
Blocks: 2024710
TreeView+ depends on / blocked
 
Reported: 2021-11-12 22:54 UTC by Oleg Girko
Modified: 2021-12-09 01:11 UTC (History)
6 users (show)

Fixed In Version: gnupg2-2.3.3-2.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2024710 (view as bug list)
Environment:
Last Closed: 2021-11-18 18:54:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Improved patch that fixes the problem (7.40 KB, patch)
2021-11-13 13:38 UTC, Oleg Girko
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-328 0 None None None 2021-11-12 22:56:22 UTC

Description Oleg Girko 2021-11-12 22:54:38 UTC
Description of problem:
GnuPG 2.3 shipped with Fedora 25 crashes when used with --file-is-digest option.

Version-Release number of selected component (if applicable):
2.3.3

How reproducible:
Always

Steps to Reproduce:
1. Run gpg with --file-is-digest option. For example, it's run this way from signd service.

Actual results:
Crash with the following error:
gpg: Ohhhh jeeee: Assertion "sig->version >= 4" in mk_notation_policy_etc failed (sign.c:89)

Expected results:
Normal functioning without crashes.

Additional info:
The problem is caused by applying gnupg-2.2.20-file-is-digest.patch patch that sets sig->version to 3 in write_signature_packets() function in g10/sign.c file if opt.file_is_digest is non-zero (--file-is-digest option option is set).

Version 3 sigs is deprecated long ago.
In GnuPG 2.2, mk_notation_policy_etc() function was called from write_signature_packets() if sig->version >= 4.
In GnuPG 2.3, it's called unconditionally.
And there is an assert in mk_notation_policy_etc() that requires sig->version >= 4.

Hence, setting sig->version to 3 is incorrect.

Comment 1 Oleg Girko 2021-11-13 01:30:25 UTC
I've built gnupg with the gnupg-2.2.20-file-is-digest.patch patch modified with the chunk setting sig->version to 3 in write_signature_packets() removed.

Now gpg with --file-is-digest option doesn't crash. However, packages signed with signd service look strange: "rpm --checksig -v" command on a package reports the following:

/var/lib/obs/repos/Fedora/35/noarch/build-compare-2019.02.19.git.3277313-1.fc35.1.noarch.rpm:
    Header V4 RSA/SHA256 Signature, key ID 46e6bab4: BAD
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V4 RSA/SHA256 Signature, key ID 46e6bab4: BAD
    MD5 digest: OK

Please note V4 RSA/SHA256 signatures that are marked as BAD.

For comparison, this is how a package signed on Fedora 34 with gpg 2.2 looks:

/var/lib/obs/repos/Fedora/35/noarch/build-compare-2019.02.19.git.3277313-1.fc35.6.noarch.rpm:
    Header V3 RSA/SHA256 Signature, key ID e3e15fa6: NOKEY
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V3 RSA/SHA256 Signature, key ID e3e15fa6: NOKEY
    MD5 digest: OK

Please note V3 RSA/SHA256 signatures that are marked as NOKEY.

And if I use sign on a text file and then try "gpg --verify" ob it, I get "BAD signature" error.
Looks like just simply removing setting sig->version to 3 in gnupg-2.2.20-file-is-digest.patch results in incorrect behaviour.
Unfortunately, I don't fully understand logic behind this patch, so may be somebody more proficient may help.

Comment 2 Oleg Girko 2021-11-13 13:38:06 UTC
Created attachment 1841547 [details]
Improved patch that fixes the problem

This patch is the replacement for gnupg-2.2.20-file-is-digest.patch that prevents gpg2 crash while still preserving correct behaviour when signing files with sign utility and signd service.

Comment 3 Oleg Girko 2021-11-13 13:38:51 UTC
OK, I've compared Fedora's file-is-digest patch, openSUSE's files-are-digests patch (yes, they have almost the same patch, but with different option's name) and changes between versions 2.2 and 2.3, and made a better patch that actually works. At least, RPM packages and text files signed using sign command have correct signatures:

/var/lib/obs/repos/Fedora/35/noarch/build-compare-2019.02.19.git.3277313-1.fc35.2.noarch.rpm:
    Заголовок V3 RSA/SHA256 Signature, key ID 46e6bab4: OK
    Заголовок SHA256 digest: OK
    Заголовок SHA1 digest: OK
    Payload SHA256 digest: OK
    V3 RSA/SHA256 Signature, key ID 46e6bab4: OK
    MD5 digest: OK

I've attached the patch to this bug report.

Comment 4 Oleg Girko 2021-11-13 13:41:14 UTC
For comparison, this is openSUSE's files-are-digests patch:
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2/gpg2/gnupg-2.0.18-files-are-digests.patch?expand=1

Comment 5 Jakub Jelen 2021-11-15 08:38:35 UTC
Thank you for the report.

Unfortunately, I do not have personally any use case for this commandline option so I do not know how to simply test it. Can you provide couple of commands that can verify its functionality so I can add it to our automated tests? Ideal would be full test for Fedora CI [1], but just couple of commands with wrong and expected outputs would do.

I adapted your patch for fedora in [2]. Can you also verify it solves the issue for you before I will push it to everyone?

[1] https://docs.fedoraproject.org/en-US/ci/
[2] https://src.fedoraproject.org/rpms/gnupg2/pull-request/12

Comment 6 Oleg Girko 2021-11-16 16:42:46 UTC
(In reply to Jakub Jelen from comment #5)
> Unfortunately, I do not have personally any use case for this commandline
> option so I do not know how to simply test it.

Yes, this option is not intended for use by regular users. Its main purpose is for signd service provided by obs-signd package. So, you can ask owners of this package to verify this fix.

> Can you provide couple of
> commands that can verify its functionality so I can add it to our automated tests?

So, as far as I understand, this patch allows to use file name instead of file contents to be used for signing.
Information needed for GnuPG to sign a file is the following:
* file contents,
* signature type (0 for detached signature),
* timestamp.

First, a SHA256 hash is computed of concatenation of the data listed above: file contents, signature type (zero byte), timestamp in binary format (4 bytes).
Then, a string containing concatenation of the following is used instead of filename: SHA256 hash, '@' sign, signature type in hex ("00"), timestamp in hex.
The file with this name is not required to exist, no attempt to open it is made. This digest argument is used *instead* of file name.

Hence, a script to sign and verify files using --file-is-digest option will look like this:

    for file do
      trailer_hex=$(printf 00%08x $(date +%s))
      hash=$( (cat "$file" && echo "$trailer_hex" | xxd -r -p) |
              sha256sum | awk '{print $1}' )
      gpg --batch --file-is-digest --digest-algo=SHA256 --sign  --detach-sign \
          --armor --output "$file.asc" "${hash}@${trailer_hex}"
      gpg --verify "$file.asc" "$file"
    done

The expected output should contain "Good signature" string (or equivalent for your locale).

Another way to test would be to actually set up signd service and sign some file using it.
To do this, you'll need a Fedora 35 system where you have root access. First, install obs-signd package, then follow these instructions:
https://en.opensuse.org/openSUSE:Build_Service_Signer

Of course, you'll need to slightly adjust these instructions to Fedora (like using systemctl to start signd service instead of openSUSE-specific commands).
Also, skip a step for adding DSA subkey (it's not just unnecessary, but causes wrong subkey to be used for sining). And you don't need to start obssigner service (you have no OBS installed).
Once you have signd configured and started, use the following commands to sign any file you like and then verify the signature:

    sign -d "$file"
    HOME=/root gpg --verify "$file.asc" "$file"

(where "$file" is the name of the file).

> Ideal would be full test for Fedora CI [1], but just couple of
> commands with wrong and expected outputs would do.

Unfortunately, I don't yet have Fedora packager rights (but working on this), and I'm not familiar with Fedora CI. I hope that commands I've provided above will be useful. For example, the first scriptlet can be adapted for %check section of the spec file.

> I adapted your patch for fedora in [2]. Can you also verify it solves the
> issue for you before I will push it to everyone?

If this patch is exactly the same as I've attached to this bug report, then it's already verified. I'm already using gnupg2 package with this patch to sign packages built by my test OBS server. I've actually verified that signatures generated by signd service are correct before attaching this patch to this bug report.

Comment 7 Oleg Girko 2021-11-16 22:27:57 UTC
(In reply to Oleg Girko from comment #6)
> Another way to test would be to actually set up signd service and sign some
> file using it.
> To do this, you'll need a Fedora 35 system where you have root access.
> First, install obs-signd package, then follow these instructions:
> https://en.opensuse.org/openSUSE:Build_Service_Signer

I forgot to mention one more important adjustment to these instructions: use --full-gen-key instead of --gen-key option to generate a new key. The new GnuPG 2.3 generates default key using ECC key type by default without asking questions.

Comment 8 Jakub Jelen 2021-11-18 17:42:38 UTC
Thanks. I managed to reproduce and verify the new version works as expected. I will update gnupg2 shortly (after rawhide will allow me to build a package).

Comment 9 Jakub Jelen 2021-11-18 18:54:13 UTC
Built in rawhide and in Fedora 35. Update is coming: https://bodhi.fedoraproject.org/updates/FEDORA-2021-45c44b31a2

Comment 10 Fedora Update System 2021-11-19 19:09:36 UTC
FEDORA-2021-45c44b31a2 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-45c44b31a2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-45c44b31a2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Pavel Raiskup 2021-11-24 07:14:19 UTC
*** Bug 2025727 has been marked as a duplicate of this bug. ***

Comment 12 Pavel Raiskup 2021-12-08 07:51:13 UTC
Can you manually push https://bodhi.fedoraproject.org/updates/FEDORA-2021-45c44b31a2 to stable please?

Comment 13 Jakub Jelen 2021-12-08 08:07:32 UTC
I would love to, but I no longer see the button to do that for some reason. I waived the tests, but that did not change anything. Asking on #fedora-devel and hopefully I will get some answers.

Comment 14 Fedora Update System 2021-12-09 01:11:21 UTC
FEDORA-2021-45c44b31a2 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.