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: From wk at gnupg.org Thu Nov 28 11:30:17 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Nov 2024 11:30:17 +0100 Subject: [Announce] GnuPG 2.4.7 and Gpg4win 4.4.0 released Message-ID: <87jzcn4pmu.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: version 2.4.7. This version fixes a couple of bugs. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP (aka LibrePGP) 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.4.7 =================================== * gpg: Allow the use of an ADSK subkey as ADSK subkey. [T6882] * gpg: Avoid a failure exit code for expired ultimately trusted keys. [T7351] * gpg: Fix comparing ed448 to ed25519 with --assert-pubkey-algo. [T7425] * gpg: Retain binary representation for import->export with Ed25519 key signatures. [T7426] * gpgsm: Improvement for some rare P12 files. [rG5f9975abf5] * scd: More mitigations against lock ups with multiple cards or apps. [T7323, T7402] * gpgtar: Fix directory creation during extraction. [T7380] * gpg-mail-tube: Minor fixes. * gpgconf: Add list flag to trusted-key et al. [T7313] * Fix a build problem on macOS (missing unistd.h). [T7193] Release-info: https://dev.gnupg.org/T7353 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 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 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.7.tar.bz2 (8M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.7.tar.bz2.sig A source code version with all GnuPG related libraries: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.4.7_20241125.tar.xz (16M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.4.7_20241125.tar.xz.sig A new release of the Windows version Gpg4win in the form of the full featured Gpg4win installer including this version of GnuPG as well as a full featured GUI and a PDF editor can be retrieved from here: https://files.gpg4win.org/gpg4win-4.4.0.exe (34M) https://files.gpg4win.org/gpg4win-4.4.0.exe.sig and its source code is https://files.gpg4win.org/gpg4win-4.4.0.tar.xz (251M) https://files.gpg4win.org/gpg4win-4.4.0.tar.xz.sig 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.4.7.tar.bz2 you would use this command: gpg --verify gnupg-2.4.7.tar.bz2.sig gnupg-2.4.7.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.4.7.tar.bz2, you run the command like this: sha1sum gnupg-2.4.7.tar.bz2 and check that the output matches the next line: 2d510a1a7294f2f9ef3f2e280c93c3ad9b0cdb68 gnupg-2.4.7.tar.bz2 c2a5a2103f2c02d7067f9360f105478ca694a32c gnupg-w32-2.4.7_20241125.tar.xz 5c5e06f9f36d816ba14847d813127c9510836394 gpg4win-4.4.0.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, 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 the 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/T7353 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 has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. 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, answering questions on the mailing lists, or helped us in the past with their donations. *Thank you all* 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. 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) 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. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 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 luca.vincenti at garr.it Wed Nov 27 12:09:36 2024 From: luca.vincenti at garr.it (Luca Vincenti) Date: Wed, 27 Nov 2024 12:09:36 +0100 Subject: Mirroring GnuPG Message-ID: Hello, We at GARR have a mirror service aimed at the Italian community and we have been mirroring this project for a while using rsync on this source: ftp.gnupg.org::gnupg. Since the release of GnuPG 2.4.6 (2024-10-29), we have been experiencing a "Permission denied" error while copying 6 files: /gnupg/g10-0.2.3.tar.gz.pgp.sig /gnupg/g10-0.2.3.tar.gz.sig /gnupg/g10-0.2.4.tar.gz.pgp.sig /gnupg/g10-0.2.5.tar.gz.pgp.sig /gnupg/g10-0.2.6.tar.gz.pgp.sig /gnupg/g10-0.2.7.tar.gz.sig Full error as follows: rsync: send_files failed to open "/gnupg/g10-0.2.3.tar.gz.pgp.sig" (in gnupg): Permission denied (13) We suspect the problem might be on the source. We were also not able to find any recommendations on how to properly mirror this project and what is needed to become an official mirror listed here: www.gnupg.org/download/mirrors.html Any help is welcome, Thank you. GARR Mirror Service -- Luca Vincenti Gruppo IT - Dipartimento Infrastruttura GARR - The Italian Academic and Research Network Via dei Tizii, 6/b - 00185 Roma, Italy Tel: +39 06 4962 2517 Mob: +39 331 1404831 Email:luca.vincenti at garr.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at ml.seichter.de Thu Nov 28 16:23:11 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Thu, 28 Nov 2024 16:23:11 +0100 Subject: GnuPG 2.4.7 for OS X / macOS is now available Message-ID: I am happy to announce that release 2.4.6 of GnuPG for OS X / macOS is now available. The installation disk image provides unified binaries suitable for both ARM- and Intel-based Macs. Please see https://sourceforge.net/p/gpgosx/docu/Download/ for further details. -Ralph From kloecker at kde.org Thu Nov 28 17:42:55 2024 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Thu, 28 Nov 2024 17:42:55 +0100 Subject: Mirroring GnuPG In-Reply-To: References: Message-ID: <2284314.vFx2qVVIhK@daneel> On Mittwoch, 27. November 2024 12:09:36 Mitteleurop?ische Normalzeit Luca Vincenti via Gnupg-users wrote: > We at GARR have a mirror service aimed at the Italian community and we > have been mirroring this project for a while using rsync on this source: > ftp.gnupg.org::gnupg. I think you missed this announcement at https://gnupg.org/ ``` Our FTP server has been discontinued (2024-08-20) For technical and organisational reasons we recently shutdown our FTP server. Instead of using ftp.gnupg.org please use https://gnupg.org/ftp/ . ``` All FTP mirrors seem to be dead or empty. A couple of HTTP mirrors seem to mirror https://gnupg.org/ftp/gcrypt . 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 daniele at grinta.net Thu Nov 28 18:06:37 2024 From: daniele at grinta.net (Daniele Nicolodi) Date: Thu, 28 Nov 2024 18:06:37 +0100 Subject: Mirroring GnuPG In-Reply-To: <2284314.vFx2qVVIhK@daneel> References: <2284314.vFx2qVVIhK@daneel> Message-ID: On 28/11/24 17:42, Ingo Kl?cker wrote: > On Mittwoch, 27. November 2024 12:09:36 Mitteleurop?ische Normalzeit Luca > Vincenti via Gnupg-users wrote: >> We at GARR have a mirror service aimed at the Italian community and we >> have been mirroring this project for a while using rsync on this source: >> ftp.gnupg.org::gnupg. > > I think you missed this announcement at https://gnupg.org/ I think you missed that Luca is using rsync, not ftp :-) Cheers, Dan