I got my hands on a macOS box, and this particular problem is fixed in 2e64ccb0.
I still cannot compile gnupg there, but I'm working on it.
I got my hands on a macOS box, and this particular problem is fixed in 2e64ccb0.
I still cannot compile gnupg there, but I'm working on it.
I'm going to close this issue due to inactivity. Feel free to reopen it.
Also, most options join words with hyphens, but some don't.
Fixed in 1.7 with gpgme_op_keysign.
Thanks. I believe the relevant part is:
checking whether the resolver is usable... no
checking whether I can make the resolver usable with BIND_8_COMPAT... no
The latter is indeed a MacOS X specific thing.
Would you be so kind to execute the following commands on your machine, and
report the results back?
grep COMPAT /usr/include/arpa/*
grep PACKETSZ /usr/include/arpa/*
This has been fixed in July with c49c43d7.
Thanks for the report. Please attach the full output of configure.
This is an issue of GNOME as packaged by Red Hat. Please file a bug in Red
Hat's bug tracker instead.
Sorry, I cannot reproduce this problem using 2.1.11:
% export GNUPGHOME=$(mktemp -d)
% echo "keyserver hkps://hkps.pool.sks-keyservers.net
hkp-cacert
/home/teythoon/repos/g10/gnupg-2.1.11/dirmng/sks-keyservers.netCA.pem" >
$GNUPGHOME/dirmngr.conf
% g10/gpg2 --recv-keys 99B03CE455DB476E737057B44FD0FA5528DB9E3F
gpg: /tmp/tmp.QINMXRcRqH/trustdb.gpg: trustdb created
gpg: key 28DB9E3F: public key "Justus Winter <justus@gnupg.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
% g10/gpg2 --refresh-keys
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key 28DB9E3F: "Justus Winter <justus@gnupg.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
(Adding the .onion service makes no difference for me either.)
Indeed, this is unfortunate, but not as bad as you make it sound (unless the
user uses always trust).
Note that this is not about signing (which uses the private key), but about
encryption. I've changed the bug title accordingly.
This happens also with master, and it seems the order of keys in the public
keyring is important:
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.TR2cSoWHMb/pubring.kbx' created
gpg: /tmp/tmp.TR2cSoWHMb/trustdb.gpg: trustdb created
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: 1A7265CF27F9E78E: There is no assurance this key belongs to the named user
sub rsa2048/1A7265CF27F9E78E 2016-09-14 test.user@example.org
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Primary key fingerprint: CA77 8656 2AAC BBB2 6A50 3A50 8D62 594F 1FE9 0C7B
Subkey fingerprint: 52CB E9DC 1812 9F78 3054 6569 1A72 65CF 27F9 E78E
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
130 teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export
GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.Hfjbb2jvji/pubring.kbx' created
gpg: /tmp/tmp.Hfjbb2jvji/trustdb.gpg: trustdb created
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: DAB278A8736B0D2C: There is no assurance this key belongs to the named user
sub rsa2048/DAB278A8736B0D2C 2016-09-14 user@example.org
Primary key fingerprint: 6680 B181 D853 CEB5 6671 ECC7 0098 8FEC 00B5 CA77
Subkey fingerprint: 3909 7C31 399C A746 87B3 5D74 DAB2 78A8 736B 0D2C
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
Fixed in 72fa314b.
Actually, I'd argue that tdbio_set_dbname did not handle this case correctly. In
any case, if you must create some temporary gnupghomes, deleting the whole
directory might be both easier and more robust.
Fixed in a27410a2.
Can you please test if the following patch that has been committed recently
fixes your problem?
https://git.gnupg.org/cgi-bin/gitweb.cgi?
p=pinentry.git;a=commitdiff;h=2227f67af53f38d3d7f97760f2553d2c9ed05969
(It is not NCURSES_INCLUDE, but NCURSES_CFLAGS should be set by
PKG_CHECK_MODULES.)
Thanks!
Can you please tell us what version of ssh you are using (ssh -V)?
https://pagure.io/pygpgme/c/6648b075fb3d434c599d7e1793bd1f0bbe85dfe3?branch=master says:
T767 indicates that
gpgme_set_passphrase_cb is a deprecated corner of the API and that
developers using gpgme should really rely on the gpg-agent to handle
this stuff.
That is not correct. gpgme_set_passphrase_cb is not deprecated, and gpg21 does honor the flag.
In fact, allow-loopback-pinentry is the default since GnuPG 2.1.12.
Fixed in 135185b7.
Ok, there are no significant patches on top of pygpgme. Note that pygpgme is not really
maintained, and that we neither develop nor support pygpgme. But seeing that dnf is important to
Fedora, let's figure this out.
It would be nice if you could try to reproduce the problem without pygpgme though, just to make a
more minimal test case. I see the exception is thrown during some import. This is how I strace
gnupg to see what ioctls it is issuing:
% strace -eioctl g10/gpg --import ../tests/openpgp/samplekeys/ecc-sample-1-pub.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0BA52DF0BAA59D9C: public key "ec_dsa_dh_256 <openpgp@brainhub.org>" imported
si_utime=0, si_stime=0} ---
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
gpg: Total number processed: 1
gpg: imported: 1
+++ exited with 0 +++
Note that if you try to strace your gpgme-based application, you need to pass '-f' to strace to
follow forks.
I have grepped through gpgme and gnupg, and it looks like gnupg is only doing ioctls to terminals,
so maybe your container setup is doing something funny to terminals. But let's see what the strace
shows.
Fixed in 2f1f1f06.
Grabbing the pointer might have unexpected repercussions though, e.g. one isn't
able to move windows around anymore. Let's see how it turns out.
What operating system are you using?
We had the exact same patch committed (21e83f42) and later reverted (f0db3192).
Discussion: https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/030051.html
This is really weird. Merely not adding the password reveal button to the hbox
'fixes' this problem. Therefore, I don't believe that the patch introduces the
bug, it merely makes it manifest itself.
I looked around in the related gtk bits, but I believe the problem might be in
the X server, or the asynchronous interaction with it. I don't believe it is
worth digging further into X.
Workaround committed in ad390f29.
Indeed, thanks for the analysis!
Fixed in 40365b28.
Fixed in c971ff08.
Fixed in 2.1.14 with the switch to Scheme-based tests.
import-clean does call the same code, but it behaves differently for the key you
mention. I created a test key that does get cleaned up upon import.
Merged in 583a464c, thanks!
Note that we prefer contributions sent to the mailinglist using git send-email.
Thanks for the report.
I see that you are using pygpgme, is that correct? If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?
Let's try to figure out which ioctl fails. Could you try to strace this process?
Fixed in b2572b0c.
Thanks for letting us know. Unfortunately, we do not test on MacOS yet, but we are working
on that.
I have neither experience with debugging on MacOS, nor do I have access to such a machine.
I'm afraid you are on your own for now.
The ssh test is new, so we need to figure out why it does not work. Please do
make -C tests/openpgp check TESTS="setup.scm ssh.scm" verbose=2
This lets us see what ssh-add prints to stderr. It might be related to the version of
OpenSSH shipped with the OS.
The API of pyme3 is almost identical to that of pyme, the former being a port to Python3,
while the latter is for Python2. We also added a more idiomatic interface on top of that, but
porting pyme applications should be easy. It is different to the API of pygpgme though.
I don't know exactly when 1.7 will be released, but it is overdue, so I'd say next month.
That is not a bad commit, that is Werner evolving our software. pygpgme is unmaintained since
I ran the testsuite myself, and I can reproduce the issue, among many other failures: 24 if I'm
using the GnuPG components from Debian/unstable, 9 if I am using more recent components.
One of them is test_encrypt_to_signonly, which tries to encrypt a mail to a key only usable for
signing, and expects a general error, which all recent versions of GPGME return in this case, but
this was a bug, fixed in GPGME master, which returns the correct error.
Updating pygpgme is out of scope for us. If you merely need any binding, consider using the pyme3
bindings that we merged into GPGME proper, and will release with 1.7. You can also find it on
pypi, it requires GPGME 1.6.x to build.
The way I see it is that the pygpgme bindings and its test suite are way too unmaintained and the
test suite too noisy to demonstrate a bug in GnuPG or GPGME. Feel free to reopen this bug if you
have compelling evidence that we broke something, preferably a small test case not using pygpgme.
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.