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