- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 27 2020
I am interested in that. I have a yubikey here that I wish to use productively for brainpool-256 signing, bp-512 (just for fun) encrypting and cv25519 authentication. I need to use brainpool signing and encryption subkeys for VS-NfD compliant communication and I want to be more modern then RSA ;-)
Merged into master. Thanks!
Thanks! I would merge your commits but I'll like to talk to werner tomorrow about the always adding "--with-keygrip" I also think its useful but it might have expensive internal side effects that I am not aware of.
I have difficutlty to accept that as an issue in our tracker. Somehow the GUI for Kleopatra appears to be confusing for your "Sender" which apparently is not you, correct? This results in the wrong keys selected for encryption.
With this amount of information I cannot see any path of change for our software.
Could you maybe provide a screenshot how the recipient selection looks for your user in Kleopatra, so that we can discover why it might be confusing or why the recipients key is not selected correctly?
@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).
Jan 25 2020
Jan 24 2020
(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)
ok, that's deeply weird. i'm assuming that this machine has IPv4 connectivity. I have no idea why dirmngr would be returning EAFNOSUPPORT in that case.
Right after the failed connection I see:
$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 4 d keys.openpgp.org (37.218.245.50) (5s) OK
Regarding Cygwin: The sources are a bit hard to find.
https://cygwin.com/packages.html
-> https://cygwin.com/packaging/repos.html
-> https://cygwin.com/git-cygwin-packages/
-> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libgcrypt.git;a=summary
Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here: https://lists.debian.org/debian-bsd/2014/08/msg00092.html
For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt
I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:
branch dkg/fix-4821 contains a fix for this, in commit 414938cfedbdb97b83d00e8619dec9502096be22
in particular, c4cf527ea227edb468a84bf9b8ce996807bd6992 and f2aeb2563ba2f55eea7f52041e52062fdc839a64
The dkg/fix-4820 branch now has these two fixes.
Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.
Jan 23 2020
For easier reference or searchability, the test error looks like this:
I implemented the script described previsouly (https://dev.gnupg.org/T3891#114950) in the smartpgp-cli utility provided in the SmartPGP repository (see commit https://github.com/ANSSI-FR/SmartPGP/commit/4be0fa442b43c2bafd5f0171417ff68fd88cbe2d).
This appears to be a different error than above. here we see:
With tls-debug 16:
dirmngr[9162.6] DBG: chan_6 <- END dirmngr[9162.6] DBG: dns: libdns initialized dirmngr[9162.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/common.c[_gnutls_x509_get_raw_field2]:1575 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_subject_unique_id]:3902 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_issuer_unique_id]:3952 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990 dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990 dirmngr[9162.6] number of system provided CAs: 142 dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Allocating epoch #0 dirmngr[9162.6] DBG: gnutls:L2: added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list dirmngr[9162.6] DBG: Using TLS library: GNUTLS 3.6.11 dirmngr[9162.6] DBG: http.c:connect_server: trying name='keys.openpgp.org' port=443 dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success dirmngr[9162.6] error creating socket: Address family not supported by protocol dirmngr[9162.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol dirmngr[9162.6] DBG: gnutls:L13: BUF[HSK]: Emptied buffer dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Start of epoch cleanup dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: End of epoch cleanup dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Epoch #0 freed dirmngr[9162.6] marking host 'keys.openpgp.org' as dead dirmngr[9162.6] host 'keys.openpgp.org' marked as dead dirmngr[9162.6] command 'KS_PUT' failed: No keyserver available dirmngr[9162.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr> dirmngr[9162.6] DBG: chan_6 <- BYE dirmngr[9162.6] DBG: chan_6 -> OK closing connection dirmngr[9162.6] handler for fd 6 terminated
Could it be that the system installed CAs are not sufficient for the TSL handshake? But then also curl should fail on that host. But curl https://keys.openpgp.org is fine.
On Solaris, the test errors are because of:
USAGE Because of the impact on system resources, the use of mlock() and munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY} privilege.
OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.
Jan 22 2020
Patch have been applied to master, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=79ed620ec46adbb08f5cea6a4865a95a436e4109
this looks to me like a problem with the TLS handshake -- it looks like this is a response coming from the TLS stack -- as rfc 8446 says, alert 49 is access_denied:
Some users of ours wanted to use KDF with their OpenPGP smart cards. Could you tell when solution to this issue could be expected?
Additionally, is there any workaround for the current state? Perhaps based on T3823, or on derived [1]? To which values the PINs had to be set?
I have added standard-resolver and debug network to the dirmngr.conf, killed the running dirmngr:
Jan 21 2020
Yes, I need to optimize it.
@jukivili thanks for looking into this. If you want, you can go with "Marvin W. <git at larma.de>" or just keep as is.
Hi @slandden. Have you made any progress since the last time I asked?
I believe "geometry" field value from [SignEncryptFilesWizard] can help in debug.
But I'm not sure about posting it here: does it contain any sensitive info?
Result of renaming:
It helped, but only for 1st run. Then problem occurs again.
I've tried to restart the app, but it doesn't help.
Thanks for the report. I have observed that the Window is sometimes opened in the background so I accept that this is an issue for Kleopatra somehow and we need to look into it. I know that your problem is a bit different but that is related.
I've downgraded to gpg4win-3.1.10 - still be reproducible...
FWIW, I found an open xterm with my query from last week:
For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20
In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.
Jan 20 2020
@Valodim: I am pretty sure that last week it resolved only to a v4 address; today (and from another network and resolver) I get the same addresses as you.
# host keys.openpgp.org keys.openpgp.org has address 37.218.245.50 keys.openpgp.org has IPv6 address 2a00:c6c0:0:154:1::1 keys.openpgp.org mail is handled by 100 mail.keys.openpgp.org.
that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?
Thanks. I see the situation for Solaris 11 Openindiana. In master (will be 1.9.0), it has no problem.
We need to fix in 1.8. I will.
Here are the logs. The package was configured with
CC="gcc -m64 -O2 -D_XOPEN_SOURCE=700"
$ ping keys.openpgp.org -c1 PING keys.openpgp.org (37.218.245.50) 56(84) bytes of data. 64 bytes from 37.218.245.50 (37.218.245.50): icmp_seq=1 ttl=48 time=24.1 ms
Please give us log for Solaris 11 Openindiana.
I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.
Jan 19 2020
but keys.openpgp.org resolves only to a v4 address.
Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).