Re: using OpenPGP card to unlock a LUKS device on boot
Am 06.04.22 um 18:15 schrieb Robert J. Hansen via Gnupg-users: >> You're barking up the wrong tree: It wasn't me who brought politics to >> this list. > > You're the one who is turning a single throwaway line in someone's > signature block into an angry argument. No. But you're the one who obviously _must_ have the last word. > >> Nonsense. The OP issued a statement, I replied and that could have been >> it. It is you who is obviously thriving on extending this discussion. > > It "could have been it", I am certain, if he had apologized, removed the > line from his signature block, and stopped. Had he done otherwise we'd > be right where we are now. Assumptions are the mother of all disasters. > > Regardless: I think I've made my position clear. He is under no > obligation to remove a line from his signature block that you object to > on purely political grounds. Let's drop this subject and return to > talking about GnuPG. Amen! Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: using OpenPGP card to unlock a LUKS device on boot
Am 06.04.22 um 17:04 schrieb Robert J. Hansen via Gnupg-users: >> Just as I am free to comment on a political statement that I find >> provocative, blatantly wrong and in the context of current events almost >> derisive. > > Excepting that this is not a mailing list for politics. You're barking up the wrong tree: It wasn't me who brought politics to this list. > > Matthias has a line in his signature that you object to. I object to > it, too, but the only thing we need to do is nothing. Perhaps you'd There are times when "doing nothing" isn't an option any longer. It may have escaped you but there is a war raging in Europe. > like to place your own line in your own signature file making your > pro-NATO feelings clear? Either way, bringing it to the forefront of > discussion is incredibly off-topic. Nonsense. The OP issued a statement, I replied and that could have been it. It is you who is obviously thriving on extending this discussion. > > We'd like to keep this mailing list on-topic. Thanks for > understanding. :) Then heed your own advice and simply keep your wisdoms to yourself. Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: using OpenPGP card to unlock a LUKS device on boot
Am 06.04.22 um 16:06 schrieb Robert J. Hansen via Gnupg-users: >> Given recent events: can't you spare us your stupid signature? > > Matthias should be, and is, free to advocate for his beliefs in his > signature. Just as I am free to comment on a political statement that I find provocative, blatantly wrong and in the context of current events almost derisive. > > If we don't stand up for people's right to peacefully say things we > don't like, we have failed as a community. Then stand up for *my* right to peacefully say things as well. Or perhaps just mind your own business. > > I say this as an American who's a fanatical supporter of NATO. Leave > the guy alone, and let's get back to discussions about GnuPG. Thanks. :) American or whatever: fanatics are always suspicious to me. Apart from that: What I do or say is not yours to decide. And I don't need your advice in this matter. And the OP is probably able to speak for himself. The signature is a provocative political statement and it therefore has to be expected and is probably even intended that people react to it. And so I did. That's all. Like it or not. Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: using OpenPGP card to unlock a LUKS device on boot
Am 05.04.22 um 16:57 schrieb Matthias Apitz: > > Hello, > > Can someone please comment in the forum or here (and I copy it over) how > an OpenPGP card could be used to unlock a ciphered LUKS partition during > boot of the L5 mobile device, see this posting at the end: > > https://forums.puri.sm/t/librem-5-unlock-luks-volume-with-a-fido2-device/16890/7 > > Werner, what about your L5? > > Thanks > > matthias > Given recent events: can't you spare us your stupid signature? Or replace "instead" by "through"? Even for die-hard ideologists it's about time to adapt to reality. Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] A New Future for GnuPG
Great! This sounds like a success story that has only just begun. The right solution at the right time! The market for secure communication is huge and IMO still in its infancy. And for a small fish in a big pond there's lots of room to grow. ;) Congratulations! And good luck to you and GnuPG.com! Rainer signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint associated public key does not match displayed public key
Am 18.12.21 um 19:07 schrieb Ingo Klöcker: > On Freitag, 17. Dezember 2021 18:04:04 CET S.B. via Gnupg-users wrote: >>> Otherwise, you can simply send your exported key to the person you want to >>> give your public key to. >> >> Yeah so, I can attach the .asc file that's in my Disk/users/SamiBadri >> folder (it's the only .asc file I've seen), but I'm assuming that is >> my public key. Is that correct? > > Well, it depends. We have no idea what the .asc file in Disk/users/SamiBadri > contains. It could be your public key. Or it could be somebody else's public > key. Or it could be something other than a public key. > > Quite frankly, I suggest that you follow Robert's advice and start your > learning experience with OpenPGP by using an email client that supports > OpenPGP out-of-the-box. All decent email clients should have a functionality > to attach your public key to an email without you having to attach some file > manually. > >> Is there anyway to send your private key? > > Sure. You can send any file to anyone, so, of course, you can do the same > with > your private key (unless it's stored on a smartcard in a read-protected slot). > > A decent email client should not offer a functionality to attach your secret > key to an email. So, if you stick to what your email client offers you, then > you should be safe. > >> I want to know so that I don't do it accidentally. > > Then don't attach random files you find on your disk to your emails without > knowing what those files contain. > >> Also, if I >> use the cat SamiB.asc command, the terminal reveals a certificate (and >> I assume that's my public key certificate). > > You shouldn't assume anything if you are dealing with encryption software. > You > should be sure what you are doing. Otherwise, in the extreme, you could > jeopardize the lives of other people. > And then there's the one you're communicating with. Also make sure that *he* knows what he is doing. Otherwise you might jeopardize your own life. For example: Someone who replies to your top secret, perfectly encrypted mail - without encrypting his reply. ;) Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Thunderbird's hints and history for OpenPGP/MIME (new wiki page)
Am 03.12.21 um 12:04 schrieb Bernhard Reiter: > Hi Peter, > > Am Donnerstag 02 Dezember 2021 17:35:17 schrieb Dr. Peter Voigt: >> thanks for that page. I'm not using Thunderbird but I know many people >> who do. In particular the option to turn off the annoying dots is very >> useful. > > good to know that you think it is useful. :) No doubt it is useful. This three-dot-BS by default looks more like a bug than a meaningful feature, IMO. > >> Did you toot the link through Mastodon as well >> - I just failed to find and re-toot a correspondig content. > > I didn't toot it so far. > > First I wanted to gather some feedback, especially about the following > section, where I've added a recommendation what to use instead > of incompatible header encryption: > > > | Transport information in a decentral network - just like the writing on the > | outside of a postal mail envelope - cannot be protected in principle. > | When reflecting on this, chose a subject that is plausible in context, > | but without sensitive contents, to best veil potential unwanted observers. > | (Your thinking is right: The more sensitive this is, the more you have > | to build up a plausible context for your unavoidable traces first.) > This caters more to spies or people who have to be paranoid for an other reason. And they will know already. The average user, I guess, just wants to keep private communication private. And what the subject reveals should in most cases be negligible. So to me this paragraph seems a bit out of place. > (Also I've just improved the phrasing and spelling.) > > Best Regards, > Bernhard Thanks for your time and effort! Rainer > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [OT] English [was Re: Key Management - BSI had send private key instead of public key]
Am 18.11.21 um 22:21 schrieb Stuart Longland: > On Thu, 18 Nov 2021 10:48:55 +0100 > Rainer Fiebig via Gnupg-users wrote: > >> That's kind of a misconception: as English is a western germanic >> language it's not that German made its way into English but English is >> *based* on German. > > Ahh true, to the purists, English is not a language… it's a composite > of German, French, Italian, Spanish… and lots of others. > > Some might say English is a "language" that beats up other languages > and steals their vocabulary. That seems a bit too harsh to me. As I see it, English is a language that evolved from its base by integrating useful or chic elements of those languages that were present over time. A quite natural thing, I guess. And perhaps one reason why it became so successful. > > It doesn't mean the source language is immediately understandable by > those that speak its derivative though even if individual words can be > identified. :-) > Yeah, that's a pity. But at least you have a head start should you ever decide to go for the real thing. ;) Cheers and good luck! Rainer ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Management - BSI had send private key instead of public key
Am 18.11.21 um 13:27 schrieb Ineiev: > On Thu, Nov 18, 2021 at 10:48:55AM +0100, Rainer Fiebig via Gnupg-users wrote: >> That's kind of a misconception: as English is a western germanic >> language it's not that German made its way into English but English is >> *based* on German. > > To be precise, not on German---it's based on the common ancestor. > both English and German deviate considerably from it. > I guess that saves the day for some. I can almost hear the sigh of relief. ;) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Management - BSI had send private key instead of public key
Am 17.11.21 um 23:49 schrieb Stuart Longland via Gnupg-users:
> On Tue, 16 Nov 2021 23:17:58 +
> Стефан Васильев via Gnupg-users wrote:
>
>> [1]
>> https://www.golem.de/news/verschluesselung-bsi-verschickt-privaten-pgp-schluessel-2111-161073.html
>
> Is there an English translation of this article somewhere? I never
> learned German beyond what made its way into the English language or
> what I might've picked up from episodes of 'Allo 'Allo or Hogan's
> Heroes…
That's kind of a misconception: as English is a western germanic
language it's not that German made its way into English but English is
*based* on German.
You would be amazed how many words are similar or even pronounced
identically - like Haus/house, Maus/mouse, Finger/finger etc. pp. The
similarities between English and the dialect spoken in coastal regions
of northern Germany ("Plattdeutsch") are even more striking.
So you already do speak German - to some extent. In case you don't
believe me or wonder where "Anglo-Saxon" comes from, start here:
https://en.wikipedia.org/wiki/Angles.
A bit OT, I know. But I couldn't resist. Hope you're not offended. ;)
Kind regards!
Rainer
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
SOLVED: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 28.07.21 um 15:45 schrieb Bernhard Reiter: > Hi Rainer, > > Am Mittwoch 28 Juli 2021 11:22:18 schrieb Rainer Fiebig via Gnupg-users: >> Hi! I'm having a problem when searching for keys on keyservers when >> using "gpg --search-keys". >> >> The only line in dirmngr.conf (except for comments) is: >> keyserver hkps://keys.openpgp.org OK, I could figure it out, finally: Beyond Linux From Scratch (BLFS) do not use ntbTLS for TLS, they use gnuTLS. But in connection with an update of gnupg I had installed ntbTLS in my former system because it was listed on https://gnupg.org/download/index.html. So I had it in my build list for my latest BLFS as well. Obviously, gnupg prefers ntbTLS over gnuTLS. And so gnupg was built with ntbTLS instead of gnuTLS. From the build log: [...] GnuPG v2.2.29 has been configured as follows: [...] TLS support: ntbTLS [...] ntbTLS was built after p11-kit but it doesn't seem to cooperate with p11-kit in the same way that gnuTLS does and so expects the certificates in those places that Werner has mentioned but which differ from the setup in BLFS. By configuring gnupg with --disable-ntbTLS it uses gnuTLS for TLS support. And now gpg --search-keys works as expected in my BLFS. My bad! Thanks to everybody involved! Sorry for having wasted your time! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 31.07.21 um 21:00 schrieb Xi Ruoyao:
> On Sat, 2021-07-31 at 19:56 +0200, Rainer Fiebig wrote:
>> Am 31.07.21 um 17:40 schrieb Werner Koch:
>>> On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
>>>
If you built gnupg from its default configuration, it does not
automatically look in /etc/ssl/certs for CA certificates. You may
want
>>>
>>> On Unix and unless gnupg was build with --with-default-trust-store-
>>> file
>>> the following collections of certificates are used for TLS:
>>>
>>> { "/etc/ssl/ca-bundle.pem" },
>>> { "/etc/ssl/certs/ca-certificates.crt" },
>>> { "/etc/pki/tls/cert.pem" },
>>> { "/usr/local/share/certs/ca-root-nss.crt" },
>>> { "/etc/ssl/cert.pem" }
>>>
>
> Hi Werner,
>
> Our "recommended" configuration in BLFS is: gnutls is built with p11-kit
> and --with-default-trust-store-pkcs11="pkcs11:", and gnupg is built with
> gnutls. So gnupg "should" use certificates from p11-kit trust store I
> think? And it works for me.
>
> I saw your discussion with "curl". In BLFS curl uses OpenSSL instead of
> GnuTLS, so they actually have different trust stores. GnuTLS (using
> p11-kit) uses /etc/pki/anchors, OpenSSL uses /etc/ssl/certs.
>
> I remember once an unclean shutdown caused a similar issue on my system
> (/etc/pki/anchors is disrupted, and every program using GnuTLS just
> started to distrust every certificate).
>
> Hi Rainer,
>
> Try "gnutls-cli keys.openpgp.org". If it does not get into "Simple
> Client Mode" as expected, it means p11-kit trust store may be disrupted.
> Try "make-ca -f -g" to rebuild it.
>
> And check if your p11-kit was built with
> -Dtrust_paths=/etc/pki/anchors as the BLFS book says. If not sure,
> rebuild it. (I can also remember once I've mistyped the path, this also
> caused every program using GnuTLS started to distrust every
> certificate.)
>
OK, issued "make-ca -f -g" and re-built gnupg *without* path_to_file.
But the result then was again
~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568
gpg: error searching keyserver: No inquire callback in IPC
So the only way to get this reliably working on my system seems to be
building gnupg *with* path_to_file.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 31.07.21 um 21:00 schrieb Xi Ruoyao:
> On Sat, 2021-07-31 at 19:56 +0200, Rainer Fiebig wrote:
>> Am 31.07.21 um 17:40 schrieb Werner Koch:
>>> On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
>>>
If you built gnupg from its default configuration, it does not
automatically look in /etc/ssl/certs for CA certificates. You may
want
>>>
>>> On Unix and unless gnupg was build with --with-default-trust-store-
>>> file
>>> the following collections of certificates are used for TLS:
>>>
>>> { "/etc/ssl/ca-bundle.pem" },
>>> { "/etc/ssl/certs/ca-certificates.crt" },
>>> { "/etc/pki/tls/cert.pem" },
>>> { "/usr/local/share/certs/ca-root-nss.crt" },
>>> { "/etc/ssl/cert.pem" }
>>>
>
> Hi Werner,
>
> Our "recommended" configuration in BLFS is: gnutls is built with p11-kit
> and --with-default-trust-store-pkcs11="pkcs11:", and gnupg is built with
> gnutls. So gnupg "should" use certificates from p11-kit trust store I
> think? And it works for me.
>
> I saw your discussion with "curl". In BLFS curl uses OpenSSL instead of
> GnuTLS, so they actually have different trust stores. GnuTLS (using
> p11-kit) uses /etc/pki/anchors, OpenSSL uses /etc/ssl/certs.
>
> I remember once an unclean shutdown caused a similar issue on my system
> (/etc/pki/anchors is disrupted, and every program using GnuTLS just
> started to distrust every certificate).
>
> Hi Rainer,
>
> Try "gnutls-cli keys.openpgp.org". If it does not get into "Simple
> Client Mode" as expected, it means p11-kit trust store may be disrupted.
> Try "make-ca -f -g" to rebuild it.
>
Thanks. "gnutls-cli keys.openpgp.org" seems to work:
~> gnutls-cli keys.openpgp.org
Processed 145 CA certificate(s).
Resolving 'keys.openpgp.org:443'...
Connecting to '37.218.245.50:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
[...]
- Handshake was completed
- Simple Client Mode:
- Peer has closed the GnuTLS connection
~>
> And check if your p11-kit was built with
> -Dtrust_paths=/etc/pki/anchors as the BLFS book says. If not sure,
> rebuild it. (I can also remember once I've mistyped the path, this also
> caused every program using GnuTLS started to distrust every
> certificate.)
>
p11-kit was built with
--with-trust-paths=/etc/pki/anchors
which is in accordance with BLFS-10.1. But I suppose that is equivalent
to -Dtrust_paths=/etc/pki/anchors ?
Anyway - I'll try "make-ca -f -g" and then re-build gnupg without
--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt
and report back.
So long!
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 31.07.21 um 17:40 schrieb Werner Koch:
> On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
>
>> If you built gnupg from its default configuration, it does not
>> automatically look in /etc/ssl/certs for CA certificates. You may want
>
> On Unix and unless gnupg was build with --with-default-trust-store-file
> the following collections of certificates are used for TLS:
>
> { "/etc/ssl/ca-bundle.pem" },
> { "/etc/ssl/certs/ca-certificates.crt" },
> { "/etc/pki/tls/cert.pem" },
> { "/usr/local/share/certs/ca-root-nss.crt" },
> { "/etc/ssl/cert.pem" }
>
Thanks. None of those files is on my system. So it's probably no wonder
that "--search-keys" didn't work.
Either I messed up big or LFS/BLFS uses a setup for the certificates
that is not what gnupg expects. In the latter case
--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt
may indeed be the way to go for LFS/BLFS systems.
I'll cc this to blfs-support so that the editors can draw their own
conclusions. Or castigate me for being too stupid to follow the
instructions somewhere. ;)
>> to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so
>> that dirmngr looks in the Mozilla certificate library.
>
> Not a too good idea becuase these certificates are used for a different
> purpose.
>
>
> FWIW, here is the list of internal certificate classes used:
>
> CERTTRUST_CLASS_SYSTEM = 1, /* From the system's list of trusted certs. */
> CERTTRUST_CLASS_CONFIG = 2, /* From dirmngr's config files. */
> CERTTRUST_CLASS_HKP = 4, /* From --hkp-cacert*/
> CERTTRUST_CLASS_HKPSPOOL= 8, /* The one and only from sks-keyservers */
>
>
> Shalom-Salam,
>
>Werner
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 29.07.21 um 19:36 schrieb Andrew Gallagher: > On 29/07/2021 17:52, Rainer Fiebig wrote: >> >> ~> openssl x509 -text > After" >> Not After : Sep 30 14:01:15 2021 GMT > > So the file exists, and appears to have the correct contents (the > difference in checksum is probably whitespace or commentary, I wouldn't > worry about it). > > I'm going to refer back to my earlier statement: "It looks like dirmngr > isn't using the same set of CAs that curl is using". > > If you built gnupg from its default configuration, it does not > automatically look in /etc/ssl/certs for CA certificates. You may want > to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so > that dirmngr looks in the Mozilla certificate library. > Perhaps solved. As the main issue here seemed to be that gnupg could not find the certificate(s) and the symlink to /etc/ssl/certs (all .pem) did not work, I re-built gnupg with this configure-switch: --with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt And now --search-keys is working: ~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: data source: https://keys.openpgp.org:443 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > ~> gpg --keyserver hkps://keys.openpgp.org --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: data source: https://keys.openpgp.org:443 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > ~> gpg --keyserver hkps://pgpkeys.eu --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: data source: https://pgpkeys.eu:443 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa Łukasz Langa (Work e-mail account) 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > However, having to build gnupg with this switch feels somewhat akward, like a workaround, not like it should be. I'll post this solution over at blfs-supp...@lists.linuxfromscratch.org and see what they think about it. Perhaps they have a more elegant solution or can tell me whether I've made a configuration-mistake elsewhere. Thank you guys for your time and suggestions. They helped a lot! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 29.07.21 um 19:36 schrieb Andrew Gallagher: > On 29/07/2021 17:52, Rainer Fiebig wrote: >> >> ~> openssl x509 -text > After" >> Not After : Sep 30 14:01:15 2021 GMT > > So the file exists, and appears to have the correct contents (the > difference in checksum is probably whitespace or commentary, I wouldn't > worry about it). > > I'm going to refer back to my earlier statement: "It looks like dirmngr > isn't using the same set of CAs that curl is using". Yes, that seems to be at the heart of the matter. Curl is built with this ./configure switch: --with-ca-path=/etc/ssl/certs and so it finds the correct certificate. There's no such switch for gnupg. So I guess dirmngr looks in /etc/pki for the certs? And maybe the DST_Root_CA_X3 (in "ca-bundle.crt) there is different (outdated?) from the one in /etc/ssl/certs. > > If you built gnupg from its default configuration, it does not > automatically look in /etc/ssl/certs for CA certificates. You may want > to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so > that dirmngr looks in the Mozilla certificate library. > The manpage for dirmngr says that the certificates in /etc/gnupg/trusted-certs are expected to be in .der or .crt encoding. Those in /etc/ssl are .pem, though. I created a symlink /etc/gnupg/trusted-certs -> /etc/ssl/certs/ but gpg --search-keys still fails, probably due to the .pem encoding. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 29.07.21 um 18:45 schrieb Andrew Gallagher: > On 29/07/2021 17:33, Rainer Fiebig wrote: >> Thanks. File exists but has a different checksum: >> >> /etc/ssl/certs> sha256sum DST_Root_CA_X3.pem >> 4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980 >> DST_Root_CA_X3.pem > > Ah, I wonder is the expiry date different. Can you incant the following > please? > > ``` > openssl x509 -text ``` > > Mine says: > > ``` > Not After : Sep 30 14:01:15 2021 GMT > ``` > Same here: ~> openssl x509 -text http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 29.07.21 um 18:16 schrieb Andrew Gallagher: > On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote: >> Am 28.07.21 um 21:38 schrieb Ingo Klöcker: >>> On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users > wrote: >>> >>> Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you? >>> >> No, same output as reported initially. > > The common problem is the LetsEncrypt R3 certificate. > >> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 >> * ALPN, server accepted to use http/1.1 >> * Server certificate: >> * subject: CN=keys.openpgp.org >> * start date: Jul 26 04:32:08 2021 GMT >> * expire date: Oct 24 04:32:06 2021 GMT >> * subjectAltName: host "keys.openpgp.org" matched cert's >> "keys.openpgp.org" >> * issuer: C=US; O=Let's Encrypt; CN=R3 >> * SSL certificate verify ok. > ... >> Looks OK to me. The Let's Encrypt certificate is recognized and >> verified. Or what do you think? > > I think it looks like dirmngr isn't using the same set of CAs that curl > is using. > > The missing root certificate is: > >> 2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root > CA >> X3,O=Digital Signature Trust Co. > Can you confirm that /etc/ssl/certs/DST_Root_CA_X3.pem exists on your > machine and has the following checksum? > > ``` > andrewg@whippet:~$ sha256sum /etc/ssl/certs/DST_Root_CA_X3.pem > 139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99 > /etc/ssl/certs/DST_Root_CA_X3.pem > ``` > Thanks. File exists but has a different checksum: /etc/ssl/certs> sha256sum DST_Root_CA_X3.pem 4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980 DST_Root_CA_X3.pem > Also, is your system clock correct? (long shot, but always worth asking > when debugging TLS cert issues) > System clock is OK. No problem asking - I'm happy for every clue I can get in this matter. ;) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 28.07.21 um 21:38 schrieb Ingo Klöcker: > On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users wrote: >> Am 28.07.21 um 17:42 schrieb Andrew Gallagher: >>> On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote: >>>> 2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit >>>> 'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der >>>> Kette >>>> 2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed: >>>> Fehlendes Herausgeberzertifikat in der Kette >>>> 2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 >>>> beendet >>> >>> "Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing >>> publisher certificate in the chain", is that correct? >> >> Correct. >> >>> keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to >>> other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses >>> the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org. >> >> This works: >> >> ~> gpg --keyserver pgpkeys.eu --search-keys >> E3FF2839C048B25C084DEBE9B26995E310250568 >> gpg: enabled debug flags: memstat >> gpg: data source: http://pgpkeys.eu:11371 >> (1) Łukasz Langa (GPG langa.pl) >> Łukasz Langa >> Łukasz Langa >> Łukasz Langa (Work e-mail account) >>4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 >> Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe >> von Nummern, Nächste (N) oder Abbrechen (Q) > > > Doesn't use TLS. Just plain HTTP. > >> Each of these lines in dirmngr.conf also work: >> keyserver http://keys2.andreas-puls.de/ >> keyserver http://pgpkeys.eu/ > > Ditto. Since your problems seem to be related to TLS it's not really > surprising that keyservers not using https work. > At least I now know that such keyservers still exist. ;) > Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you? > No, same output as reported initially. > What does 'curl -v https://keys.openpgp.org' say? > ~> curl --max-filesize 1 -v https://keys.openpgp.org * Trying 37.218.245.50:443... * Connected to keys.openpgp.org (37.218.245.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=keys.openpgp.org * start date: Jul 26 04:32:08 2021 GMT * expire date: Oct 24 04:32:06 2021 GMT * subjectAltName: host "keys.openpgp.org" matched cert's "keys.openpgp.org" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. > GET / HTTP/1.1 > Host: keys.openpgp.org > User-Agent: curl/7.77.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Server: nginx/1.14.2 < Date: Thu, 29 Jul 2021 07:20:26 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 1761 < Connection: keep-alive < Vary: Accept-Encoding < X-Frame-Options: SAMEORIGIN < X-XSS-Protection: 1; mode=block < X-Content-Type-Options: nosniff < Referrer-Policy: no-referrer-when-downgrade < Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; report-uri https://keysopenpgporg.report-uri.com/r/d/csp/enforce < Strict-Transport-Security: max-age=31536000; includeSubDomains < Expect-CT: max-age=31536000, report-uri="https://keysopenpgporg.report-uri.com/r/d/ct/reportOnly"; < alt-svc: h2="zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion:443"; ma=86400; persist=1 < [..] Looks OK to me. The Let's Encrypt certificate is recognized and verified. Or what do you think? > Regards, > Ingo > Thanks for your help! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 28.07.21 um 17:42 schrieb Andrew Gallagher: > On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote: >> 2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit >> 'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der >> Kette >> 2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed: >> Fehlendes Herausgeberzertifikat in der Kette >> 2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 >> beendet > > "Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing > publisher certificate in the chain", is that correct? > Correct. > keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to > other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses > the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org. > This works: ~> gpg --keyserver pgpkeys.eu --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: enabled debug flags: memstat gpg: data source: http://pgpkeys.eu:11371 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa Łukasz Langa (Work e-mail account) 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > Each of these lines in dirmngr.conf also work: keyserver http://keys2.andreas-puls.de/ keyserver http://pgpkeys.eu/ ~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: enabled debug flags: memstat gpg: data source: http://keys2.andreas-puls.de:80 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa Łukasz Langa (Work e-mail account) 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > > What OS are you using? Do you have the latest version of ca-certificates > (or equivalent) installed? > Linux From Scratch, latest stable. The ca-certificates (from Mozilla.org) are updated regularly (automated). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Am 28.07.21 um 15:45 schrieb Bernhard Reiter:
> Hi Rainer,
>
> Am Mittwoch 28 Juli 2021 11:22:18 schrieb Rainer Fiebig via Gnupg-users:
>> Hi! I'm having a problem when searching for keys on keyservers when
>> using "gpg --search-keys".
>>
>> The only line in dirmngr.conf (except for comments) is:
>> keyserver hkps://keys.openpgp.org
>
> note that this particular keyserver has decided to be incompatible with
> the current OpenPGP standard, by ommitting a valid user id, unless
> it was "validated".
> (It says so it in its FAQ and there is port of a discussion here
> https://dev.gnupg.org/T4393#133695)
> This could potentially cause problems.
>
>> However, this (and only this) works:
>>
>> ~> gpg --keyserver keyserver.ubuntu.com --search-keys
>> E3FF2839C048B25C084DEBE9B26995E310250568
>
> Have you tried some other keyservers like http://keys2.andreas-puls.de/ ?
> Or you can set some dirmngr options to get more diagnostic output
> in its logfile. (See dirmngr's documentation.)
>
> Regards,
> Bernhard
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
Thanks for your quick reply. Set dirmngr to "verbose". The output points
to a certificate-issue (again my apologies to non German-speaking members):
~> cat dirmngr.log
2021-07-28 16:06:49 dirmngr[4134] Es wird auf Socket
`/run/user/1000/gnupg/S.dirmngr' gehört
2021-07-28 16:06:49 dirmngr[4135.0]dauerhaft geladene Zertifikate: 0
2021-07-28 16:06:49 dirmngr[4135.0] zwischengespeicherte Zertifikate: 0
2021-07-28 16:06:49 dirmngr[4135.0] vertrauenswürdige Zertifikate: 0
(0,0,0,0)
2021-07-28 16:06:49 dirmngr[4135.6] Handhabungsroutine für fd 6 gestartet
2021-07-28 16:06:49 dirmngr[4135.6] connection from process 4132 (1000:1000)
2021-07-28 16:06:50 dirmngr[4135.6] resolve_dns_addr for
'keys.openpgp.org': 'keys.openpgp.org' [already known]
2021-07-28 16:06:50 dirmngr[4135.6] resolve_dns_addr for
'keys.openpgp.org': 'keys.openpgp.org' [already known]
2021-07-28 16:06:50 dirmngr[4135.6] detected interfaces: IPv4 IPv6
2021-07-28 16:06:50 dirmngr[4135.6] Zertifikat wurde zwischengespeichert
2021-07-28 16:06:50 dirmngr[4135.6] Zertifikat wurde zwischengespeichert
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Das Zertifikat ist korrekt
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Das Zertifikat ist korrekt
2021-07-28 16:06:50 dirmngr[4135.6] Hinweis: Die unkritische
Zertifikatsrichtlinie ist nicht erlaubt
2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Holen des Zertifikats
mittels Subject: Konfigurationsfehler
2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate
{C4A7B1A47B2C71FADBE14B9075FFC41560858910} not found using
authorityKeyIdentifier
2021-07-28 16:06:50 dirmngr[4135.6] Herausgeberzertifikat nicht gefunden
2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root CA
X3,O=Digital Signature Trust Co.
2021-07-28 16:06:50 dirmngr[4135.6] TLS handshake failed: Fehlendes
Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 beendet
~>
Have to admit that I'm a bit clueless here.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--search-keys: "gpg: error searching keyserver: No inquire callback in IPC"
Hi! I'm having a problem when searching for keys on keyservers when using "gpg --search-keys". The only line in dirmngr.conf (except for comments) is: keyserver hkps://keys.openpgp.org gnupg version is 2.2.29 but I also see this with 2.2.27. Locale is German but "Kein "Inquire" "Callback" für IPC gesetzt" should be equivalent to "No inquire callback in IPC". Sorry. ~> gpg --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: enabled debug flags: memstat gpg: error searching keyserver: Kein "Inquire" "Callback" für IPC gesetzt gpg: Suche auf dem Schlüsselserver fehlgeschlagen: Kein "Inquire" "Callback" für IPC gesetzt gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg:build=0 update=0 insert=0 delete=0 gpg:reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks ~> However, this (and only this) works: ~> gpg --keyserver keyserver.ubuntu.com --search-keys E3FF2839C048B25C084DEBE9B26995E310250568 gpg: enabled debug flags: memstat gpg: data source: http://162.213.33.8:11371 (1) Łukasz Langa (GPG langa.pl) Łukasz Langa Łukasz Langa Łukasz Langa (Work e-mail account) 4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11 Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) [...] Any ideas? Thanks. Rainer Fiebig ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
