Debian Patches
Status for gnupg2/2.2.46-2
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| freepg/0002-gpg-accept-subkeys-with-a-good-revocation-but-no-sel.patch | gpg: accept subkeys with a good revocation but no self-sig during import * g10/import.c (chk_self_sigs): Set the NODE_GOOD_SELFSIG flag when we encounter a valid revocation signature. This allows import of subkey revocation signatures, even in the absence of a corresponding subkey binding signature. -- This fixes the remaining test in import-incomplete.scm. |
Vincent Breitmoser <look@my.amazin.horse> | no | 2019-06-13 | ||
| freepg/0003-gpg-allow-import-of-previously-known-keys-even-witho.patch | gpg: allow import of previously known keys, even without UIDs * g10/import.c (import_one): Accept an incoming OpenPGP certificate that has no user id, as long as we already have a local variant of the cert that matches the primary key. -- This fixes two of the three broken tests in import-incomplete.scm. |
Vincent Breitmoser <look@my.amazin.horse> | no | 2019-06-13 | ||
| freepg/0004-tests-add-test-cases-for-import-without-uid.patch | tests: add test cases for import without uid This commit adds a test case that does the following, in order: - Import of a primary key plus user id - Check that import of a subkey works, without a user id present in the imported key - Check that import of a subkey revocation works, without a user id or subkey binding signature present in the imported key - Check that import of a primary key revocation works, without a user id present in the imported key -- Note that this test currently fails. The following changesets will fix gpg so that the tests pass. |
Vincent Breitmoser <look@my.amazin.horse> | no | 2019-06-13 | ||
| freepg/0005-gpg-drop-import-clean-from-default-keyserver-import-.patch | gpg: drop import-clean from default keyserver import options * g10/gpg.c (main): drop IMPORT_CLEAN from the default opt.keyserver_options.import_options Given that SELF_SIGS_ONLY is already set, it's not clear what additional benefit IMPORT_CLEAN provides. Furthermore, IMPORT_CLEAN means that receiving an OpenPGP certificate from a keyserver will potentially delete data that is otherwise held in the local keyring, which is surprising to users who expect retrieval from the keyservers to be purely additive. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2019-07-15 | ||
| freepg/0006-Do-not-use-OCB-mode-even-if-AEAD-OCB-key-preference-.patch | Do not use OCB mode even if AEAD: OCB key preference is set. (overrideable with --force-ocb) |
Andreas Metzler <ametzler@debian.org> | not-needed | vendor | 2024-05-09 | |
| freepg/0007-Do-not-set-AEAD-OCB-key-preference-on-new-keys.patch | Do not set AEAD: OCB key preference on new keys. | Andreas Metzler <ametzler@debian.org> | not-needed | vendor | 2024-05-09 | |
| freepg/0011-gpg-default-to-3072-bit-keys.patch | gpg: default to 3072-bit keys. * agent/command.c (hlp_genkey): update help text to suggest the use of 3072 bits. * doc/wks.texi: Make example match default generation. * g10/keygen.c (gen_elg): update default from 2048 to 3072. * g10/keyid.c (pubkey_string): update comment so that first example is the default 3072-bit RSA. -- 3072-bit RSA, DSA, and El Gamal is widely considered to be 128-bit-equivalent security. This update adjusts the documentation to reflect the 3072-bit default, and makes El Gamal keys also default to 3072 bits. (cherry picked from commit 909fbca19678e6e36968607e8a2348381da39d8c) |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2017-09-07 | ||
| freepg/0012-gpg-default-digest-algorithm-SHA512.patch | gpg: Always support and default to using SHA-512. * g10/main.h (DEFAULT_DIGEST_ALGO): Use SHA512 instead of SHA256 in standard modes. Use SHA256 for PGP8, and SHA1 for archaic modes. * configure.ac: Do not allow disabling sha512. * g10/misc.c (map_md_openpgp_to_gcry): Always support SHA512. -- SHA512 is more performant on most 64-bit platforms than SHA256, and offers a better security margin. It is also widely implemented. RFC 4880 specifies SHA512, and any 4880-compatible client in the last 10 years supports it. According to doc/gpg.texi, PGP 8 supports SHA256. There's no clear reason to default to SHA1 for compatibility with those clients. (RFC 2440 and PGP7 don't support SHA256, so leave that alone) |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2025-02-05 | ||
| freepg/0013-gpg-Prefer-SHA-512-and-SHA-384-in-personal-digest.patch | gpg: Prefer SHA-512 and SHA-384 in personal-digest-preferences. * g10/keygen.c (keygen_set_std_prefs): prefer SHA-512 and SHA-384 by default. -- In 8ede3ae29a39641a2f98ad9a4cf61ea99085a892, upstream changed the defaults for --default-preference-list to advertise a preference for SHA-512, without touching --personal-digest-preferences. This makes the same change for --personal-digest-preferences, since every modern OpenPGP library supports them all. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2018-01-03 | ||
| freepg/0014-gpg-default-to-AES-256.patch | gpg: default to AES-256. * g10/main.h (DEFAULT_CIPHER_ALGO): Prefer AES256 by default. -- It's 2017, and pretty much everyone has AES-256 available. Symmetric crypto is also rarely the bottleneck (asymmetric crypto is much more expensive). AES-256 provides some level of protection against large-scale decryption efforts, and longer key lengths provide a hedge against unforseen cryptanalysis. (cherry picked from commit 73ff075204df09db5248170a049f06498cdbb7aa) |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2017-09-07 | ||
| freepg/0015-gpg-Report-BEGIN_-status-before-examining-the-input.patch | [PATCH] gpg: Report BEGIN_* status before examining the input. * common/miscellaneous.c (is_openpgp_compressed_packet) (is_file_compressed): Moved to ... * common/iobuf.c: ... in this file. (is_file_compressed): Change the argument to INP, the iobuf. * common/util.h (is_file_compressed): Remove. * common/iobuf.h (is_file_compressed): Add. * g10/cipher-aead.c (write_header): Don't call write_status_printf here. (cipher_filter_aead): Call write_status_printf when called with IOBUFCTRL_INIT. * g10/cipher-cfb.c (write_header): Don't call write_status_printf here. (cipher_filter_cfb): Call write_status_printf when called with IOBUFCTRL_INIT. * g10/encrypt.c (encrypt_simple): Use new is_file_compressed function, after call of iobuf_push_filter. (encrypt_crypt): Likewise. * g10/sign.c (sign_file): Likewise. -- |
NIIBE Yutaka <gniibe@fsij.org> | no | 2023-05-24 | ||
| freepg/0016-gpg-Do-not-fail-with-an-error-for-a-Note-diagnostic.patch | [PATCH] gpg: Do not fail with an error for a "Note:" diagnostic From 48aa9e82657902ceb7ef081c6c55adbea5dd0217 Mon Sep 17 00:00:00 2001 * g10/trustdb.c (validate_keys): Use log_info instead of log_error for not found or expired UTKs. -- Actually the not-found case used log_error for decades. The semantically simialr expired case did thus the same. The actual problem is for example in the import case where gpg exits with a failure despite that a key validation was requested. |
Werner Koch <wk@gnupg.org> | yes | debian upstream | 2024-10-30 | |
| freepg/0017-Ship-dutch-translation-po-nl.po-in-tarball.patch | Ship dutch translation (po/nl.po) 8a9d4b55b09d04482b46055f0a60f01b86738df3 imported the nl.po file from the 2.0 branch, but it is not being shipped in any of the tarballs built as a result of make dist, even though all the other po/*.po files are shipped. This has already been corrected in 2.4, but was ignored for 2.2. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2024-05-15 | ||
| freepg/0018-Avoid-simple-memory-dumps-via-ptrace.patch | Avoid simple memory dumps via ptrace This avoids needing to setgid gpg-agent. It probably doesn't defend against all possible attacks, but it defends against one specific (and easy) one. If there are other protections we should do them too. This will make it slightly harder to debug the agent because the normal user won't be able to attach gdb to it directly while it runs. The remaining options for debugging are: * launch the agent from gdb directly * connect gdb to a running agent as the superuser Upstream bug: https://dev.gnupg.org/T1211 |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2015-08-11 | ||
| freepg/0019-Disallow-compressed-signatures-and-certificates.patch | Disallow compressed signatures and certificates Compressed packets have significant attack surface, both due to the potential for denial of service (zip bombs and the like) and for code execution via memory corruption vulnerabilities in the decompressor. Furthermore, I am not aware of any implementation that uses them in keys or detached signatures. Therefore, disallow their use in such contexts entirely. When parsing detached signatures, forbid any packet that is not a signature or marker packet. When parsing keys, return an error when encountering a compressed packet, instead of decompressing the packet. Furthermore, certificates, keys, and signatures are not allowed to contain partial-length or indeterminate-length packets. Reject those in parse_packet, rather than activating the partial-length filter code. |
Demi Marie Obenour <demi@invisiblethingslab.com> | no | 2022-06-29 | ||
| freepg/0020-ssh-agent-emulation-under-systemd-inject-SSH_AUTH_SO.patch | [PATCH] ssh-agent emulation under systemd: inject SSH_AUTH_SOCK at socket start/stop If enable-ssh-support is set, we want the user's system environment to know about the agent's socket. By injecting it into the systemd session manager's user environment when the socket is first opened: - The lifetime of SSH_AUTH_SOCK is tied to the lifetime of the service. - The variable is set in a user-visible file. - It is easier to customize the socket variable, for instance for running multiple ssh-agent or testing purpuse. |
Richard Hansen <rhansen@rhansen.org> (gate on enable-ssh-agent config) | no | 2025-01-30 | ||
| debian-packaging/avoid-beta-warning.patch | avoid-beta-warning avoid self-describing as a beta Using autoreconf against the source as distributed in tarball form invariably results in a package that thinks it's a "beta" package, which produces the "THIS IS A DEVELOPMENT VERSION" warning string. since we use dh_autoreconf, i need this patch to avoid producing builds that announce themselves as DEVELOPMENT VERSIONs. See discussion at: http://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029065.html |
Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org> | no | 2015-04-14 | ||
| debian-packaging/avoid-regenerating-defsincdate-use-shipped-file.patch | avoid regenerating defsincdate (use shipped file) upstream ships doc/defsincdate in its tarballs. but doc/Makefile.am tries to rewrite doc/defsincdate if it notices that any of the files have been modified more recently, and it does so assuming that we're running from a git repo. However, we'd rather ship the documents cleanly without regenerating defsincdate -- we don't have a git repo available (debian builds from upstream tarballs) and any changes to the texinfo files (e.g. from debian/patches/) might result in different dates on the files than we expect after they're applied by dpkg or quilt or whatever, which makes the datestamp unreproducible. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-08-29 | ||
| dirmngr-idling/dirmngr-hkp-Avoid-potential-race-condition-when-some.patch | dirmngr: hkp: Avoid potential race condition when some hosts die. * dirmngr/ks-engine-hkp.c (select_random_host): Use atomic pass through the host table instead of risking out-of-bounds write. -- Multiple threads may write to hosttable[x]->dead while select_random_host() is running. For example, a housekeeping thread might clear the ->dead bit on some entries, or another connection to dirmngr might manually mark a host as alive. If one or more hosts are resurrected between the two loops over a given table in select_random_host(), then the allocation of tbl might not be large enough, resulting in a write past the end of tbl on the second loop. This change collapses the two loops into a single loop to avoid this As Werner points out, this isn't currently strictly necessary, since npth will not switch threads unless a blocking system call is made, and no blocking system call is made in these two loops. However, in a subsequent change in this series, we will call a function in this loop, and that function may sometimes write(2), or call other functions, which may themselves block. Keeping this as a single-pass loop avoids the need to keep track of what might block and what might not. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-10-29 | ||
| dirmngr-idling/dirmngr-Avoid-need-for-hkp-housekeeping.patch | dirmngr: Avoid need for hkp housekeeping. * dirmngr/ks-engine-hkp.c (host_is_alive): New function. Test whether host is alive and resurrects it if it has been dead long enough. (select_random_host, map_host, ks_hkp_mark_host): Use host_is_alive instead of testing hostinfo_t->dead directly. (ks_hkp_housekeeping): Remove function, no longer needed. * dirmngr/dirmngr.c (housekeeping_thread): Remove call to ks_hkp_housekeeping. -- Rather than resurrecting hosts upon scheduled resurrection times, test whether hosts should be resurrected as they're inspected for being dead. This removes the need for explicit housekeeping, and makes host resurrections happen "just in time", rather than being clustered on HOUSEKEEPING_INTERVAL seconds. According to 392e068e9f143d41f6350345619543cbcd47380f, dns_stuff_housekeeping only works on Windows, so it also isn't necessary in debian, but it remains in place for now. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-10-29 | ||
| dirmngr-idling/dirmngr-Avoid-automatically-checking-upstream-swdb.patch | dirmngr: Avoid automatically checking upstream swdb. * dirmngr/dirmngr.c (housekeeping_thread): Avoid automatically checking upstream's software database. In Debian, software updates should be handled by the distro mechanism, and additional upstream checks only confuse the user. * doc/dirmngr.texi: document that --allow-version-check does nothing. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-11-20 | ||
| gpg-agent-idling/agent-Create-framework-of-scheduled-timers.patch | agent: Create framework of scheduled timers. agent/gpg-agent.c (handle_tick): Remove intermittent call to check_own_socket. (tv_is_set): Add inline helper function for readability. (handle_connections) Create general table of pending scheduled timeouts. -- handle_tick() does fine-grained, rapid activity. check_own_socket() is supposed to happen at a different interval. Mixing the two of them makes it a requirement that one interval be a multiple of the other, which isn't ideal if there are different delay strategies that we might want in the future. Creating an extensible regular timer framework in handle_connections should make it possible to have any number of cadenced timers fire regularly, without requiring that they happen in cadences related to each other. It should also make it possible to dynamically change the cadence of any regularly-scheduled timeout. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-10-31 | ||
| gpg-agent-idling/agent-Allow-threads-to-interrupt-main-select-loop-wi.patch | agent: Allow threads to interrupt main select loop with SIGCONT. * agent/gpg-agent.c (interrupt_main_thread_loop): New function on non-windows platforms, allows other threads to interrupt the main loop if there's something that the main loop might be interested in. -- For example, the main loop might be interested in changes in program state that affect the timers it expects to see. I don't know how to do this on Windows platforms, but i welcome any proposed improvements. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-11-01 | ||
| gpg-agent-idling/agent-Avoid-tight-timer-tick-when-possible.patch | agent: Avoid tight timer tick when possible. * agent/gpg-agent.c (need_tick): Evaluate whether the short-phase handle_tick() is needed. (handle_connections): On each cycle of the select loop, adjust whether we should call handle_tick() or not. (start_connection_thread_ssh, do_start_connection_thread): Signal the main loop when the child terminates. * agent/call-scd.c (start_scd): Call interrupt_main_thread_loop() once the scdaemon thread context has started up. -- With this change, an idle gpg-agent that has no scdaemon running only wakes up once a minute (to check_own_socket). Thanks to Ian Jackson and NIIBE Yutaka who helped me improve some of the blocking and corner cases. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-11-01 | ||
| gpg-agent-idling/agent-Avoid-scheduled-checks-on-socket-when-inotify-.patch | agent: Avoid scheduled checks on socket when inotify is working. * agent/gpg-agent.c (handle_connections): When inotify is working, we do not need to schedule a timer to evaluate whether we control our own socket or not. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2016-11-01 | ||
| Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch | Use hkps://keys.openpgp.org as the default keyserver As of 2.2.17, GnuPG will refuse to accept any third-party certifications from OpenPGP certificates pulled from the keyserver network. The SKS keyserver network currently has at least a dozen popular certificates which are flooded with enough unusable third-party certifications that they cannot be retrieved in any reasonable amount of time. The hkps://keys.openpgp.org keyserver installation offers HKPS, performs cryptographic validation, and by policy does not distribute third-party certifications anyway. It is not distributed or federated yet, unfortunately, but it is functional, which is more than can be said for the dying SKS pool. And given that GnuPG is going to reject all the third-party certifications anyway, there is no clear "web of trust" rationale for relying on the SKS pool. One sticking point is that keys.openpgp.org does not distribute user IDs unless the user has proven control of the associated e-mail address. This means that on standard upstream GnuPG, retrieving revocations or subkey updates of those certificates will fail, because upstream GnuPG ignores any incoming certificate without a user ID, even if it knows a user ID in the local copy of the certificate (see https://dev.gnupg.org/T4393). However, we have three patches in debian/patches/import-merge-without-userid/ that together fix that bug. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2019-07-11 | ||
| Make-gpg-zip-use-tar-from-PATH.patch | Make gpg-zip use tar from $PATH Apparently there is no clean way to configure this from ./configure, and upstream is deprecating gpg-zip anyway. So just force-set tar to be manually "tar" (meaning, that we should look in the $PATH at runtime). See also https://dev.gnupg.org/T4251 and https://bugs.debian.org/913582 |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2018-11-18 | ||
| from-master/common-Use-gnupg_spawn_process_fd-to-invoke-gpg-agent-dir.patch | common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr. * common/asshelp.c (start_new_gpg_agent): Call gnupg_spawn_process_fd and gnupg_wait_process. (start_new_dirmngr): Likewise. -- With --daemon option, gpg-agent/dirmngr detaches by itself. (cherry picked from commit b1c56cf9e2bb51abfd47747128bd2a6285ed1623) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2019-07-24 | ||
| from-master/common-Fix-the-previous-commit.patch | common: Fix the previous commit. * common/asshelp.c [HAVE_W32_SYSTEM] (start_new_gpg_agent): Use gnupg_spawn_process_detached. (start_new_dirmngr): Likewise. (cherry picked from commit 044379772fc5b0f39c6a36809722e702808b6ec3) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2019-07-24 | ||
| from-master/build-Use-LDAP_DEPRECATED-to-detect-ldap-library.patch | [PATCH] build: Use LDAP_DEPRECATED to detect ldap library. * m4/ldap.m4: Define LDAP_DEPRECATED when test. -- (cherry picked from commit ddc6f7d194918791ac9dff0e5af4b80933189afd) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2022-09-15 | ||
| debian-packaging/Build-regexp-against-debian-s-unicode-data-package.patch | Build regexp against debian's unicode-data package It should be simple enough to auto-generate the regexp table from stock UnicodeData.txt. Upstream doesn't seem inclined to keep it up-to-date, and using the stock debian package that ships it instead of upstream's stale version will take care of new case sensitivity issues automatically. This also reduces our dependence on material in the upstream tarball that differs from what is in upstream revision control. This addresses one part of #1071202. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2024-05-16 | ||
| debian-packaging/Always-build-common-status-codes.h-and-common-audit-event.patch | Always build common/status-codes.h and common/audit-events.h This reduces our dependence on files injected into the upstream tarball. This addresses part of #1071202 |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | not-needed | 2024-05-16 | ||
| restore-nl.po.patch | restore nl.po nl.po was mistakenly not shipped by upstream. Restore it for the debian package. Updated translation by Frans Spiesschaert #1072492. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | yes | 2024-05-17 | ||
| Fix-spelling.patch | Fix spelling | Daniel Kahn Gillmor <dkg@fifthhorseman.net> | yes | 2025-01-08 | ||
| debian-packaging/systemd-gpg-agent-socket-GPG_AGENT_INFO.patch | gpg-agent.socket: Set GPG_AGENT_INFO in systemd for gnupg1 GPG_AGENT_INFO is already set in debian/Xsession.d/90gpg-agent, but that only affects sessions that run Xsession. This change affects any session that imports systemd environment variables. See: https://gitlab.gnome.org/GNOME/gdm/-/commit/448134d3cdbc54e5359ea33d387993b0defdaefa https://github.com/sddm/sddm/issues/1276 |
Richard Hansen <rhansen@rhansen.org> | no | 2024-11-18 | ||
| gpg-Fix-newlines-in-Cleartext-Signature-Framework-CSF-mes.patch | gpg: Fix newlines in Cleartext Signature Framework (CSF) messages * g10/armor.c (fake_packet): trim the final newline (and any trailing whitespace) from synthetic literal data packet when parsing CSF. * g10/plaintext.c (handle_plaintext): don't drop final newline when verifying a CSF message. * g10/textfilter.c (copy_clearsig_text): digest each newline in the text to be signed, and always emit a non-digested additional newline before the signature section. * tests/openpgp/clearsig.scm: tighten up tests to confirm equality even when the message has no final newline. -- https://datatracker.ietf.org/doc/html/rfc9580#section-7.1-3 https://datatracker.ietf.org/doc/html/rfc4880#section-7.1 Says: > The line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP > SIGNATURE-----' line that terminates the signed text is not > considered part of the signed text. Before this change, GnuPG would emit a spurious newline at the end of the message when verifying a CSF message, even if the signed text did not contain an extra newline. This change aligns the output of gpg -- when generating and verifying CSF messages -- to match the input exactly. When signing, it produces a signature over the textmode version of the input material. And when verifying while producing output, it produces output corresponding to the signed material. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | yes | 2025-02-20 | ||
| from-2.4/gpg-Lookup-key-for-merging-inserting-only-by-primary-key.patch | gpg: Lookup key for merging/inserting only by primary key. * g10/getkey.c (get_keyblock_byfpr_fast): Add arg primary_only and implement. * g10/import.c (import_one_real): Simplify filling the fpr buffer with zeroes. (import_one_real): Find key only by primary fingerprint. -- This should have been done early: When looking up the original keyblock we want to update, we need to lookup it up only using the primary key. This avoids to find a key which has the primary key also has a subkey. (ported by dkg from commit 25d748c3dfc0102f9e54afea59ff26b3969bd8c1 from STABLE-BRANCH-2-4) |
Werner Koch <wk@gnupg.org> | no | 2025-02-11 | ||
| from-2.4/gpg-Remove-a-signature-check-function-wrapper.patch | gpg: Remove a signature check function wrapper. * g10/sig-check.c (check_signature2): Rename to (check_signature): this and remove the old wrapper. Adjust all callers. (cherry picked by dkg from commit 9cd371b12d80cfc5bc85cb6e5f5eebb4decbe94f) |
Werner Koch <wk@gnupg.org> | no | 2025-02-20 | ||
| from-2.4/gpg-Fix-a-verification-DoS-due-to-a-malicious-subkey-in-t.patch | gpg: Fix a verification DoS due to a malicious subkey in the keyring. * g10/getkey.c (get_pubkey): Factor code out to ... (get_pubkey_bykid): new. Add feature to return the keyblock. (get_pubkey_for_sig): Add arg r_keyblock to return the used keyblock. Request a signing usage. (get_pubkeyblock_for_sig): Remove. (finish_lookup): Improve debug output. * g10/sig-check.c (check_signature): Add arg r_keyblock and pass it down. * g10/mainproc.c (do_check_sig): Ditto. (check_sig_and_print): Use the keyblock returned by do_check_sig to show further information instead of looking it up again with get_pubkeyblock_for_sig. Also re-check the signature after the import of an included keyblock. -- The problem here is that it is possible to import a key from someone who added a signature subkey from another public key and thus inhibits that a good signature good be verified. Such a malicious key signature subkey must have been created w/o the mandatory backsig which bind a signature subkey to its primary key. For encryption subkeys this is not an issue because the existence of a decryption private key is all you need to decrypt something and then it does not matter if the public subkey or its binding signature has been put below another primary key; in fact we do the latter for ADSKs. (cherry picked by dkg from commit da0164efc7f32013bc24d97b9afa9f8d67c318bb with significant edits to align with 2.2) |
Werner Koch <wk@gnupg.org> | no | 2025-02-21 |
All known versions for source package 'gnupg2'
- 2.4.7-6 (experimental)
- 2.2.46-2 (sid)
- 2.2.46-1 (trixie)
- 2.2.40-1.1 (bookworm)
- 2.2.27-2+deb11u2 (bullseye-security, bullseye)