| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 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 | ||
| block-ptrace-on-secret-daemons/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 | ||
| 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 | ||
| from-master/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 is widely considered to be 128-bit-equivalent security. This is a sensible default in 2017. (cherry picked from commit 909fbca19678e6e36968607e8a2348381da39d8c) |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2017-09-07 | ||
| from-master/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 | ||
| update-defaults/gpg-Default-to-SHA-512-for-all-signature-types-on-RS.patch | gpg: Default to SHA-512 for all signature types on RSA keys. * g10/main.h (DEFAULT_DIGEST_ALGO): Use SHA512 instead of SHA256 in --gnupg mode (leave strict RFC and PGP modes alone). * 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. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2017-09-07 | ||
| update-defaults/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 | ||
| import-merge-without-userid/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 | ||
| import-merge-without-userid/gpg-allow-import-of-previously-known-keys-even-without-UI.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 | ||
| import-merge-without-userid/gpg-accept-subkeys-with-a-good-revocation-but-no-self-sig.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 | ||
| 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 | ||
| gpg-drop-import-clean-from-default-keyserver-import-optio.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 * doc/gpg.texi: reflect this change in the documentation 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 | ||
| 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-upstream/gpg-Report-an-error-for-receiving-key-from-agent.patch | gpg: Report an error for receiving key from agent. * g10/export.c (do_export_one_keyblock): Report an error. -- (cherry picked from commit 6f0066db2c87e6362473d17c0621011ed1e1eae6) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2020-11-26 | ||
| from-upstream/gpg-Move-NETLIBS-after-GPG_ERROR_LIBS.patch | gpg: Move NETLIBS after GPG_ERROR_LIBS. * g10/Makefile.am (LDADD): Remove NETLIBS. (gpg_LDADD, gpgv_LDADD): Add NETLIBS after GPG_ERROR_LIBS. (gpgcompose_LDADD, t_keydb_get_keyblock_LDADD): Likewise. (t_stutter_LDADD): Likewise. -- (cherry picked from commit b26bb03ed96f380ad603f7ad902862625233c931) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2022-10-18 | ||
| from-upstream/dirmngr-Fix-build-with-no-LDAP-support.patch | dirmngr: Fix build with no LDAP support. * dirmngr/server.c [USE_LDAP] (start_command_handler): Conditionalize. -- Cherry-pick master commit of: 7011286ce6e1fb56c2989fdafbd11b931c489faa (cherry picked from commit a5c3821664886ffffbe6a83aac088a6e0088a607) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2022-10-18 | ||
| from-upstream/gpg-Move-NETLIBS-after-GPG_ERROR_LIBS-another.patch | gpg: Move NETLIBS after GPG_ERROR_LIBS (another). * g10/Makefile.am (t_keydb_LDADD): Add NETLIBS after GPG_ERROR_LIBS. -- (cherry picked from commit 256b3c05789d8026b62f594bd592199a90b1b446) |
NIIBE Yutaka <gniibe@fsij.org> | no | 2022-10-18 |