Debian Patches

Status for gnupg2/2.4.7-6

Patch Description Author Forwarded Bugs Origin Last update
from-upstream/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.

(cherry picked from commit 25d748c3dfc0102f9e54afea59ff26b3969bd8c1)
Werner Koch <wk@gnupg.org> no 2025-02-11
from-upstream/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 from commit 9cd371b12d80cfc5bc85cb6e5f5eebb4decbe94f)
Werner Koch <wk@gnupg.org> no 2025-02-20
from-upstream/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 from commit da0164efc7f32013bc24d97b9afa9f8d67c318bb)
Werner Koch <wk@gnupg.org> no 2025-02-21
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
* 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
freepg/0008-avoid-systemd-deprecation-warning.patch avoid-systemd-deprecation-warning NIIBE Yutaka <gniibe@fsij.org> no 2023-08-21
freepg/0009-Add-systemd-support-for-keyboxd.patch Add systemd support for keyboxd NIIBE Yutaka <gniibe@fsij.org> no 2023-08-23
freepg/0010-Ship-sample-systemd-unit-files.patch Ship sample systemd unit files
This reverts the systemd-relevant parts of upstream's
eae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed

In that commit, Werner Koch wrote:

> The use of systemd is deprecated because of additional complexity
> and the race between systemd based autolaunching and the explicit
> gnupg based and lockfile protected autolaunching.

FreePG aims to support socket-activated systemd integration for modern
Gnu/Linux systems that use GnuPG. That integration does not appear to
actually have the race condition posited by Werner above, as described
by Coelacanthus in https://dev.gnupg.org/T6336#171407
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2023-01-23
freepg/0011-el-gamal-default-to-3072-bits.patch gpg: default El Gamal to 3072-bit keys.
* g10/keygen.c (gen_elg): update default from 2048 to 3072.

--

3072-bit El Gamal is widely considered to be 128-bit-equivalent security.

While using El Gamal might be ill-advised, if you're going to use it,
it might as well be a reasonable strength.


(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/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
freepg/0021-gpg-Sync-compliance-mode-cleanup-with-master.patch [PATCH GnuPG 14/19] gpg: Sync compliance mode cleanup with master
* g10/gpg.c (set_compliance_option): Clean up option settings for
compliance modes.
* doc/gpg.texi: note that --allow-old-cipher-algos must come after any
compliance setting.

--

This makes it possible to reset all options affected by any non-gnupg
compliance mode to their default values by using --compliance=gnupg.

This synchronizes the compliance mode behaviors with the master
branch, including commits:

- 54a8770aeb20eb9e18b5e95e51c376ec7820f8f6
- 0bdf5859935e3db15baaf5d0d96b723ddbd2acd5
- 04d58ff8475575f22a5ee1fb8c4f2c2dca0b5522
- aa46ba28ba75fc479b407c572c723b51b22d4a73
- 4b2729b983bf3c6c1186ebdf1962f64d8cb1b3a1
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-03
freepg/0022-gpg-emit-RSA-pubkey-algorithm-when-in-compatibility-.patch [PATCH GnuPG 15/19] gpg: emit RSA pubkey algorithm when in compatibility modes

* doc/gpg.texi (Compliance Options): --gnupg offers LibrePGP behavior,
and prefers LibrePGP where it diverges from OpenPGP; --rfc4880bis is
an alias for --gnupg; Explain that --rfc2440 is ancient; correct
punctuation. (default-new-key-algo): drop incorrect information
about defaults. (default-new-key-algo): Remind the user that this
should come after any compliance modes, like --allow-old-cipher-algos.
* g10/gpg.c (set_compliance_option): default pubkey algorithm for
legacy compliance is 3072-bit RSA.
* common/compliance.c (gnupg_compliance_label) new function,
prototyped...
* common/compliance.h: ...here.
* g10/keygen.c (parse_key_parameter_part): when using a legacy
compliance mode, ensure that new keys are only algorithms known by the
corresponding tools.

--

Before this fix, the following command:

gpg --rfc4880 --quick-gen-key "$USERID"

would produce an OpenPGP secret key that would not be compatible for
use with an RFC 4880 client. The generated certificate would be a
problem if the user has a another OpenPGP client that is limited to
RFC 4880, and it would be a problem for any peer who wants
to encrypt to or validate signatures from the corresponding
certificate.

With this fix, default key generation under a compatibility mode will
actually produce compatible, interoperable OpenPGP key.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-04
freepg/0023-gpg-Reintroduce-openpgp-as-distinct-from-rfc4880.patch [PATCH GnuPG 16/19] gpg: Reintroduce --openpgp as distinct from --rfc4880

* common/compliance.{c,h}: add CO_OPENPGP
* options.h: #define OPENPGP by analogy with RFC4880
* g10/gpg.c (set_compliance_option): define oOpenPGP separately from
oRFC4880; re-point oDE_VS to use oRFC4880 to avoid changing oDE_VS.
* g10/misc.c (compliance_failure): Describe standards modes
* doc/gpg.texi: (Compliance options): distinguish between --rfc4880
and --openpgp
--

This change adopts baseline MTI digest algorithms for modern OpenPGP
when --compliance=openpgp is supplied.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-04
freepg/0024-gpg-Emit-LibrePGP-material-only-in-compliance-gnupg.patch [PATCH GnuPG 17/19] gpg: Emit LibrePGP material only in --compliance=gnupg

* g10/encrypt.c (use_aead): only emit LibrePGP AEAD/OCB if in
--compliance=gnupg or --force-ocb
* g10/keygen.c (keygen_set_std_prefs): when opt.compliance !=
CO_GNUPG, skip the LibrePGP AEAD algorithm preferences subpacket
during key generation. (keygen_upd_std_prefs): If opt.compliance !=
CO_GNUPG, don't advertise support for LibrePGP features (v5 keys,
OCB). (parse_key_parameter_part): Unless opt.compliance == CO_GNUPG,
error out when prompted to produce a v5 key.

--

Emit the following objects only in CO_GNUPG:

- AEAD/OCB
- preferred AEAD Algorithm subpackets
- Feature bit for "v5" and LibrePGP AEAD
- new v5 keys, new *448 keys

This change makes it so that --compliance=openpgp mode produces
objects that other OpenPGP-compatible implementations will be able to
handle.

In the case of encrypted data, it will decline to emit LibrePGP
AEAD/OCB, which means other implementations will be able to decrypt.

In the case of new keys, not only will OpenPGP-compatible peers be
able to communicate with the newly generated certificates, but if the
secret key is shared with other OpenPGP implementations they will be
able to handle it.

And we avoid setting feature advertisements which might encourage
other people to send LibrePGP-formatted material to the user, so that
when the secret key is shared with another OpenPGP-compatible
implementation, it will be able to handle the incoming material.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-04
freepg/0025-gpg-gpgconf-list-report-actual-compliance-mode.patch [PATCH GnuPG 18/19] gpg: --gpgconf-list: report actual compliance mode

* g10/gpg.c (gpgconf_list): report actual compliance mode

--
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-06
freepg/0026-gpg-Default-to-compliance-openpgp.patch [PATCH GnuPG 19/19] gpg: Default to --compliance=openpgp
* g10/gpg.c (main): default
set_compliance_option(oOpenPGP).
* tests/openpgp/encrypt.scm (Checking OCB): offer --compliance=gnupg
to make it possible to emit LibrePGP AEAD/OCB for the test.
* doc/gpg.texi: change description of what the default compliance
option is.

--

This change is made with the purpose of not inflicting LibrePGP
material on the ecosystem generally unless the user wants it done.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> no 2025-02-04
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
from-master/gpg-agent-idling/0001-agent-Add-agent_kick_the_loop-function.patch [PATCH 01/12] agent: Add agent_kick_the_loop function.
* agent/agent.h (agent_kick_the_loop): New.
* agent/gpg-agent.c [HAVE_W32_SYSTEM] (the_event2): New.
[HAVE_PSELECT_NO_EINTR] (event_pipe_fd): New.
[!HAVE_PSELECT_NO_EINTR] (main_thread_pid): New.
(create_an_event): New, factored out.
(get_agent_daemon_notify_event): Use create_an_event.
(handle_signal): Add a case for SIGCONT.
(agent_kick_the_loop): New.
(handle_connections): Call pselect possibly with the pipe.
Call eselect with THE_EVENT2.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-08-24
from-master/gpg-agent-idling/0001-agent-Use-a-thread-to-monitor-socket-takeover.patch [PATCH 1/9] agent: Use a thread to monitor socket takeover.

* agent/gpg-agent.c (check_own_socket_running): Remove.
(socket_takeover_detected): New.
(check_own_socket): Remove.
(handle_tick): Don't call check_own_socket any more.
(handle_connections): Start off the check_own_socket_thread.
Check socket_takeover_detected to handle the event.
(do_check_own_socket): New, factoring out the task.
(check_own_socket_thread): Loop with the interval.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
from-master/gpg-agent-idling/0002-agent-Fix-the-handling-of-socket-takeover.patch [PATCH 2/9] agent: Fix the handling of socket takeover.
* agent/gpg-agent.c (handle_connections): Check the takeover when
interrupted.
(check_own_socket_thread): Kick the loop when detected.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-08-30
from-master/gpg-agent-idling/0003-agent-Recover-support-CHECK_OWN_SOCKET_INTERVAL-0.patch [PATCH 3/9] agent: Recover support CHECK_OWN_SOCKET_INTERVAL == 0.

* agent/gpg-agent.c (handle_connections): Only spawn the thread
when CHECK_OWN_SOCKET_INTERVAL > 0.
[CHECK_OWN_SOCKET_INTERVAL == 0] (check_own_socket_pid_cb)
(do_check_own_socket, check_own_socket_thread): Ifdef out.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
from-master/gpg-agent-idling/0004-agent-Have-a-thread-monitoring-parent-PID-and-homedi.patch [PATCH 4/9] agent: Have a thread monitoring parent PID and homedir.

* agent/gpg-agent.c (CHECK_PROBLEMS_INTERVAL): New.
(socket_takeover_detected): Remove.
(problem_detected): New.
(handle_tick): Don't check parent PID and homedir in this function.
(handle_connections): Spawn check_others_thread when needed. Handle
AGENT_PROBLEM_PARENT_HAS_GONE and AGENT_PROBLEM_HOMEDIR_REMOVED.
(check_own_socket_thread): Check SHUTDOWN_PENDING variable in the
loop. Use PROBLEM_DETECTED variable.
(check_others_thread): New.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
from-master/gpg-agent-idling/0005-agent-Better-interaction-between-main-loop-and-cache.patch [PATCH 5/9] agent: Better interaction between main loop and cache expiration.


* agent/agent.h (agent_cache_housekeeping): Remove.
(agent_cache_expiration): New.
* agent/cache.c (agent_cache_housekeeping): Remove.
(agent_cache_expiration): New.
* agent/gpg-agent.c (TIMERTICK_INTERVAL): Remove.
(handle_tick): Remove.
(handle_connections): Call agent_cache_expiration and use the timeout
value determined by the call.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
from-master/gpg-agent-idling/0006-agent-Introduce-management-of-timer-to-expire-cache-.patch [PATCH 6/9] agent: Introduce management of timer to expire cache entries.

* agent/cache.c (struct timer_s): New.
(struct cache_item_s): Add a member filed T for timer.
(the_timer_list, the_timer_list_new): New.
(insert_to_timer_list_new, insert_to_timer_list): New.
(remove_from_timer_list, remove_from_timer_list_new): New.
(housekeeping): Remove.
(compute_expiration, update_expiration): New.
(do_expire): New.
(TIMERTICK_INTERVAL): Remove.
(agent_cache_expiration): Use timer list to manage the expiration
of cache entries.
(agent_flush_cache): Call update_expiration when needed.
(agent_put_cache): Don't call housekeeping any more, but
update_expiration for an entry in question.
(agent_get_cache): Likewise.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-08-31
from-master/gpg-agent-idling/0007-agent-Fix-the-previous-commit.patch [PATCH 7/9] agent: Fix the previous commit.
* agent/cache.c (remove_from_timer_list_new): Fix cut&paste error.
TV_SEC field should not be touched.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-01
from-master/gpg-agent-idling/0008-agent-Fix-timer-list-management.patch [PATCH 8/9] agent: Fix timer list management.
* agent/cache.c (insert_to_timer_list): Update TV_SEC of the top entry
when inserted.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-01
from-master/gpg-agent-idling/0009-agent-Fix-sock_inotify_fd-handling.patch [PATCH 9/9] agent: Fix sock_inotify_fd handling.
* agent/gpg-agent.c (handle_connections): Also check SOCK_INOTIFY_FD
when spawning check_onw_socket_thread. When removal of the socket
is detected, do same as AGENT_PROBLEM_SOCKET_TAKEOVER.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
from-master/gpg-agent-idling/0010-agent-Fix-timer-round-up-check-when-inserting-an-ent.patch [PATCH 10/10] agent: Fix timer round-up check when inserting an entry into cache.

* agent/cache.c (insert_to_timer_list): Round up when >= a half second.

--
NIIBE Yutaka <gniibe@fsij.org> no 2023-09-04
Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch Use hkps://keys.openpgp.org as the default keyserver
Upstream's choice of default keyserver is not federated with other
keyservers, is subject to flooding attacks, does no e-mail
verification, and is intermittently unreachable.

keys.openpgp.org is also not federated with other keyservers, but
avoids the other drawbacks.

Upstream intends to ship no keyserver default in the future, so it is
not worth trying to convince them to choose a better default.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> not-needed 2022-12-25
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
do-not-install-gnutls.7.html.to.mandir.diff Do not install gnupg.7.html into usr/share/man/manh/ Andreas Metzler <ametzler@debian.org> yes upstream vendor 2024-11-02
add_keyboxd_systemd_support.diff Add keyboxd systemd support NIIBE Yutaka <gniibe@fsij.org> not-needed 2023-08-22
gpg-agent.socket-Set-GPG_AGENT_INFO-in-systemd-for-g.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> not-needed 2025-02-26
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> no 2025-02-20

All known versions for source package 'gnupg2'

Links