From jb-gnumlists at wisemo.com Fri Nov 1 11:20:14 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Fri, 1 Nov 2024 11:20:14 +0100 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: <87plnjuvmm.fsf@jacob.g10code.de> References: <87jze01l58.fsf@jacob.g10code.de> <87plnqf3ry.fsf@akagi.fsij.org> <87plnjuvmm.fsf@jacob.g10code.de> Message-ID: <71873321-26cd-b23f-56b0-7c2f13112cb4@wisemo.com> On 10/29/2024 10:05 AM, Werner Koch via Gnupg-users wrote: > Hi! > > you should really set aside problems wit the distribution and use the > speedo variant to build eberthing. This is somewhat similar to an > AppImage. From the README: > > To quickly build all required software without installing it, the > Speedo target may be used: > > make -f build-aux/speedo.mk native > > This target downloads all required libraries and does a native build > of GnuPG to PLAY/inst/. GNU make and the patchelf tool are > required. After the build the entire software including all > libraries can be installed into an arbitrary location using for > example: > > make -f build-aux/speedo.mk install SYSROOT=/usr/local/gnupg26 THIS IS BAD!? It is the make-based version of the memed "download and run random code from the internet" instructions that security-ignorant teams keep posting as their "Linux" install instructions.? The semi-embedded "buildroot" project did the same years ago . Unless the speedo make target actively checks each download against a strong hash stored in the initial gnupg tarball, this exposes the user/dev to all manner of supply chain attacks by running unvetted build scripts and other code from whomever hijacks any one of the various upstream URLs. Systemd blindly loading random 3rd party decompression libraries into all compatible demon processes was similarly exploited this year by someone invading one of the compression projects. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From dgouttegattat at incenp.org Sat Nov 2 00:21:07 2024 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 01 Nov 2024 23:21:07 +0000 Subject: Question on Kyber Encryption (Key Gen) In-Reply-To: <71873321-26cd-b23f-56b0-7c2f13112cb4@wisemo.com> References: <87plnjuvmm.fsf@jacob.g10code.de> <71873321-26cd-b23f-56b0-7c2f13112cb4@wisemo.com> Message-ID: <3584516.dWV9SEqChM@borealin.local.incenp.org> On Friday, 1 November 2024 10:20:14 GMT Jakob Bohm via Gnupg-users wrote: > Unless the speedo make target actively checks each download against a > strong hash stored in the initial gnupg tarball It does, actually. More precisely, it checks each download against a strong hash stored in a swdb.lst file. Granted, that file is not in the original tarball and is instead downloaded from an online source, but its signature is verified against GnuPG?s release signing key, which IS in the original tarbal (g10/distsigkey.gpg). - Damien -------------- 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 xwindows at xwindows.in.th Sat Nov 2 11:52:12 2024 From: xwindows at xwindows.in.th (Nutchanon Wetchasit) Date: Sat, 2 Nov 2024 17:52:12 +0700 Subject: v1.4: How to check user ID-binding hash with `gpg --list-packets`? Message-ID: <31a11740-0673-f901-5ce5-133aa89f46c3@xwindows.in.th> Hello, I have few PGP keys I generated years ago with GPG Classic 1.4, around the time that I changed its `cert-digest-algo` configuration key from its default value to "SHA512". [1] And now, I would like to use one of these in actual encrypted correspondences, but I'm not sure which one was actually generated after the config change. I have also used one of them for signing certain public document; so I would like to avoid generating new key as much as possible... So the question is: how could I verify, from `gpg --list-packets` output, that the public key file in question uses sufficiently-secure hash functions (SHA-256/384/512 in case of RSA-based keys) in its user ID certificate binding signature? - In case this mattered: one of the keys I would like to check is: I guess the information I'm looking for is around here in the `gpg --list-packets` listing: > :signature packet: algo 1, keyid F1D9FE7298C60B03 > version 4, created 1619409428, md5len 0, sigclass 0x13 > digest algo 2, begin of digest 54 a3 ^ But does the "digest algo 2" really mean the same thing as what's so-called "H2" in the `pref` command output of `gpg --edit-key` shell? As far as I understand, the information I'm looking for is considered under-the-hood and isn't available directly from interactive `gpg --edit-key` interface in this GPG version 1.4 at least. (Please correct me if I'm wrong about this) Note: I know that the hard way to do this is opening the tome of RFC 2440 [2] and try identifying everything from the beginning to the point that revealed the information I wanted to know; but that method is quite error prone, so I would like to know about a specific point to look for, before trying to plow my way through. Regards, Nutchanon Wetchasit GnuPG: 1.4.12 (Debian) System: Debian GNU/Linux 7.0 "Wheezy" i386 ----- [1] As far as I understand, GPG classic uses SHA-1 hash for user ID binding signature unless configured otherwise. With SHA-1 being considered dodgy for security use, I proceeded to change that setting (and associated default cipher/hash preferences), for it to continue to be usable with meaningful level of secrecy. [2] https://www.rfc-editor.org/rfc/rfc2440.html From wk at gnupg.org Mon Nov 4 09:47:49 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Nov 2024 09:47:49 +0100 Subject: v1.4: How to check user ID-binding hash with `gpg --list-packets`? In-Reply-To: <31a11740-0673-f901-5ce5-133aa89f46c3@xwindows.in.th> (Nutchanon Wetchasit via Gnupg-users's message of "Sat, 2 Nov 2024 17:52:12 +0700") References: <31a11740-0673-f901-5ce5-133aa89f46c3@xwindows.in.th> Message-ID: <87jzdjqtai.fsf@jacob.g10code.de> Hi! On Sat, 2 Nov 2024 17:52, Nutchanon Wetchasit said: > from its default value to "SHA512". [1] And now, I would like to use > one of these in actual encrypted correspondences, but I'm not sure which one > was actually generated after the config change. I have also used one of them That is easy. Given that your key is older than 2019 we won't reject keys with SHA-1 key signatures. However, you can enforce this and also any other crypto use of SHA-1 by adding weak-digest SHA1 to your gpg.conf. > > :signature packet: algo 1, keyid F1D9FE7298C60B03 > > version 4, created 1619409428, md5len 0, sigclass 0x13 > > digest algo 2, begin of digest 54 a3 > > ^ But does the "digest algo 2" really mean the same thing as > what's so-called "H2" in the `pref` command output of > `gpg --edit-key` shell? Right, 2 is SHA1. H2 means hash algo number 2. DIGEST_ALGO_MD5 = 1, DIGEST_ALGO_SHA1 = 2, DIGEST_ALGO_RMD160 = 3, /* 4, 5, 6, and 7 are reserved. */ DIGEST_ALGO_SHA256 = 8, DIGEST_ALGO_SHA384 = 9, DIGEST_ALGO_SHA512 = 10, DIGEST_ALGO_SHA224 = 11, > As far as I understand, the information I'm looking for is considered > under-the-hood and isn't available directly from interactive Right. However, you can do some tricks with --list-filter to filter out certain packets. > [1] As far as I understand, GPG classic uses SHA-1 hash for user ID binding > signature unless configured otherwise. With SHA-1 being considered dodgy > for security use, I proceeded to change that setting (and associated Yes. You may however create a new binding signature which will then use SHA256. For example by changing the expiration date. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mm at dorfdsl.de Tue Nov 5 13:12:15 2024 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 5 Nov 2024 13:12:15 +0100 Subject: S/MIME which certificate format In-Reply-To: <87msnfn4at.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> Message-ID: <20241105131215.10b77ed1@ryz.dorfdsl.de> Am 20.06.2024 um 15:15:38 Uhr schrieb Werner Koch: > your certificate is the first I have seen with empty Subject but a an > altSubjectName. This is valid but not yet supported. > > Tracked at https://dev.gnupg.org/T7171 As the release notes say it is fixed in 2.4.6, I tried it today, but doesn't work yet. m at ryz:~$ gpgsm --import zertifikat-smime/PKCS7_File/PKCS7.p7b gpgsm: enabled debug flags: ipc gpgsm: enabled compatibility flags: gpgsm: no issuer found in certificate gpgsm: Grundlegende Zertifikatpr?fungen fehlgeschlagen - nicht importiert gpgsm: ksba_cert_hash failed: Kein Wert ksba: ber-decoder: node `?': TLV length too large gpgsm: gesamte verarbeitete Anzahl: 1 gpgsm: nicht importiert: 1 gpgsm: secmem usage: 0/16384 bytes in 0 blocks m at ryz:~$ m at ryz:~$ gpgsm --version gpgsm (GnuPG) 2.4.6 libgcrypt 1.11.0 libksba 1.6.7 Copyright (C) 2024 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/m/.gnupg Unterst?tzte Verfahren: Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256 Pubkey: RSA, ECC, ECC Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL m at ryz:~$ -- Gru? Marco Send unsolicited bulk mail to 1718889338muell at cartoonies.org From wk at gnupg.org Tue Nov 5 13:51:12 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Nov 2024 13:51:12 +0100 Subject: S/MIME which certificate format In-Reply-To: <20241105131215.10b77ed1@ryz.dorfdsl.de> (Marco Moock via Gnupg-users's message of "Tue, 5 Nov 2024 13:12:15 +0100") References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> Message-ID: <875xp1q1xb.fsf@jacob.g10code.de> Hi! and thanks the report. On Tue, 5 Nov 2024 13:12, Marco Moock said: > As the release notes say it is fixed in 2.4.6, I tried it today, but > doesn't work yet. Unfortunately the tracker has no information on a sample certificate useful for debugging. I didn't checked the mailing list though. What does gpgsm --show-cert zertifikat-smime/PKCS7_File/PKCS7.p7b give? Can you also extraxt the certificate and provide it as a DER or PEM encoded file (feel free so sent to my private address). > gpgsm: Grundlegende Zertifikatpr?fungen fehlgeschlagen - nicht > importiert gpgsm: ksba_cert_hash failed: Kein Wert Interesting. Libksba can't find a certificate structure at all. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mm at dorfdsl.de Tue Nov 5 17:11:35 2024 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 5 Nov 2024 17:11:35 +0100 Subject: S/MIME which certificate format In-Reply-To: <875xp1q1xb.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> Message-ID: <20241105171135.6d3d4807@ryz.dorfdsl.de> Am 05.11.2024 um 13:51:12 Uhr schrieb Werner Koch: > On Tue, 5 Nov 2024 13:12, Marco Moock said: > > > As the release notes say it is fixed in 2.4.6, I tried it today, but > > doesn't work yet. > > Unfortunately the tracker has no information on a sample certificate > useful for debugging. I didn't checked the mailing list though. What > does > > gpgsm --show-cert zertifikat-smime/PKCS7_File/PKCS7.p7b > > give? m at ryz:~$ gpgsm --show-cert zertifikat-smime/PKCS7_File/PKCS7.p7b gpgsm: enabled debug flags: ipc gpgsm: enabled compatibility flags: gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert gpgsm: ksba_cert_hash failed: Kein Wert ksba: ber-decoder: node `?': TLV length too large File ........: zertifikat-smime/PKCS7_File/PKCS7.p7b ID: 0xFFFFFFFF S/N: keine (dec): keine Issuer: [error] Subject: [error] sha2_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF sha1_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF md5_fpr: FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF certid: error keygrip: error notBefore: keine notAfter: keine hashAlgo: (null) keyType: [error] subjKeyId: [none] authKeyId: [none] keyUsage: [none] extKeyUsage: [none] policies: [none] chainLength: [none] crlDP: [none] authInfo: [none] subjInfo: [none] gpgsm: secmem usage: 0/16384 bytes in 0 blocks m at ryz:~$ Can you also extraxt the certificate and provide it as a DER or > PEM encoded file (feel free so sent to my private address). I got it in different formats from Sectigo. PKCS7, PEM and plain text. The plain text version contained no line breaks, I had to add them so openssl could parse them. Certificate: Data: Version: 3 (0x2) Serial Number: cd:b8:82:cf:52:a4:25:8a:4c:b6:fa:03:c4:15:dd:bd Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Client Authentication and Secure Email CA Validity Not Before: Jun 10 00:00:00 2024 GMT Not After : Jun 10 23:59:59 2026 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:92:8a:f5:bc:23:3b:e5:f1:0b:02:06:96:80:22: a0:fb:37:5c:8f:bc:07:08:8f:e9:59:85:eb:ec:47: 46:f5:48:7f:e6:ca:00:1e:8c:7a:81:e4:3c:98:a7: 7e:33:95:7c:ae:36:52:c5:93:46:62:23:7a:66:63: 31:99:62:33:df:da:73:cc:c6:2a:e2:40:66:3d:ae: 95:0c:59:b4:5a:4a:f1:8c:5a:73:3c:d0:e1:02:ee: fb:95:17:62:03:1c:6a:7a:b8:06:03:ee:6e:9c:c2: 75:11:c5:16:aa:11:a5:23:06:65:78:2f:5c:5f:3f: 07:95:8a:ec:c1:37:75:e6:9e:a6:1a:50:aa:b8:13: ed:fe:cd:2b:b5:b0:ef:d8:16:b7:05:ef:38:18:3d: 25:cb:72:e4:50:29:2b:ee:f2:b3:45:eb:d5:41:93: 8b:f6:82:1b:d2:37:3c:c2:44:4a:aa:4e:3c:fc:f9: e3:e8:52:ec:08:07:9c:8c:2f:dc:4b:ff:16:25:fa: f1:b5:a4:4f:5b:16:5b:db:97:51:1e:70:4c:c4:aa: 35:03:ac:da:87:4f:08:ef:69:62:cd:7a:84:38:ba: db:8b:60:27:41:eb:be:85:b5:52:f7:2a:f2:8c:b8: d3:17:d9:fa:ad:76:46:d9:0b:1d:82:10:f5:66:9d: b6:7a:b6:03:d0:a1:1a:bd:23:fd:24:8d:5a:9b:2d: 99:00:23:74:2f:6d:c5:fd:f3:6d:0a:d7:93:88:f7: 70:dc:80:9b:03:99:7b:3e:70:39:45:05:c1:07:a6: c8:7a:1a:bb:73:f0:46:80:02:fb:68:16:e8:c6:2f: e6:9a:58:35:10:4b:27:96:ae:f3:67:8a:18:dd:3b: 0b:d9:d2:67:56:b7:2d:dc:48:3b:7f:90:e7:d0:cc: 47:8e:f5:de:46:03:f9:fb:37:0b:1b:8e:d4:16:9e: 09:d5:42:5d:df:2a:09:0e:b1:54:7d:16:c4:6a:82: f7:df:5a:3e:4f:10:82:ef:a7:70:31:32:c1:af:46: 3c:f7:c9:3d:23:76:e5:d3:7a:41:a1:01:9a:c5:42: 5c:a4:36:7f:00:f1:59:4e:5d:96:ce:25:45:6c:77: 6f:9e:cf:62:ba:d3:3a:86:6b:8d:87:86:40:cf:de: b9:e2:b0:01:f7:96:0c:72:90:11:52:b3:8a:c6:96: e8:33:c5:c8:45:e2:0c:e1:22:52:44:7b:3c:e2:84: c7:5a:c2:93:7b:06:a0:e8:7b:a0:9c:d5:3e:c9:10: fd:e2:5a:27:e4:63:a9:69:33:b4:53:21:29:da:19: 44:e6:3b:24:b9:24:0e:94:11:11:5a:ad:a1:ba:9d: 80:ac:37 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: 09:C0:F2:FC:0B:DA:94:DB:5F:FE:2B:DF:A8:99:42:CF:C9:E0:AD:00 X509v3 Subject Key Identifier: 29:8E:85:EF:E4:89:A7:35:82:CC:93:24:FD:ED:34:9C:DC:91:5F:33 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: E-mail Protection X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6449.1.2.1.10.2 CPS: https://sectigo.com/SMIMECPS Policy: 2.23.140.1.5.1.3 X509v3 CRL Distribution Points: Full Name: URI:http://crl.sectigo.com/SectigoRSAClientAuthenticationandSecureEmailCA.crl Authority Information Access: CA Issuers - URI:http://crt.sectigo.com/SectigoRSAClientAuthenticationandSecureEmailCA.crt OCSP - URI:http://ocsp.sectigo.com X509v3 Subject Alternative Name: critical email:mm at dorfdsl.de Signature Algorithm: sha256WithRSAEncryption Signature Value: 6b:ee:7e:e9:ba:44:61:29:af:f8:1e:e1:f6:45:77:b2:37:3b: 27:4b:32:19:a9:33:e8:15:2b:a5:9e:2b:98:1a:5e:3a:95:9d: 8d:04:92:1f:a8:0d:2d:8a:3b:ed:89:c7:ad:00:31:14:76:cd: 9b:06:ac:b7:90:e7:c3:64:4c:7b:44:89:7b:4f:1d:97:43:4b: 23:56:e7:91:77:42:18:28:7e:7d:f9:7c:fa:d0:f1:04:2f:fe: b7:b3:23:2d:95:1a:d5:4d:d6:b7:67:ba:84:b5:d2:82:0c:8a: 06:c9:f4:b5:57:ef:12:d5:e9:b2:99:96:67:c4:10:b9:53:a2: 6a:d5:bf:5f:f7:9c:a1:e2:23:cc:8e:21:23:8e:5c:3c:cb:30: c7:90:22:35:57:70:16:1b:56:e4:a8:b6:8c:b9:27:e9:e8:e8: 33:c9:b1:18:1a:ff:88:07:cf:da:e6:8e:85:4c:05:d1:87:a4: e9:49:28:7c:f5:cf:cc:1e:9a:93:db:8f:e0:ee:cf:0f:2c:a8: 12:c4:a4:69:4b:73:06:80:57:c7:31:35:ca:a6:56:01:5d:db: 01:f2:42:ce:70:fb:03:7d:e9:a0:cb:80:b7:13:ae:9e:e1:29: e0:c0:b4:95:e5:ae:18:a8:d8:cc:aa:f3:53:89:47:23:27:21: db:46:8b:35 -----BEGIN CERTIFICATE----- MIIF8zCCBNugAwIBAgIRAM24gs9SpCWKTLb6A8QV3b0wDQYJKoZIhvcNAQELBQAw gZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UE AxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMjQwNjEwMDAwMDAwWhcNMjYwNjEwMjM1OTU5WjAAMIICIjAN BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkor1vCM75fELAgaWgCKg+zdcj7wH CI/pWYXr7EdG9Uh/5soAHox6geQ8mKd+M5V8rjZSxZNGYiN6ZmMxmWIz39pzzMYq 4kBmPa6VDFm0WkrxjFpzPNDhAu77lRdiAxxqergGA+5unMJ1EcUWqhGlIwZleC9c Xz8HlYrswTd15p6mGlCquBPt/s0rtbDv2Ba3Be84GD0ly3LkUCkr7vKzRevVQZOL 9oIb0jc8wkRKqk48/Pnj6FLsCAecjC/cS/8WJfrxtaRPWxZb25dRHnBMxKo1A6za h08I72lizXqEOLrbi2AnQeu+hbVS9yryjLjTF9n6rXZG2QsdghD1Zp22erYD0KEa vSP9JI1amy2ZACN0L23F/fNtCteTiPdw3ICbA5l7PnA5RQXBB6bIehq7c/BGgAL7 aBboxi/mmlg1EEsnlq7zZ4oY3TsL2dJnVrct3Eg7f5Dn0MxHjvXeRgP5+zcLG47U Fp4J1UJd3yoJDrFUfRbEaoL331o+TxCC76dwMTLBr0Y898k9I3bl03pBoQGaxUJc pDZ/APFZTl2WziVFbHdvns9iutM6hmuNh4ZAz9654rAB95YMcpARUrOKxpboM8XI ReIM4SJSRHs84oTHWsKTewag6HugnNU+yRD94lon5GOpaTO0UyEp2hlE5jskuSQO lBERWq2hup2ArDcCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r 36iZQs/J4K0AMB0GA1UdDgQWBBQpjoXv5ImnNYLMkyT97TSc3JFfMzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADATBgNVHSUEDDAKBggrBgEFBQcDBDBQBgNV HSAESTBHMDoGDCsGAQQBsjEBAgEKAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3Nl Y3RpZ28uY29tL1NNSU1FQ1BTMAkGB2eBDAEFAQMwWgYDVR0fBFMwUTBPoE2gS4ZJ aHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsG AQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdo dHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAbBgNVHREBAf8EETAPgQ1tbUBkb3JmZHNs LmRlMA0GCSqGSIb3DQEBCwUAA4IBAQBr7n7pukRhKa/4HuH2RXeyNzsnSzIZqTPo FSulniuYGl46lZ2NBJIfqA0tijvticetADEUds2bBqy3kOfDZEx7RIl7Tx2XQ0sj VueRd0IYKH59+Xz60PEEL/63syMtlRrVTda3Z7qEtdKCDIoGyfS1V+8S1emymZZn xBC5U6Jq1b9f95yh4iPMjiEjjlw8yzDHkCI1V3AWG1bkqLaMuSfp6OgzybEYGv+I B8/a5o6FTAXRh6TpSSh89c/MHpqT24/g7s8PLKgSxKRpS3MGgFfHMTXKplYBXdsB 8kLOcPsDfemgy4C3E66e4SngwLSV5a4YqNjMqvNTiUcjJyHbRos1 -----END CERTIFICATE----- -- Gru? Marco Send unsolicited bulk mail to 1730811072muell at cartoonies.org From bernhard at intevation.de Wed Nov 13 10:52:55 2024 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 13 Nov 2024 10:52:55 +0100 Subject: Gpg4win usage in US institutions asking for ACR ('VPAT') and "terms". Message-ID: <202411131053.02152.bernhard@intevation.de> Hello, there have been three questions lately by US institutions similar to https://forum.gnupg.org/t/bureaucracy-policy-documentation/5949/2 asking for "terms and conditions" for Gpg4win or suggesting individual ones. Or asking for "privacy terms" and a self-assessment following VPAT for an "Accessibility Conformance Report" (ACR). As we all want all constitutional users to be able to use GnuPG and Gpg4win: Does somebody have ideas how other Free Software products are handled regaring the "terms"? For instance LibreOffice or Firefox? And suggestions for GnuPG/Gpg4win? Are there documents we could refer to, that explain the situation for a Free Software product for US organisations (or even state specific circumstances)? For VPAT I did a quick search: Found https://listarchives.libreoffice.org/global/accessibility/msg01041.html 2023 saying: | In the United States, without a VPAT, you can say goodby to the SMB and larger organisations. | FWIW, over the years, individuals and corporations have posted requests for VPATs on various LibO lists. Invariably they are surprised and upset that LibO does not have one, and usually do not understand why the organisation that set LibO up on their system is responsible for providing the VPAT. | Due to potential legal liability, amongst other things, LibO has not provided a generic VPAT. It is possible to craft a VPAT that is both accurate, and has minimal legal liabilities, when organisations grab it, without paying attention to what they are obtaining. The ethics of providing such a document is up to the individual, and/or corporate master. https://support.mozilla.org/en-US/kb/accessibility-features-firefox seems to have one | Accessibility Conformance Report (ACR) | This recent report describes how the Firefox browser currently works for | people with disabilities. It is based on the ITI Voluntary Product | Accessibility Template (VPAT? 2.5) and covers compliance with the Web | Content Accessibility Guidelines (WCAG 2.2) and with the Revised Section 508 | of the Rehabilitation Act https://wiki.mozilla.org/images/d/d4/Firefox_VPAT_124_on_Windows_OS_%28April_2024%29.pdf It is probably a bit of work to create an ACR and it may have legal implications as well. Werner, does GnuPG.com plan to create an ACR for GnuPG (VS) Desktop? Maybe a general one for Gpg4win and this packaging with support can be useful. All: how would it help Gpg4win if we had an ACR like Mozilla? Or can we somehow address the legal hurdles differently? Best Regards, Bernhard [1] https://en.wikipedia.org/wiki/Voluntary_Product_Accessibility_Template -- https://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 -------------- 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 wk at gnupg.org Thu Nov 14 09:30:40 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Nov 2024 09:30:40 +0100 Subject: Gpg4win usage in US institutions asking for ACR ('VPAT') and "terms". In-Reply-To: <202411131053.02152.bernhard@intevation.de> (Bernhard Reiter via Gnupg-users's message of "Wed, 13 Nov 2024 10:52:55 +0100") References: <202411131053.02152.bernhard@intevation.de> Message-ID: <8734jukyj3.fsf@jacob.g10code.de> Hi Bernhard, On Wed, 13 Nov 2024 10:52, Bernhard Reiter said: > Werner, does GnuPG.com plan to create an ACR for GnuPG (VS) Desktop? > Maybe a general one for Gpg4win and this packaging with support We did BITV 2.0 [1] conformance tests for GnuPG VS-Desktop and got a respective certification. Given that the GUI part (Kleopatra) was tested and the GUI is the same as in GnuPG Desktop (GPD), the certification should also be valid for GnuPG Desktop. Gpg4win is different in that it has no default configuration and thus differs in some aspects from stock GPD. We won't do BITV certification run for Gpg4win because this is too costly. I have no experience with VPAT; but it seems to be a weaker thing than the German BITV [1]. Although the scope for BITV testing is for all kind of software, the actual tests and their results are imho heavily oriented towards web sites. Properties of complex desktop software, like our certification management, are not too well considered by the rules and thus our certification reads "teilweise konform" (partial compliant) to BITV 2.0 (EN301549 V2.12). Salam-Shalom, Werner ps. Sometimes I wonder why blind users seem to like GUIs with screenreaders more than command line interfaces. The latter are way better accessible using a standard Braille terminal. [1] https://de.wikipedia.org/wiki/Barrierefreie-Informationstechnik-Verordnung -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From mm at dorfdsl.de Sat Nov 16 20:31:31 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sat, 16 Nov 2024 20:31:31 +0100 Subject: import of GPG key doesn't work and doesn't give an error message Message-ID: <20241116203131.0a4911f3@ryz.dorfdsl.de> Hello! I tried to import a GPG key. gpg --recv-keys 0x020898F03962F8B76B42D9F1E805C860F0E3CCB5 --verbose It won't be listed by --list-keys and doesn't give an error message. Do I use it wrong, is the key faulty or is it a problem on my system? m at ryz:~$ gpg --version gpg (GnuPG) 2.4.6 libgcrypt 1.11.0 Copyright (C) 2024 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/m/.gnupg Unterst?tzte Verfahren: ?ff. Schl?ssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Verschl?.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2 m at ryz:~$ -- Gru? Marco Send unsolicited bulk mail to 1731785219muell at stinkedores.dorfdsl.de From rjh at sixdemonbag.org Sat Nov 16 23:34:31 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 Nov 2024 17:34:31 -0500 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <20241116203131.0a4911f3@ryz.dorfdsl.de> References: <20241116203131.0a4911f3@ryz.dorfdsl.de> Message-ID: <3de87f6b-6bf9-479a-9616-197105fb498e@sixdemonbag.org> > It won't be listed by --list-keys and doesn't give an error message. It does, in fact. rjh at sarah ~ % gpg --recv-keys 0x020898F03962F8B76B42D9F1E805C860F0E3CCB5 --verbose gpg: Note: '--verbose' is not considered an option gpg: "--verbose" not a key ID: skipping gpg: key E805C860F0E3CCB5: no user ID gpg: Total number processed: 1 "--verbose" needs to come before any commands. That's why you're not seeing verbose output. The reason why you're not importing the certificate is because the certificate is corrupt or malformed. According to the OpenPGP specification, a certificate must have at least one user ID. This certificate has no user IDs, which means it's garbage data and GnuPG is doing the right thing by not importing a corrupt or malformed certificate. Hope this helps! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1E7A94D4E87F91D5.asc Type: application/pgp-keys Size: 1355 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Sun Nov 17 08:25:54 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 17 Nov 2024 08:25:54 +0100 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <3de87f6b-6bf9-479a-9616-197105fb498e@sixdemonbag.org> References: <20241116203131.0a4911f3@ryz.dorfdsl.de> <3de87f6b-6bf9-479a-9616-197105fb498e@sixdemonbag.org> Message-ID: <20241117082554.4df231e4@ryz.dorfdsl.de> Am 16.11.2024 um 17:34:31 Uhr schrieb Robert J. Hansen via Gnupg-users: > > It won't be listed by --list-keys and doesn't give an error > > message. > > It does, in fact. It doesn't, on my machine, which I want to investigate further. > rjh at sarah ~ % gpg --recv-keys > 0x020898F03962F8B76B42D9F1E805C860F0E3CCB5 --verbose > gpg: Note: '--verbose' is not considered an option > gpg: "--verbose" not a key ID: skipping > gpg: key E805C860F0E3CCB5: no user ID > gpg: Total number processed: 1 I dong see those line starting with gpg: when running the same command. > "--verbose" needs to come before any commands. That's why you're not > seeing verbose output. I now put it at the beginning, but still no output at all. $? is zero, which is strange if the key is broken and won't be imported. > The reason why you're not importing the certificate is because the > certificate is corrupt or malformed. According to the OpenPGP > specification, a certificate must have at least one user ID. This > certificate has no user IDs, which means it's garbage data and GnuPG > is doing the right thing by not importing a corrupt or malformed > certificate. Thanks! I will contact the user. -- Gru? Marco Send unsolicited bulk mail to 1731774871muell at cartoonies.org From andrewg at andrewg.com Sun Nov 17 10:14:47 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 17 Nov 2024 09:14:47 +0000 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <20241117082554.4df231e4@ryz.dorfdsl.de> References: <20241117082554.4df231e4@ryz.dorfdsl.de> Message-ID: <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> On 17 Nov 2024, at 07:26, Marco Moock via Gnupg-users wrote: > > ?Am 16.11.2024 um 17:34:31 Uhr schrieb Robert J. Hansen via Gnupg-users: > >> rjh at sarah ~ % gpg --recv-keys >> 0x020898F03962F8B76B42D9F1E805C860F0E3CCB5 --verbose >> gpg: Note: '--verbose' is not considered an option >> gpg: "--verbose" not a key ID: skipping >> gpg: key E805C860F0E3CCB5: no user ID >> gpg: Total number processed: 1 > > I dong see those line starting with gpg: when running the same command. A question to both Robert and Marco: Where did you get your gnupg(s) from? In the above transcript it looks like it is querying keys.openpgp.org, which sometimes distributes keys without userids. Depending on where you sourced gnupg (upstream or a distribution) and whether you had a copy of the key already, gnupg may or may not accept the downloaded key. If you change the keyserver to pgpkeys.eu or keyserver.ubuntu.com it should work. A From mm at dorfdsl.de Sun Nov 17 10:53:23 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 17 Nov 2024 10:53:23 +0100 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> References: <20241117082554.4df231e4@ryz.dorfdsl.de> <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> Message-ID: <20241117105323.00227ff1@ryz.dorfdsl.de> Am 17.11.2024 um 09:14:47 Uhr schrieb Andrew Gallagher: > A question to both Robert and Marco: > Where did you get your gnupg(s) from? Debian repo, currently experimental. > In the above transcript it looks like it is querying > keys.openpgp.org, which sometimes distributes keys without userids. Is there a special reason for that? -- Gru? Marco Send unsolicited bulk mail to 1731831287muell at cartoonies.org From andrewg at andrewg.com Sun Nov 17 11:12:25 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 17 Nov 2024 10:12:25 +0000 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <20241117105323.00227ff1@ryz.dorfdsl.de> References: <20241117105323.00227ff1@ryz.dorfdsl.de> Message-ID: <181F9493-71CE-4F4B-A2ED-EF08C347766E@andrewg.com> On 17 Nov 2024, at 09:54, Marco Moock via Gnupg-users wrote: > > ?Am 17.11.2024 um 09:14:47 Uhr schrieb Andrew Gallagher: > >> A question to both Robert and Marco: >> Where did you get your gnupg(s) from? > > Debian repo, currently experimental. OK, that would explain why Robert gets an error message and you don?t. If you don?t have a copy of the key already, then the key is unusable without the userid. The difference is that Robert?s gnupg rejects the downloaded (userid-less) key out of hand, while yours tries to merge it with any existing local copy first, which doesn?t generate the same error message. But without a userid it will still get discarded. Changing keyserver should fix the issue in any case. >> In the above transcript it looks like it is querying >> keys.openpgp.org, which sometimes distributes keys without userids. > > Is there a special reason for that? Excessively-cautious interpretation of GDPR. keys.openpgp.org relies on explicit consent before publishing userids, while other keyservers rely on public interest. A From rjh at sixdemonbag.org Mon Nov 18 12:34:41 2024 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 Nov 2024 06:34:41 -0500 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> References: <20241117082554.4df231e4@ryz.dorfdsl.de> <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> Message-ID: <462546d9-6da5-4fe8-ac22-dce7bb6c83ce@sixdemonbag.org> > A question to both Robert and Marco: > Where did you get your gnupg(s) from? GnuPG 2.4.6 from Homebrew on Apple Silicon. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Nov 18 12:39:08 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 18 Nov 2024 11:39:08 +0000 Subject: import of GPG key doesn't work and doesn't give an error message In-Reply-To: <462546d9-6da5-4fe8-ac22-dce7bb6c83ce@sixdemonbag.org> References: <20241117082554.4df231e4@ryz.dorfdsl.de> <3B60D3B4-128F-4E9F-BF41-21724E147D19@andrewg.com> <462546d9-6da5-4fe8-ac22-dce7bb6c83ce@sixdemonbag.org> Message-ID: <3A4962DB-B397-422C-8C4A-782140996344@andrewg.com> On 18 Nov 2024, at 11:34, Robert J. Hansen via Gnupg-users wrote: > >> A question to both Robert and Marco: >> Where did you get your gnupg(s) from? > > GnuPG 2.4.6 from Homebrew on Apple Silicon. Thanks, yes that would be consistent with the difference in error messages. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: