Use pointer-sized unsigned integer for the flags field.

I understand your emulator is s390x. Perhaps, on the emulator, memory layout is different?
I now see that C99 is OK for GnuPG, or at least no problem for gpgscm.

In D421#2968, @gniibe wrote:

I think that there are two archs: s390 and s390x. Latter is 64-bit and supports 32-bit version as well.

I think that there are two archs: s390 and s390x. Latter is 64-bit and supports 32-bit version as well.
Use of machine word size (32-bit for 32-bit machine, 64-bit for 32-bit machine) is good. That will be update of Diff 1255.
But I don't know how it is achieved easily.
(If we can ignore LLP64, we can use unsigned long.)
Please go ahead that way.

@gniibe thanks for figuring this out. This is rather mundane, I'm somewhat astonished that I did not think of that :(.

Please decide for _flag access on 64-bit machine, if 32-bit access is better or not.
If 64-bit access is better, update version of {Diff1255} is needed, instead.
unsigned long is not good for LLP64 system. Use unsigned long long for 64-bit system.

Update of the diff, so that we can keep _flag field access to 32-bit on 64-bit machine.

Applied as ebe12be034f0.

Re-purposing the encryption lock would have been my suggestion as well.

While I can't reproduce this problem myself, I think I found an issue of gpg-agent passphrase caching.
Double free may happen when multiple threads enter agent_put_cache, for example.

In 2.1.19, gpg-agent uses getpeerucred for macOS. I changed it (since it seemed not working). In 2.1.20, gpg-agent now uses getsockopt with LOCAL_PEERPID.
It seems for me that the crash occurs by ucred_free. If this is the case, 2.1.20 fixes this issue.

This is no a bug but a non-proper installation of libgcrypt. In fact the output
of libgcrypt's "make install" shows hints on how to finish the install; also
pointing to ldconfig.

In general it is not easy to install a newer version of a library on a system
which already has an older version of that library.

I was able to reproduce it again. Maybe this bug depends on which keyserver in
the pool answers. The error is the same for Tor and non-Tor connections.

I don't know why, it is not repdroducible anymore.

This seems to be a bug in our new resolver library. I have contacted the author
for assistance.

This is a duplicate of #2990.

Hey :-)

Glad to see I'm not the only one ;-)

Indeed, I can reproduce this.

PS: Hi flokli :)

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

Okay... using a later distribution with a newer wget fixed this:
https://travis-ci.org/azul/gpg-build/builds/203543109

closing. Sorry for the noise.

The same build works locally for me with wget 1.17.1.
travis has 1.13.4

$ wget --version

GNU Wget 1.13.4 built on linux-gnu.

+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/openssl

Wgetrc:

    /etc/wgetrc (system)

Locale: /usr/share/locale

Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"

    -DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib 

    -I../../lib -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 

    -fstack-protector --param=ssp-buffer-size=4 -Wformat 

    -Wformat-security -Werror=format-security -DNO_SSLv2 

    -D_FILE_OFFSET_BITS=64 -g -Wall

Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat

    -Wformat-security -Werror=format-security -DNO_SSLv2 

    -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions 

    -Wl,-z,relro -Lyes/lib -lssl -lcrypto -lz -ldl -lz -lidn -lrt 

    ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

http://www.gnu.org/licenses/gpl.html.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@xemacs.org>.

Please send bug reports and questions to <bug-wget@gnu.org>.

I nearly filed this as a minor bug to start with. Apologies for the
mis-classification.

My thinking was that there are a few rarer cases on unattended/shared
environments where this may be an issue. Scripts may deliberately be using a
umask that allows write permission to files it's creating, not expecting that
pubring (or other keyring) changes will create a new file. Other users/services
may need read permission to those keyrings, and actually end up with write
permission. This is potentially a problem despite the data not being secret.

Granted, the above hypothetical situation is uncommon and easily worked around
with better design/testing, but it might catch people out.

I don't consider this a minor bug.

The pubring does not contain secret information but only sensitive data, like
many files in a user's $HOME. The umask is the standard Unix way of restricting
access for new files. For files holding secret data we explicitly set the
permissions.

Thanks for the report. I can replicate this.

Attached example output after patch is applied. Now User4 has full validity like
expected, and the debug output shows a match for User4's email address (NOTE:
the debug output has 'YES' for no match and 'NO' for successful match)

D406: 944_example.patch

Attached example patch prevents escaping normal lowercase letters.

Note that this isn't a general solution, though it does solve the issue for me.
For example, some email addresses have numbers (I don't know if having backslash
before numbers is an issue like it is for letters)

Attached example are the following setup:

user1 tsign user2 with full trust, depth 1, domain="customer.com". User2 signs
user3 through user5 (regular signatures). User4 is at customer.com, users 3 and
5 are at example.com.

Ok profiles are now there and look workable, but it looks like they are only
supporting configuration values that are currently accessible through gpgconf:

[gpg]
trust-model tofu+pgp
keyserver-options auto-key-retrieve
auto-key-locate local,wkd,pka,cert,dane

Leads to:

gpgconf: /opt/gnupg/etc/gnupg/automated.profile:7:0: error: unknown option
'trust-model' in section 'gpg'
gpgconf: /opt/gnupg/etc/gnupg/automated.profile:8:0: error: unknown option
'keyserver-options' in section 'gpg'

So we need more options promoted to gpgconf. Which I think is ok, we can just
mark them as Expert / Invisible and GUI's should respect that.

ah, misread the 2.1.16 part, so yes, it seems to be fixed.

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

The man page:
"none" does not show the key ID at all but shows the fingerprint in a separate
line.

OK, then this is just an issue for interactive usage, but still an issue.

When using a script you should not parse the human readable output.

gpg2 --status-fd 2 --verify /tmp/msg

[GNUPG:] VALIDSIG 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 2016-11-14 1479138285
0 4 0 1 8 00 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

See https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS
for the meaning of these fields

In gpg2.1.16 the fingerprint is also used instead of the keyid if you do:

/opt/gnupg/bin/gpg --keyid-format none --verify foo.sig

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

John is using 2.1.14, but this bug was fixed in 2.1.15.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

There are a couple of ideas on how to use mail for key retrieval. We won't be
able to implement them for 2.2 but we should consider this for 2.3.

There won't be any changes for 1.4, though.

lechten: I agree with justus' evaluation. Further we can't change the sematics
of --default-cert-expire in the way you want that; it would not be compatible.

Fixed with 2.1.14.

Look at what the man page says on how to specify a user id:

• By exact match on an email address. This is indicated by enclosing the email address in the usual way with left and right angles. <heinrichh@uni-duesseldorf.de>

The default however is a substring match on the entire user id. Note that
issue2359 is also about this and it may introduce a slighlty modified way on how
a key is specified by a mail address.

Should only be chnaged for master, though.

gpgme 1.7.0 has been released and thus I consider this bug solved.

gpgme 1.7 will have gpgme_op_createkey which takes "default" and
"future-default" as algorithm parameters. There is also a bunch of user
functions to make creating a key easy with gpgme.

This was already mentioned in T2360 so let's not clutter the tracker.
Resolved as duplicate.

Duplicate of T2360

To piggyback something on this issue.

To quote T2359 (aheinecke on May 17 2016, 11:59 AM / Roundup):

e.g. an API to check which key: gpg -er aheinecke@intevation.de

I did not have groups on the radar for this. If a recipient is a group then
gnupg would use multiple keys in this command.

I think locate-keys would be a great mechanism to support this easily in MUAs.
When we change it that for a given mailbox only the single most valid Key is
returned we could also have the semantic that if then multiple Keys are returned
we have a group.

The document you cite also states that UID/UAT lines only use field 10.

Also, neither UID nor UAT packets encode an expiration date [0], the way an UID/UAT can expire
is that the self-signature expires [1].

0: https://tools.ietf.org/html/rfc4880#section-5.11
1: https://tools.ietf.org/html/rfc4880#section-5.2.3.3

I do no longer agree with your first problem. Key expiration is different from signature
expiration, the way to quickly generate a key that expires in one year is:

    $ g10/gpg --quick-gen-key quick_test - - 1y

I guess one could argue that if one specifies --default-cert-expire=X when adding an uid, that
the self-signature for the new uid should expire. But to be honest, I doubt that this matches
user expectations.

What would be the use case really? I know that I'll lose access to that mail address in X years
and hence want my uid to expire then.