From karel-v_g at tutanota.com Sat Jul 3 22:29:15 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sat, 3 Jul 2021 22:29:15 +0200 (CEST) Subject: GPG4Win 3.1.16: mkportable.exe missing? Message-ID: Hello! After Updating from GPG4Win 3.1.15 to .16 I noticed that the newest build does not install mkportable.exe?! Is it missing by intend or by accident? How can I make the latest build portable? Thanks for help! Karel PS: I hope it is okay to ask this GPG4Win-related question here on the GnuPG-list!? From wk at gnupg.org Sun Jul 4 17:43:46 2021 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Jul 2021 17:43:46 +0200 Subject: [Announce] GnuPG 2.2.29 (LTS) released Message-ID: <87tulaaxu5.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG LTS release: version 2.2.29. This release fixes a few minor regression recently introduced with 2.2.28 and changes the default OpenPGP keyserver. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.29 (2021-07-04) ================================================= * Fix regression in 2.2.28 for Yubikey NEO. [#5487] * Change the default keyserver to keyserver.ubuntu.com. This is a temporary change due to the shutdown of the SKS keyserver pools. [47c4e3e00a] * gpg: Let --fetch-key return an exit code on failure. [#5376] * dirmngr: Fix regression in KS_GET for mail address pattern. [#5497] * Add fallback in case the Windows console can't cope with Unicode. [#5491] * Improve initialization of SPR532 in the CCID driver and make the driver more robust. [#5297,b90c55fa66db] * Make test suite work in presence of a broken Libgcrypt installation. [#5502] * Make configure option --disable-ldap work again. Release-info: https://dev.gnupg.org/T5498 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.29 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.29.tar.bz2 (7046k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.29.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.29_20210704.exe (4381k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.29_20210704.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of Gpg4win will probably not be published. Users affected by one of the fixed bugs may instead install this version on top of Gpg4win 3.1.16. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.29.tar.bz2 you would use this command: gpg --verify gnupg-2.2.29.tar.bz2.sig gnupg-2.2.29.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.29.tar.bz2, you run the command like this: sha1sum gnupg-2.2.29.tar.bz2 and check that the output matches the next line: 55393b89cfe520087f4fe55ade2d573e245af58b gnupg-2.2.29.tar.bz2 12ac77a653bfd36a836e7ccd1de95e08a81c9f6d gnupg-w32-2.2.29_20210704.tar.xz 5ca4348a20b52250d7ff962667d47f5da65ca679 gnupg-w32-2.2.29_20210704.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5498 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From frs0 at abv.bg Sun Jul 4 18:36:43 2021 From: frs0 at abv.bg (=?utf-8?B?0JLQuNC60YLQvtGAINCU0LbQtdC70LXQv9C+0LI=?=) Date: Sun, 4 Jul 2021 19:36:43 +0300 (EEST) Subject: Run Kleopatra on MS Windows 10 Message-ID: <137492890.1017210.1625416603881@nm81.abv.bg> Hello, I'm using Gpg4win on Windows 10 Home (64-bit). Gpg4Win version: 3.1.16 When I try to run Kleopatra from the desktop (not as an administrator), it doesn't run. When I run it as an administrator, I get a dialog with the following warning message: "Kleopatra cannot be run as administrator without breaking file permissions in the GnuPG data folder. To manage keys for other users please manage them as a normal user and copy the 'AppData\Roaming\gnupg' directory with proper permissions. Are you sure you want to continue?" As I understand, this is a known issue. Looked for working solutions, but so far found some workarounds: 1. Install an older version of Gpg4win (e.g. 3.1.14) 2. Run Kleopatra through the cmd 3. Run as a normal user (Found more info in an article on the GnuPG Wiki: https://wiki.gnupg.org/Gpg4win/RunAsUser) Are there other recommended solutions or workarounds for this type of issue? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From feiphung at hotmail.com Tue Jul 6 12:20:33 2021 From: feiphung at hotmail.com (Cheng Fei Phung) Date: Tue, 6 Jul 2021 10:20:33 +0000 Subject: set the default setting of using "echo RELOADAGENT | gpg-connect-agent" In-Reply-To: References: Message-ID: Hi, how do I set the default setting of using "echo RELOADAGENT | gpg-connect-agent" for https://wiki.archlinux.org/title/Pass ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglist at chiraag.me Tue Jul 6 21:24:22 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Tue, 06 Jul 2021 19:24:22 +0000 Subject: set the default setting of using "echo RELOADAGENT | gpg-connect-agent" In-Reply-To: References: Message-ID: 12021/04/26 02:64.27 ?????, Cheng Fei Phung via Gnupg-users ??????: > Hi, > > how do I set the default setting of using "echo RELOADAGENT | > gpg-connect-agent" > for [1]https://wiki.archlinux.org/title/Pass ? > > References: > > [1] https://wiki.archlinux.org/title/Pass Why do you need to do that? This feels like an XY problem: https://en.wikipedia.org/wiki/XY_problem Sincerely, Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Jul 6 21:59:07 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Jul 2021 15:59:07 -0400 Subject: recommendation for key servers In-Reply-To: References: Message-ID: <871r8bi584.fsf@fifthhorseman.net> On Mon 2021-06-28 18:42:02 +0100, Andrew Gallagher via Gnupg-users wrote: > It?s not clear, but it may be due to a lack of canonical ordering of > packets. There are no published specifications for how to canonically order OpenPGP packets, but i sketched a proposal here: https://dev.gnupg.org/T3389 Adoption of such a canonical ordering would reduce the amount of computation for synchronizing keyservers, once they all adopted the same one. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jul 7 00:20:23 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 6 Jul 2021 23:20:23 +0100 Subject: recommendation for key servers In-Reply-To: <871r8bi584.fsf@fifthhorseman.net> References: <871r8bi584.fsf@fifthhorseman.net> Message-ID: On 06/07/2021 20:59, Daniel Kahn Gillmor wrote: > On Mon 2021-06-28 18:42:02 +0100, Andrew Gallagher via Gnupg-users wrote: >> It?s not clear, but it may be due to a lack of canonical ordering of >> packets. > > There are no published specifications for how to canonically order > OpenPGP packets, but i sketched a proposal here: > > https://dev.gnupg.org/T3389 > > Adoption of such a canonical ordering would reduce the amount of > computation for synchronizing keyservers, once they all adopted the same > one. That's an interesting idea, and it has merit in itself, but from a keyserver point of view I think a more general solution is to explode TPKs into atomic components, sync them separately, and reconstruct the TPK on demand at query time. This addresses not just reordering of packets, but also differential filtering, simultaneous updates, etc. See https://github.com/hockeypuck/hockeypuck/issues/137 -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 7 09:14:49 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Jul 2021 09:14:49 +0200 Subject: recommendation for key servers In-Reply-To: <871r8bi584.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Tue, 06 Jul 2021 15:59:07 -0400") References: <871r8bi584.fsf@fifthhorseman.net> Message-ID: <87y2ai8uja.fsf@wheatstone.g10code.de> On Tue, 6 Jul 2021 15:59, Daniel Kahn Gillmor said: > There are no published specifications for how to canonically order > OpenPGP packets, but i sketched a proposal here: There has never been a need for such an ordering except for what the specs require. Introducing a specific order will make most applications non-compliant. Further, and more important, it does not help because an application can't rely on this and needs to do sort anyway. ASN.1 DER rules for a SET require a specific order but OpenPGP fortuntalely avoid ASN.1 encodings. > Adoption of such a canonical ordering would reduce the amount of > computation for synchronizing keyservers, once they all adopted the same Keyservers can of course do that if that better fits their processing model. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Jul 7 15:14:15 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Jul 2021 09:14:15 -0400 Subject: recommendation for key servers In-Reply-To: References: <871r8bi584.fsf@fifthhorseman.net> Message-ID: <87lf6igtaw.fsf@fifthhorseman.net> On Tue 2021-07-06 23:20:23 +0100, Andrew Gallagher wrote: > That's an interesting idea, and it has merit in itself, but from a > keyserver point of view I think a more general solution is to explode > TPKs into atomic components, sync them separately, and reconstruct the > TPK on demand at query time. This addresses not just reordering of > packets, but also differential filtering, simultaneous updates, etc. > > See https://github.com/hockeypuck/hockeypuck/issues/137 thanks, this is a very interesting framing. I've written some comments on that github issue to try to think it through more. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 7 19:57:14 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Jul 2021 19:57:14 +0200 Subject: recommendation for key servers In-Reply-To: <87o8begvb4.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 07 Jul 2021 08:30:55 -0400") References: <871r8bi584.fsf@fifthhorseman.net> <87y2ai8uja.fsf@wheatstone.g10code.de> <87o8begvb4.fsf@fifthhorseman.net> Message-ID: <87lf6i80sl.fsf@wheatstone.g10code.de> On Wed, 7 Jul 2021 08:30, Daniel Kahn Gillmor said: > Without a canonical form, we simply can't make such a proposal. You need to check for the canonical form anway and thus it is easier to directly sort it. In case of signature subpackets (if that is one of your concerns), this if of course not possible and thus this would require that the specs require a specfic order > I'm happy for OpenPGP to continue avoiding ASN.1 as much as possible! > (and a bit bummed that a tiny, mangled bit of ASN.1 has crept in with > ECC but i guess that's water under the bridge) Oh, it is already also in PCKS#1.5 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Jul 8 00:30:57 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Jul 2021 18:30:57 -0400 Subject: recommendation for key servers In-Reply-To: <87lf6i80sl.fsf@wheatstone.g10code.de> References: <871r8bi584.fsf@fifthhorseman.net> <87y2ai8uja.fsf@wheatstone.g10code.de> <87o8begvb4.fsf@fifthhorseman.net> <87lf6i80sl.fsf@wheatstone.g10code.de> Message-ID: <87czrthi3i.fsf@fifthhorseman.net> On Wed 2021-07-07 19:57:14 +0200, Werner Koch wrote: > You need to check for the canonical form anway and thus it is easier to > directly sort it. In case of signature subpackets (if that is one of > your concerns), this if of course not possible and thus this would > require that the specs require a specfic order yep, i'm uninterested in any canonicalization trying to sort the hashed subpackets -- they are whatever they are on the wire and any reasonable implementation should accept them and retain them as is. Canonicalization should be limited to the parts that are "flexible" in that reordering does not invalidate signatures. >> I'm happy for OpenPGP to continue avoiding ASN.1 as much as possible! >> (and a bit bummed that a tiny, mangled bit of ASN.1 has crept in with >> ECC but i guess that's water under the bridge) > > Oh, it is already also in PCKS#1.5 ugh, right. so it goes? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brandon753.ba at gmail.com Thu Jul 8 02:57:09 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Wed, 7 Jul 2021 17:57:09 -0700 Subject: HID Omnikey 3121 Smart Card Reader and GPG Message-ID: <051b2020-b4f6-b2b7-c94a-54feed466b9b@gmail.com> So I have purchased an Omnikey 3121 smart card reader for use with my GPG smart card version 2.1. Whenever I put my card in and request `gpg --card-status`, the reader flashes its light for about a minute, and then finally, gpg returns with: ``` ?? ~ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device ``` Now I know the card reader works because if I use pscs_scan I immediately get: ``` ?? ~ pcsc_scan Using reader plug'n play mechanism Scanning present readers... 0: HID Global OMNIKEY 3x21 Smart Card Reader [OMNIKEY 3x21 Smart Card Reader] 00 00 Wed Jul? 7 17:41:24 2021 ?Reader 0: HID Global OMNIKEY 3x21 Smart Card Reader [OMNIKEY 3x21 Smart Card Reader] 00 00 ? Event number: 2 ? Card state: Card inserted, ? ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C + TS = 3B --> Direct Convention + T0 = DA, Y(1): 1101, K: 10 (historical bytes) ? TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU ??? 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s ? TC(1) = FF --> Extra guard time: 255 (special value) ? TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 ----- ? TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 ----- ? TA(3) = FE --> IFSC: 254 ? TB(3) = 75 --> Block Waiting Integer: 7 - Character Waiting Integer: 5 ? TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following ----- ? TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V + Historical bytes: 00 31 C5 73 C0 01 40 00 90 00 ? Category indicator byte: 00 (compact TLV data object) ??? Tag: 3, len: 1 (card service data byte) ????? Card service data byte: C5 ??????? - Application selection: by full DF name ??????? - Application selection: by partial DF name ??????? - EF.DIR and EF.ATR access services: by GET DATA command ??????? - Card without MF ??? Tag: 7, len: 3 (card capabilities) ????? Selection methods: C0 ??????? - DF selection by full DF name ??????? - DF selection by partial DF name ????? Data coding byte: 01 ??????? - Behaviour of write functions: one-time write ??????? - Value 'FF' for the first byte of BER-TLV tag fields: invalid ??????? - Data unit in quartets: 2 ????? Command chaining, length fields and logical channels: 40 ??????? - Extended Lc and Le fields ??????? - Logical channel number assignment: No logical channel ??????? - Maximum number of logical channels: 1 ??? Mandatory status indicator (3 last bytes) ????? LCS (life card cycle): 00 (No information given) ????? SW: 9000 (Normal processing.) + TCK = 0C (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C ??? OpenPGP Card V2 ``` And if I run `pkcs15-tool -k`, I get the following returned: ``` ?? ~ pkcs15-tool -k Using reader with a card: HID Global OMNIKEY 3x21 Smart Card Reader [OMNIKEY 3x21 Smart Card Reader] 00 00 Private RSA Key [Signature key] ??? Object Flags?? : [0x03], private, modifiable ??? Usage????????? : [0x20C], sign, signRecover, nonRepudiation ??? Access Flags?? : [0x1D], sensitive, alwaysSensitive, neverExtract, local ??? Algo_refs????? : 0 ??? ModLength????? : 4096 ??? Key ref??????? : 0 (0x00) ??? Native???????? : yes ??? Auth ID??????? : 01 ??? ID???????????? : 01 ??? MD:guid??????? : Private RSA Key [Encryption key] ??? Object Flags?? : [0x03], private, modifiable ??? Usage????????? : [0x22], decrypt, unwrap ??? Access Flags?? : [0x1D], sensitive, alwaysSensitive, neverExtract, local ??? Algo_refs????? : 0 ??? ModLength????? : 4096 ??? Key ref??????? : 1 (0x01) ??? Native???????? : yes ??? Auth ID??????? : 02 ??? ID???????????? : 02 ??? MD:guid??????? : Private RSA Key [Authentication key] ??? Object Flags?? : [0x03], private, modifiable ??? Usage????????? : [0x222], decrypt, unwrap, nonRepudiation ??? Access Flags?? : [0x1D], sensitive, alwaysSensitive, neverExtract, local ??? Algo_refs????? : 0 ??? ModLength????? : 4096 ??? Key ref??????? : 2 (0x02) ??? Native???????? : yes ??? Auth ID??????? : 02 ??? ID???????????? : 03 ??? MD:guid??????? : ``` So I believe the card reader is working fine, but gpg is just not working with it for some reason. On the GPG howto page, it's listed as (https://www.gnupg.org/howtos/card-howto/en/ch02s02.html): Omnikey Cardman 3121 (and 2020) This USB card reader supports CCID and PC/SC. The older Omnikey Cardman 2020 is no longer produced. The newer reader has not been tested, but Omnikey says that the two readers are compatible. To add some context, I am able to use my Identiv SCR3500 just fine with the same system using the same card; I just wanted a more permanent setup for my desktop. I am using gpg version 2.3.1 on Debian Sid. Are there steps I can/should take to diagnose what's going on? Is this card reader not compatible with the GPG drivers? Any advice would be appreciated. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Jul 8 09:48:04 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 08 Jul 2021 16:48:04 +0900 Subject: HID Omnikey 3121 Smart Card Reader and GPG In-Reply-To: <051b2020-b4f6-b2b7-c94a-54feed466b9b@gmail.com> References: <051b2020-b4f6-b2b7-c94a-54feed466b9b@gmail.com> Message-ID: <87v95l2qmj.fsf@jumper.gniibe.org> Hello, Brandon Anderson wrote: > So I have purchased an Omnikey 3121 smart card reader for use with my > GPG smart card version 2.1. Reading the descriptors: https://ccid.apdu.fr/ccid/readers/CardMan3121.txt It says: 02.... Short APDU level exchange This means that the reader cannot handle larger data. So, I think that Omnikey CardMan 3121 can work in the use case with OpenPGP card if it's key is RSA 1024. But it doesn't work well for RSA-2048 or RSA-4096. -- From wk at gnupg.org Fri Jul 9 08:11:54 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Jul 2021 08:11:54 +0200 Subject: HID Omnikey 3121 Smart Card Reader and GPG In-Reply-To: <87v95l2qmj.fsf@jumper.gniibe.org> (NIIBE Yutaka's message of "Thu, 08 Jul 2021 16:48:04 +0900") References: <051b2020-b4f6-b2b7-c94a-54feed466b9b@gmail.com> <87v95l2qmj.fsf@jumper.gniibe.org> Message-ID: <87o8bc6mol.fsf@wheatstone.g10code.de> On Thu, 8 Jul 2021 16:48, NIIBE Yutaka said: > So, I think that Omnikey CardMan 3121 can work in the use case with > OpenPGP card if it's key is RSA 1024. Exactly, I used to use Omnikey readers too but I had to gave up due to this problem. On Windows Omnikey's driver uses proprietary escape codes to make it work: /* We employ a hack for Omnikey readers which are able to send TPDUs using an escape sequence. There is no documentation but the Windows driver does it this way. Tested using a CM6121. This method works also for the Cherry XX44 keyboards; however there are problems with the ccid_transceive_secure which leads to a loss of sync on the CCID level. If Cherry wants to make their keyboard work again, they should hand over some docs. */ The 6121 is a PCMCIA style reader which I could make work for my old laptop. As usual with reader vendors they use their ASICs for all types of readers and thus he sees the problem also with the 3121. I have an 5121 here but I can use it only for RFID. He may be able to use the 3121 with ECC keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brandon753.ba at gmail.com Sat Jul 10 01:20:08 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Fri, 9 Jul 2021 16:20:08 -0700 Subject: HID Omnikey 3121 Smart Card Reader and GPG In-Reply-To: <87o8bc6mol.fsf@wheatstone.g10code.de> References: <051b2020-b4f6-b2b7-c94a-54feed466b9b@gmail.com> <87v95l2qmj.fsf@jumper.gniibe.org> <87o8bc6mol.fsf@wheatstone.g10code.de> Message-ID: <778c69bd-e4f0-611c-44ee-437f5a636c32@gmail.com> > On Thu, 8 Jul 2021 16:48, NIIBE Yutaka said: > >> So, I think that Omnikey CardMan 3121 can work in the use case with >> OpenPGP card if it's key is RSA 1024. > Exactly, I used to use Omnikey readers too but I had to gave up due to > this problem. On Windows Omnikey's driver uses proprietary escape codes > to make it work: > > /* We employ a hack for Omnikey readers which are able to send > TPDUs using an escape sequence. There is no documentation > but the Windows driver does it this way. Tested using a > CM6121. This method works also for the Cherry XX44 > keyboards; however there are problems with the > ccid_transceive_secure which leads to a loss of sync on the > CCID level. If Cherry wants to make their keyboard work > again, they should hand over some docs. */ > > The 6121 is a PCMCIA style reader which I could make work for my old > laptop. As usual with reader vendors they use their ASICs for all types > of readers and thus he sees the problem also with the 3121. I have an > 5121 here but I can use it only for RFID. > > He may be able to use the 3121 with ECC keys. > > Wow, that is interesting to know; I guess I will return the Omnikey 3221 and pick up an Identiv SCR3310 instead. I really liked the vertical slot design on the Omnikey for the card as all the cheaper no-name readers that were vertical would give me USB problems if plugged in permanently, so I was hoping the Omnikey would be a better reader. Anyway, thank you both for letting me know what was going on. - Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Mon Jul 12 14:05:37 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Jul 2021 14:05:37 +0200 Subject: GPG4Win 3.1.16: mkportable.exe missing? In-Reply-To: References: Message-ID: <5734429.lOV4Wx5bFT@kymo.gruen> Hello Karel, Am Samstag, 3. Juli 2021, 22:29:15 CEST schrieb karel-v_g--- via Gnupg-users: > After Updating from GPG4Win 3.1.15 to .16 I noticed that the newest build > does not install mkportable.exe?! Is it missing by intend or by accident? as far as I know mkportable works in principle on Gpg4win 3.1.16, see success reports on https://dev.gnupg.org/T5287 So the question is why does it not install for you. Can you try a reinstall and select all components? > PS: I hope it is okay to ask this GPG4Win-related question here on the > GnuPG-list!? To me it is okay, though gpg4win-users-en at wald.intevation.org is even more appropriate. If possible, followup there. (You need to subscribe to the list.) Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From marcio.barbado at gmail.com Mon Jul 12 18:15:26 2021 From: marcio.barbado at gmail.com (Marcio Barbado, Jr.) Date: Mon, 12 Jul 2021 13:15:26 -0300 Subject: contact list issues Message-ID: Hello, as a part of securing e-mail, I think proper address book management (and the network of contacts one might maintain) poses a crucial aspect. Thus, I've been wondering about secure PIM-related address book (or contact list) management strategies. My goal is to move away from the Google Contacts service but keep my contacts reasonably available. So, I would like to know if someone in this list is able to share positive results in that sense. Regards, -- Marcio Barbado, Jr. mobile: 55 11 9-9649-4709 IEEE member # 93931653, South Brazil Section ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Esta mensagem e qualquer arquivo nela contido ? confidencial. "Pratica crime de viola??o de telecomunica??es quem, transgredindo lei ou regulamento, exiba aut?grafo ou qualquer documento ou arquivo, divulgue ou comunique, informe ou capte, transmita a outrem ou utilize o conte?do, resumo, significado, interpreta??o, indica??o ou efeito de qualquer comunica??o dirigida a terceiro." (Artigo 56 da Lei n.? 4.117 de 27 de agosto de 1962, aplic?vel aos crimes em telecomunica??es, nos termos do art. 215, I, da Lei 9.472/97). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE This message including any attachments is confidential information of Marcio Barbado Junior. Disclosure, copying or distribution is prohibited without permission of Marcio Barbado Junior. If you are not the intended recipient, please reply to the sender and then delete this message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Jul 13 10:21:01 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Jul 2021 10:21:01 +0200 Subject: Run Kleopatra on MS Windows 10 In-Reply-To: <137492890.1017210.1625416603881@nm81.abv.bg> References: <137492890.1017210.1625416603881@nm81.abv.bg> Message-ID: <202107131021.02166.bernhard@intevation.de> Hello, Am Sonntag 04 Juli 2021 18:36:43 schrieb ?????? ???????? via Gnupg-users: > Hello, I'm using Gpg4win on Windows 10 Home (64-bit). Gpg4Win version: > 3.1.16 > > When I try to run Kleopatra from the desktop (not as an administrator), > it doesn't run. try to find out why it does not run. If you have been using Kleopatra as an administrator before (which is not recommended), you may have a permission problem somewhere. So one way could be to move away (backup) your GnuPG data and then see if Kleopatra runs again. > When I run it as an administrator, I get a dialog with the > following warning message: "Kleopatra cannot be run as administrator > without breaking file permissions in the GnuPG data folder. To manage keys > for other users please manage them as a normal user and copy the > 'AppData\Roaming\gnupg' directory with proper permissions. Are you sure you > want to continue?" You can just continue there, if you know what you are doing and can live with the permission and security consequences (as outlined in https://wiki.gnupg.org/Gpg4win/RunAsUser) > As I understand, this is a known issue. Looked for working solutions, but > so far found some workarounds: > 1. Install an older version of Gpg4win (e.g. 3.1.14) > 2. Run Kleopatra through the cmd > 3. Run as a normal user (Found more info in an article on the GnuPG Wiki: > https://wiki.gnupg.org/Gpg4win/RunAsUser) > > Are there other recommended solutions or workarounds for this type of > issue? Thanks! Best Regards, Bernhard ps.: Let us move this discussion to https://lists.wald.intevation.org/mailman/listinfo/gpg4win-users-en/ which is more focussed on Gpg4win topics. :) -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jul 13 10:30:21 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Jul 2021 10:30:21 +0200 Subject: contact list issues In-Reply-To: References: Message-ID: <202107131030.22289.bernhard@intevation.de> Hello Marcio, Am Montag 12 Juli 2021 18:15:26 schrieb Marcio Barbado, Jr. via Gnupg-users: > My goal is to move away from the Google Contacts service but keep my > contacts reasonably available. > > So, I would like to know if someone in this list is able to share positive > results in that sense. using a privacy sensitive email provider can help you here. E.g. with https://posteo.de/en the addressbook can be shared by CardDAV and is available to many email clients, I've shared it successfully with Android and SailfishOS devices via https://f-droid.org/de/packages/at.bitfire.davdroid/ I saw it on Kmail, too and vdirsyncer would also allow a sync. I guess mailbox.org will offer a similiar service and there are probably more email providers out there that offer CalDAV with the account. (Posteo and Mailbox.org just came out top on a 2015 test for privacy aware providers in a test.de survey and they are add-free and with a reasonable fee.) Note that both also offer WKD services. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From fxkl47BF at protonmail.com Tue Jul 13 14:33:11 2021 From: fxkl47BF at protonmail.com (fxkl47BF) Date: Tue, 13 Jul 2021 12:33:11 +0000 Subject: contact list issues In-Reply-To: <202107131030.22289.bernhard@intevation.de> References: <202107131030.22289.bernhard@intevation.de> Message-ID: ??????? Original Message ??????? On Tuesday, July 13th, 2021 at 3:30 AM, Bernhard Reiter wrote: > Hello Marcio, > Am Montag 12 Juli 2021 18:15:26 schrieb Marcio Barbado, Jr. via Gnupg-users: > > My goal is to move away from the Google Contacts service but keep my > > contacts reasonably available. > > So, I would like to know if someone in this list is able to share positive > > results in that sense. > > using a privacy sensitive email provider can help you here. > E.g. with > https://posteo.de/en > the addressbook can be shared by CardDAV and is available to many email > clients, I've shared it successfully with Android and SailfishOS devices > via https://f-droid.org/de/packages/at.bitfire.davdroid/ > I saw it on Kmail, too and vdirsyncer would also allow a sync. > I guess mailbox.org will offer a similiar service > and there are probably more email providers out there that offer CalDAV > with the account. (Posteo and Mailbox.org just came out top on a 2015 test > for privacy aware providers in a test.de survey and they are add-free and > with a reasonable fee.) Note that both also offer WKD services. a little off topic but the only issue i have with posteo is how they handle what they consider spam they just bounce it back to the sender you never get a chance to review the messages From stefan.vasilev at posteo.ru Wed Jul 14 14:45:53 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 12:45:53 +0000 Subject: Call me crazy, but ... Message-ID: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> if a person, within the EU, would put his COVID vaccination certificate QR-Code in his pub-key as photo-ID I would say that than another GnuPG user, within the EU, or maybe later in the U.S. and elsewhere too, would have the assurance, without that the public key is otherwise signed, that this pub key belongs to that person. On GitHub is a decoder available, which allows users to verify the digital signature of such COVID certs, with trustlists from EU member states. https://github.com/stapelberg/coronaqr Regards Stefan From brandon753.ba at gmail.com Wed Jul 14 15:41:11 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Wed, 14 Jul 2021 06:41:11 -0700 Subject: Call me crazy, but ... In-Reply-To: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> Message-ID: <18d68f4a-42bb-ec5d-773e-7a98b0e464f2@gmail.com> What exactly stops me, a person wanting to impersonate that user, from putting the same QR-Code I got from that public key into my own keypair? On 7/14/21 5:45 AM, ?????? ???????? via Gnupg-users wrote: > if a person, within the EU, would put his COVID vaccination > certificate QR-Code > in his pub-key as photo-ID I would say that than another GnuPG user, > within > the EU, or maybe later in the U.S. and elsewhere too, would have the > assurance, > without that the public key is otherwise signed, that this pub key > belongs to that > person. > > On GitHub is a decoder available, which allows users to verify the > digital signature > of such COVID certs, with trustlists from EU member states. > > https://github.com/stapelberg/coronaqr > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Wed Jul 14 16:05:50 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 14:05:50 +0000 Subject: Call me crazy, but ... In-Reply-To: <18d68f4a-42bb-ec5d-773e-7a98b0e464f2@gmail.com> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <18d68f4a-42bb-ec5d-773e-7a98b0e464f2@gmail.com> Message-ID: <04b6ac64fafc7c7fe1ec0a3ae0b695e6@posteo.de> Brandon Anderson wrote: > What exactly stops me, a person wanting to impersonate that user, from > putting the same QR-Code I got from that public key into my own > keypair? Nothing, if you obtained the pub key from a key server! The idea would be that Alice and Bob, not having a CA, nor WoT signatures, while they both never met in person, could make a duplicate without the photo-id, which they always use and upload to key servers etc. and for verification purposes the could exchange the pub keys with to photo-id for comparison of both keys. Once compared they both sign then the pub keys which have no photo-id. Regards Stefan From johanw at vulcan.xs4all.nl Wed Jul 14 16:09:57 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 14 Jul 2021 16:09:57 +0200 Subject: Call me crazy, but ... In-Reply-To: <18d68f4a-42bb-ec5d-773e-7a98b0e464f2@gmail.com> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <18d68f4a-42bb-ec5d-773e-7a98b0e464f2@gmail.com> Message-ID: <88ebdd6e-bed8-a41b-0aa3-bf6f2f6c479d@vulcan.xs4all.nl> On 14-07-2021 15:41, Brandon Anderson via Gnupg-users wrote: > What exactly stops me, a person wanting to impersonate that user, from > putting the same QR-Code I got from that public key into my own keypair? Nothing. This latest EU implementation of a social credit system is intended to be used with an offline ID card. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From stefan.vasilev at posteo.ru Wed Jul 14 16:11:33 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 14:11:33 +0000 Subject: Call me crazy, but ... In-Reply-To: References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> Message-ID: <1a981a47817409e4dd20ea31975b2a80@posteo.de> accounts-gnupg at holbrook.no wrote: > Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU > covid qr code of mine, but neither could do it. > > Is that some kind of custom encoding going on? Yes, it should work. What you can try is to use an online QR decoder and use from the obtained text the first string (in base45) and save it in a text file and then run the Golang program only with the text file. coronadecode -verify < base45string.txt. Without using the the trustparameter it uses then by default the German trustlist. Regards Stefan From accounts-gnupg at holbrook.no Wed Jul 14 15:41:05 2021 From: accounts-gnupg at holbrook.no (accounts-gnupg at holbrook.no) Date: Wed, 14 Jul 2021 15:41:05 +0200 Subject: Call me crazy, but ... In-Reply-To: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> Message-ID: Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU covid qr code of mine, but neither could do it. Is that some kind of custom encoding going on? l On Wed, Jul 14, 2021 at 12:45:53PM +0000, ?????? ???????? via Gnupg-users wrote: > if a person, within the EU, would put his COVID vaccination certificate > QR-Code > in his pub-key as photo-ID I would say that than another GnuPG user, within > the EU, or maybe later in the U.S. and elsewhere too, would have the > assurance, > without that the public key is otherwise signed, that this pub key belongs > to that > person. > > On GitHub is a decoder available, which allows users to verify the digital > signature > of such COVID certs, with trustlists from EU member states. > > https://github.com/stapelberg/coronaqr > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From accounts-gnupg at holbrook.no Wed Jul 14 16:28:57 2021 From: accounts-gnupg at holbrook.no (accounts-gnupg at holbrook.no) Date: Wed, 14 Jul 2021 16:28:57 +0200 Subject: Call me crazy, but ... In-Reply-To: <1a981a47817409e4dd20ea31975b2a80@posteo.de> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <1a981a47817409e4dd20ea31975b2a80@posteo.de> Message-ID: "online decoder" will part of the point is not to upload my qr to some external site. That should strictly not be necessary. Are there other qr decode apps (cli) out there that people have used successfully with the corona qr surveillance trojan? On Wed, Jul 14, 2021 at 02:11:33PM +0000, ?????? ???????? wrote: > accounts-gnupg at holbrook.no wrote: > > Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU > > covid qr code of mine, but neither could do it. > > > > Is that some kind of custom encoding going on? > > Yes, it should work. What you can try is to use an online QR decoder > and use from the obtained text the first string (in base45) and save > it in a text file and then run the Golang program only with the text > file. coronadecode -verify < base45string.txt. Without using the > the trustparameter it uses then by default the German trustlist. > > Regards > Stefan From stefan.vasilev at posteo.ru Wed Jul 14 16:42:14 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 14:42:14 +0000 Subject: Call me crazy, but ... In-Reply-To: References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <1a981a47817409e4dd20ea31975b2a80@posteo.de> Message-ID: <3a7d2f5a96c5d21ce61cb9897835fcbb@posteo.de> accounts-gnupg at holbrook.no wrote: > "online decoder" will part of the point is not to upload my qr to some > external site. That should strictly not be necessary. > > Are there other qr decode apps (cli) out there that people have used > successfully with the corona qr surveillance trojan? I don't know, I have only used zbarimg, as described. Regards Stefan From ageyev at gmail.com Wed Jul 14 16:23:42 2021 From: ageyev at gmail.com (Viktor) Date: Wed, 14 Jul 2021 17:23:42 +0300 Subject: Call me crazy, but ... In-Reply-To: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> Message-ID: <03f9f72d-97b8-84b2-2933-d76bade52d6e@gmail.com> It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. In general: unless we have other trusted person to verify that public key belongs to certain person, we can not ensure key owner identity before we have some transactions signed with this key. And we should not only trust person that has verified public key certificate, we should also know and trust the procedure this person used to verify public key certificate. And this is very important if there is a dispute, say about a signed contract. This was the flaw in pgp's web of trust: verification procedures were not known. Best regards, Viktor Ageyev CEO, Cryptonomica.net On 14/07/2021 15:45, ?????? ???????? via Gnupg-users wrote: > if a person, within the EU, would put his COVID vaccination certificate > QR-Code > in his pub-key as photo-ID I would say that than another GnuPG user, within > the EU, or maybe later in the U.S. and elsewhere too, would have the > assurance, > without that the public key is otherwise signed, that this pub key > belongs to that > person. > > On GitHub is a decoder available, which allows users to verify the > digital signature > of such COVID certs, with trustlists from EU member states. > > https://github.com/stapelberg/coronaqr > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From stefan.vasilev at posteo.ru Wed Jul 14 19:32:58 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 17:32:58 +0000 Subject: Call me crazy, but ... In-Reply-To: <03f9f72d-97b8-84b2-2933-d76bade52d6e@gmail.com> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <03f9f72d-97b8-84b2-2933-d76bade52d6e@gmail.com> Message-ID: Viktor wrote: > It's the same as putting any other public information in public key > certificate. You can put first and last name, email address and even > photo of another person. But this information can be digitally verified and is issued EU wide by Governemnt trusted sources in this field. > In general: unless we have other trusted person to verify that public > key belongs to certain person, we can not ensure key owner identity > before we have some transactions signed with this key. I think nowadays in digital age the time of single individuals who need to be trusted for digital verification purposes is long over, or how would you manage this if you, for example, are a trusted person with no sigs from others and people in other countries should trust you and your verification skills (and honesty)? > And we should not only trust person that has verified public key > certificate, we should also know and trust the procedure this person > used to verify public key certificate. And this is very important if > there is a dispute, say about a signed contract. In EU with eID and eIDAS it is all outlined and nobody has again to trust a single individual or his skill set the person used to verify a valid certificate. The reason why I opened this thread was to show users the cheapest[1] way to put digitally certified data, from trusted EU sources, which can be digitally verified, into a photo-ID, to bind the included full name to the same full name as the pub keys UID. However, just used as duplicate for comaprison and not to be uploaded to keyservers like I said in another reply. [1] In Germany exists Governikus, which acts on behalf of the BSI as CA for OpenPGP users for free, but it never took off under German GnuPG users, because it requires the purchase of an BSI certified card Reader and that the person has already a new ID-card, which this functionallity is activated in the ID-card chip. > This was the flaw in pgp's web of trust: verification procedures were > not known. I would say they were known, but you could not rely on them. Regards Stefan From andrewg at andrewg.com Wed Jul 14 20:12:36 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 Jul 2021 19:12:36 +0100 Subject: Call me crazy, but ... In-Reply-To: References: Message-ID: > On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users wrote: > > ?Viktor wrote: > >> It's the same as putting any other public information in public key >> certificate. You can put first and last name, email address and even >> photo of another person. > > But this information can be digitally verified and is issued EU wide by > Governemnt trusted sources in this field. But this puts logical causality the wrong way around. Just because the thing *being signed* is genuine, does not prove that the thing *doing the signing* is genuine. IMO this proposal is abuse of the public key infrastructure. If you want to sign an ID document, just sign an ID document and distribute it through other channels. Attaching it as a signed packet to a key adds zero value, at nonzero cost. A From stefan.vasilev at posteo.ru Wed Jul 14 20:49:10 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 18:49:10 +0000 Subject: Call me crazy, but ... In-Reply-To: References: Message-ID: <2c514f77f5be2404dbd0248668de4d69@posteo.de> Andrew Gallagher wrote: >> On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users >> wrote: >> >> ?Viktor wrote: >> >>> It's the same as putting any other public information in public key >>> certificate. You can put first and last name, email address and even >>> photo of another person. >> >> But this information can be digitally verified and is issued EU wide >> by >> Governemnt trusted sources in this field. > > But this puts logical causality the wrong way around. Just because the > thing *being signed* is genuine, does not prove that the thing *doing > the signing* is genuine. > > IMO this proposal is abuse of the public key infrastructure. If you > want to sign an ID document, just sign an ID document and distribute > it through other channels. Attaching it as a signed packet to a key > adds zero value, at nonzero cost. What abuse do you see here, if I may ask? I see it as an non-public option among virtual GnuPG friends to include in a duplicate certified data, which is not meant to been distributed on keyservers etc. or made public to the world and acts for two pub keys comparison. Regards Stefan From johanw at vulcan.xs4all.nl Wed Jul 14 21:05:26 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 14 Jul 2021 21:05:26 +0200 Subject: Call me crazy, but ... In-Reply-To: References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <03f9f72d-97b8-84b2-2933-d76bade52d6e@gmail.com> Message-ID: <60a101a1-4749-f960-ed0e-e798a44f6ecb@vulcan.xs4all.nl> On 14-07-2021 19:32, ?????? ???????? via Gnupg-users wrote: > from trusted EU sources, We may have a different idea about "trusted". There are enough fake official ID's, like undercover police uses. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From stefan.vasilev at posteo.ru Wed Jul 14 21:19:41 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 19:19:41 +0000 Subject: Call me crazy, but ... In-Reply-To: <60a101a1-4749-f960-ed0e-e798a44f6ecb@vulcan.xs4all.nl> References: <3b5e997c9a061c9405a3bdafe30ffc7a@posteo.de> <03f9f72d-97b8-84b2-2933-d76bade52d6e@gmail.com> <60a101a1-4749-f960-ed0e-e798a44f6ecb@vulcan.xs4all.nl> Message-ID: <758c6ec8a2b407a51ac053931ca4ff70@posteo.de> Johan Wevers wrote: > On 14-07-2021 19:32, ?????? ???????? via Gnupg-users wrote: > >> from trusted EU sources, > > We may have a different idea about "trusted". There are enough fake > official ID's, like undercover police uses. And on the other side the WoT and OpenPGP is/was never accepted in Internet businesses, politics etc. and super good things like Governikus never took off among German GnuPG users to spread in the world to make GnuPG an accepted product for trusted digital signatures in Internet businesses etc. Regards Stefan From brandon753.ba at gmail.com Wed Jul 14 22:39:39 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Wed, 14 Jul 2021 13:39:39 -0700 Subject: Call me crazy, but ... In-Reply-To: <2c514f77f5be2404dbd0248668de4d69@posteo.de> References: <2c514f77f5be2404dbd0248668de4d69@posteo.de> Message-ID: <427cec5a-7fe9-9d21-9aab-18fc6c4aeb85@gmail.com> > Andrew Gallagher wrote: >>> On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users >>> wrote: >>> >>> ?Viktor wrote: >>> >>>> It's the same as putting any other public information in public key >>>> certificate. You can put first and last name, email address and even >>>> photo of another person. >>> >>> But this information can be digitally verified and is issued EU wide by >>> Governemnt trusted sources in this field. >> >> But this puts logical causality the wrong way around. Just because the >> thing *being signed* is genuine, does not prove that the thing *doing >> the signing* is genuine. >> >> IMO this proposal is abuse of the public key infrastructure. If you >> want to sign an ID document, just sign an ID document and distribute >> it through other channels. Attaching it as a signed packet to a key >> adds zero value, at nonzero cost. > > What abuse do you see here, if I may ask? I see it as an non-public > option > among virtual GnuPG friends to include in a duplicate certified data, > which > is not meant to been distributed on keyservers etc. or made public to > the world and acts for two pub keys comparison. > > Again, this does not sound very secure or make much sense to me. It also seems to make several assumptions that I do not think are proper in any security situation that would call for GPG to begin with. You want to share a secret credential that you have with someone not in person to prove identity, something which can be copied and shared with others no differently than when you shared it with them. It is like using a government-backed CA but worse because you give everyone you communicate with access to the secret. You are assuming the person you are sharing this picture with won't use it themselves to impersonate you. You are assuming the communication channel you are using to share this picture with is secure and not being intercepted or spied upon, which could result in someone stealing and using this credential themselves. This then begs the question, if you have a channel that securely communicates between the two parties (the other party you trust enough to share this secret credential with) anyways, what the need for the QR code to begin with is? Just share your public key and be done with it. From stefan.vasilev at posteo.ru Thu Jul 15 00:51:04 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 14 Jul 2021 22:51:04 +0000 Subject: Call me crazy, but ... In-Reply-To: <427cec5a-7fe9-9d21-9aab-18fc6c4aeb85@gmail.com> References: <2c514f77f5be2404dbd0248668de4d69@posteo.de> <427cec5a-7fe9-9d21-9aab-18fc6c4aeb85@gmail.com> Message-ID: Brandon Anderson wrote: >> Andrew Gallagher wrote: >>>> On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users >>>> wrote: >>>> >>>> ?Viktor wrote: >>>> >>>>> It's the same as putting any other public information in public key >>>>> certificate. You can put first and last name, email address and >>>>> even >>>>> photo of another person. >>>> >>>> But this information can be digitally verified and is issued EU wide >>>> by >>>> Governemnt trusted sources in this field. >>> >>> But this puts logical causality the wrong way around. Just because >>> the >>> thing *being signed* is genuine, does not prove that the thing *doing >>> the signing* is genuine. >>> >>> IMO this proposal is abuse of the public key infrastructure. If you >>> want to sign an ID document, just sign an ID document and distribute >>> it through other channels. Attaching it as a signed packet to a key >>> adds zero value, at nonzero cost. >> >> What abuse do you see here, if I may ask? I see it as an non-public >> option >> among virtual GnuPG friends to include in a duplicate certified data, >> which >> is not meant to been distributed on keyservers etc. or made public to >> the world and acts for two pub keys comparison. >> >> > > Again, this does not sound very secure or make much sense to me. It > also seems to make several assumptions that I do not think are proper > in any security situation that would call for GPG to begin with. You > want to share a secret credential that you have with someone not in > person to prove identity, something which can be copied and shared > with others no differently than when you shared it with them. It is > like using a government-backed CA but worse because you give everyone > you communicate with access to the secret. You are assuming the person > you are sharing this picture with won't use it themselves to > impersonate you. You are assuming the communication channel you are > using to share this picture with is secure and not being intercepted > or spied upon, which could result in someone stealing and using this > credential themselves. This then begs the question, if you have a > channel that securely communicates between the two parties (the other > party you trust enough to share this secret credential with) anyways, > what the need for the QR code to begin with is? Just share your public > key and be done with it. It would tell me as 3rd party that for WoT puposes, if this is still used, Alice and her good friend Bob were able to sign their pub keys remotely, based on a free of charge verification method. Regards Stefan From andrewg at andrewg.com Thu Jul 15 02:05:28 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Jul 2021 01:05:28 +0100 Subject: Call me crazy, but ... In-Reply-To: <2c514f77f5be2404dbd0248668de4d69@posteo.de> References: <2c514f77f5be2404dbd0248668de4d69@posteo.de> Message-ID: > On 14 Jul 2021, at 19:49, ?????? ???????? wrote: > > ?Andrew Gallagher wrote: >>>> On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users wrote: >>> ?Viktor wrote: >>>> It's the same as putting any other public information in public key >>>> certificate. You can put first and last name, email address and even >>>> photo of another person. >>> But this information can be digitally verified and is issued EU wide by >>> Governemnt trusted sources in this field. >> But this puts logical causality the wrong way around. Just because the >> thing *being signed* is genuine, does not prove that the thing *doing >> the signing* is genuine. >> IMO this proposal is abuse of the public key infrastructure. If you >> want to sign an ID document, just sign an ID document and distribute >> it through other channels. Attaching it as a signed packet to a key >> adds zero value, at nonzero cost. > > What abuse do you see here, if I may ask? I see it as an non-public option > among virtual GnuPG friends to include in a duplicate certified data, which > is not meant to been distributed on keyservers etc. or made public to > the world and acts for two pub keys comparison. As currently configured, there is nothing to stop this sort of information being uploaded to a keyserver. So while keyserver operators cannot yet forbid it, we should certainly not encourage it. And in any case, we should always ask what value is being added by a particular proposal, weighed against what (potential) costs are being incurred. Remembering that costs are not always borne by those enjoying the benefits. A From andrewg at andrewg.com Thu Jul 15 02:14:12 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Jul 2021 01:14:12 +0100 Subject: Call me crazy, but ... In-Reply-To: References: Message-ID: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> > On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users wrote: > > It would tell me as 3rd party that for WoT puposes, if this is still used, > Alice and her good friend Bob were able to sign their pub keys remotely, > based on a free of charge verification method. That?s what ordinary third-party sigs do. Adding medical data to a public key does not add anything to the process. You should also beware that medical information is treated as sensitive personal data under GDPR, and this subject to stricter rules. Keyserver operators already have enough legal issues handling ordinary personal data (email addresses etc) without adding vaccination certificates to the dataset. A From brandon753.ba at gmail.com Thu Jul 15 02:43:40 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Wed, 14 Jul 2021 17:43:40 -0700 Subject: Call me crazy, but ... In-Reply-To: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> Message-ID: <7272dbd2-c9a6-b4b3-aaa2-e6d1e3a8b7f7@gmail.com> >> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users wrote: >> >> It would tell me as 3rd party that for WoT puposes, if this is still used, >> Alice and her good friend Bob were able to sign their pub keys remotely, >> based on a free of charge verification method. > That?s what ordinary third-party sigs do. Adding medical data to a public key does not add anything to the process. > > You should also beware that medical information is treated as sensitive personal data under GDPR, and this subject to stricter rules. Keyserver operators already have enough legal issues handling ordinary personal data (email addresses etc) without adding vaccination certificates to the dataset. > > A I would argue what he is proposing doesn't do that at all. It is like publically posting a password to your google account and telling people they can verify it is your account by trying to sign in! Once you send your 'proof of identity,' anyone can make the same claims even if you are not sharing this on a keyserver. It's made worse by this being something I expect people will be sharing to prove vaccination, so it will likely have many potential areas to be copied. If you tell me you have not shared it with anyone yet, that still means nothing because you could be impersonating the persons whose QR code you already received from an earlier exchange. Even if this was not the case, and it indeed was a verifiable secret never shared with anyone, it does not verify the identity of the public key owner because it's susceptible to a simple man-in-the-middle attack. Assume Bob wishes to prove his ownership of public key pub_bob to Alice. Bob and Alice are communicating in a way compromised by Eve. Bob affixes his Vaccine QR code to a public key and transmits it to Alice. On route to Alice, Eve intercepts the public key, generates a key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, and sends it to Alice. Alice sees Pub_eve with Bob's QR code and concludes that Pub_eve is owned by Bob and signs it as verified. Again, this is not a secure way to verify identity. Do not do this. It is considerably worse than just having a public key exchange over the phone/video call because it gives others a way to impersonate you. If you wanted to have a video call over the internet and show "proof of identity" over that call and that was sufficient for you, then fine, but whatever you do, don't attach your proof of identity to the public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Thu Jul 15 03:22:47 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Wed, 14 Jul 2021 18:22:47 -0700 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client Message-ID: <63c44c74-6ce6-fcad-37b7-42d094739cf6@gmail.com> I have several Yubikeys and smartcards in my setup, each with its own signing subkeys, and I use these, among other things, to sign email messages. Whenever I want to send an email on thunderbird, it demands a specific smartcard by serial number for email signing and will refuse to use the smartcard/Yubikey plugged into the system. At first, I thought this was a thunderbird problem; however, according to the thunderbird docs, for smartcard signing, it sends the requests directly to GPG. When I rebooted my system and issued the command `gpg --clearsign` followed by some test data to sign, it also demanded the same specific smartcard for digital signing rather than the smartcard that was plugged into the system and had a valid subkey for signing. This behavior would go away, and gpg would pick the first valid signature subkey for which it had access after I ran the command `gpg --card-status`, but the issue does not clear on thunderbird. My public key is viewable here https://keyserver.ubuntu.com/pks/lookup?search=0xAA35E492383D0F8A2E145261255837AEF812E87E&fingerprint=on&op=index. Normally, I have my desktop Yubikey with the signature subkey ed25519/CC3C9B2F10BCED15, but thunderbird and gpg on boot (before `gpg --card-status`) refuse to sign with any other key than ed25519/5A55707CAA63F689 even when the smartcard for that key is not on the system and the smartcard for the other key is. Interestingly, thunderbird has no issue decrypting a message with the smartcard normally used on my system; it just refuses to sign if not with a specific smartcard. The fact that on-system boot gpg is exhibiting the same behavior and that thunderbird is supposedly directly using gpg for smartcard-related actions makes me think this is something I have misconfigured. Any idea what I should be doing differently? Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Thu Jul 15 12:24:02 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 15 Jul 2021 12:24:02 +0200 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: <63c44c74-6ce6-fcad-37b7-42d094739cf6@gmail.com> References: <63c44c74-6ce6-fcad-37b7-42d094739cf6@gmail.com> Message-ID: <3000999.FN2RQqX7Xp@daneel> On Donnerstag, 15. Juli 2021 03:22:47 CEST Brandon Anderson via Gnupg-users wrote: > I have several Yubikeys and smartcards in my setup, each with its own > signing subkeys, and I use these, among other things, to sign email > messages. Whenever I want to send an email on thunderbird, it demands a > specific smartcard by serial number for email signing and will refuse to > use the smartcard/Yubikey plugged into the system. Which version of gpg are you using? If you are not using 2.3, then please retry with gpg 2.3.1. Support for multiple smartcards was significantly improved in 2.3. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From johndoe65534 at mail.com Thu Jul 15 13:53:10 2021 From: johndoe65534 at mail.com (john doe) Date: Thu, 15 Jul 2021 13:53:10 +0200 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: <3000999.FN2RQqX7Xp@daneel> References: <63c44c74-6ce6-fcad-37b7-42d094739cf6@gmail.com> <3000999.FN2RQqX7Xp@daneel> Message-ID: On 7/15/2021 12:24 PM, Ingo Kl?cker wrote: > On Donnerstag, 15. Juli 2021 03:22:47 CEST Brandon Anderson via Gnupg-users > wrote: >> I have several Yubikeys and smartcards in my setup, each with its own >> signing subkeys, and I use these, among other things, to sign email >> messages. Whenever I want to send an email on thunderbird, it demands a >> specific smartcard by serial number for email signing and will refuse to >> use the smartcard/Yubikey plugged into the system. > > Which version of gpg are you using? If you are not using 2.3, then please > retry with gpg 2.3.1. Support for multiple smartcards was significantly > improved in 2.3. > Is this still relevent with the built-in gpg stuff of TB? -- John Doe From johndoe65534 at mail.com Thu Jul 15 14:05:01 2021 From: johndoe65534 at mail.com (john doe) Date: Thu, 15 Jul 2021 14:05:01 +0200 Subject: Call me crazy, but ... In-Reply-To: References: <2c514f77f5be2404dbd0248668de4d69@posteo.de> <427cec5a-7fe9-9d21-9aab-18fc6c4aeb85@gmail.com> Message-ID: <43ee9ffe-4806-9a2a-063f-dd32599d47d6@mail.com> On 7/15/2021 12:51 AM, ?????? ???????? via Gnupg-users wrote: > Brandon Anderson wrote: >>> Andrew Gallagher wrote: >>>>> On 14 Jul 2021, at 18:34, ?????? ???????? via Gnupg-users >>>>> wrote: >>>>> >>>>> ?Viktor wrote: Is '?????? ???????? ' the same person that was ban from this very list a fiew month back? It looks like I'm seeing the same stuff as before. -- John Doe From andrewg at andrewg.com Thu Jul 15 16:09:39 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Jul 2021 15:09:39 +0100 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: References: Message-ID: > On 15 Jul 2021, at 12:54, john doe via Gnupg-users wrote: > > Is this still relevent with the built-in gpg stuff of TB? Very much so. Thunderbird?s native Open PGP support is quite basic, and anything to do with smartcards still has to be delegated to an external gnupg process. A From stefan.vasilev at posteo.ru Thu Jul 15 16:23:17 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Thu, 15 Jul 2021 14:23:17 +0000 Subject: Call me crazy, but ... In-Reply-To: <7272dbd2-c9a6-b4b3-aaa2-e6d1e3a8b7f7@gmail.com> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> <7272dbd2-c9a6-b4b3-aaa2-e6d1e3a8b7f7@gmail.com> Message-ID: <2975d16c1cf20911ce84d591c1d425cb@posteo.de> Brandon Anderson wrote: >>> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >>> wrote: >>> >>> It would tell me as 3rd party that for WoT puposes, if this is still >>> used, >>> Alice and her good friend Bob were able to sign their pub keys >>> remotely, >>> based on a free of charge verification method. >> That?s what ordinary third-party sigs do. Adding medical data to a >> public key does not add anything to the process. >> >> You should also beware that medical information is treated as >> sensitive personal data under GDPR, and this subject to stricter >> rules. Keyserver operators already have enough legal issues handling >> ordinary personal data (email addresses etc) without adding >> vaccination certificates to the dataset. >> >> A > I would argue what he is proposing doesn't do that at all. It is like > publically posting a password to your google account and telling > people they can verify it is your account by trying to sign in! Once > you send your 'proof of identity,' anyone can make the same claims > even if you are not sharing this on a keyserver. It's made worse by > this being something I expect people will be sharing to prove > vaccination, so it will likely have many potential areas to be copied. > If you tell me you have not shared it with anyone yet, that still > means nothing because you could be impersonating the persons whose QR > code you already received from an earlier exchange. Even if this was > not the case, and it indeed was a verifiable secret never shared with > anyone, it does not verify the identity of the public key owner > because it's susceptible to a simple man-in-the-middle attack. > > Assume Bob wishes to prove his ownership of public key pub_bob to > Alice. Bob and Alice are communicating in a way compromised by Eve. > Bob affixes his Vaccine QR code to a public key and transmits it to > Alice. On route to Alice, Eve intercepts the public key, generates a > key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, > and sends it to Alice. Alice sees Pub_eve with Bob's QR code and > concludes that Pub_eve is owned by Bob and signs it as verified. > > Again, this is not a secure way to verify identity. Do not do this. It > is considerably worse than just having a public key exchange over the > phone/video call because it gives others a way to impersonate you. If > you wanted to have a video call over the internet and show "proof of > identity" over that call and that was sufficient for you, then fine, > but whatever you do, don't attach your proof of identity to the public > key. Why do you assume such a workflow? Alice sends the duplicate ASCII armored in an encrypted and signed message to Bob. Bob is already for a long time in possession of Alice's pub key. After receiving Alice's message he extracts the QR-code, verifies it and compares both pub keys fingerprints. Once done he deletes the duplicate and the extracted QR-code. Finally he can sign Alice's pub key, sends it back to her and she can then upload it to a keyserver. Regards Stefan From brandon753.ba at gmail.com Thu Jul 15 16:28:40 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 15 Jul 2021 07:28:40 -0700 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: References: <63c44c74-6ce6-fcad-37b7-42d094739cf6@gmail.com> <3000999.FN2RQqX7Xp@daneel> Message-ID: > On 7/15/2021 12:24 PM, Ingo Kl?cker wrote: >> On Donnerstag, 15. Juli 2021 03:22:47 CEST Brandon Anderson via >> Gnupg-users >> wrote: >>> I have several Yubikeys and smartcards in my setup, each with its own >>> signing subkeys, and I use these, among other things, to sign email >>> messages. Whenever I want to send an email on thunderbird, it demands a >>> specific smartcard by serial number for email signing and will >>> refuse to >>> use the smartcard/Yubikey plugged into the system. >> >> Which version of gpg are you using? If you are not using 2.3, then >> please >> retry with gpg 2.3.1. Support for multiple smartcards was significantly >> improved in 2.3. >> Sorry I should have included that I am using version "gpg (GnuPG) 2.3.1 libgcrypt 1.9.3" > > Is this still relevent with the built-in gpg stuff of TB? > According to https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards#Allow_the_use_of_external_GnuPG > Use the Thunderbird config editor (found at the bottom of > preferences/options), and search for > mail.openpgp.allow_external_gnupg. Switch the value to true. > > Enabling this preference will cause Thunderbird to attempt to decrypt > a message using GnuPG, whenever RNP fails to decrypt a message with > the secret keys that are available inside Thunderbird's key storage.# > So I do not see why its not relevant if its just passing the stuff down to gpg. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Thu Jul 15 16:36:54 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Thu, 15 Jul 2021 14:36:54 +0000 Subject: Call me crazy, but ... In-Reply-To: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> Message-ID: Andrew Gallagher wrote: >> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >> wrote: >> >> It would tell me as 3rd party that for WoT puposes, if this is still >> used, >> Alice and her good friend Bob were able to sign their pub keys >> remotely, >> based on a free of charge verification method. > > That?s what ordinary third-party sigs do. Adding medical data to a > public key does not add anything to the process. If it would be only medical data you are correct! But, and here a big but, this medical data contains the full name and birthday of the certificate holder *digitally signed* by EU *authorities* in this field while the cert holder had to show his *valid* ID-card to the issuer. > You should also beware that medical information is treated as > sensitive personal data under GDPR, and this subject to stricter > rules. Keyserver operators already have enough legal issues handling > ordinary personal data (email addresses etc) without adding > vaccination certificates to the dataset. As I said a duplicate key is not meant for keyserver distribution and if this should happen by accident, well than it happened. No one can be sued about this. It is or was only said in some news that one should not publish such QR-codes on social media. Regards Stefan From brandon753.ba at gmail.com Thu Jul 15 16:38:42 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 15 Jul 2021 07:38:42 -0700 Subject: Call me crazy, but ... In-Reply-To: <2975d16c1cf20911ce84d591c1d425cb@posteo.de> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> <7272dbd2-c9a6-b4b3-aaa2-e6d1e3a8b7f7@gmail.com> <2975d16c1cf20911ce84d591c1d425cb@posteo.de> Message-ID: <7a0c26e2-6615-a42b-769d-1dbeaed40df8@gmail.com> >>>> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >>>> wrote: >>>> >>>> It would tell me as 3rd party that for WoT puposes, if this is >>>> still used, >>>> Alice and her good friend Bob were able to sign their pub keys >>>> remotely, >>>> based on a free of charge verification method. >>> That?s what ordinary third-party sigs do. Adding medical data to a >>> public key does not add anything to the process. >>> >>> You should also beware that medical information is treated as >>> sensitive personal data under GDPR, and this subject to stricter >>> rules. Keyserver operators already have enough legal issues handling >>> ordinary personal data (email addresses etc) without adding >>> vaccination certificates to the dataset. >>> >>> A >> I would argue what he is proposing doesn't do that at all. It is like >> publically posting a password to your google account and telling >> people they can verify it is your account by trying to sign in! Once >> you send your 'proof of identity,' anyone can make the same claims >> even if you are not sharing this on a keyserver. It's made worse by >> this being something I expect people will be sharing to prove >> vaccination, so it will likely have many potential areas to be copied. >> If you tell me you have not shared it with anyone yet, that still >> means nothing because you could be impersonating the persons whose QR >> code you already received from an earlier exchange. Even if this was >> not the case, and it indeed was a verifiable secret never shared with >> anyone, it does not verify the identity of the public key owner >> because it's susceptible to a simple man-in-the-middle attack. >> >> Assume Bob wishes to prove his ownership of public key pub_bob to >> Alice. Bob and Alice are communicating in a way compromised by Eve. >> Bob affixes his Vaccine QR code to a public key and transmits it to >> Alice. On route to Alice, Eve intercepts the public key, generates a >> key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, >> and sends it to Alice. Alice sees Pub_eve with Bob's QR code and >> concludes that Pub_eve is owned by Bob and signs it as verified. >> >> Again, this is not a secure way to verify identity. Do not do this. It >> is considerably worse than just having a public key exchange over the >> phone/video call because it gives others a way to impersonate you. If >> you wanted to have a video call over the internet and show "proof of >> identity" over that call and that was sufficient for you, then fine, >> but whatever you do, don't attach your proof of identity to the public >> key. > > Why do you assume such a workflow? > > Alice sends the duplicate ASCII armored in an encrypted and signed > message to Bob. > > Bob is already for a long time in possession of Alice's pub key. > > After receiving Alice's message he extracts the QR-code, verifies it > and compares both pub keys fingerprints. Once done he deletes the > duplicate and the extracted QR-code. > > Finally he can sign Alice's pub key, sends it back to her and she can > then upload it to a keyserver. > When designing a scheme for cryptography, you should always assume the worst situation, so it is secure in every situation. So in this hypothetical, you are only using this scheme if Bob has already somehow verified Alices' public key? How has he managed to do so? I assume either in person or with the web of trust. However, Bob has managed to do this should be the same way Alice verified Bob's key. This brings us right back to the this QR-code does not prove ownership of Bob's public key. Again if Eve ever has seen this QR-code, either with an earlier communication or otherwise, Eve could be sending the encrypted message to Alice with Bob's QR code. From Alice's viewpoint, who has not verified Bob's public key, there is no way for her to know who is sending it, so she should not trust it. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Thu Jul 15 16:43:08 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 15 Jul 2021 07:43:08 -0700 Subject: Call me crazy, but ... In-Reply-To: References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> Message-ID: <662abfd5-892d-c65e-987f-93813c673635@gmail.com> >>> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >>> wrote: >>> >>> It would tell me as 3rd party that for WoT puposes, if this is still >>> used, >>> Alice and her good friend Bob were able to sign their pub keys >>> remotely, >>> based on a free of charge verification method. >> >> That?s what ordinary third-party sigs do. Adding medical data to a >> public key does not add anything to the process. > > If it would be only medical data you are correct! But, and here a big > but, > this medical data contains the full name and birthday of the certificate > holder *digitally signed* by EU *authorities* in this field while the > cert > holder had to show his *valid* ID-card to the issuer. > >> You should also beware that medical information is treated as >> sensitive personal data under GDPR, and this subject to stricter >> rules. Keyserver operators already have enough legal issues handling >> ordinary personal data (email addresses etc) without adding >> vaccination certificates to the dataset. > > As I said a duplicate key is not meant for keyserver distribution and > if this should happen by accident, well than it happened. No one can > be sued about this. It is or was only said in some news that one should > not publish such QR-codes on social media. > At its core, the problem here is you still are not proving this verifiable secret has not been shared with any other party. Are these being scanned to go to work? Are these being scanned to travel? Are these being used in other hypothetical key exchanges? I am going to assume you currently have one of these QR codes. Assuming you want me to sign your public key, prove to me now that you have never shared or shown it to anyone ever. If you cannot do this, I cannot be assured you are the actual party that is sharing it as it could have been an earlier party you shared it with or someone eavesdropping on the communication channel you shared it upon. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Thu Jul 15 17:01:07 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Thu, 15 Jul 2021 15:01:07 +0000 Subject: Call me crazy, but ... In-Reply-To: <7a0c26e2-6615-a42b-769d-1dbeaed40df8@gmail.com> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> <7272dbd2-c9a6-b4b3-aaa2-e6d1e3a8b7f7@gmail.com> <2975d16c1cf20911ce84d591c1d425cb@posteo.de> <7a0c26e2-6615-a42b-769d-1dbeaed40df8@gmail.com> Message-ID: Brandon Anderson wrote: >>>>> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >>>>> wrote: >>>>> >>>>> It would tell me as 3rd party that for WoT puposes, if this is >>>>> still used, >>>>> Alice and her good friend Bob were able to sign their pub keys >>>>> remotely, >>>>> based on a free of charge verification method. >>>> That?s what ordinary third-party sigs do. Adding medical data to a >>>> public key does not add anything to the process. >>>> >>>> You should also beware that medical information is treated as >>>> sensitive personal data under GDPR, and this subject to stricter >>>> rules. Keyserver operators already have enough legal issues handling >>>> ordinary personal data (email addresses etc) without adding >>>> vaccination certificates to the dataset. >>>> >>>> A >>> I would argue what he is proposing doesn't do that at all. It is like >>> publically posting a password to your google account and telling >>> people they can verify it is your account by trying to sign in! Once >>> you send your 'proof of identity,' anyone can make the same claims >>> even if you are not sharing this on a keyserver. It's made worse by >>> this being something I expect people will be sharing to prove >>> vaccination, so it will likely have many potential areas to be >>> copied. >>> If you tell me you have not shared it with anyone yet, that still >>> means nothing because you could be impersonating the persons whose QR >>> code you already received from an earlier exchange. Even if this was >>> not the case, and it indeed was a verifiable secret never shared with >>> anyone, it does not verify the identity of the public key owner >>> because it's susceptible to a simple man-in-the-middle attack. >>> >>> Assume Bob wishes to prove his ownership of public key pub_bob to >>> Alice. Bob and Alice are communicating in a way compromised by Eve. >>> Bob affixes his Vaccine QR code to a public key and transmits it to >>> Alice. On route to Alice, Eve intercepts the public key, generates a >>> key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, >>> and sends it to Alice. Alice sees Pub_eve with Bob's QR code and >>> concludes that Pub_eve is owned by Bob and signs it as verified. >>> >>> Again, this is not a secure way to verify identity. Do not do this. >>> It >>> is considerably worse than just having a public key exchange over the >>> phone/video call because it gives others a way to impersonate you. If >>> you wanted to have a video call over the internet and show "proof of >>> identity" over that call and that was sufficient for you, then fine, >>> but whatever you do, don't attach your proof of identity to the >>> public >>> key. >> >> Why do you assume such a workflow? >> >> Alice sends the duplicate ASCII armored in an encrypted and signed >> message to Bob. >> >> Bob is already for a long time in possession of Alice's pub key. >> >> After receiving Alice's message he extracts the QR-code, verifies it >> and compares both pub keys fingerprints. Once done he deletes the >> duplicate and the extracted QR-code. >> >> Finally he can sign Alice's pub key, sends it back to her and she can >> then upload it to a keyserver. >> > When designing a scheme for cryptography, you should always assume the > worst situation, so it is secure in every situation. So in this > hypothetical, you are only using this scheme if Bob has already > somehow verified Alices' public key? How has he managed to do so? I > assume either in person or with the web of trust. However, Bob has > managed to do this should be the same way Alice verified Bob's key. > This brings us right back to the this QR-code does not prove ownership > of Bob's public key. Again if Eve ever has seen this QR-code, either > with an earlier communication or otherwise, Eve could be sending the > encrypted message to Alice with Bob's QR code. From Alice's viewpoint, > who has not verified Bob's public key, there is no way for her to know > who is sending it, so she should not trust it. How do you initiate a key signing session, with 3 levels, GnuPG offers, when you started using GnuPG with virtual contacts and what level would you choose for this proposal? I have wittnessed people running a GnuPG CA with a key certification policy which gave well know people remotely a sig2 or 3, without getting in contact with the user and without asking the user. So much for the classical WoT nobody can rely on. In Alice and Bob's case, regardless if they sign keys or not, they know each other for a long time virtually. If Eve would play man in the middle since they first met, yes than this is a problem, but then (signing or not) we can consider public key cryptography as a general problem, regardless if you use GnuPG with all it's many features and FAQs or other crypto software. And here we would be then at the Governikus topic and you and others can happily ask, why the majority of German GnuPG users do not use such a fine certifcation service ... or why other (EU) countries did not follow the Governikus route (for CA cross certification)??? Regards Stefan From brandon753.ba at gmail.com Thu Jul 15 17:06:03 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 15 Jul 2021 08:06:03 -0700 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: References: Message-ID: <41f51991-99fa-467a-23da-37a7b4d9d68d@gmail.com> >> On 15 Jul 2021, at 12:54, john doe via Gnupg-users wrote: >> >> Is this still relevent with the built-in gpg stuff of TB? > Very much so. Thunderbird?s native Open PGP support is quite basic, and anything to do with smartcards still has to be delegated to an external gnupg process. > > A Another weird behavior I am just now noticing, and maybe it is related. When I insert the Yubikey that Thunderbird wants, and type into the terminal `gpg --card-status`, it outputs as expected. The same thing occurs if I insert my GPG smartcard v2.1. However, my primary Yubikey 5 Nano, which is usually on my desktop and the one I want Thunderbird to play nice with when inserted and `gpg --card-status` is run outputs: ?? yubikeyLockPassword gpg --card-status gpg: selecting card failed: End of file gpg: OpenPGP card not available: End of file The first time and then when you rerun `gpg --card-status`, it outputs the proper and expected result every time. However, this is repeatable as every time I remove and reinsert this particular Yubikey, the first card-status call falls, all later ones succeed. I wonder if this odd behavior is what's causing Thunderbird to ignore this one Yubikey. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Thu Jul 15 17:14:17 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Thu, 15 Jul 2021 15:14:17 +0000 Subject: Call me crazy, but ... In-Reply-To: <662abfd5-892d-c65e-987f-93813c673635@gmail.com> References: <0BE0B970-7058-4F55-8C23-E6515629C278@andrewg.com> <662abfd5-892d-c65e-987f-93813c673635@gmail.com> Message-ID: Brandon Anderson wrote: >>>> On 14 Jul 2021, at 23:52, ?????? ???????? via Gnupg-users >>>> wrote: >>>> >>>> It would tell me as 3rd party that for WoT puposes, if this is still >>>> used, >>>> Alice and her good friend Bob were able to sign their pub keys >>>> remotely, >>>> based on a free of charge verification method. >>> >>> That?s what ordinary third-party sigs do. Adding medical data to a >>> public key does not add anything to the process. >> >> If it would be only medical data you are correct! But, and here a big >> but, >> this medical data contains the full name and birthday of the >> certificate >> holder *digitally signed* by EU *authorities* in this field while the >> cert >> holder had to show his *valid* ID-card to the issuer. >> >>> You should also beware that medical information is treated as >>> sensitive personal data under GDPR, and this subject to stricter >>> rules. Keyserver operators already have enough legal issues handling >>> ordinary personal data (email addresses etc) without adding >>> vaccination certificates to the dataset. >> >> As I said a duplicate key is not meant for keyserver distribution and >> if this should happen by accident, well than it happened. No one can >> be sued about this. It is or was only said in some news that one >> should >> not publish such QR-codes on social media. >> > At its core, the problem here is you still are not proving this > verifiable secret has not been shared with any other party. Are these > being scanned to go to work? Are these being scanned to travel? Are > these being used in other hypothetical key exchanges? I am going to > assume you currently have one of these QR codes. Assuming you want me > to sign your public key, prove to me now that you have never shared or > shown it to anyone ever. If you cannot do this, I cannot be assured > you are the actual party that is sharing it as it could have been an > earlier party you shared it with or someone eavesdropping on the > communication channel you shared it upon. I or anybody else does not need to do that with you, only *your* virtual long time friends, having no other good option remotely. These QR-codes are meant to be carried mostly on a smartphone and if required the person can show these per request. When those codes are scanned with authorized apps no data is stored on third party servers and only the name and birthday is displayed and the signature verified, while the holder has to show his id-card as well. Regards Stefan From rjh at sixdemonbag.org Thu Jul 15 21:41:55 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 Jul 2021 15:41:55 -0400 Subject: Call me crazy, but ... In-Reply-To: <43ee9ffe-4806-9a2a-063f-dd32599d47d6@mail.com> References: <2c514f77f5be2404dbd0248668de4d69@posteo.de> <427cec5a-7fe9-9d21-9aab-18fc6c4aeb85@gmail.com> <43ee9ffe-4806-9a2a-063f-dd32599d47d6@mail.com> Message-ID: <258f810e-3093-4557-53ac-7fe615733f64@sixdemonbag.org> > Is '?????? ???????? ' the same person that > was ban from this very list a fiew month back? No, because no one was ever banned. One user, also named Stefan, was set to moderation (his messages had to be approved by an admin before appearing on list), but this was only for two weeks, and he was never banned. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Sun Jul 18 23:40:55 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Sun, 18 Jul 2021 14:40:55 -0700 Subject: Multiple Yubikeys/Smartcards and Thunderbird email client In-Reply-To: <41f51991-99fa-467a-23da-37a7b4d9d68d@gmail.com> References: <41f51991-99fa-467a-23da-37a7b4d9d68d@gmail.com> Message-ID: >>> On 15 Jul 2021, at 12:54, john doe via Gnupg-users >>> wrote: >>> >>> Is this still relevent with the built-in gpg stuff of TB? >> Very much so. Thunderbird?s native Open PGP support is quite basic, >> and anything to do with smartcards still has to be delegated to an >> external gnupg process. >> >> A > > > Another weird behavior I am just now noticing, and maybe it is > related. When I insert the Yubikey that Thunderbird wants, and type > into the terminal `gpg --card-status`, it outputs as expected. The > same thing occurs if I insert my GPG smartcard v2.1. However, my > primary Yubikey 5 Nano, which is usually on my desktop and the one I > want Thunderbird to play nice with when inserted and `gpg > --card-status` is run outputs: > > > ?? yubikeyLockPassword gpg --card-status > gpg: selecting card failed: End of file > gpg: OpenPGP card not available: End of file > > The first time and then when you rerun `gpg --card-status`, it outputs > the proper and expected result every time. However, this is repeatable > as every time I remove and reinsert this particular Yubikey, the first > card-status call falls, all later ones succeed. I wonder if this odd > behavior is what's causing Thunderbird to ignore this one Yubikey. > > Sincerely, > > Brandon Anderson > So, following up on this email, I went to sign some git commits, and the same issue that I reported happening on thunderbird happened with my git commits. The issue is similar to what is reported here three years ago https://stackoverflow.com/questions/46330629/signing-commits-in-git-uses-wrong-subkey where only the most recent signature key is attempted even if the system has a smartcard or private key to an alternative valid signing key. I have deleted the subkeys for the non-primary smartcards on my desktop and while it works is less than the desired solution, as I can not insert other smartcards for signing and may want to verify in gpg those subkeys signatures. Any insight would be greatly appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15950 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From karel-v_g at tutanota.com Wed Jul 21 14:37:20 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Wed, 21 Jul 2021 14:37:20 +0200 (CEST) Subject: GPG4Win 3.1.16: mkportable.exe missing? In-Reply-To: <5734429.lOV4Wx5bFT@kymo.gruen> References: <5734429.lOV4Wx5bFT@kymo.gruen> Message-ID: Hello! I did a complete uninstall of GPG4Win with exception of the personal data in my homedir, restarted my machine and installed GPG4Win with all options selected (usually I install it without GPG-OL). Once again mkportable.exe and paperkey.exe were missing though the rest of my GPG4win-Installation was working as expected. I was able to locate the missing files in the 3.1.16 installer and extracted them manually using 7-Zip. Thus I was able to create a portable installation. I found no reason why mkportable and paperkey were not? installed, there were no entries in my virus scanners log (Windows Defender) or any other signs for abnormal behaviour of my system. Greetings Karel 12. Juli 2021, 14:05 von bernhard at intevation.de: > Hello Karel, > > Am Samstag, 3. Juli 2021, 22:29:15 CEST schrieb karel-v_g--- via Gnupg-users: > >> After Updating from GPG4Win 3.1.15 to .16 I noticed that the newest build >> does not install mkportable.exe?! Is it missing by intend or by accident? >> > > as far as I know mkportable works in principle on Gpg4win 3.1.16, > see success reports on https://dev.gnupg.org/T5287 > > So the question is why does it not install for you. > Can you try a reinstall and select all components? > >> PS: I hope it is okay to ask this GPG4Win-related question here on the >> GnuPG-list!? >> > > To me it is okay, though gpg4win-users-en at wald.intevation.org is even more > appropriate. If possible, followup there. (You need to subscribe to the list.) > > Best Regards, > Bernhard > -- > www.intevation.de/~bernhard +49 541 33 508 3-3 > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > From jonathan.kaczynski at guildeducation.com Sat Jul 24 02:00:07 2021 From: jonathan.kaczynski at guildeducation.com (Jonathan Kaczynski) Date: Fri, 23 Jul 2021 20:00:07 -0400 Subject: gpg: used key is not marked for encryption use. Message-ID: Hi, I'm trying to understand the scenario in which we see the log message, "gpg: used key is not marked for encryption use." I haven't been able to find any mentions of the phrase on the web, so I turned to the source code. Looking at https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/pubkey-enc.c;h=6e1b0898e4b3687ef4d57ae1a6270782723b01e3;hb=refs/heads/master#l146 it is a little difficult to tease out. The context is I'm trying to debug why another party's encrypted file is producing this extra log message by gpg-2.3.1, and if it matters. They used a tool which uses the BouncyCastle java library. Would someone be able to help me with this? Thank you, Jonathan Kaczynski -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jul 27 11:03:42 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Jul 2021 11:03:42 +0200 Subject: gpg: used key is not marked for encryption use. In-Reply-To: (Jonathan Kaczynski via Gnupg-users's message of "Fri, 23 Jul 2021 20:00:07 -0400") References: Message-ID: <87zgu89lht.fsf@wheatstone.g10code.de> On Fri, 23 Jul 2021 20:00, Jonathan Kaczynski said: > I'm trying to understand the scenario in which we see the log message, > "gpg: used key is not marked for encryption use." I haven't been able to > find any mentions of the phrase on the web, so I turned to the source code. This is a warning that the encryption tool used a key which it should not have used for encryption (ie. a signing signing key). Proper OpenPGP implementation won't allow to encrypt to such a key but some implementations have bugs. Technically the keys can be used for both purposes but out of crypto hygiene this should not be done. No immediate risk, though. For S/MIME is is quite common to use the same key for encryption and signing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From root at springbeautygroup.com Tue Jul 27 01:32:53 2021 From: root at springbeautygroup.com (root) Date: Mon, 26 Jul 2021 16:32:53 -0700 Subject: keys retrieved from keyserver (keys.openpgp.org) are unusable Message-ID: <20210726233253.GB52741@springbeautygroup.com> Hi, all I've posted this question on stackoverflow.com a few days ago, and I am still waiting for someone to comment. https://stackoverflow.com/questions/68490051/key-retrieved-from-keyserver-keys-openpgp-org-cant-be-used-gpgme Long story short, when the public key is downloaded to my PC as a plain text .asc file, and later imported using the function gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the key->can_encrypt, key->sign_certify, and can_sign are all 0x01. Alternatively, if I do gpgme_op_keylist_start() using an email address with GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt, key->can_certify and key->can_sign are all 0x00. I've tried several email addresses found on keys.opengpg.org, and the result is the same. Either way, I can't use this key to even encrypt data. For the key downloaded as a .asc file, if I manually "certify" the key first using Kleopatra prior to gpgme_op_keylist_from_data_start(), it then can be used to encrypt the data. But my purpose is to use the public key downloaded remotely with GPGME_KEYLIST_MODE_EXTERN only, and without Kleopatra of course. The trust-model has been set to "ALWAYS", or "always" using gpgme_set_ctx_flag(). The crypto protocol used is OpenPGP. I can't find good hints using the sample codes in https://github.com/gpg/gpgme.git either. Any comment/suggestion is welcome. Eric From kloecker at kde.org Tue Jul 27 14:34:28 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 27 Jul 2021 14:34:28 +0200 Subject: keys retrieved from keyserver (keys.openpgp.org) are unusable In-Reply-To: <20210726233253.GB52741@springbeautygroup.com> References: <20210726233253.GB52741@springbeautygroup.com> Message-ID: <1859524.8Rs5kX7egn@daneel> On Dienstag, 27. Juli 2021 01:32:53 CEST root wrote: > Long story short, when the public key is downloaded to my PC as a plain text > .asc file, and later imported using the function > gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the > key->can_encrypt, key->sign_certify, and can_sign are all 0x01. gpgme_op_keylist_from_data_start() does _not_ import any keys. All it does is retrieve the meta data of the keys passed to it as data. Those keys cannot be used for any crypto operations like signing, encrypting, etc. because the public key data has _not_ been imported. The keys have just been listed. This is very similar to listing the keys on a keyserver without actually retrieving the public keys from the keyserver. > Alternatively, if I do gpgme_op_keylist_start() using an email address with > GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt, key->can_certify and > key->can_sign are all 0x00. I've tried several email addresses found on > keys.opengpg.org, and the result is the same. Using gpgme_op_keylist_start() with GPGME_KEYLIST_MODE_EXTERN does a remote lookup on the keyserver. It does _not_ import the found keys. That's why can_encrypt, etc. are all 0x00. You need to download and import the keys if you want to use them. Alternatively, you may want to use the auto-key-locate option of gpg which automatically locates and retrieves keys when encrypting to an email address. Don't reinvent the wheel using gpgme if you can simply use what gpg provides out of the box. Of course, you can still use gpgme for doing the encryption, but don't try to retrieve the keys yourself if gpg can do it for you. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From root at springbeautygroup.com Tue Jul 27 20:12:14 2021 From: root at springbeautygroup.com (root) Date: Tue, 27 Jul 2021 11:12:14 -0700 Subject: keys retrieved from keyserver (keys.openpgp.org) are unusable In-Reply-To: <1859524.8Rs5kX7egn@daneel> References: <20210726233253.GB52741@springbeautygroup.com> <1859524.8Rs5kX7egn@daneel> Message-ID: <20210727181214.GA12505@springbeautygroup.com> On Tue, Jul 27, 2021 at 02:34:28PM +0200, Ingo Kl?cker wrote: > On Dienstag, 27. Juli 2021 01:32:53 CEST root wrote: > > Long story short, when the public key is downloaded to my PC as a plain text > > .asc file, and later imported using the function > > gpgme_op_keylist_from_data_start() and gpgme_op_keylist_new(), the > > key->can_encrypt, key->sign_certify, and can_sign are all 0x01. > > gpgme_op_keylist_from_data_start() does _not_ import any keys. All it does is > retrieve the meta data of the keys passed to it as data. Those keys cannot be > used for any crypto operations like signing, encrypting, etc. because the > public key data has _not_ been imported. The keys have just been listed. This > is very similar to listing the keys on a keyserver without actually retrieving > the public keys from the keyserver. > > > Alternatively, if I do gpgme_op_keylist_start() using an email address with > > GPGME_KEYLIST_MODE_EXTERN, the key->can_encrypt, key->can_certify and > > key->can_sign are all 0x00. I've tried several email addresses found on > > keys.opengpg.org, and the result is the same. > > Using gpgme_op_keylist_start() with GPGME_KEYLIST_MODE_EXTERN does a remote > lookup on the keyserver. It does _not_ import the found keys. That's why > can_encrypt, etc. are all 0x00. You need to download and import the keys if > you want to use them. > This makes sense now. I will look into the sample codes and manual to see how I can download and import the keys after listing it. Any suggestion on where to look for them ? Hopefully, it'll be straight forward. > Alternatively, you may want to use the auto-key-locate option of gpg which > automatically locates and retrieves keys when encrypting to an email address. The codes that I am developing is actually a DLL used by another C#/C++ written in .Net framwork. Thus, the binary developed has to be portable. I will look into the auto-key-locate option for sure. > > Don't reinvent the wheel using gpgme if you can simply use what gpg provides > out of the box. Of course, you can still use gpgme for doing the encryption, > but don't try to retrieve the keys yourself if gpg can do it for you. I am new to GnuPG and this is a great tool in programming. I am not sure how to use gpg commands directly in C/C++ codes though. I thought gpgme is providing the interface to use gpg ? Thanks again, Eric > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From jrf at mailbox.org Wed Jul 28 11:22:18 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Wed, 28 Jul 2021 11:22:18 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" Message-ID: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> 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=0x0000000000000000 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 From bernhard at intevation.de Wed Jul 28 15:45:47 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 28 Jul 2021 15:45:47 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> Message-ID: <202107281545.54237.bernhard@intevation.de> 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 -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From jrf at mailbox.org Wed Jul 28 16:19:43 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Wed, 28 Jul 2021 16:19:43 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <202107281545.54237.bernhard@intevation.de> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <202107281545.54237.bernhard@intevation.de> Message-ID: <71888665-88a0-4dbd-02a6-ede227779a80@mailbox.org> 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 at 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. From andrewg at andrewg.com Wed Jul 28 17:42:23 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 28 Jul 2021 16:42:23 +0100 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <71888665-88a0-4dbd-02a6-ede227779a80@mailbox.org> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <202107281545.54237.bernhard@intevation.de> <71888665-88a0-4dbd-02a6-ede227779a80@mailbox.org> Message-ID: 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? 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. What OS are you using? Do you have the latest version of ca-certificates (or equivalent) installed? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jrf at mailbox.org Wed Jul 28 18:38:07 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Wed, 28 Jul 2021 18:38:07 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <202107281545.54237.bernhard@intevation.de> <71888665-88a0-4dbd-02a6-ede227779a80@mailbox.org> Message-ID: 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). From kloecker at kde.org Wed Jul 28 21:38:02 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 28 Jul 2021 21:38:02 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> Message-ID: <14955896.LIEdVQZUKm@daneel> 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. Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you? What does 'curl -v https://keys.openpgp.org' say? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From jrf at mailbox.org Thu Jul 29 09:41:54 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Thu, 29 Jul 2021 09:41:54 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <14955896.LIEdVQZUKm@daneel> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> Message-ID: 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 10000 -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! From andrewg at andrewg.com Thu Jul 29 18:16:26 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 29 Jul 2021 17:16:26 +0100 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> Message-ID: 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 at whippet:~$ sha256sum /etc/ssl/certs/DST_Root_CA_X3.pem 139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99 /etc/ssl/certs/DST_Root_CA_X3.pem ``` Also, is your system clock correct? (long shot, but always worth asking when debugging TLS cert issues) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jrf at mailbox.org Thu Jul 29 18:33:38 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Thu, 29 Jul 2021 18:33:38 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> Message-ID: <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> 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 at 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. ;) From andrewg at andrewg.com Thu Jul 29 18:45:49 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 29 Jul 2021 17:45:49 +0100 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> Message-ID: <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> 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 From jrf at mailbox.org Thu Jul 29 18:52:42 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Thu, 29 Jul 2021 18:52:42 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> Message-ID: 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 References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> Message-ID: On 29/07/2021 17:52, Rainer Fiebig wrote: > > ~> openssl x509 -text 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. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jrf at mailbox.org Thu Jul 29 20:53:09 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Thu, 29 Jul 2021 20:53:09 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> Message-ID: <16237004-a624-1ddc-ace3-ebfacbf95892@mailbox.org> 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. From jrf at mailbox.org Fri Jul 30 12:55:18 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Fri, 30 Jul 2021 12:55:18 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> Message-ID: 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-support at 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! From wk at gnupg.org Sat Jul 31 17:40:10 2021 From: wk at gnupg.org (Werner Koch) Date: Sat, 31 Jul 2021 17:40:10 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: (Andrew Gallagher via Gnupg-users's message of "Thu, 29 Jul 2021 18:36:17 +0100") References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> Message-ID: <87bl6i7aqt.fsf@wheatstone.g10code.de> 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" } > 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 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jrf at mailbox.org Sat Jul 31 19:56:34 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Sat, 31 Jul 2021 19:56:34 +0200 Subject: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <87bl6i7aqt.fsf@wheatstone.g10code.de> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> <87bl6i7aqt.fsf@wheatstone.g10code.de> Message-ID: <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org> 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 > > From jrf at mailbox.org Sat Jul 31 21:38:16 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Sat, 31 Jul 2021 21:38:16 +0200 Subject: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> <87bl6i7aqt.fsf@wheatstone.g10code.de> <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org> <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang> Message-ID: <0327ad5a-a0c0-889e-fd3c-05b8f3411101@mailbox.org> 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! From jrf at mailbox.org Sat Jul 31 22:16:35 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Sat, 31 Jul 2021 22:16:35 +0200 Subject: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> <87bl6i7aqt.fsf@wheatstone.g10code.de> <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org> <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang> Message-ID: 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. From xry111 at mengyan1223.wang Sat Jul 31 21:00:31 2021 From: xry111 at mengyan1223.wang (Xi Ruoyao) Date: Sun, 01 Aug 2021 03:00:31 +0800 Subject: [blfs-support] --search-keys: "gpg: error searching keyserver: No inquire callback in IPC" In-Reply-To: <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org> References: <353292b6-5b53-85d5-9507-6dbbc613ccc7@mailbox.org> <14955896.LIEdVQZUKm@daneel> <3a855cda-3763-b381-4137-5b39b682607f@mailbox.org> <37a41e14-3374-95f6-6ba2-2cc12bbe5adf@andrewg.com> <87bl6i7aqt.fsf@wheatstone.g10code.de> <7ed91f41-41fe-f483-9687-39291d019e0b@mailbox.org> Message-ID: <466ca329827d1b88e3e3f3d9c7e9a82e99d9de77.camel@mengyan1223.wang> 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.) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University From jotoho+mailinglist at jotoho.de Sat Jul 31 23:05:42 2021 From: jotoho+mailinglist at jotoho.de (Jonas Tobias Hopusch) Date: Sat, 31 Jul 2021 23:05:42 +0200 Subject: gpg-wks-client generates empty files Message-ID: <20210731210542.pfftewek7umzhwos@jotoho.de> Hi everyone, I have heard of Web Key Directory and the many benefits it has over the traditional keyserver approach and want to try setting it up for my personal domain. I believe that I understand the directory structure and how you would set it up but ran into a problem with gpg-wks-client when trying to follow the instructions in the wiki (https://wiki.gnupg.org/WKDHosting). When I ran the gpg-wks-client command specified on that wiki page, I noticed that the software generated the directories, policy files and created the key files but that the vast majority of those exported key files were empty. This happened using gnupg version 2.2.29, installed from archlinux's official repositories via pacman. For the purposes of debugging, I will attach the output of 'gpg --with-wkd-hash -k @jotoho.de', a directory listing of the hu-directories created by gpg-wks-client, the output of the gpg-wks-client command and the three keys I attempted to export into WKD. Does anyone know what may have gone wrong? Is there any additional information I can provide to help with tracking down what I presume to be a bug? Thanks in advance. -- Jonas Hopusch -------------- next part -------------- pub rsa4096/4C6E404513ED90C9 2019-06-20 [SC] [verf?llt: 2021-10-18] Schl.-Fingerabdruck = 53B1 B68B 5081 F3AE C906 709E 4C6E 4045 13ED 90C9 uid [ ultimativ ] Jonas Tobias Hopusch (This is my personal master key, which signs all my other keys) of4qcqetg5z8oa1uscqcz7uehu4sr9g3 at jotoho.de uid [ ultimativ ] Jonas Tobias Hopusch (Software-signing identity) e5a4bxki1ktx1jncwco5nkcofedmkxod at jotoho.de sub rsa4096/31EB56623DB25CC8 2019-06-20 [A] [verf?llt: 2021-10-18] sub rsa4096/2E42A2D974F4EE83 2019-06-20 [E] [verf?llt: 2021-10-18] sub rsa4096/2D79D7D95F0D29ED 2019-12-17 [S] [verf?llt: 2021-10-18] sub rsa4096/053B9DA04C5AC0A5 2019-12-17 [S] [verf?llt: 2021-10-18] pub rsa4096/612F3350DB59D359 2021-01-27 [C] [verf?llt: 2024-01-27] Schl.-Fingerabdruck = 1F42 EF02 BE3E 6FE8 F624 C8BC 612F 3350 DB59 D359 uid [vollst?ndig] (Domain owner of jotoho.de) n85z5mkjgfstw6o6r3t97pjamdsptfsi at jotoho.de uid [vollst?ndig] (Primary contact for web-related issues with jotoho.de) kd39y8fkyw5j8uubuicshffo9hhodk4j at jotoho.de uid [vollst?ndig] (Primary contact for networking-issues with jotoho.de) e1bxuz5fmgbtjxtngwnb56rnahtt48ij at jotoho.de uid [vollst?ndig] (Primary contact for email-related issues with jotoho.de) 17o8za5yunot7q6wddwcs4jqodngre8t at jotoho.de uid [vollst?ndig] (Primary contact for security issues with jotoho.de) t5s8ztdbon8yzntexy6oz5y48etqsnbb at jotoho.de uid [vollst?ndig] (Primary contact for abuse of/from jotoho.de servers & services) 88fb3b9rrzeapqdf3kodtkfenu7c41b7 at jotoho.de sub rsa4096/15013ADE96502164 2021-01-27 [SE] [verf?llt: 2024-01-27] pub rsa4096/16128FBFDB6214C9 2021-07-19 [C] [verf?llt: 2024-07-18] Schl.-Fingerabdruck = 5610 5D31 5120 E79B 34C4 D395 1612 8FBF DB62 14C9 uid [vollst?ndig] Gitea Automation (Signing Key for automatically created commits and tags on https://gitea.jotoho.de) sfno47rsgbbjwjk5zcdmrczcmdrdhbkr at gitea.jotoho.de sub rsa4096/B8405128B0847FE1 2021-07-19 [S] [verf?llt: 2024-07-18] -------------- next part -------------- .well-known/openpgpkey/gitea.jotoho.de/hu: insgesamt 0 -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 sfno47rsgbbjwjk5zcdmrczcmdrdhbkr .well-known/openpgpkey/jotoho.de/hu: insgesamt 24K -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 17o8za5yunot7q6wddwcs4jqodngre8t -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 88fb3b9rrzeapqdf3kodtkfenu7c41b7 -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 e1bxuz5fmgbtjxtngwnb56rnahtt48ij -rw-r--r-- 1 jonas jonas 8,3K 31. Jul 17:31 e5a4bxki1ktx1jncwco5nkcofedmkxod -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 kd39y8fkyw5j8uubuicshffo9hhodk4j -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 n85z5mkjgfstw6o6r3t97pjamdsptfsi -rw-r--r-- 1 jonas jonas 8,3K 31. Jul 17:31 of4qcqetg5z8oa1uscqcz7uehu4sr9g3 -rw-r--r-- 1 jonas jonas 0 31. Jul 17:31 t5s8ztdbon8yzntexy6oz5y48etqsnbb -------------- next part -------------- gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id 'Jonas Tobias Hopusch (This is my personal master key, which signs all my other keys) ' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: directory './jotoho.de' created gpg-wks-client: directory './jotoho.de/hu' created gpg-wks-client: policy file './jotoho.de/policy' created gpg-wks-client: key 53B1B68B5081F3AEC906709E4C6E404513ED90C9 published for 'master-key at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id 'Jonas Tobias Hopusch (Software-signing identity) ' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: key 53B1B68B5081F3AEC906709E4C6E404513ED90C9 published for 'git at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Domain owner of jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'hostmaster at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Primary contact for web-related issues with jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'webmaster at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Primary contact for networking-issues with jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'noc at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Primary contact for email-related issues with jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'postmaster at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Primary contact for security issues with jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'security at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id '(Primary contact for abuse of/from jotoho.de servers & services) ' gpg-wks-client: gpg: Schl?ssel 612F3350DB59D359: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: key 1F42EF02BE3E6FE8F624C8BC612F3350DB59D359 published for 'abuse at jotoho.de' gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: using key with user id 'Gitea Automation (Signing Key for automatically created commits and tags on https\x3a//gitea.jotoho.de) ' gpg-wks-client: gpg: Schl?ssel 16128FBFDB6214C9: Keine g?ltigen User-IDs gpg-wks-client: gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg-wks-client: gpg: ohne User-ID: 1 gpg-wks-client: directory './gitea.jotoho.de' created gpg-wks-client: directory './gitea.jotoho.de/hu' created gpg-wks-client: policy file './gitea.jotoho.de/policy' created gpg-wks-client: key 56105D315120E79B34C4D39516128FBFDB6214C9 published for 'autosign at gitea.jotoho.de' -------------- next part -------------- A non-text attachment was scrubbed... Name: key1.gpg Type: application/octet-stream Size: 16477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: key2.gpg Type: application/octet-stream Size: 6244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: key3.gpg Type: application/octet-stream Size: 3497 bytes Desc: not available URL: