From wk at gnupg.org Tue Oct 1 18:15:00 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2024 18:15:00 +0200 Subject: 2.5.1 testing: [pqc] gpg exporting a secret dual key is not yet supported In-Reply-To: (Dongsheng Song via Gnupg-devel's message of "Tue, 1 Oct 2024 00:27:34 +0800") References: Message-ID: <87msjnu7ej.fsf@jacob.g10code.de> On Tue, 1 Oct 2024 00:27, Dongsheng Song said: > So what is the current backup and recovery solution for 1024_cv448 Backup the the private-keys-v1.d directory. > subkey? When or which version will support exporting 1024_cv448 Thanks for the reminder. I hope to get this into the next version. See https://dev.gnupg.org/T7315 . 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 gniibe at fsij.org Wed Oct 2 07:23:57 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 02 Oct 2024 14:23:57 +0900 Subject: 2.5.1 testing: gpg export secret key error on cv25519/v5 In-Reply-To: References: Message-ID: <87msjnhyc2.fsf@akagi.fsij.org> Hello, Dongsheng Song wrote: > I'm running tests for GnuPG 2.5.1 on and I found that the gpg export > secret key error on cv25519/v5 has a regression: Thank you for your report. I created a ticket for this bug. https://dev.gnupg.org/T7316 In GnuPG 2.4.x, v5 key is experimental. Incompatible change is introduced in 2.5, and it's ongoing change (generation is with new OID, exporting is not yet supported for cv25519/v5). -- From calvin at cmpct.info Thu Oct 3 16:28:36 2024 From: calvin at cmpct.info (Calvin Buckley) Date: Thu, 3 Oct 2024 11:28:36 -0300 Subject: Requesting bug tracker account Message-ID: Hi, I'd like a BT account to report a bug and submit a patchset that fixes said patchset for review; it fixes an issue with using gpgrt dynamically on some platforms, but I'd like review to catch any subtleties with it. The account name could be "calvin", and my name and email address should be on this email. Regards, Calvin Buckley From alan.coopersmith at oracle.com Wed Oct 9 00:03:44 2024 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Tue, 8 Oct 2024 15:03:44 -0700 Subject: [PATCH GnuPG] build: Fix GNUPG_CHECK_ENDIAN to work with gcc 14 Message-ID: <20241008220629.1282-1-alan.coopersmith@oracle.com> Before this fix, running configure on Solaris 11.4 x86 with gcc 14 claimed x86 systems were big endian, because the test failed to compile: conftest.c:103:1: error: return type defaults to 'int' [-Wimplicit-int] 103 | main () { | ^~~~ conftest.c: In function 'main': conftest.c:111:15: error: implicit declaration of function 'exit' [-Wimplicit-function-declaration] 111 | exit (u.c[sizeof (long) - 1] == 1); | ^~~~ Signed-off-by: Alan Coopersmith --- acinclude.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 98a87f673..a63edbe28 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -84,7 +84,7 @@ AC_DEFUN([GNUPG_CHECK_ENDIAN], not big endian #endif]])], gnupg_cv_c_endian=big, gnupg_cv_c_endian=little)]) if test "$gnupg_cv_c_endian" = unknown; then - AC_RUN_IFELSE([AC_LANG_SOURCE([[main () { + AC_RUN_IFELSE([AC_LANG_PROGRAM([[#include ]],[[ /* Are we little or big endian? From Harbison&Steele. */ union { @@ -93,7 +93,7 @@ AC_DEFUN([GNUPG_CHECK_ENDIAN], } u; u.l = 1; exit (u.c[sizeof (long) - 1] == 1); - }]])], + ]])], gnupg_cv_c_endian=little, gnupg_cv_c_endian=big, gnupg_cv_c_endian=$tmp_assumed_endian -- 2.45.2 From gniibe at fsij.org Wed Oct 9 07:40:55 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 09 Oct 2024 14:40:55 +0900 Subject: [PATCH GnuPG] build: Fix GNUPG_CHECK_ENDIAN to work with gcc 14 In-Reply-To: <20241008220629.1282-1-alan.coopersmith@oracle.com> References: <20241008220629.1282-1-alan.coopersmith@oracle.com> Message-ID: <87r08psujc.fsf@akagi.fsij.org> Hello, Thank you for your report. Alan Coopersmith wrote: > Before this fix, running configure on Solaris 11.4 x86 with gcc 14 > claimed x86 systems were big endian, because the test failed to compile: If it works well, using AC_C_BIGENDIAN of autoconf is better, I suppose. I'd like to apply something like following: diff --git a/configure.ac b/configure.ac index 991313093..36ff452d7 100644 --- a/configure.ac +++ b/configure.ac @@ -544,19 +544,6 @@ AH_BOTTOM([ #endif -/* We didn't define endianness above, so get it from OS macros. This - is intended for making fat binary builds on OS X. */ -#if !defined(BIG_ENDIAN_HOST) && !defined(LITTLE_ENDIAN_HOST) -#if defined(__BIG_ENDIAN__) -#define BIG_ENDIAN_HOST 1 -#elif defined(__LITTLE_ENDIAN__) -#define LITTLE_ENDIAN_HOST 1 -#else -#error "No endianness found" -#endif -#endif - - /* Hack used for W32: ldap.m4 also tests for the ASCII version of ldap_start_tls_s because that is the actual symbol used in the library. winldap.h redefines it to our commonly used value, @@ -1332,6 +1319,10 @@ AC_MSG_NOTICE([checking for system characteristics]) AC_C_CONST AC_C_INLINE AC_C_VOLATILE +AC_C_BIGENDIAN([AC_DEFINE(BIG_ENDIAN_HOST,1, + [Defined if the host has big endian byte ordering])], + [AC_DEFINE(LITTLE_ENDIAN_HOST,1, + [Defined if the host has little endian byte ordering])]) AC_TYPE_SIZE_T AC_TYPE_MODE_T AC_CHECK_FUNCS([sigdescr_np]) @@ -1347,15 +1338,6 @@ gl_TYPE_SOCKLEN_T AC_SEARCH_LIBS([inet_addr], [nsl]) -AC_ARG_ENABLE(endian-check, - AS_HELP_STRING([--disable-endian-check], - [disable the endian check and trust the OS provided macros]), - endiancheck=$enableval,endiancheck=yes) - -if test x"$endiancheck" = xyes ; then - GNUPG_CHECK_ENDIAN -fi - # fixme: we should get rid of the byte type AC_CHECK_TYPES([byte, ushort, ulong, u16, u32]) AC_CHECK_SIZEOF(unsigned short) -- From wk at gnupg.org Thu Oct 10 12:42:03 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Oct 2024 12:42:03 +0200 Subject: [PATCH GnuPG] build: Fix GNUPG_CHECK_ENDIAN to work with gcc 14 In-Reply-To: <20241008220629.1282-1-alan.coopersmith@oracle.com> (Alan Coopersmith via Gnupg-devel's message of "Tue, 8 Oct 2024 15:03:44 -0700") References: <20241008220629.1282-1-alan.coopersmith@oracle.com> Message-ID: <87frp4nssk.fsf@jacob.g10code.de> On Tue, 8 Oct 2024 15:03, Alan Coopersmith said: > - AC_RUN_IFELSE([AC_LANG_SOURCE([[main () { > + AC_RUN_IFELSE([AC_LANG_PROGRAM([[#include ]],[[ Which requires a full C90 compiler. In the old times that was not the case and iirc this would have failed for old HP/UX installations. Meanwhile this is all obsolete because we anyway require most of C99. As Niibe-san explains we should better use the somwhat modern tests fro autoconf. Shalom-Salam, 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 alan.coopersmith at oracle.com Fri Oct 11 00:50:35 2024 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Thu, 10 Oct 2024 15:50:35 -0700 Subject: [PATCH GnuPG] build: Fix GNUPG_CHECK_ENDIAN to work with gcc 14 In-Reply-To: <87r08psujc.fsf@akagi.fsij.org> References: <20241008220629.1282-1-alan.coopersmith@oracle.com> <87r08psujc.fsf@akagi.fsij.org> Message-ID: On 10/8/24 22:40, NIIBE Yutaka wrote: > Hello, > > Thank you for your report. > > Alan Coopersmith wrote: >> Before this fix, running configure on Solaris 11.4 x86 with gcc 14 >> claimed x86 systems were big endian, because the test failed to compile: > > If it works well, using AC_C_BIGENDIAN of autoconf is better, I suppose. AC_C_BIGENDIAN works fine on Solaris - it detects that SPARC is bigendian and that x86/x64 is not. Switching to it seems like an even better fix. Thanks -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From ametzler at bebt.de Thu Oct 24 18:31:19 2024 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 24 Oct 2024 18:31:19 +0200 Subject: gnupg 2.2.45 untagged Message-ID: Hello, it look like 2.2.45 was released (tarball available). Could you please push the GIT tag? TIA, cu Andreas From wk at gnupg.org Sat Oct 26 15:09:14 2024 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Oct 2024 15:09:14 +0200 Subject: gnupg 2.2.45 untagged In-Reply-To: (Andreas Metzler's message of "Thu, 24 Oct 2024 18:31:19 +0200") References: Message-ID: <87a5erxb7p.fsf@jacob.g10code.de> Hi! > it look like 2.2.45 was released (tarball available). Could you please push > the GIT tag? Done, sorry. But please remember that end-of-life will be in 2 months. Better migrate to 2.4. 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 wk at gnupg.org Tue Oct 29 15:20:51 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Oct 2024 15:20:51 +0100 Subject: [Announce] GnuPG 2.4.6 released Message-ID: <87frofuh18.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: version 2.4.6. This version fixes a couple of bugs, comes with a few new features, and has now full support for Portuguese. 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.4.6 =================================== * gpg: New command --quick-set-ownertrust. [rG967678d972] * gpg: Indicate disabled keys in key listings and add list option "show-ownertrust". [rG2a0a706eb2] * gpg: Make sure a DECRYPTION_OKAY is never issued for a bad OCB tag. [T7042] * gpg: Do not allow to accidently set the RENC usage. [T7072] * gpg: Accept armored files without CRC24 checksum. [T7071] * gpg: New --import-option "only-pubkeys". [T7146] * gpg: Repurpose the AKL mechanism "ldap" to work like the keyserver mechnism but only for LDAP keyservers. [rG6551281ca3] * gpg: ADSKs are now configurable for new keys. [T6882] * gpg: New option --proc-all-sigs. [T7261] * gpg: Fix a wrong decryption failed status for signed and OCB encrypted messages without a signature verification key. [T7042] * gpg: Make --no-literal work again for -c and --store. [T5852] * gpg: Fix getting key by IPGP. [T7288] * gpg: Validate the trustdb after the import of a trusted key. [T7200] * gpg: Exclude expired trusted keys from the key validation process. [T7200] * gpgsm: New option --assert-signer. [T7286] * gpgsm: Emit user IDs with an empty Subject also in colon mode. [T7171] * keyboxd: Fix a race condition on the database handle. [T7294] * agent: Consider an empty pattern file as valid. [rGc27534de95] * agent: Fix error handling of READKEY. [T6012] * agent: Avoid random errors when storing key in ephemeral mode. [T7129, rG19d93a239d] * agent: Make "SCD DEVINFO --watch" more robust. [T7151] * agent: Fix detection of the yet unused trustflag de-vs. [T5079] * scd: Improve KDF data object handling for OpenPGP cards. [T7058] * scd: Avoid buffer overrun with more than 16 PC/SC readers. [T7129, rG524e3a9345] * scd: Fix how the scdaemon on its pipe connection finishes. [T7160] * gpgconf: Check readability of some files with -X and change its output format. [rG759adb2493] * gpg-mail-tube: New tool to apply PGP/MIME encryption to a mail. [rGa564a9f66c] * Fix a race condition in creating the socket directory. [T7332] * Fix some uninitialized variables and double frees in error code paths. [T7129] Release-info: https://dev.gnupg.org/T7030 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 compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.6.tar.bz2 (7923k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.6.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.4.6_20241029.exe (5488k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.6_20241029.exe.sig The source used to build this Windows installer can be found in the same directory with a ".tar.xz" suffix. A new release of Gpg4win has not yet been done because we are still working on GUI improvements. 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.6.tar.bz2 you would use this command: gpg --verify gnupg-2.4.6.tar.bz2.sig gnupg-2.4.6.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.6.tar.bz2, you run the command like this: sha1sum gnupg-2.4.6.tar.bz2 and check that the output matches the next line: 2d8aa2662c398d60f1f8e0bf46fd163eae703189 gnupg-2.4.6.tar.bz2 f296bcb4e252975b818246771102f8db057e24ad gnupg-w32-2.4.6_20241029.tar.xz 6d6b2017152fea4532afe38ce00e38a438b1e4bb gnupg-w32-2.4.6_20241029.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/T7030 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 with 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 tmz at pobox.com Tue Oct 29 18:46:24 2024 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 29 Oct 2024 13:46:24 -0400 Subject: [Announce] GnuPG 2.4.6 released In-Reply-To: <87frofuh18.fsf@jacob.g10code.de> References: <87frofuh18.fsf@jacob.g10code.de> Message-ID: Hi Werner, Werner Koch via Gnupg-devel wrote: > We are pleased to announce the availability of a new stable GnuPG > release: version 2.4.6. This version fixes a couple of bugs, comes > with a few new features, and has now full support for Portuguese. This release includes 35d80ebd7 (doc: Add support for generating HTML versions of the man pages., 2024-09-19) which builds the HTML documentation unconditionally. This calls yat2m with the --gnupgorg option added in libgpg-error 1.48. Building now fails when an older libgpg-error is installed and the builder doesn't override the YAT2M option to point at the embedded copy in the gnupg tarball, as the command found in PATH is preferred. Should the libgpg-error version requirement be increased and/or what is the suggested method for folks building against distribution packages? Perhaps an option to explicitly enable or disable the HTML documentation would be welcome? -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From hell.ivan1991 at gmail.com Wed Oct 30 12:40:18 2024 From: hell.ivan1991 at gmail.com (Ivan Hell) Date: Wed, 30 Oct 2024 12:40:18 +0100 Subject: Incompatability with other PGP implementations Message-ID: Hello, I'm not sure if this is the correct place to post such a question but I hope I can get an answer nevertheless. In my everyday life I use GPG mainly to sign documents and git commits. Recently I had to implement a Node.js application that uses GPG keys in order to verify GPG signed documents. For this reason I used the following library: https://openpgpjs.org/. The GPG key in use had the following structure: Master-Key (created: 2022-01-01, expires: 2030-01-01) | -> signing subkey (created: 2022-01-01, expires: 2024-10-15) | -> encryption subkey (created: 2022-01-01, expires: 2024-10-15) Up until now everything worked like a charm. Since both subkeys expired during this month I decided to update their expire Date using the GPG CLI: Master-Key (created: 2022-01-01, expires: 2030-01-01) | -> signing subkey (created: 2022-01-01, expires: 2026-10-15, updated 2024-10-14) | -> encryption subkey (created: 2022-01-01, expires: 2026-10-15, updated 2024-10-14) In consequence I exported the key again and imported it in my Node.js application. However, from that point on message verification in my Node.js application always failed for messages signed before 2024-10-14. In contrast, signature verification using GPG worked without any issues. To better understand the problem I looked through the implementation of opengpgjs and noticed that the error was caused by the signing key's binding signature validity check. In contrast to GPG, when checking a signature validity, this library looks at the subkey's binding signature creation date instead of the subkey's creation date. In consequence I filed an issue on their github project and started a discussion with the project maintainer: https://github.com/openpgpjs/openpgpjs/issues/1800. As a result, the maintainer noted that the library strictly adheres to the OpenPGP specification and its RFCs when checking signatures and that gpg may deviate slightly in its implementation of the standard. He also argued that according to sequoia-pgp's OpenPGP interoperability tests, most implementations adhere to his interpretation of the standard: https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?impls=7594#Key_revocation_test__subkey_signs__primary_key_is_not_revoked__base_case_ My question now is whether the current implementation of GPG is exposed to a security risk by not taking the creation date of the binding signature into account? I also wanted to find out whether there is a way to adapt the implementation in GPG so that it is compatible with the other OpenPGP implementations (possibly using a configuration option)? Best regards Ivan From wk at gnupg.org Wed Oct 30 15:08:57 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2024 15:08:57 +0100 Subject: Incompatability with other PGP implementations In-Reply-To: (Ivan Hell via Gnupg-devel's message of "Wed, 30 Oct 2024 12:40:18 +0100") References: Message-ID: <87plnhu1hi.fsf@jacob.g10code.de> Hi! Thanks for the description of your problem. However, I am not sure whether I really understood all details. On Wed, 30 Oct 2024 12:40, Ivan Hell said: > key's binding signature validity check. In contrast to GPG, when > checking a signature validity, this library looks at the subkey's > binding signature creation date instead of the subkey's creation date. Interesting, the binding signature creation time is "soft"-timestamp and has is used to figure out which binding signature prevails. The specs leave it to the implementer on how to do this. GnuPG and PGP have been developed together in a way to achieve best compatibility. Thus the interpretation of the OpenPGP standard as implemented by gpg is as close as possible to the interpretation of PGP.com's interpretation of the OpenPGP respective their original implementation. In fact, David and me worked closely with Hal Finney of PGP to have a common understanding on how to interpret a standard. > the OpenPGP specification and its RFCs when checking signatures and > that gpg may deviate slightly in its implementation of the standard. A specification always needs interpretation and cross-testing. You simply can't write a specification for an existing protocol (PGP 2 and 5) in such a detail that it describes everything. If you would do that you would replicate the implementation. I believe it is common sense that interop testing is the best way to achieve high interoperability. > He also argued that according to sequoia-pgp's OpenPGP > interoperability tests, most implementations adhere to his Well, someone wrote a new implementation of OpenPGP and thus uses an own interpretation. How they also write a test suite and claim that this reflects the standard. Does it really reflect the actual use of OpenPGP and all the deployed versions of PGP, GnuPG, RNP, and BouncyCastle used in productive environments? We don't have exact numbers but an educated guess (based on my >25 years experience and lots of commercial support) is that they make up more more than 95% of deployed implementations. > My question now is whether the current implementation of GPG is > exposed to a security risk by not taking the creation date of the > binding signature into account? I also wanted to find out whether The problem here is that a few newcomers try to break an existing and well matured standard by adding new interpretations (and a new version of OpenPGP) and thereby creating interoperability problems. > there is a way to adapt the implementation in GPG so that it is > compatible with the other OpenPGP implementations (possibly using a No, we won't play that game. BTW, this trouble was the reason why RNP and us came up with a new term for the widely deployed version of OpenPGP (rfc4880bis): LibrePGP [1]. Salam-Shalom, Werner [1] See https://librepgp.org for more information. -- 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 wk at gnupg.org Wed Oct 30 15:15:47 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2024 15:15:47 +0100 Subject: HTML man pages failed to build (was: GnuPG 2.4.6 released) In-Reply-To: (Todd Zullinger via Gnupg-devel's message of "Tue, 29 Oct 2024 13:46:24 -0400") References: <87frofuh18.fsf@jacob.g10code.de> Message-ID: <87ldy5u164.fsf_-_@jacob.g10code.de> Hi! On Tue, 29 Oct 2024 13:46, Todd Zullinger said: > which builds the HTML documentation unconditionally. This > calls yat2m with the --gnupgorg option added in libgpg-error > 1.48. Oh, does that happen in the default way to build it? I always do a double build to make sure we are really building everything from the tarball. > Should the libgpg-error version requirement be increased > and/or what is the suggested method for folks building > against distribution packages? Perhaps an option to > explicitly enable or disable the HTML documentation would be Yeah, should only be build in --enable-maintainer-mode. After all the HTML rendering still has a couple f problems. Shalom-Salam, 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: