Bug#1058572: [pkg-gnupg-maint] Bug#1058572: Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd
Hi! On Fri, 15 Dec 2023 09:22, NIIBE Yutaka said: > is created. Note that keyboxd just works with systemd by socket > activation. Why do you think so. keyboxd is started on demand by gpg or gpgsm. There is no --supervised option as we still have for dirmngr and gpg-agent. In case Debian added this option this will the cause of the problem because two keyboxd might show up and one takes the database lock. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature
Bug#1053531: [pkg-gnupg-maint] Bug#1053531: gnupg/gpg-agent/pinentry: timeout
Hi Thorsten, > distracted by being asked a question, and it had terminated the > pinentry and agent, asking me for a password on stderr/tty without > pinentry, but as soon as I went to type it there, it ended up with: The second one is the usual ssh prompt in a failed ssh-agent. > IMHO the pinentry form shouldn’t time out (or at least be reasonable > about it, e.g. time out after one hour, at the earliest, or so). Put a pinentry-timeout into gpg-agent.conf --pinentry-timeout n This option asks the Pinentry to timeout after n seconds with no user input. The default value of 0 does not ask the pinentry to timeout, however a Pinentry may use its own default timeout value in this case. A Pinentry may or may not honor this request. The default is 60 seconds, iirc. No timeout is not a good idea either because you will run into a related problem when you request a second action requiring a pinentry - that will then wait for the already open pinentry somewhere on another desktop. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term
Hi! On Thu, 27 Jul 2023 15:24, NIIBE Yutaka said: > - ... and default keyserver choice: > debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch FWIW, if you need to change the default, the proper location is /etc/gnupg/dirmngr.conf and not a source code patch. > - And for the specific keyserver, there are local changes: > debian/patches/import-merge-without-userid/ Which breaks the gnupg policy and are harmful for the entire ecosystem. There is a reason that we we use a syncing keyserver instead of the x-th attempt to for a "verifying" keyserver onto PGP users. > - Upstream deprecates systemd support, which was originally introduced > in Debian version. Perhaps, we will need a Debian local patch for > this. The problem here is that GnuPG has its own way to start its agents. Using systemd activation here introduces races because you can't have two (advisory) locking systems where each does not know about the other. For an engineering POV we can't switch to socket activation for portability reasons. Keep in mind that the heaviest desktop users of gpg are on Windows and we tried hard to keep changes as small as possible. That benefits all users: On Linux, AIX, *BSD and Windows. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature
Bug#980838: [pkg-gnupg-maint] Bug#980838: scdaemon
On Mon, 31 Jan 2022 09:52, Christian Weiske said: > Jan 30 07:39:51 dojo systemd[1076614]: gpgconf: Fehler bei Ausführung > von `/usr/lib/gnupg/scdaemon': wahrscheinlich nicht installiert Put disable-scdaemon into gpg-agent.conf Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#949761: [pkg-gnupg-maint] Bug#949761: gpgconf: make socketdir configurable to users
On Tue, 21 Dec 2021 15:17, NIIBE Yutaka said: >> gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses >> GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but >> the directory /run/user/2339 is removed on logout by elogind >> even if processes are still running. > > I happened to find a possible solution for this problem, if a user uses > systemd. Another solution is to run touch /var/lib/elogin/linger/$(id -un) once to more or less get standard Unix semantics back. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#1001331: [pkg-gnupg-maint] Bug#1001331: gpg: Provide interface to inspect (detached) signatures
Hi!
> I cannot stop using as I do not know of a publicly supported interface
> to inspect a (detached) signature to get its issuer fingerprint or
> keyid.
You can do this:
gpg --verify --status-fd 1 x.asc /dev/null 2>/dev/null \
| awk '$1=="[GNUPG:]" && $2=="BADSIG" { print $3}'
which greps for
[GNUPG:] BADSIG 19CC1C9E085B107A w...@gnupg.org
This shows the keyid but not the newer fingerprint. Adding something
for the fingerprint would be easy, but it takes some time before it will
be widely enough deployed.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP signature
Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options
On Sun, 14 Mar 2021 14:32, Christoph Biedl said: > Point is, the legacy file ~/.gnupg/options is still being used in > surprisingly many applications, also in documentation: Then please file a bug against such documentation. And maybe even against any application which read the option filre directly, that is without using gpgconf. > https://codesearch.debian.net/search?q=.gnupg%2Foptions=1 Look at the code shown tehre: Almost everywhere it is used as a fallback from gpg.conf. > In Debian, revert that commit, and emit a deprecation warning if the > legacy file is parsed. Sysadmins will kill you if you do that. The global conf file has been a long standing request from many parties. It comes very hadny for large installations because it can be used to enforce options on users. That is why I took the trouble to actually backported this from master. Supporting the legacy option file would be a Bad Idea. In particular for a new major release it should be not a problem to add release notes mention that after 18 years the deprecated legacy option file is not anymore supported. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#985158: [pkg-gnupg-maint] Bug#985158: gpg: No longer reads .gnupg/options
On Sat, 13 Mar 2021 20:40, Kurt Roeckx said: > It seems that the config file ~/.gnupg/options is no longer read, > and it's now reading (among others) ~/.gnupg/gpg.conf Oops. I totally forgot about this this legacy file. The reason for this is that we switched to a new option parser which also features global config files. Right, that should not have happened. Fixing this if complicated and thus I would suggest to use a symlink or way better to get rename the file. This 19 year old NEWS entry gives some historic background: Noteworthy changes in version 1.1.92 (2002-09-11) - * [IMPORTANT] The default configuration file is now ~/.gnupg/gpg.conf. If an old ~/.gnupg/options is found it will still be used. This change is required to have a more consistent naming scheme with forthcoming tools. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#980768: [pkg-gnupg-maint] Bug#980768: gnupg2: reduce Build-Depends
> * libcurl4-gnutls-dev is unused. While curl is mentioned in source >comments and checked for in configure, it is never actually used. You mean GnuPG's configure? I can't find it. It was tested for in GnuPG 1 and 2.0 but not anymore since 2.1. I am just a curious upstream. Salam-Shalom, Werner -- * Free Assange and protect free journalism! * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons! signature.asc Description: PGP signature
Bug#979412: [pkg-gnupg-maint] Bug#979412: pinentry: "--lc-type" in manapges is typo for "--lc-ctype"
FWIW, that was fixed 11 years ago in upstream (commit 971962116fba3769d8260b5016f93c6f9ebf083f) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Bug#978630: [pkg-gnupg-maint] Bug#978630: Bug#978630: gnupg: --check-sigs trusts weak digest alg if weak digest was trusted when importing key
It gets cached if it has been checked. There are some pre-conditions for this for example the existance of the corresponding public key.
Bug#978630: [pkg-gnupg-maint] Bug#978630: gnupg: --check-sigs trusts weak digest alg if weak digest was trusted when importing key
Hi! gpg caches key signature verification results. Use --no-sig-cache to disable this cache. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#977909: [pkg-gnupg-maint] Bug#977909: Bug#977909: gnupg: `--trust-model always` doesn't trust keys
On Tue, 22 Dec 2020 22:41, Ansgar said: > The warning is incorrect as GnuPG was told that the key is trusted. The warning is there for a reasons and it will not be changed. >> I am not sure what python3-gpg is. > > The official Python bindings for GPGME. Sorry, I did not knew Debian's package name for the GPGME binding. Anyway, if you think that is a bug in the python binding, please file a bug a dev.gnupg.org (tag as gpgme and python) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#977909: [pkg-gnupg-maint] Bug#977909: gnupg: `--trust-model always` doesn't trust keys
> The output then contains:
>
> | gpg: WARNING: Using untrusted key!
Look here:
if (opt.trust_model == TM_ALWAYS)
{
if (!opt.quiet)
log_info(_("WARNING: Using untrusted key!\n"));
It is just a warning - use --quiet to silence this warning.
> If I try to use python3-gpg to verify the signature, the signatures
I am not sure what python3-gpg is.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP signature
Bug#951025: [pkg-gnupg-maint] Bug#951025: gnupg: GPG tries to get passphrase from wrong place
> my passphrase on my desktop XFCE session. However, I am not at that > computer, so I cannot provide it with a passphrase. After having logged into the other box with ssh -X, run in that ssh session: gpg-connect-agent updatestartuptty /bye This tells gpg-agent on which DISPLAY or tty it should pop up the pinentry. In contrast to gpg ssh and the ssh-agent protocol have no way to convey the DISPLAY and other envvars to gpg-agent, thus you need to tell it manually. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#945279: [pkg-gnupg-maint] Bug#945279: gpg-wks-client: --install-key does not create policy file
On Fri, 22 Nov 2019 11:36, Hans-Christoph Steiner said: > It should create a zero length file, as recommended in the draft: "it > is sufficient if that file has a zero length". Good idea. Tracked upstream as https://dev.gnupg.org/T4753 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail
On Tue, 19 Nov 2019 14:50, Bernhard Übelacker said:
> Maybe it is of some help, following seem to be locations with the
> missing symbols:
> ...
> #8 0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
> #9 0xb27e5281 in () at libgpgme.so.11, in _gpgme_io_select at
This is the code at that place (at least in my master but we have not
chnaged it for quite some time)
else if (fds[i].for_read)
{
> if (FD_ISSET (fds[i].fd, ))
{
Right, the tested FD might be out of range for FD_ISSET but we have an
earlier check for this:
if (fds[i].for_read)
{
if (fds[i].fd >= FD_SETSIZE)
{
TRACE_END (dbg_help, " -BAD- ]");
gpg_err_set_errno (EMFILE);
return TRACE_SYSRES (-1);
}
So the code should not be the problem. Hwoever if the fd table is
corrupt you might run into this but. Nex step would be looking into
libc - I have no copy handy right now ...
> I found this upstream feature request, which could fit,
> but there is also a change mentioned that should avoid that crash,
> that is already included ...
> Are you maybe hitting this limit?
Nope, see the code above.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP signature
Bug#942127: [pkg-gnupg-maint] Bug#942127: bugs in the FILTER EXPRESSIONS section of the gpg man page
On Thu, 10 Oct 2019 18:42, Steve McIntyre said: > Looks like a simple cut and paste / completion error. Now fixed upstream. Thanks for reporting. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#939508: [pkg-gnupg-maint] Bug#939508: scdaemon: scdaemon does not share access with pcscd used by opensc
On Thu, 5 Sep 2019 13:05, robert.grizz...@quoininc.com said: > I am attempting to use both the gpg and PIV functionaity of a Yubikey 5 > device, but scdaemon takes exclusive access. This is the intended behavior FWIW: GnuPG master has dedicated support for Yubikeys and since today allows on-the-fly switching between the PIV and the OpenPGP application on the Yubikey. Thus you can use the Yubikey to sign commits with the OpenPGP key and also use it in Firefox or Thunderbird via the scute.org (git master) pkcs#11 provider. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#931339: [pkg-gnupg-maint] Bug#931339: gnupg: Change default keyserver?
On Tue, 2 Jul 2019 15:55, guil...@debian.org said: > According to the dirmngr(8) man page, the default built-in server is > «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and Not from upstream. We have a default keyserver because that is (or better was) a pool of keyservers which allows to maintain a set of responsive keyservers without chnages on the client side. keys.openpgp.org may ask to be included into the pool but I doubt that this makes sense because it is, like pgp.com, a standalone keyserver which by design can't synchronize with others. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#931340: dirmngr goes into endless loop if keyserver responses with http error 503
Hi, this bug was reported on Monday as https://dev.gnupg.org/T4600 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#923204: [pkg-gnupg-maint] Bug#923204: gpg-agent has a false dependency on libpam-systemd
On Sun, 24 Feb 2019 16:56, joshud...@gmail.com said: > gpg-agent --server or directly from .profile (ssh sessions) by > gpg-agent --daemon. FWIW, actually gpg-agent is started on-demand from all tools requiring it. To explicitly start it "gpgconf --launch agent" can and should be used. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature
Bug#914395: [pkg-gnupg-maint] Bug#914395: dirmngr log
On Sun, 25 Nov 2018 22:22, csm...@debian.org said: > It seems it needs the SRV record and fails wrong without it. > Checking on the same system looking up that SRV record I get the > expected NXDOMAIN error. That seems to be a Debian specific problem; with a dirmngr started by the gpg command, I get this with master (and pretty sure also with 2.2.11): DBG: chan_7 <- KEYSERVER --clear hkp://keyring.debian.org DBG: chan_7 -> OK DBG: chan_7 <- KS_GET -- 0xDF50FEA5 DBG: dns: libdns initialized DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org) -> 0 records DBG: dns: resolve_dns_name(keyring.debian.org): Success resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known] resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already known] DBG: dns: resolve_dns_name(keyring.debian.org): Success DBG: chan_7 -> S SOURCE http://keyring.debian.org:11371 DBG: (20847 bytes sent via D lines not shown) Can you please test with standard-resolver no-use-tor in dirmngr.conf ? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpQo0mPcGr38.pgp Description: PGP signature
Bug#914395: [pkg-gnupg-maint] Bug#914395: Acknowledgement (gpg recv-key fails with no route to host)
On Fri, 23 Nov 2018 00:23, csm...@debian.org said: > It appears dirmngr tries to lookup a SRV record and that's the no route to > host error. Please put this into ~/.gnupg/dirmngr.conf --8<---cut here---start->8--- log-file /whatever verbose debug ipc,dns,network --8<---cut here---end--->8--- and best try also with upstream or Sid and not the heavily patched Debian version. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpaPYSibvVTj.pgp Description: PGP signature
Bug#913614: [pkg-gnupg-maint] Bug#913614: Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"
On Tue, 13 Nov 2018 16:19, tia...@debian.org said: > Even for something that shouldn't have a reason to prompt, like > "--recv-keys" with a full fingerprint? You are right, this should not be needed. I recall that we recently fixed a similar case where we accidentally printed to the tty. In any case --batch is always a good idea if you don't expect any interactivity. I agree that this --batch thing is contrary to standard Unix behavior where you would explicitly need to to select an interactive option. However, due to the legacy of of PGP and GPG 1.4 we had to use the tty anyway to query the passphrase and for the dedicated commands like --edit-key. For reasons of syncing prompts with tty input more and more output had to be send to the tty directly and, well, at some places we got it wrong. Now, with gpg-agent and its Pinentry, we could have inhibited the tty access by default and allow it only for interactive commands. But then came the request for --pinentry-loopback and the new Tofu prompts ... > Would it make sense to detect that there's no TTY present and assume > batch mode? (apologies if something like that's been proposed before) You can't do that in a reliable way. But let me check whether it is possible to turn this into a non-fatal error and terminate only when an input is requested. Nothing for 2.2, though. Given dkg's comments, your best choice is to use --no-tty or no-tty in gpg.conf. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3Tkj3qXLv1.pgp Description: PGP signature
Bug#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"
On Tue, 13 Nov 2018 14:18, be...@debian.org said: > Passing "--no-tty" to gpg works around this issue. For any script use you should anyway use --batch which disables the use of the tty as a side-effect. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpEKDPn6XMXr.pgp Description: PGP signature
Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Tue, 16 Oct 2018 09:51, s...@debian.org said: > However, none of this solves co-installability in Debian: > libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be > installed at the same time, because they have different content in > /usr/bin/gpg-error-config, and that will be a problem for as long as /usr/bin/gpg-error-config should only be used for native building. For cross-building it is expected that a dedicated gpg-error-config script is installed in the root directory of the host platform (e.g. as /usr/i686-w64-mingw32/bin/gpg-error-config) and only that gpg-error-config should ever be considered. In past this required manual configuration but meanwhile SYSROOT seems to be an accepted standard and we can make use of it. This means to only look there for the config script to get the right version and not take whatever we find and only print a warning if the platform is wrong. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3e0bdhz6hy.pgp Description: PGP signature
Bug#909693: [pkg-gnupg-maint] Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed
On Fri, 28 Sep 2018 00:57, invernom...@paranoici.org said: > It's clear that the CRL revocation check is the step that takes a long > time. Right. And it depends on the certificate issuer and how they maintain CRLs. If they release CRLs only once a week, things should be okay becuase GnuPG caches them. However, some CAs are creating new CRLs every hour or even more often and if they are really long (e.g. by including expired certifciates, which is silly, but some did this) this is an effective DoS. > The man page states that disabling CRL checks is especially intended > for off-line operations (which is not my case, except for infrequent Yes, that is the theory. But in practise CRLs don't work and OCSP is also not much better. > So, is disabling CRL checks advisable or not? How often do you run a "gpg --refresh-key" which is basically the OpenPGP way for checking for revocations? Does anyone actually revoke X.509 certifciates. Weel, some organisations have their in-house use of C.509 and they can implement everything properly. But everything else? I can't decide. It might be worth to add a black- or whitelist to our CRL checks or add an option to violate the nextUpdate field (expiration time) of a CRL and trigger an update only every few days. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp584PyiqB6u.pgp Description: PGP signature
Bug#909693: [pkg-gnupg-maint] Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed
On Wed, 26 Sep 2018 22:44, invernom...@paranoici.org said: > While verifying an OpenPGP signature with gpg is definitely fast, > verifying a pkcs7-signature with gpgsm is super slow. Sure that it is the verification and not the CRL or OCSP revocation check? It dependes on the issuer of the certifciate. Try with "disable-crl-checks" in gpgsm.conf? OCSP check are disabled by default. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpTh1s2D8jTD.pgp Description: PGP signature
Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose
On Mon, 3 Sep 2018 12:52, vinc...@vinc17.net said: > So, do you mean that it is a bug in Mutt, which doesn't filter them > out? Yes, if you don't want to see them. IIRC, tlr once used a wrapper process to invoke the actual tool. I have not used the direct invocation for 15 years. Anyway it is better to use crypt_set_gpgme ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpZScnCNO2b5.pgp Description: PGP signature
Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose
On Sun, 2 Sep 2018 15:18, vinc...@vinc17.net said: > outputs many [GNUPG:] debugging messages, partly hiding useful output. These ain't no debugging messages but the required information for any program or script to interact with gpg. You have requested them using the --status-fd option. Which is the Right Thing to do. The human readable output is, well, for humans and not for machine consumption. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpAsr4T6T_sU.pgp Description: PGP signature
Bug#901498: [pkg-gnupg-maint] Bug#901498: FTBFS on stretch, needs newer libgpg-error
On Thu, 14 Jun 2018 09:14, daniel.baum...@progress-linux.org said:
> when locally backporting gnupg2, I noticed that 2.2.8-1 now FTBFS on
> stretch due to old libgpg-error. Would you mind bumping build-depends
Please apply the attached patch to GnuPG 2.2.8 as suggested by
https://dev.gnupg.org/T4012
Salam-Shalom,
Werner
--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From 18274db32b5dea7fe8db67043a787578c975de4d Mon Sep 17 00:00:00 2001
From: Werner Koch
Date: Fri, 8 Jun 2018 22:01:10 +0200
Subject: [PATCH GnuPG] gpg: Allow building with older libgpg-error.
* g10/mainproc.c (proc_encrypted): Use constant from logging.h
--
Because the log levels are enums I had to change there names in
libgpg-error to avoid clashes. Master uses the new names but 2.2
needs to stick to the old names.
Fixes-commit: 825909e9cd5f344ece6c0b0ea3a9475df1d643de
Signed-off-by: Werner Koch
---
g10/mainproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/g10/mainproc.c b/g10/mainproc.c
index 72b0dd828..f5cc4532a 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -683,7 +683,7 @@ proc_encrypted (CTX c, PACKET *pkt)
* are rare in practice we print a hint on how to decrypt
* such messages. */
log_string
-(GPGRT_LOGLVL_INFO,
+(GPGRT_LOG_INFO,
_("Hint: If this message was created before the year 2003 it is\n"
"likely that this message is legitimate. This is because back\n"
"then integrity protection was not widely used.\n"));
--
2.11.0
pgpjcNzLcqdEE.pgp
Description: PGP signature
Bug#900247: [pkg-gnupg-maint] Bug#900247: gpg-check-pattern.1: Some formatting changes in the manual
Hi! The man pages for gnupg are generated from texinfo source using the yat2m tool. This is part of GnuPG but we are in the progress of moving it to libgpg-error (which is a common dependency of all GnuPG stuff). Thus it would would be better to assign this bug to libgpg-error and bonus points for adding an issue to dev.gnupg.org. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp5hwkOjjYnU.pgp Description: PGP signature
Bug#894983: gnupg2: CVE-2018-9234: Able to certify public keys without a certify key present when using smartcard
On Thu, 5 Apr 2018 22:49, car...@debian.org said: > CVE-2018-9234[0]: > | GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key > | certification requires an offline master Certify key, which results in > | apparently valid certifications that occurred only with access to a > | signing subkey. That is more a description of an unspecified behaviour of OpenPGP. It is From the specs not clear whether a subkey shall be able to certify a a userid or a subkey. The problem which such a certification from a subkey is that you can't evaluate it due to the catch-22: The key usage flags are part of the signature itself and to check the signature you need to have the usage flags. For the primary key this is not a problem because it implicitly has certification usage. We are currently testing a patch but are also considering to disallow certification from subkeys at all. > Please adjust the affected versions in the BTS as needed. Can you > clarify if this affects as well way back to STABLE-BRANCH-1-4? We won't do any large change to 1.4 and may eventually remove smart card support from 1.4 - it is anyway very limited when not used with 2.2 gpg-agent and even then it does not support everything we have in 2.2 Salam-Shalom, Werner p.s. I am bit wondering whether escalating this bug report (https://dev.gnupg.org/T3844) via a CVE was a sensible strategy. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpZANs2lvu_L.pgp Description: PGP signature
Bug#891931: [pkg-gnupg-maint] Bug#891931: Bug#891931: gnupg: semantic change of the package to a meta-package results in upgrade bloat
On Sun, 4 Mar 2018 16:23, d...@fifthhorseman.net said: > the binary, "gnupg" refer to "gpg" plus the traditional "gpg-agent" and > "dirmngr", and then some complete "gnupg-all" wihch depends on You need to include at least gpgconf because this is an important tool. Not only for gpgme (which requires it to not fallback to gpg1) but also in regard to many howtos. Also gpg-connect-agent is very useful and often mentioned in replies to questions. gpg-wks-client is also build by default, but that could in theory be bundled with dirmngr. As you write, it is soon getting more and more complicated. To me only separating out dirmngr and gpg-wks-tools in a, say, gnupg-network may make some sense soto support users who don't want any network access. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp7T0jEyBQzF.pgp Description: PGP signature
Bug#889594: [pkg-gnupg-maint] Bug#889594: dgit started to fails its autopkgtests, with git gnupg2/2.2.4-1+
On Mon, 5 Feb 2018 13:48, ijack...@chiark.greenend.org.uk said: > gnupg2's agent startup code is full of races. Probably, the new I have seen no such bug report yet in upstream. Please submit one but use the upstream version and not the heavily patched Debian version. First try with the the defaults and only then try again in --supervised mode as used by Debian. > "Required" ? AIUI gnupg2 is supposed to start its own agent on > demand. Right. BTW, there is no "gnupg2" anymore, please use the name "gnupg" (or "gnupg1" if you are talking about the obsolete gnupg1 version). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpvPHPIdNbTJ.pgp Description: PGP signature
Bug#884517: [pkg-gnupg-maint] Bug#884517: Grab option should be reverted as enabled by default
On Sat, 16 Dec 2017 09:34, ber...@debian.org said: > passphrase by default. I didn't find any rationale behind this change. See: > https://github.com/gpg/gnupg/commit/3d78ae4d3de08398fabae5821045a3a1da6dadbe [ Please dont reference an arbirary repo mirror of gnupg. Either use the Debian repo or upstream. ] > I think this is a surprising change and a major security vector. It's > easy with a "follow mouse pointer" focus mode to get one password I don't think that this is a major security vector. In fact we even considered to create keys by default w/o passphrase. Most users don't have a tightened up box and those who have that know what to do: * agent: Option --no-grab is now the default. The new option --grab allows to revert this. Over the years we have received so many request to allow c+p of the passphrase and to treat the pinentry as a normal entry field. On most current desktops the grabbing does not work reliable or is ineffective due to the underlying GUI system. GNOME and macOS use there own passphrase manager anyway and more or less bypass the pinentry. On Windows it has no effect either. Also X and the need for grabbing is more and more replaced by Wayland or whatever thing distros like these days. Under the general directive to make GnuPG easier to use for the masses we changed some of the defaults. Those who have a need for securing there systems need to work up a lot on their configuration anyway, and thus adding a few options to GnuPG is just one more point on a list of hundreds of items to care about. Back in the days when Debian defaulted to the most secure configuration, the grab was of course justified. When I install a new Debian box today I have to disable a lot of services before I can reasonable say, I did something to secure that box. The question is whether we want to do something against mass surveillance or help a small group of targeted persons to secure their machines by default. We can't do both. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpQYzKqHzG3S.pgp Description: PGP signature
Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package
On Wed, 29 Nov 2017 23:56, d...@fifthhorseman.net said: > libgpgme provides *no functionality* whatsoever if gpg is not installed. That is not fully correct. For example in the Outlook plugin we used to use gpgme just to provide data objects with callback functionality and to connect to the so-called UI-server. It is also possible to use GPGME to connect to arbitrary Assuan servers, however except form the UI-Server (i.e. gpa --daemon) there are not may other Assuan servers outside of the GnuPG realm. The general idea about GPGME is an API for end-to-end encryption. It _might_ be that GPGME tests immediately for GnuPG availibility but that seems to be wrong. This should be delayed until the caller really requests an GPGME context for the OpenPGP or SMIME protocol. OTOH, given that there are many signed mails, Mutt will in any case try to verify those mails and thus run into a GPGME error. The erro handling should be more gracefully then. Unfortunately since the last 15 years or so I use Mutt only rarely. I can't say anything about Debian packing rules, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpUeelRZiZv3.pgp Description: PGP signature
Bug#882985: [pkg-gnupg-maint] Bug#882985: gcrypt: libgcrypt should use all memory pools for all secure allocations
On Tue, 28 Nov 2017 12:08, amul.s...@fisglobal.com said: > libgcrypt 1.8.1 contains the needed fixes and is compatile with GnuPG Actually libgcrypt 1.8.2 will contain those fixes. Right now they are only in the Git repo. I can release 1.8.2 on short notice. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp97hkQimyw1.pgp Description: PGP signature
Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package
On Tue, 28 Nov 2017 00:49, d...@fifthhorseman.net said: > The fact is, libgpgme explicitly fails in many use cases if gpg-agent or > dirmngr are not available. This partial, unpredictable failure is not It should return an error like No Agent, No Dirmngr, or No Pinentry. If not that is a bug either in GnuPG or gpgme. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpeF6l9Kqh3L.pgp Description: PGP signature
Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir
On Mon, 27 Nov 2017 18:24, ans...@debian.org said:
>> this is a deliberate choice by upstream.
>
> Yes, I saw it in the source :-/
There is a clear reason for this. In the past we had lot of troubles
with too freely configurable socket names and file systems which don't
support local sockets. Recall that GnuPG 2.x goes back to 2003 and it
has always used the local socket and fully relied on it for gpgsm - a
maybe nice application but nevertheless a tool which has been in wide
use since about 2005 by a few large sites. So with 2.2 removed the
trouble by using a fixed socket dir utilizing the /var/run hierarchy
which is on all known Unices a local file system supporting sockets.
The only overhead a _Unix_ sysadm has to do is putting this into
rc.local:
[ ! -d /run/user ] && mkdir /run/user
awk -F: = 1000 && $3 < 65000 {print $3}' \
| ( while read uid rest; do
if [ ! -d "/run/user/$uid" ]; then
mkdir /run/user/$uid
chown $uid /run/user/$uid
chmod 700 /run/user/$uid
fi
done )
Unfortunately Debian GNU/Linux is no longer a standard Unix system and
thus long standing things don't work anymore. nohup.
On such semi-Unix systems you need to work around their shortcomings; in
your case cron. Adding yet another thing and in particular XDG, which
more targets the desktop than the server, would make things more
complicate.
However, there is another proposal on the gnupg-devel list to try
another socketdir first. The suggestion is to try the socket names in
this order:
1. /var/run/gnupg/user/UID/S.gpg-agent
2. /var/run/user/UID/gnupg/S.gpg-agent
3. HOME/.gnupg/S.gpg-agent
The first one would be new. It has the advantage that systemd does not
know about it and thus can't remove it (and should not because it
belongs to gnupg). The disadvantage is that systemd does not remove
this directory and gpg-agent can't use the directory removal as trigger
to terminate itself. However, it is at the discretion of the sysadm to
create such directories in the first place.
The other option would be a global config file to list additional socket
directories to try. That would a require a bit more code but that shall
not be the problem.
> Yes, but that depends on the internal gpg logic to decide where to put
> sockets (which is unstable). If one could tell gpg which directory to
That is not unstable due to gpg but because something removes or creates
directories which are supposed to exist right after system startup or at
least before calling gpg the first time.
> It also requires to call gpgconf to configure the supervisor (and the
> location might change at any time in the future so gpgconf needs to be
The directories are fixed and won't change: Iff /var/run/user/UID exists
it is used, if not ~/.gnupg is used (with all its problems).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpiqhccJmTEI.pgp
Description: PGP signature
Bug#872368: [pkg-gnupg-maint] Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package
On Thu, 23 Nov 2017 13:48, linkfa...@yahoo.fr said: > Many mutt users do not do any secret key operation. I think those who > do need to create or setup a private key first - and probably put some To foster the use of end to end encryption we should get away from the need to install plugins. Encryption should be a core functionality of all MUAs and not something optional. For Mutt pinentry-curses should be installed first so that the default pinentry-gtk won't suck in all kind of unneeded X stuff. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpu82wdAcaC0.pgp Description: PGP signature
Bug#876144: [pkg-gnupg-maint] Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint
On Tue, 19 Sep 2017 00:52, d...@fifthhorseman.net said: > If other members of pkg-gnupg-maint could follow up on this bug to > state intent to participate, that would be great. The mix of Debian bugs related to gnupg and discussion on the packing or use is for me, as upstream author, not perfect because I sometimes miss important discussions which draw in bug reports which will anyway end up at dev.gnupg.org if upstream needs to care about. This I would be in favor of having a new mailing list. Shalom-Salam, Werner p.s. Sure, I can also change my procmail rules ;-) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpllQiNcKcaQ.pgp Description: PGP signature
Bug#874721: [pkg-gnupg-maint] Bug#874721: gnupg: the option --debug-quick-random seems to be ignored
> With gnupg 1.4 the corresponding option --quick-random had the desidered > effect, but since the move gnupg 2.1 this seems to be ignored, to the Your problem is that the keys are generated by gpg-agent. Thus you would need to use --debug-quick-random in gpg-agent.conf. However, this is not possible because we need to switch libgcrypt into quick random mode as early as possible and thus gpg-agent detects it only when given on the command line. Now, gpg-agent is started on demand by gpg and thus we need a way to put it on the command line. If you put this into the gpg.conf agent-program /usr/bin/gpg-agent|--debug-quick-random the agent will be started by gpg with an additional option of --debug-quick-random. The use of the pipe symbol is an ugly kludge but does its work. See gnupg/tests/openpgp/defs.scm for the other options we use for the gnupg internal regression tests. Another way is to start the agent first. The GPGME test suite does this and uses the script gpgme/tests/start-stop-agent. Yet another way is to gobally do away with /dev/random and use /dev/urandom (or the getrandom syscall). With Libgcrypt 1.8 this can be done by putting only-urandom into /etc/gcrypt/random.conf. That might in fact be a good idea for builder boxes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpBtiILMyPAe.pgp Description: PGP signature
Bug#874304: [pkg-gnupg-maint] Bug#874304: gpg: --refresh-keys became extremely verbose and complaining
On Wed, 6 Sep 2017 22:21, invernom...@paranoici.org said: > In the meantime, dear Werner, is there any additional information > I could provide to help you in pinpointing the bug? No, this is pretty obvious. Although I would not call it a bug ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpSMHDWjktfO.pgp Description: PGP signature
Bug#874304: [pkg-gnupg-maint] Bug#874304: gpg: --refresh-keys became extremely verbose and complaining
> but I get the same ultra-lengthy output. Okay, so the issue is a different one. I did not replicate it but looked for chnages which could have introduced it. > Once again, the --no-verbose option does not seem to help, while the -q > option seems to only suppress the old (useful) output, while retaining > the lengthy signature check output... --no-verbose simply removes as previous given --verbose (e.g. in gpg.conf). --quit instead should really shut up gpg. > a) If gpg repairs the key, while it refreshes it, why does it need > to repair it again and again, each time I refresh the same key > (which is unchanged on the keyserver)? > Is the key "broken" on the keyserver itself? The repair thing requires that all key signatures are checked and that is why I assumed it was the cuase for the verbose output. > b) While gpg is repairing the key, does it really need to be so > verbose and show one line for each verifiable signature? > Could gpg repair the key without producing all this output? > Maybe when the --no-verbose option has been passed? No real reasons, probably introduced during development. OTOH, I consider it useful to have _some_ diagnostics to see why an import takes long. Consider for example my key which has a lot of made up key signature for a fun effect. I'd appreciate if you can file a bug upstream at https://dev.gnupg.org Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpXeVLseo5if.pgp Description: PGP signature
Bug#874304: [pkg-gnupg-maint] Bug#874304: gpg: --refresh-keys became extremely verbose and complaining
On Mon, 4 Sep 2017 22:34, invernom...@paranoici.org said: > The output seems to be (more or less) the old output of > "gpg --refresh-keys $KEYID", combined with the output of > "gpg --check-sigs $KEYID". That is likley due to * gpg: By default try to repair keys during import. New sub-option no-repair-keys for --import-options. in 2.1.22. To avoid this you should put no-repair-keys into gpg.conf. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpW7UAYncn2j.pgp Description: PGP signature
Bug#868550: [pkg-gnupg-maint] Bug#868550: Bug#868550: reprepro seems to provide a repro
On Thu, 24 Aug 2017 22:08, ijack...@chiark.greenend.org.uk said: > I have a log generated by this > log-file /home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/AGENT.log > in gpg-agent.conf but due to an infelicitly in my arrangments all of Use log-file socket:///home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/S.log and run watchgnupg --force --time-only \ /home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/S.log >AGENT.log in another tty to get combined output. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpwpHjm9CD6s.pgp Description: PGP signature
Bug#867268: [pkg-gnupg-maint] Bug#867268: dirmngr: Can't set nameserver port
On Wed, 5 Jul 2017 12:43, he...@debian.org said: > and I actually wants to make sure that gnupg is using dns over tor. FWIW, --use-tor forces the use of Tor for DNS lookups. This does not use the limited Tor features for DNS but by default uses the DNS server 8.8.8.8. If you want to use another DNS server you can set it with --namesever. Make sure to use a high traffic public server and not some private or low-traffic server. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpUTlUam5Dk0.pgp Description: PGP signature
Bug#866964: Fwd: mpi_set_secure leads to heap corruption
On Tue, 4 Jul 2017 03:05, gni...@fsij.org said: > Yes. While the patch is right, I followed the suggestion for less > surprise. The reason why it was falsely allocated as nlimbs is likely to save on secure memory. Now that we auto-grow the secure memory this is not needed and thus this simple and correct fix is sufficient. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpplv_FEHN8G.pgp Description: PGP signature
Bug#835394: [pkg-gnupg-maint] Bug#835394: gnupg-agent: gpg agent refusing ssh agent work
On Tue, 20 Jun 2017 07:09, raphael.d...@gmail.com said: > $ eval $(gpg-agent --enable-ssh-support) Please don't do that anymore. SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" export SSH_AUTH_SOCK is the way to go. > automatically provides two of my keys. ssh-add -D does not seem to > remove them from the (gpg)-agent. Right. gpg-agent takes a copy of the key and stored it in its own DB. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpY87nQUseua.pgp Description: PGP signature
Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs
On Thu, 15 Jun 2017 17:43, d...@fifthhorseman.net said: > I believe that killing gpg-agent kills scdaemon, which de-initializes > the smartcard on shutdown, which takes it out of authenticated mode. Right the smartcard is power-cycled and thus it clears all its transient state. > on whether that's feasible or not. it would be nice to have the > semantics of the cache ttl be the same, regardless of whether a key is > stored on a smartcard or not. The properties of a smartcard and an on-disk key are very different. In fact a smartcard should be considered another gpg-agent to which gpg-agent delegates its operation. The properties of the smartcard are controlled by the card; for example an OpenPGP card can be configured to require a PIN for each signing operation. Other types of smartcards have different conditions for example cards for quailified signatures allow only a cewrtain number of signatures before a PIN needs to be re-entered as well as more complicated schemes. Using the passphrase TTL also for a card does not really match. A workaround is to force a reset of the card by putting card-timeout N in scdaemon.conf which shuts down the card after N seconds. Well, as of now N is just a binary flag to tell sdaemon to shutdown the card at the next timer tick; thus immediately after an operation. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpwnqfmacdKZ.pgp Description: PGP signature
Bug#863221: [pkg-gnupg-maint] Bug#863221: Bug#863221: Bug#863221: dirmngr doesn't reload resolv.conf
Okay froods, https://dev.gnupg.org/rGb5f356e9fba2d99909f8f54d7b7e6836bed87b68 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpkuq5DgyTJT.pgp Description: PGP signature
Bug#863221: [pkg-gnupg-maint] Bug#863221: Bug#863221: dirmngr doesn't reload resolv.conf
On Wed, 24 May 2017 23:36, d...@fifthhorseman.net said: > full dirmngr flush on every network change -- in particular, that would > mean that every time we join the network, we would be more likely to > announce to the network about the various CRLs and keyservers that we're Good point. That would outweigh the chance that a new network connection results in a different on the keyserver. The latter should anyway be handled by dirmngr gracefully. I'll see what I can do. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpOXJcy9_uP5.pgp Description: PGP signature
Bug#863221: [pkg-gnupg-maint] Bug#863221: dirmngr doesn't reload resolv.conf
Hi! When you switch the laptop connection you should flush dirmngr anyway and thus I do not consider the need to do this just for the resolver. gpgconf --reload dirmngr in the ifup script should do that job. Note that gpgconf won't start a component on --reload or --kill if it is not yet started. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpKgG4dhRVDi.pgp Description: PGP signature
Bug#860745: [pkg-gnupg-maint] Bug#860745: Please suggest a fix for "server $SOMETHING is older than us" message
On Tue, 25 Apr 2017 22:31, d...@fifthhorseman.net said: > Do you recommend terminating all per-user gpg-agent and dirmngr > instances upon package upgrade? This would be a significant change from I can't decide this. What I do if something goes wrong after an update is to look into the Debian.NEWS.gz and changelog/Debian.gz. However for a security fix I would suggest to restart the daemons on installation or mail/show a respective message. > I just filed it here: https://dev.gnupg.org/T3117 Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpqJJf_IUUfh.pgp Description: PGP signature
Bug#860745: [pkg-gnupg-maint] Bug#860745: Please suggest a fix for "server $SOMETHING is older than us" message
On Sun, 23 Apr 2017 11:09, enr...@debian.org said: > Technically it sounds like the right thing. I had no idea I could get > hints with --verbose, though, so I wouldn't have seen it. Isn't it the first thing with Unix tools to add -v when you wonder what is going on ;-). > Could gpg tell dirmngr/gpg-agent to kill themselves the next time they > are idle and not servicing anyone? I imagine that would do the restart Well, correct installation of a software update is the task of the sysadmin or the distribution. This is the same as an update of libc or other libraries; something(tm) must happen to restart all processes using an updated library. We print the notice only to help in debugging for those who build the software on their own and forget a task. > cosmetic thing, or could there be a malfunction, like an ABI mismatch, > or an attack vector, like a security issue having been fixed in the new > server version, and needing a restart to take effect? Most things keep on on working even with an older versions. We try to make sure not to break things. However, you won't have access to bug fixes and new features. People sometimes wonder why they didn't notice a change after updating to a new gpg version and continue to complain - that is why we have this warning. Make the life easer for the maintainers. > If it's just cosmetic, I'd suggest to move the warning to --verbose > hints as well. If there is a danger, I'd like the danger to be spelled > out clearly, like: > > gpg: WARNING: server 'dirmngr' is older than us (2.1.17 < 2.1.18). Run with > --verbose for details. > gpg: further info: Outdated servers may lack important security fixes. > gpg: further info: A restart can be forced using "gpgconf --kill all" Hmmm. Can you file a report to bugs.gnupg.org ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp929cZHKnao.pgp Description: PGP signature
Bug#860745: [pkg-gnupg-maint] Bug#860745: Please suggest a fix for "server $SOMETHING is older than us" message
On Wed, 19 Apr 2017 18:53, d...@fifthhorseman.net said: > I wouldn't want to encourage people to restart the daemons -- i'd rather > encourage them to terminate them and let the new versions be restarted Right. > gpg: WARNING: server 'dirmngr' is older than us (2.1.17 < 2.1.18). Run > 'gpgconf --kill dirmngr' to terminate it. A new instance will be restarted > as needed. We already have some hints messages printed in --verbose mode, like: gpg: further info: Tor is not properly configured So I would suggest to print gpg: further info: A restart can be forced using "gpgconf --kill all" > Alternately, it might be nice for gpg to try to effect the restart > itself (though i worry that could get into a loop, since gpg itself is Not a good idea in case you have other sessions running or you need the cache. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpTU_SsvU0cH.pgp Description: PGP signature
Bug#568375: [pkg-gnupg-maint] Bug#568375: Bug#568375: gnupg-agent: does not work with `git tag -s`
On Wed, 15 Feb 2017 20:52, d...@fifthhorseman.net said: > However, this will cause problems for people dealing with a smartcard > with a PGPv3 key on it. I doubt that you can put a PGP-2 key on an OpenPGP smartcard. We require a SHA-1 fingerprint. > hm, bummer. a configure option to keep the agent access but not the > direct smartcard access would be nice to have. Feel free to add a request, but I dount that we will implement that. Maintaining the smartcard code in 1.4 is way to much work. Testing is the major problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgppBYdHRolgb.pgp Description: PGP signature
Bug#568375: [pkg-gnupg-maint] Bug#568375: Bug#568375: gnupg-agent: does not work with `git tag -s`
On Wed, 15 Feb 2017 16:23, d...@fifthhorseman.net said: > should we adjust the build of 1.4 in debian to patch out the direct > access of smartcards? if we use --disable-card-support during > ./configure will that disable use of the agent for smartcards as well, > or will it just remove the direct access? --disable-card-support removes all support for smartcards. I would not mind if you use that option. --disable-agent-support without --disable-card-support will only use the direct smartcard access code. Thus is is the opposite of what you want. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpFZUVuOeisf.pgp Description: PGP signature
Bug#568375: [pkg-gnupg-maint] Bug#568375: Bug#568375: gnupg-agent: does not work with `git tag -s`
On Tue, 14 Feb 2017 00:55, d...@fifthhorseman.net said: > * gpg 1.4 expects to connect directly to the active smartcard. 2.1 >expects access to the smartcard to be mediated by the scdaemon >process. I don't know what happens if both of these systems try to >access a single smartcard concurrently, but i imagine it's not If gpg 1.4 can access the card via agent+scdaemon it uses these daemons to access the card. Thus many things should work. If 1.4 can't do that it uses an old copy of the code used by scdaemon to access the card. That code is old and thus a lot of things won't work. I can't suggest to use 1.4 with smardcards. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpCLzy6TNyOz.pgp Description: PGP signature
Bug#703062: [pkg-gnupg-maint] Bug#703062: please add udev rules for cardman 4040
On Tue, 14 Feb 2017 06:47, gni...@fsij.org said: > If you still have the device, please let me know if it works. I'm I have a device but no pcmcia/pc-card slot on regular used machines. > afraid it's too old to support current version of OpenPGP card with > RSA key length >= 2048. Yep, that is why I moved to USB tokens. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpgh0X9YioQN.pgp Description: PGP signature
Bug#854005: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works
On Mon, 6 Feb 2017 07:04, gni...@fsij.org said: > simultaneously/interchangeably on a system. scdaemon is not a system- > wide service for all smartcards, but it's specific to OpenPGP card and > it's per user service for gpg-agent. FWIW: Scdaemon supports several smartcards and certain other cards than the OpenPGP card are in active use (in particular for S/MIME). However, scdaemon does not make use of any "middleware" commonly seen with these cards. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpHHWK6z_3Ce.pgp Description: PGP signature
Bug#854038: [pkg-gnupg-maint] Bug#854038: [gnupg] --sender option seems not to be respected when verifying
On Fri, 3 Feb 2017 11:47, ktns...@gmail.com said: > gpg(1) reads that `--sender' option can be used to suppress some uids > printed by TOFU code when verifying messages, but the option seems to > have no effect. It does not do much right now but we have it here so that GPGME can provide it. What is currently does is to use the first given mail address for the signer's user id signature sub-packet; but only if the user id was not specified by mail address (-u). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp5xGOMPaUMD.pgp Description: PGP signature
Bug#851707: [pkg-gnupg-maint] Bug#851707: pinentry-gtk-2 frequently fails to grab the keyboard under awesome
On Thu, 2 Feb 2017 19:29, ber...@debian.org said:
> I am fixing with this patch. Only lightly tested.
FWIW, I forgot to push a fix I had in my local repo. Just did this, put
also not tested. This is basically the same as yours but w/o any delay.
Shalom-Salam,
Werner
commit b0e0bdeac5d40ca645afc9017778b39a26303523
Author: Werner Koch <w...@gnupg.org>
Date: Wed Jan 11 18:40:17 2017 +0100
gtk2: Fix a problem with fvwm
* gtk+-2/pinentry-gtk-2.c (grab_pointer): Take care of
GDK_GRAB_ALREADY_GRABBED.
--
Debian-bug-id: 850708
Co-authored-by: Vincent Lefevre <vinc...@vinc17.net>
Signed-off-by: Werner Koch <w...@gnupg.org>
Modified gtk+-2/pinentry-gtk-2.c
diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c
index 473c4aa..e37601f 100644
--- a/gtk+-2/pinentry-gtk-2.c
+++ b/gtk+-2/pinentry-gtk-2.c
@@ -203,7 +203,12 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer
data)
(void)data;
/* Change the cursor for the duration of the grab to indicate that
- something is going on. */
+ * something is going on. The fvwm window manager grabs the pointer
+ * for a short time and thus we may end up with the already grabbed
+ * error code. Actually this error code should be used to detect a
+ * malicious grabbing application but with fvwm this renders
+ * Pinentry only unusable. Thus we try again several times also for
+ * that error code. See Debian bug 850708 for details. */
/* XXX: It would be nice to have a key cursor, unfortunately there
is none readily available. */
cursor = gdk_cursor_new_for_display (gtk_widget_get_display (win),
@@ -215,7 +220,8 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer
data)
NULL /* confine to */,
cursor,
gdk_event_get_time (event));
- while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE);
+ while (tries++ < max_tries && (err == GDK_GRAB_NOT_VIEWABLE
+ || err == GDK_GRAB_ALREADY_GRABBED));
if (err)
{
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpQN_FqPA2gb.pgp
Description: PGP signature
Bug#850269: [pkg-gnupg-maint] Bug#850269: gpgme1.0: FTBFS randomly (not enough entropy)
On Tue, 24 Jan 2017 01:45, d...@fifthhorseman.net said: > to drive gpg, though. I think we do still need that test in gpgme, just > like we'd need a higher-level test for a mail user agent that was Agreed. Upstream commit a98951a * tests: Use --debug-quick-random for tests will go into 1.8.1 (to be released soon) to address the problem of requiring a lot of entropy. In case you want to cherry-pick you may want to look for a few related commits. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgplKPXzgCw8Q.pgp Description: PGP signature
Bug#853935: [pkg-gnupg-maint] Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess
On Thu, 2 Feb 2017 11:37, a...@debian.org said: > Trying to use it on Sid or Stretch causes one pinentry window popup per > guessed try (i.e. potentially thousands). And since pinentry usually I don't know rephase but according to the description it should not use gpg to test the passphrase. The way such a tool should work is to extra the protected key and then use Libgcrypt directly to test all variants. Shall the GnuPG team look on how we can improve and fix that tool? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpgn18mt667E.pgp Description: PGP signature
Bug#851298: [pkg-gnupg-maint] Bug#851298: 10 second delay on first ssh use (sleeps in agent_libgcrypt_progress_cb)
On Fri, 13 Jan 2017 20:02, wea...@debian.org said: > I suspect the callback shouldn't try to sleep if the entropy is being > read from a non-blocking source, or maybe the callback shouldn't be The sleeping is done to reqlinguish control to other threads. Libgcrypt 1.7 unfortunately needs to resort to the progress callback to do that. Changing the sleep amount to 0 or better by replacing the sleep call with gpgrt_yield () should be sufficient. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpLBDX1RBox7.pgp Description: PGP signature
Bug#850708: [pkg-gnupg-maint] Bug#850708: Bug#850708: gpg: decryption failed: No secret key
On Wed, 11 Jan 2017 12:22, vinc...@vinc17.net said:
> This wasn't the problem. The problem was the incorrect error code:
> GDK_GRAB_NOT_VIEWABLE instead of GDK_GRAB_ALREADY_GRABBED
I do not think this is tan incorrect error code but we should look at
GDK_GRAB_ALREADY_GRABBED too:
/* Change the cursor for the duration of the grab to indicate that
* something is going on. The fvwm window manager grabs the pointer
* for a short time and thus we may end up with the already grabbed
* error code. Actually this error code should be used to detect a
* malicious grabbing application but with fvwm this renders
* Pinentry only unusable. Thus we try again several times also for
* that error code. See Debian bug 850708 for details. */
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From f7ceec0fea9f7f2043b835bbe70fc8b1a91d8770 Mon Sep 17 00:00:00 2001
From: Werner Koch <w...@gnupg.org>
Date: Wed, 11 Jan 2017 18:40:17 +0100
Subject: [PATCH] gtk2: Fix a problem with fvwm
* gtk+-2/pinentry-gtk-2.c (grab_pointer): Take care of
GDK_GRAB_ALREADY_GRABBED.
--
Debian-bug-id: 850708
Co-authored-by: Vincent Lefevre <vinc...@vinc17.net>
Signed-off-by: Werner Koch <w...@gnupg.org>
---
gtk+-2/pinentry-gtk-2.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c
index 473c4aa..e37601f 100644
--- a/gtk+-2/pinentry-gtk-2.c
+++ b/gtk+-2/pinentry-gtk-2.c
@@ -203,7 +203,12 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer data)
(void)data;
/* Change the cursor for the duration of the grab to indicate that
- something is going on. */
+ * something is going on. The fvwm window manager grabs the pointer
+ * for a short time and thus we may end up with the already grabbed
+ * error code. Actually this error code should be used to detect a
+ * malicious grabbing application but with fvwm this renders
+ * Pinentry only unusable. Thus we try again several times also for
+ * that error code. See Debian bug 850708 for details. */
/* XXX: It would be nice to have a key cursor, unfortunately there
is none readily available. */
cursor = gdk_cursor_new_for_display (gtk_widget_get_display (win),
@@ -215,7 +220,8 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer data)
NULL /* confine to */,
cursor,
gdk_event_get_time (event));
- while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE);
+ while (tries++ < max_tries && (err == GDK_GRAB_NOT_VIEWABLE
+ || err == GDK_GRAB_ALREADY_GRABBED));
if (err)
{
--
2.8.1
pgpGXGHrNg0OS.pgp
Description: PGP signature
Bug#850475: [PATCH] common: Avoid unnecessary ambiguity in argparse.
On Tue, 10 Jan 2017 22:16, d...@fifthhorseman.net said: > If two struct ARGPARSE_OPTS share a prefix in their long_opt name, but > have the exact same short_opt and flags, they are aliases and not Smart. Please push with the usual two dashes before the free form text. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpBN3Xrqw8Gn.pgp Description: PGP signature
Bug#850656: [pkg-gnupg-maint] Bug#850656: gnupg-agent: Please allow config to specify fast RNG
On Sun, 8 Jan 2017 23:32, ijack...@chiark.greenend.org.uk said:
> dgit test suite. But I have to jump through hoops to do so: I end up
> putting a stunt gpg program on the PATH so that I can pass
> --agent-program.
Obviously we had the same problem in the test suite and thus we
implemented an ugly hack to pass additional options via the
--agent-program option:
else if ((s=strchr (agent_program, '|')) && s[1] == '-' && s[2]=='-')
{
/* Hack to insert an additional option on the command line. */
program = xtrystrdup (agent_program);
if (!program)
{
gpg_error_t tmperr = gpg_err_make (errsource,
gpg_err_code_from_syserror ());
xfree (sockname);
assuan_release (ctx);
return tmperr;
}
p = strchr (program, '|');
*p++ = 0;
program_arg = p;
}
We use use it like this in the test suite:
(define (create-gpghome)
(log "Creating test environment...")
(srandom (getpid))
(make-test-data "random_seed" 600)
(log "Creating configuration files")
(for-each
(lambda (name)
(file-copy (in-srcdir (string-append name ".tmpl")) name)
(let ((p (open-input-output-file name)))
(cond
((string=? "gpg.conf" name)
(if have-opt-always-trust
(display "no-auto-check-trustdb\n" p))
(display (string-append "agent-program "
(tool 'gpg-agent)
"|--debug-quick-random\n") p)
(display "allow-weak-digest-algos\n" p))
((string=? "gpg-agent.conf" name)
(display (string-append "pinentry-program " PINENTRY "\n") p)
'("gpg.conf" "gpg-agent.conf")))
I would suggest to have a close look at the test suite to see how to do
certain things. For example we recently introduced a --build-prefix
option to gpgconf to setup a different build directory to replace other
hacks to use the binaries from the build directory:
(define gpg-components (apply gpg-conf
`(,@(if installed? '()
(list '--build-prefix (getenv "objdir")))
--list-components)))
For help with using gnupg I would kindly suggest to mail to gnupg-devel
and not to open a bug for each question.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgp38J2BysaND.pgp
Description: PGP signature
Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup
On Sun, 8 Jan 2017 18:47, ijack...@chiark.greenend.org.uk said: > follow, but I am still stumped as to get debugging output from > gpg-agent. I tried making a stunt shell script to pass --debug-all The best way to debug the system is to --8<---cut here---start->8--- log-file socket:// verbose debug ipc --8<---cut here---end--->8--- into the respective configure files. For gpg-agent.conf you way also add "debug-pinentry". Which debug flags you nee depends on what you want to debug. ipc is a good start the other debug flags are listed in the man pages or use $ gpg-agent --debug help gpg-agent[7724]: reading options from '/home/wk/.gnupg/gpg-agent.conf' gpg-agent[7724]: available debug flags: gpg-agent[7724]: 2 mpi gpg-agent[7724]: 4 crypto gpg-agent[7724]: 32 memory gpg-agent[7724]: 64 cache gpg-agent[7724]:128 memstat gpg-agent[7724]:512 hashing gpg-agent[7724]: 1024 ipc gpg-agent[7724]: gpg-agent running and available to get a list of supported debug flags. They slightly differ between tools and you most likely don't want "hashing" becuase that creates a file per hash context. The best way to view or collect the debug output is to start watchgnupg --force --time-only $(gpgconf --list-dirs socketdir)/S.log in another xterm See also the watchnug man page. The use of gpgconf to figure out the log socket and the abbreviated "socket://" log-file is currently missing From that man page. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpqNCxqNkQIl.pgp Description: PGP signature
Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup [and 1 more messages])
On Sun, 8 Jan 2017 23:46, ijack...@chiark.greenend.org.uk said: > gpg-agent is AIUI the main program which handles key material. We > cannot afford for it to be afflicted by threading bugs. Please point out a single threading bug in gpg-agent or any other part of GnuPG. But before you point me to your patches please learn about nPth (and its predecessor GNU Pth) and understand why we are not using Posix threads directly. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpOWS6Bpr4gG.pgp Description: PGP signature
Bug#848999: [pkg-gnupg-maint] Bug#848999: pinentry-gtk2: Fails to work, appears as gpg-agent not working
Hi! I have no insight on why pinentry fails for you. As a workaround you may try "no-grab" in gpg-agent.conf Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpUjYl93f_Mz.pgp Description: PGP signature
Bug#850475: [pkg-gnupg-maint] Bug#850475: Addition of --clear-sign alias breaks --clear
On Fri, 6 Jan 2017 21:54, wea...@debian.org said: > So for decades "gpg --clear" has worked as shorthand for "gpg > --clearsign". Same for --edit, which is now --edit-key or --edit-card. The abbreviated commands are convenience for interactive use and not expected to be used in scripts etc. Thus we we won't change that. BTW: I have never used --clear because that is too much to type. I always use -sb which goes back to PGP-2. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpn32DBXZltz.pgp Description: PGP signature
Bug#841143: [pkg-gnupg-maint] Bug#841143: gnupg2 races and hangs
On Thu, 5 Jan 2017 18:25, ijack...@chiark.greenend.org.uk said: > I also tried to look at the gnupg2 source code. After reading it I > was not surprised the agent startup is racy, and I was very > discouraged from trying to debug it. Is there a design document or > comment somewhere which I missed, which explains how the startup Please explain why starting gpg-agent is racy. We are doing this for many years w/o problems. The code is well commented. Start at gnupg/g10/call-agent.c:start_agent. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpwrVK83JQBL.pgp Description: PGP signature
Bug#849845: [pkg-gnupg-maint] Bug#849845: Bug#849845: dirmngr: Can't resolve keyserver hostname anymore
On Mon, 2 Jan 2017 13:46, intrig...@debian.org said: > ... which is expected if querying 127.0.0.1, that doesn't support > SRV records. The question is whether we should gracefully handle this failure and return 0 records found (as done < 2.1.17)? > Jan 02 13:37:57 dirmngr[8281]: DBG: dns: > resolve_dns_name(hkps.pool.sks-keyservers.net): Success > Jan 02 13:37:57 dirmngr[8281]: can't connect to > 'hkps.pool.sks-keyservers.net': no IP address for host I can't replicate this neither when running dirmnagr as dirmngr --options /dev/null --debug ipc,dns -v \ --log-file socket:// --daemon nor when bypassing the new libdns: dirmngr --options /dev/null --debug ipc,dns -v \ --log-file socket:// --daemon --standard-resolver What options do you have in your dirmngr.conf ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp__tobb90N5.pgp Description: PGP signature
Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore
Hi!
The attached patch fixes this problem.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From b200e636ab20d2aa93d9f71f3789db5a04af0a56 Mon Sep 17 00:00:00 2001
From: Werner Koch <w...@gnupg.org>
Date: Mon, 2 Jan 2017 10:00:33 +0100
Subject: [PATCH] dirmngr: Strip root zone suffix from libdns cname results.
* dirmngr/dns-stuff.c (resolve_name_libdns): Strip trailing dot.
(get_dns_cname_libdns): Ditto.
--
Signed-off-by: Werner Koch <w...@gnupg.org>
---
dirmngr/dns-stuff.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dirmngr/dns-stuff.c b/dirmngr/dns-stuff.c
index a31b073..f2e1df9 100644
--- a/dirmngr/dns-stuff.c
+++ b/dirmngr/dns-stuff.c
@@ -732,6 +732,10 @@ resolve_name_libdns (const char *name, unsigned short port,
err = gpg_error_from_syserror ();
goto leave;
}
+ /* Libdns appends the root zone part which is problematic
+ * for most other functions - strip it. */
+ if (**r_canonname && (*r_canonname)[strlen (*r_canonname)-1] == '.')
+(*r_canonname)[strlen (*r_canonname)-1] = 0;
}
dai = xtrymalloc (sizeof *dai + ent->ai_addrlen -1);
@@ -1899,6 +1903,13 @@ get_dns_cname_libdns (const char *name, char **r_cname)
*r_cname = xtrystrdup (cname.host);
if (!*r_cname)
err = gpg_error_from_syserror ();
+ else
+{
+ /* Libdns appends the root zone part which is problematic
+ * for most other functions - strip it. */
+ if (**r_cname && (*r_cname)[strlen (*r_cname)-1] == '.')
+(*r_cname)[strlen (*r_cname)-1] = 0;
+}
leave:
dns_free (ans);
--
2.8.1
pgp9mvglUVpLn.pgp
Description: PGP signature
Bug#848951: [pkg-gnupg-maint] Bug#848951: gnupg: Utilize multiple cores on CPU for encryption and decryption (and compression)
On Wed, 21 Dec 2016 17:47, witold.bary...@gmail.com said: > Everybody know CTR is easy to parallelize and easy to understand implement, CTR is a reincarnation of RC4 - bug wise. Nobody with a sane mind wants a counter mode. It is also not an AE mode and thus nothing to be used for new protocols. > CCM is another options - > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ccm/ccm.pdf FWIW, here are the numbers fro current Libgcrypt on amd64: AES| nanosecs/byte mebibytes/sec cycles/byte CFB enc | 1.77 ns/B 537.9 MiB/s 4.08 c/B -- non-AE CFB dec | 0.373 ns/B2554.7 MiB/s 0.859 c/B -- non-AE CTR enc | 0.396 ns/B2409.6 MiB/s 0.910 c/B -- non-AE CTR dec | 0.396 ns/B2409.9 MiB/s 0.910 c/B -- non-AE CCM enc | 2.19 ns/B 435.6 MiB/s 5.04 c/B CCM dec | 2.25 ns/B 423.7 MiB/s 5.18 c/B GCM enc | 1.07 ns/B 890.9 MiB/s 2.46 c/B GCM dec | 1.07 ns/B 890.8 MiB/s 2.46 c/B OCB enc | 0.440 ns/B2165.9 MiB/s 1.01 c/B OCB dec | 0.453 ns/B2107.5 MiB/s 1.04 c/B So, CCM is pretty slow. The whole reason why we have that slow CCM is due to patent fears. And it is cumbersome to work with. > still most of the work can be parallelized, and if authentication stage is > faster than encryption, it should not be a bottlneck for performance. It is anyway I/O bounded. This is why I wrote theoretical speedup. For backing up large amounts of data, gpg is not an optimal tool. If there is a real need for a faster tool we could add one to GnuPG which does only one thing (symmetric encryption) without the various options possible in OpenPGP. bugs.gnupg.org has a “wish” category. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpeyacKGKmHu.pgp Description: PGP signature
Bug#848951: [pkg-gnupg-maint] Bug#848951: gnupg: Utilize multiple cores on CPU for encryption and decryption (and compression)
On Wed, 21 Dec 2016 14:33, boyan.pen...@gmail.com said: > Is this straighforward? What changes should I make to gpg.conf to give > this a shot? You need to convince the OpenPGP WG that OCB is the way forward. The prefer other and slower modes due to patents on PCB. However, these patents are freely licensed to basically all software. And then we need to implement this in GnuPG... Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3X4L04ube_.pgp Description: PGP signature
Bug#848951: [pkg-gnupg-maint] Bug#848951: gnupg: Utilize multiple cores on CPU for encryption and decryption (and compression)
On Wed, 21 Dec 2016 06:57, witold.bary...@gmail.com said: > Using cipher and compression algorithms that can utilize multiple cores It is not possible to parallelize encryption using the CFB mode as required by OpenPGP. In theory it would be possible to run the hashing (which is also run on the plaintext) on a different thread. However that would complicate matters a lot and I doubt that there will be a real benefit. What would really improve throughput is a different encryption mode to replace CFB and its SHA-1 based MDC. My suggestion to the WG is the use of OCB which would be a lot faster: On an X220 you get these values AES| nanosecs/byte mebibytes/sec cycles/byte CFB enc | 1.77 ns/B 537.9 MiB/s 4.08 c/B CFB dec | 0.373 ns/B2557.6 MiB/s 0.858 c/B OCB enc | 0.436 ns/B2189.4 MiB/s 1.00 c/B OCB dec | 0.452 ns/B2107.9 MiB/s 1.04 c/B | nanosecs/byte mebibytes/sec cycles/byte SHA1 | 1.88 ns/B 507.7 MiB/s 4.32 c/B Thus the theoretical speedup would be CFBSHA1 OCB enc 1.77 + 1.88 = 3.65 0.44 8 times dec 0.37 + 1.88 = 2.25 0.45 5 times Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpijXZUWhdU1.pgp Description: PGP signature
Bug#847552: [pkg-gnupg-maint] Bug#847552: gnupg: decrypting after X pinentry is sometimes slow: around 10 seconds on a small file
On Sun, 18 Dec 2016 19:34, vinc...@vinc17.net said: > Couldn't it cache the RNG status on disk? That is whqt random_seed is used for. However we need to get a few extra bytes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpypmNt6hVtW.pgp Description: PGP signature
Bug#847552: [pkg-gnupg-maint] Bug#847552: gnupg: decrypting after X pinentry is sometimes slow: around 10 seconds on a small file
On Sun, 18 Dec 2016 17:00, jspri...@debian.org said: > which led me to this patch: This is agent: Kludge to mitigate blocking calls in Libgcrypt. * agent/gpg-agent.c (agent_libgcrypt_progress_cb): Sleep for 100ms on "need_entropy". -- During key generation Libgrypt will read from /dev/random which may block. Libgcrypt is not nPth aware and thus the entire process will block. Fortunately there is also a select with a short timeout to run the progress callback. We detect this in gpg-agent and introduce a short delay to give other threads (i.e. connections) an opportunity to run. This alone is not sufficient, an updated Libgpg-error is also required to make the lock functions nPth aware. Are you also using libgpg_error 1.25? If there is not enough entropy available it should not harm to wait a bit and relinquish control to other threads. Unless other processes content about entropy fom the kernel this sleep call can't be the reasons for your delays. Well, we could reduce it to 20ms or so. > needs entropy when doing gpg -d. gpg needs to initialize its own RNG in almost all cases. This is required for the generation of an internal cookie to verify --clearsigned messages and also for the RSA blinding (to mitigate side channel attacks). Do you have a ~/.gnupg/random_seed ? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpItg6RstYKq.pgp Description: PGP signature
Bug#847552: [pkg-gnupg-maint] Bug#847552: gnupg: decrypting after X pinentry is sometimes slow: around 10 seconds on a small file
On Fri, 9 Dec 2016 13:04, vinc...@vinc17.net said: > $ gpg -d note.gpg > gpg: AES encrypted data > gpg: cancelled by user "cancelled" was unfortunately a catch-all error of pinentries. > Note: I got this error immediately, and no windows are opened. > > A few minutes later, everything was OK. That is strange. It might be that the agent popped up a pinentry before the one you used but for some reasons this did not show up on your screen. After a long timeout that invisible pinentry gets killed and you get your pinentry. Pinentry access is serialized. Debug hint: Put --8<---cut here---start->8--- log-file socket:// debug ipc debug-pinentry verbose --8<---cut here---end--->8--- into gpg-agent.conf and restart the agent. Then run in another xterm watchgnupg --force --time-only $(gpgconf --list-dirs socketdir)/S.log to immediately see what the agent is doing. it won't show confidential stuff so you may even be able to post snippets from the output. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgprk3ZdlCYMq.pgp Description: PGP signature
Bug#847552: [pkg-gnupg-maint] Bug#847552: gnupg: decrypting after X pinentry is sometimes slow: around 10 seconds on a small file
Can you please try to switch to pinentry-gtk-2 to see whether this makes a difference? Either change the symlink or put pinentry-program /usr/bin/pinentry-gtk-2 into gpg-agent.conf and gpgconf --reload gpg-agent Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpziC1tqvyPr.pgp Description: PGP signature
Bug#847206: [pkg-gnupg-maint] Bug#847206: Bug#847206: gpg-agent: can't connect to the agent: File name too long
On Tue, 6 Dec 2016 19:07, d...@fifthhorseman.net said: > You could work around it by creating a gnupg_home dir for your tests at > the top level of your build tree, and it would fit within the requisite Sandro: Assuming 2.1, you can also do this: GNUPGHOME= export GNUPGHOME gpgconf --create-socketdir [.. your test code ...] which creates a dedicated directory below /run/user to be used for sockets. For cleanup you can use --remove-socketdir; use -v to see what it actually does. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpXUyu7ORr9l.pgp Description: PGP signature
Bug#846834: [pkg-gnupg-maint] Bug#846834: gnupg: ERRSIG rc codes are no longer correct (breaks 0install)
On Sat, 3 Dec 2016 16:29, tal...@gmail.com said:
> (33554441 is 0x0x209)
As a quick fix you can mask the low 16 bits which are the actual error
code. The higher bits are
used to indicate the source of the error. These structured error codes
are used in all GnuPG components for size about 2003.
For testing error codes we always use a gpg_err_code(rc) inline
functions and thus we did not noticed this change. The reason we see
this now in 2.1.16 is that somewhere in the code we added the error
sources to an error code (code taken from gpg-1.4 used 0 for the error
source) and this ended up in the ERRSIG status line.
I agree that this breaks the API and needs to be fixed. If we want to
know the full error code with source we need to add a new arg to the
ERRSIG line but we can't change the existing values.
Masking the error code in your code won't harm and is probably the
fastest fix. I also pushed a commit with the real fix:
commit ef10c348bffc7dad19e1832bebc453755d209420
Author: Werner Koch <w...@gnupg.org>
Date: Sat Dec 3 21:35:45 2016 +0100
gpg: Fix error code arg in ERRSIG status line.
* g10/mainproc.c (check_sig_and_print): Use gpg_err_code to return an
error code in ERRSIG.
--
Debian-bug-id: 846834
Signed-off-by: Werner Koch <w...@gnupg.org>
Modified g10/mainproc.c
diff --git a/g10/mainproc.c b/g10/mainproc.c
index 30e19fe..ac2ab03 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -2223,7 +2223,7 @@ check_sig_and_print (CTX c, kbnode_t node)
snprintf (buf, sizeof buf, "%08lX%08lX %d %d %02x %lu %d",
(ulong)sig->keyid[0], (ulong)sig->keyid[1],
sig->pubkey_algo, sig->digest_algo,
-sig->sig_class, (ulong)sig->timestamp, rc);
+sig->sig_class, (ulong)sig->timestamp, gpg_err_code (rc));
write_status_text (STATUS_ERRSIG, buf);
if (gpg_err_code (rc) == GPG_ERR_NO_PUBKEY)
{
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpg1faxJCtX5.pgp
Description: PGP signature
Bug#846175: [pkg-gnupg-maint] Bug#846175: gnupg-agent: Cannot use/delete ssh keys w/ empty passphrase
On Tue, 29 Nov 2016 14:49, matth...@urlichs.de said: > When in doubt, do both? No. As I explained the key might be in use by other tools not just ssh. Tracking which key has been ssh-add'ed which has been taken from a different source would be pretty complicated. > In any case, if it's been added by ssh-add, it needs to be dropped. > Otherwise you're not compatible with ssh-agent. gpg-agent works different than ssh-agent in that it provides a persistent store for the keys. It is not a plugin-replacement for ssh-agent but merely speaks the same protocol and opts to differ from ssh-agent semantics. > One of my use cases is to add the key (from removable media) to some > long-running process's key store. That process proceeds to do various > remote things, after which it no longer requires access and thus removes You can use gpg-connect-agent to remove keys from gpg-agent's store: $ gpg-connect-agent > keyinfo --ssh-list S KEYINFO 1234567890334957345974597345984574958445 D - - - P - - S Lists information about all keys enabled fro use with ssh (~/.gnupg/sshcontrol). For a description of the format use "help keyinfo". The command DELETE_KEY can be used to delete the key. Although a bit hackish you may access gpg-agent's internal store directly: For example with the key above you can do: rm ~/.gnupg/private-keys-v1.d/1234567890334957345974597345984574958445.key or backup that file with the key somewhere and restore it when you need it again. Note that a key must also be listed in sshcontrol; but ssh-add takes care of that. The key can be listed there but does not need to be actually available under private-keys-v1.d Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpghNAIn3WTI.pgp Description: PGP signature
Bug#846175: [pkg-gnupg-maint] Bug#846175: gnupg-agent: Cannot use/delete ssh keys w/ empty passphrase
On Tue, 29 Nov 2016 00:20, matth...@urlichs.de said: > I can't delete them; "ssh-add -d path/to/file-pub" silently fails. > So does "ssh-add -D". gpg-agent does not support this because it stores the key in its own database. As you may have noticed ss-add is only required once to tell gpg-agent about the key. The code to remove the indentity has this comment: /* FIXME: What to do here - forgetting the passphrase or deleting the key from key cache? */ Given that there is no easy way to know the origin of the key (it may have been added by ssh-add or be for example a gpg subkey) I tend to implement the latter (i.e. forgetting the passphrase). > gpg-agent[6308]: failed to unprotect the secret key: No passphrase given > > Umm, yes a passphrase *was* asked for, and given; it just happens to be > empty. So? This worked before updating my system to Testing yesterday. Indeed there is a bug when adding an ssh-key w/o passphrase. I filed gnupg bug https://bugs.gnupg.org/gnupg/issue2856 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3fa97Zx9Jx.pgp Description: PGP signature
Bug#842291: [pkg-gnupg-maint] Bug#842291: notmuch processes frequently stuck in select()
On Wed, 23 Nov 2016 18:19, d...@fifthhorseman.net said: > 0) turn off CRL updates entirely during s/mime signature verification The gpgsm option is --disable-crl-checks. > 1) do s/mime signature verification without CRL updates, but schedule > CRL checks to happen in the background for dirmngr, so that future > verifications will reflect the cert validity As above but use dirmngr-client--url --load-crl URLOFCRL You need to known the URL of the CRL, though. > 2) have dirmngr avoid checking CRLs that it knows it has already > updated recently A CRL carries a next-update date which is homored by dirmngr. Further dirmngr doesn't avoids to download a CRL unless 30 minutes have passed since the lassed download. > 3) tell dirmngr to use much shorter CRL fetch timeouts gpgsm -k --enable-crl-check --force-crl-refresh USERID > that's a 20-second lag between each failed check, adding up to 80 That seems to be caused by DNS lookups. For example ADNS keeps on trying even if it has received an ENETUNREACH and thus no UDP query packet has been sent out. We will very likely replace ADNS by a more flexible library in the next GnuPG version. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpM3cSJdhUyC.pgp Description: PGP signature
Bug#845078: [pkg-gnupg-maint] Bug#845078: Links against libadns1 with limited security support
On Sun, 20 Nov 2016 10:03, a...@sigxcpu.org said: > libadns1 has limited security support in Debian so I wonder if this is a > good choice for dirmngr. Please consider using another resolver by Due to the unresponsive ADNS upstream maintainer, we are evaluating other options than ADNS. We have two reasons to use our own resolver: - Avoids the use of the Windows API. However, that can be changed with some effort. - To enable TOR based DNS. That currently works only on Windows because there we can and need to use a patch version of ADNS :-(. We actually don't make use of the async features of ADNS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpG_wuNq_F3E.pgp Description: PGP signature
Bug#844117: [pkg-gnupg-maint] Bug#844117: gnupg locks up until straced
On Sat, 12 Nov 2016 17:45, ijack...@chiark.greenend.org.uk said: > I just tried to use caff. I found that it seemed to hang, every > time. I tried debugging it with strace. Put --8<---cut here---start->8--- log-file /wherever/dirmngr.log verbose debug ipc --8<---cut here---end--->8--- into dirmngr.conf. kill dirmngr and run caff again. This gives you a nice log. You may also want to start dirmngr yourself to see how it works: gpg-conncet-agent --dirmngr then enter "help" to get a list of commands. You may the check which DNS resolver is used: getinfo dnsinfo Add a keyserver (if you don't have one in the config) keyserver hkp://keys.gnupg.net and view the table of keyservers: keyserver --resolve --hosttable Looking up keys can be done using ks_get 1234567812345678 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpjoCKnKLpe8.pgp Description: PGP signature
Bug#844084: [pkg-gnupg-maint] Bug#844084: gnupg: typo in man page
Hi, that was already fixed in the repo by Ineiev and committed in September. Will go into 2.1.16. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpSWVoU0Icly.pgp Description: PGP signature
Bug#806940: [pkg-gnupg-maint] Bug#806940: Bug#806940: gpgv-static possible?
On Wed, 9 Nov 2016 14:48, d...@fifthhorseman.net said:
> So looking at get_pwdir in common/stringhelp.c, all of those calls are
> inside the get_pwdir function, wrapped in an #ifdef HAVE_PWD_H. This
> code is used for tilde(~) expansion inside do_make_filename(), which
> itself is a helper function for the make_{,abs}filename{,_try}
> functions. if it's an isolated tilde, and $HOME is set, it's not used.
Exactly: Here is the relevant code from make_filename:
if (first_part[1] == '/' || !first_part[1])
{
/* This is the "~/" or "~" case. */
home = getenv("HOME");
if (!home)
home = home_buffer = get_pwdir (xmode, NULL);
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpJ7hbLbZ8fg.pgp
Description: PGP signature
Bug#842015: [pkg-gnupg-maint] Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus
On Wed, 9 Nov 2016 00:41, d...@fifthhorseman.net said: > dbus-user-session is also very much in line with gpg-agent's > --standard-socket option (which is now the default): both of them have > the concept of a single session running for any given user on the > machine. In GnuPG that depends on the GNUPGHOME and not on the user. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpLDzJFMoq6o.pgp Description: PGP signature
Bug#806940: [pkg-gnupg-maint] Bug#806940: Bug#806940: Bug#806940: gpgv-static possible?
On Wed, 9 Nov 2016 13:43, gni...@fsij.org said: > I think that it is OK for gpgv-static not supporting tilda expansion. Agreed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpyjV3tDXiuv.pgp Description: PGP signature
Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Bug#842015: Similar issue, no emacs
>> It would be great to get better error messages in the hands of users. >> Anything in that direction is welcome. > > I'll look into this. Done. If you run gpg with -v you now get this: gpg: pinentry launched (pid 23496, flavor gtk2, version 0.9.8-beta32) and if the curses fallback is used gpg: pinentry launched (pid 26376, flavor gtk2:curses, version 0.9.8-beta32) For the currently release pinentries, the flavor will showup as "unknown". This also changes the PINENTRY_LAUNCHED status callback and I hope that this does not break anything. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpZ3grnv6gFZ.pgp Description: PGP signature
Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Similar issue, no emacs
On Thu, 3 Nov 2016 18:51, vinc...@vinc17.net said: > The fallback to Curses is actually a bug when --no-tty is provided > as a gpg option, because this is documented as: I agree. > So, the terminal can't be used to output the prompt for the > passphrase. I suppose that applications that do not know how > to redraw the screen use this option. No, this option predates gpg-agent and I have not used it for years. We would need to convey this option to pinemtry via gpg-error. Simply unsetting GPG_TTY is not enough. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgplPoaNiYW2k.pgp Description: PGP signature
Bug#842015: [PINENTRY PATCH] gnome3: Test if Gcr System Prompter is available at startup.
On Thu, 3 Nov 2016 17:25, d...@fifthhorseman.net said: > Could you please also include some feedback on the actual code provided? Looks fine. I have no way to test it right now, though. > It would make the orthographic nit-pickery a little easier to stomach. > > --dkg, frustrated, and trying to fix real problems here For easier reading a common indentation is a Good Thing. Given that I assume to see even more patches from you we need to be a bit picky about this. I fact, i told Justus only yesterday to keep an eye on these things. I know this can be frustrating - I'll buy you a beer or two. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpCxGS0ODRlZ.pgp Description: PGP signature
Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Similar issue, no emacs
On Thu, 3 Nov 2016 16:13, d...@fifthhorseman.net said: > i do not either, but i will work on a patch that provides something > approximating this approach today. Thanks. > I'm not sure why you prefer it that way. If pinentry is used as a Because the pinentry code makes assumptions on how it has been initialized. Changing this by switching the UI method on the fly needs a closer analysis of the side effects. Pinentry is also not designed as a long running process - it is easier to terminate pinentry and let the caller start a different pinentry. It would for example be possible to tell the caller (gpg-agent), that it should try a different pinentry version the next time it calls pinentry. This way we could get around the gnome problems. But sure it would also be surprising if sometimes the GTK or QT pinentry pops up instead of the GNOME pinentry . Even more surprising than the fallback to Curses. BTW, the fallback to Curses can also be troublesome if the calling application does not know about this and has no way to redraw the screen. > It would be great to get better error messages in the hands of users. > Anything in that direction is welcome. I'll look into this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpW94nceR4Hs.pgp Description: PGP signature
