From ametzler at bebt.de  Mon Nov  4 17:55:36 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 4 Nov 2024 17:55:36 +0100
Subject: [patch] two typo fixes found by lintian
Message-ID: <Zyj8iA_firiO7LmV@argenau.bebt.de>

Hello,

please find attached a patch against gnupg GIT master to fix two typos.

cu Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typos-lintian.diff
Type: text/x-diff
Size: 1011 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241104/cd13e0ce/attachment.diff>

From wk at gnupg.org  Mon Nov  4 18:08:16 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2024 18:08:16 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <Zyj8iA_firiO7LmV@argenau.bebt.de> (Andreas Metzler's message of
 "Mon, 4 Nov 2024 17:55:36 +0100")
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
Message-ID: <87ttcnorjz.fsf@jacob.g10code.de>

On Mon,  4 Nov 2024 17:55, Andreas Metzler said:

>    @item only-pubkeys
> -  Do now allow to import secret keys.
> +  Do not allow one to import secret keys.

Isn't

    Do not allow the import of secret keys.

better and more clear?

-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241104/ab6cdff7/attachment.sig>

From ametzler at bebt.de  Mon Nov  4 18:20:42 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 4 Nov 2024 18:20:42 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <87ttcnorjz.fsf@jacob.g10code.de>
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <87ttcnorjz.fsf@jacob.g10code.de>
Message-ID: <ZykCauPjYFmNBD-O@argenau.bebt.de>

On 2024-11-04 Werner Koch <wk at gnupg.org> wrote:
> On Mon,  4 Nov 2024 17:55, Andreas Metzler said:

> >    @item only-pubkeys
> > -  Do now allow to import secret keys.
> > +  Do not allow one to import secret keys.

> Isn't

>     Do not allow the import of secret keys.

> better and more clear?

Hmm. How about "Prohibit import of secret keys."? I hope a native
speaker can shed some light. ;-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From mail at bernhard-voelker.de  Mon Nov  4 19:28:14 2024
From: mail at bernhard-voelker.de (Bernhard Voelker)
Date: Mon, 4 Nov 2024 19:28:14 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <87ttcnorjz.fsf@jacob.g10code.de>
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <87ttcnorjz.fsf@jacob.g10code.de>
Message-ID: <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>



On 11/4/24 18:08, Werner Koch via Gnupg-devel wrote:
> On Mon,  4 Nov 2024 17:55, Andreas Metzler said:
>
>>     @item only-pubkeys
>> -  Do now allow to import secret keys.
>> +  Do not allow one to import secret keys.
>
> Isn't
>
>      Do not allow the import of secret keys.
>
> better and more clear?

Isn't the change more about "now" vs. "not"?

Have a nice day,
Berny


From ametzler at bebt.de  Mon Nov  4 21:09:06 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 4 Nov 2024 21:09:06 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <87ttcnorjz.fsf@jacob.g10code.de>
 <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
Message-ID: <Zykp4mGTIFXAqyrU@argenau.bebt.de>

On 2024-11-04 Bernhard Voelker <mail at bernhard-voelker.de> wrote:


> On 11/4/24 18:08, Werner Koch via Gnupg-devel wrote:
>> On Mon,  4 Nov 2024 17:55, Andreas Metzler said:

>>>     @item only-pubkeys
>>> -  Do now allow to import secret keys.
>>> +  Do not allow one to import secret keys.

>> Isn't

>>      Do not allow the import of secret keys.

>> better and more clear?

> Isn't the change more about "now" vs. "not"?

Both changes ("allow to" and "now") are significant.

cu Andreas


From paul at boddie.org.uk  Mon Nov  4 22:53:40 2024
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 04 Nov 2024 22:53:40 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <Zykp4mGTIFXAqyrU@argenau.bebt.de>
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
 <Zykp4mGTIFXAqyrU@argenau.bebt.de>
Message-ID: <6117997.u5xhZ7jtQd@jason>

On Monday, 4 November 2024 21:09:06 CET Andreas Metzler wrote:
> On 2024-11-04 Bernhard Voelker <mail at bernhard-voelker.de> wrote:
> > On 11/4/24 18:08, Werner Koch via Gnupg-devel wrote:
> >> On Mon,  4 Nov 2024 17:55, Andreas Metzler said:
> >>>     @item only-pubkeys
> >>> 
> >>> -  Do now allow to import secret keys.
> >>> +  Do not allow one to import secret keys.
> >> 
> >> Isn't
> >> 
> >>      Do not allow the import of secret keys.
> >> 
> >> better and more clear?
> > 
> > Isn't the change more about "now" vs. "not"?
> 
> Both changes ("allow to" and "now") are significant.

This is becoming confusing, but looking at the message item name, which 
appears to be "only-pubkeys", it seems that the original message text used 
"now" in error where "not" was actually intended.

Correcting this initial mistake...

"Do not allow to import secret keys."

...yields a rather awkward sentence, but Werner's suggestion tidies it up:

"Do not allow the import of secret keys."

Of course, one could also suggest the following:

"Do not import secret keys."

I guess it depends on what the message is really supposed to mean and in which 
context it appears, but I hope that this feedback helps on the matter of the 
wording.

Paul




From ametzler at bebt.de  Mon Nov  4 21:09:06 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 4 Nov 2024 21:09:06 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <87ttcnorjz.fsf@jacob.g10code.de>
 <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
Message-ID: <Zykp4mGTIFXAqyrU@argenau.bebt.de>

On 2024-11-04 Bernhard Voelker <mail at bernhard-voelker.de> wrote:


> On 11/4/24 18:08, Werner Koch via Gnupg-devel wrote:
>> On Mon,  4 Nov 2024 17:55, Andreas Metzler said:

>>>     @item only-pubkeys
>>> -  Do now allow to import secret keys.
>>> +  Do not allow one to import secret keys.

>> Isn't

>>      Do not allow the import of secret keys.

>> better and more clear?

> Isn't the change more about "now" vs. "not"?

Both changes ("allow to" and "now") are significant.

cu Andreas


From gsteemso at gmail.com  Wed Nov  6 05:20:17 2024
From: gsteemso at gmail.com (Gordon Steemson)
Date: Tue, 5 Nov 2024 20:20:17 -0800
Subject: Things I had to do to make GnuPG et al compile
Message-ID: <CABKoxZq6crWMdBq3km6mzzL2CgDc9bRB0A003QXgsfLRrSoa2Q@mail.gmail.com>

Hi all,

The following details just what I had to patch, and/or otherwise work
around, in order to build GPG
and its supporting libraries, based on the release versions supplied
by the GnuPG website.  The
build system was a Power Mac G5 running Mac OS 10.5.8, and the
compiler was Apple?s version of GCC
4.2.1 (mainly because it supports ?universal?, i.e. multi?platform,
builds without having to repeat
the compilation for each target).  In the same order as the various
packages are listed on GnuPG?s
website,

1) GnuPG:  In addition to arranging updated versions of assorted
support software (such as cURL,
           OpenSSH, and ld), I had to write the following patch:

--- old/g10/gpg.h 2023-04-04 01:28:39.000000000 -0700
+++ new/g10/gpg.h 2024-10-04 09:55:48.000000000 -0700
@@ -68,9 +68,6 @@
 struct dirmngr_local_s;
 typedef struct dirmngr_local_s *dirmngr_local_t;

-/* Object used to describe a keyblock node.  */
-typedef struct kbnode_struct *KBNODE;   /* Deprecated use kbnode_t.
*/typedef struct kbnode_struct *kbnode_t;
-
 /* The handle for keydb operations.  */
 typedef struct keydb_handle_s *KEYDB_HANDLE;

--- old/g10/keydb.h 2024-03-07 05:17:49 -0800
+++ new/g10/keydb.h 2024-10-04 12:43:11 -0700
@@ -24,6 +24,7 @@

 #include "../common/types.h"
 #include "../common/util.h"
+#include "keyring.h"
 #include "packet.h"

 /* What qualifies as a certification (key-signature in contrast to a
--- old/g10/keydb-private.h 2023-04-04 01:28:39 -0700
+++ new/g10/keydb-private.h 2024-10-04 09:55:38 -0700
@@ -23,13 +23,9 @@

 #include <assuan.h>
 #include "../common/membuf.h"
-
-
-/* Ugly forward declarations.  */
-struct keyring_handle;
-typedef struct keyring_handle *KEYRING_HANDLE;
-struct keybox_handle;
-typedef struct keybox_handle *KEYBOX_HANDLE;
+#include "gpg.h"
+#include "keyring.h"
+#include "../kbx/keybox.h"


 /* This is for keydb.c and only used in non-keyboxd mode. */
--- old/g10/keyring.h 2023-04-04 01:28:39 -0700
+++ new/g10/keyring.h 2024-10-04 11:06:21 -0700
@@ -22,6 +22,10 @@

 #include "../common/userids.h"

+/* Object used to describe a keyblock node.  */
+typedef struct kbnode_struct *KBNODE;   /* Deprecated use kbnode_t. */
+typedef struct kbnode_struct *kbnode_t;
+
 typedef struct keyring_handle *KEYRING_HANDLE;

 int keyring_register_filename (const char *fname, int read_only, void **ptr);
--- old/g10/packet.h 2023-04-04 01:28:39 -0700
+++ new/g10/packet.h 2024-10-04 12:47:37 -0700
@@ -30,6 +30,7 @@
 #include "../common/openpgpdefs.h"
 #include "../common/userids.h"
 #include "../common/util.h"
+#include "keyring.h"

 #define DEBUG_PARSE_PACKET 1

--- old/g13/Makefile.in 2024-03-07 05:45:52 -0800
+++ new/g13/Makefile.in 2024-10-04 12:54:33 -0700
@@ -530,7 +530,7 @@
           $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV)

 t_g13tuple_SOURCES = t-g13tuple.c g13tuple.c
-t_g13tuple_LDADD = $(t_common_ldadd)
+t_g13tuple_LDADD = $(t_common_ldadd) $(LIBINTL)
 all: all-am

 .SUFFIXES:
--- old/kbx/keybox.h 2023-05-30 04:44:45 -0700
+++ new/kbx/keybox.h 2024-10-04 00:27:09 -0700
@@ -28,6 +28,7 @@

 #include "../common/iobuf.h"
 #include "keybox-search-desc.h"
+#include "../g10/keyring.h"

 #ifdef KEYBOX_WITH_X509
 # include <ksba.h>

           Notice that most elements of this patch involve swapping
around the inclusion of a
           specific header file and/or the declaration of a specific
data type.  The only exception
           is the bit for the G13 Makefile, which adds libintl to a
list of linker flags.

2) Libgpg-error:  I had to write the following patch for
src/spawn-posix.c, to account for Darwin?s
                  very indirect manner of accessing the environment.
Some elements of it will need
                  to be adjusted for general use; for example, I have
no idea how to appropriately
                  conditionalize the header?file inclusion in the first chunk.

--- old/src/spawn-posix.c 2024-06-19 00:33:41 -0700
+++ new/src/spawn-posix.c 2024-10-02 18:34:07 -0700
@@ -36,6 +36,7 @@
 # include <signal.h>
 #endif
 #include <unistd.h>
+#include <crt_externs.h>
 #include <fcntl.h>

 #include <sys/socket.h>
@@ -318,6 +319,7 @@
 my_exec (const char *pgmname, const char *argv[], gpgrt_spawn_actions_t act)
 {
   int i;
+  char **envp;

   /* Assign /dev/null to unused FDs.  */
   for (i = 0; i <= 2; i++)
@@ -342,7 +344,9 @@
   _gpgrt_close_all_fds (3, act->except_fds);

   if (act->environ)
-    environ = act->environ;
+    envp = act->environ;
+  else
+    envp = _NSGetEnviron;

   if (act->atfork)
     act->atfork (act->atfork_arg);
@@ -351,7 +355,7 @@
   if (pgmname == NULL)
     return 0;

-  execv (pgmname, (char *const *)argv);
+  execve (pgmname, (char *const *)argv, (char *const *)envp);
   /* No way to print anything, as we have may have closed all streams. */
   _exit (127);
   return -1;

3) Libgcrypt:  This actually needed no patching at all for my system,
but if you try to build it on
               the slightly older Mac OS 10.4, you need to
conditionalize the inclusion of
               Availablity.h (which apparently only existed as of Mac
OS 10.5).  The patch below ?
               not written by me ? makes this change.

--- old/random/rndoldlinux.c 2023-11-28 18:04:36 +0000
+++ new/random/rndoldlinux.c 2023-11-28 18:05:45 +0000
@@ -29,7 +29,11 @@
 #include <fcntl.h>
 #include <poll.h>
 #if defined(__APPLE__) && defined(__MACH__)
+#ifdef __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
+#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1050
 #include <Availability.h>
+#endif
+#endif
 #ifdef __MAC_10_11
 #include <TargetConditionals.h>
 #if !defined(TARGET_OS_IPHONE) || TARGET_OS_IPHONE == 0

4) Libksba:  This is the only element of the entire system that seems
to work entirely unmodified.

5) Libassuan:  This actually does not build correctly no matter what I
do, and I have no idea why.
               It SEEMS to, but the `make check` step reveals that two
of the four tests fail
               outright, whining about an invalid argument to
assuan_sendfd().  Here:

[...]
fdpassing[22515]: assuan_sendfd failed: Invalid argument
FAIL: fdpassing
fdpassing[22549]: assuan_sendfd failed: Invalid argument
FAIL: fdpassing-socket.sh

               I can still _install_ it just fine, but this shows that
the utility of so doing is
               rather limited.

6) ntbTLS:  This seems to work correctly, but the `make check` step
doesn?t actually do anything,
            so it?s hard to really tell.

7) nPth:  I had to make some fairly extensive, if minor, changes to
make this work, due mainly to
          the age of my system.  They are collected in this patch:

--- old/src/npth.c 2024-02-05 03:09:26 -0800
+++ new/src/npth.c 2024-10-31 11:18:20 -0700
@@ -63,7 +63,41 @@
   return 0;
 }
 #else
-# include <semaphore.h>
+# ifdef __MAC_10_0  /* i.e., if we?re on a Mac at all */
+   /* As noted above, Mac OS only partially implements POSIX semaphores
+      ? but Grand Central Dispatch only exists from Mac OS 10.6 onward.
+      This glue is for older versions of Mac OS.  (Only tested on 10.5.)
+    */
+#  include <CoreServices/CoreServices.h>
+#  include <CarbonCore/Multiprocessing.h>
+   typedef MPSemaphoreID sem_t;
+
+   static int
+   sem_init (sem_t *sem, int is_shared, unsigned int value)
+   {
+     (void)is_shared;
+     if (MPCreateSemaphore ((MPSemaphoreCount)UINT_MAX,
(MPSemaphoreCount)value, sem) == noErr)
+       return 0;
+     else
+       return -1;
+   }
+
+   static int
+   sem_post (sem_t *sem)
+   {
+     MPSignalSemaphore (*sem);
+     return 0;
+   }
+
+   static int
+   sem_wait (sem_t *sem)
+   {
+     MPWaitOnSemaphore (*sem, kDurationForever);
+     return 0;
+   }
+# else
+#  include <semaphore.h>
+# endif
 #endif
 #ifdef HAVE_UNISTD_H
 # include <unistd.h>

          I also had to add a couple of `-F` flags to the compiler
command line to tell it what
          system frameworks to include:

-F/System/Library/Frameworks/CoreServices
-F/System/Library/Frameworks/CoreServices.framework/Frameworks

          It?s likely that a more concise way of putting that exists,
but this worked.

8) Pinentry:  As with ntbTLS, this _looks_ OK, but since the `make
check` step doesn?t do anything,
              you can?t really tell.  The configuration step also
appears to have missed the
              presence of X11 in the system, but it?s unclear whether
that would actually affect
              anything in the absence of GTK et sim.

9) GPGME:  I can?t get this to build the Python 3 bindings, because it
uses setup.py ? which has
           been deprecated to the point of unuseability.  Even if that
part WAS doing what it is
           meant to do, it looks like it still wouldn?t work; the Make
script which cycles through
           the list of Pythons that were located fails to properly
switch between them, so that it
           builds a working directory for each version but only
actually compiles anything into the
           first one.  (It?s hard to tell, but that might be SWIG?s
fault.  I don?t understand the
           process well enough to diagnose it properly; there?s a lot
of black magic going on while
           setup.py is executing, assuming of course that you?re
running a Python obsolete enough
           it _will_ deign to execute.  I can state authoratively that
under Python 3.10 it refuses
           to, and rather loudly at that.)

           In addition to those woes, `make check` fails outright in a
number of respects.  The
           stage that tests GPGSM fails 7 out of 9 tests, for reasons
I cannot make sense of, and
           the Python bindings don?t test correctly because it?s
looking in the wrong place for
           some of the files under Python 2.7, and as aforementioned,
nothing gets built in the
           first place under Python 3.10.  If you work around that by
copying the Python 2.7
           extension into the Python 3.10 directory, it still fails to
test properly; it tries to
           load `gpg.py` but doesn?t find it.

           Unsurprisingly, `make install` fails due to the Python
bindings not being as expected,
           and also of course due to `setup.py` being called directly
which Python 3.10 refuses to
           tolerate.

I hope this all is at least vaguely useful to soemone.

Sincerely,
Gordon Steemson

-- 
The world?s only gsteemso


From wk at gnupg.org  Wed Nov  6 11:23:07 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Nov 2024 11:23:07 +0100
Subject: Things I had to do to make GnuPG et al compile
In-Reply-To: <CABKoxZq6crWMdBq3km6mzzL2CgDc9bRB0A003QXgsfLRrSoa2Q@mail.gmail.com>
 (Gordon Steemson via Gnupg-devel's message of "Tue, 5 Nov 2024
 20:20:17 -0800")
References: <CABKoxZq6crWMdBq3km6mzzL2CgDc9bRB0A003QXgsfLRrSoa2Q@mail.gmail.com>
Message-ID: <87msicoe44.fsf@jacob.g10code.de>

Hi!

Thanks for the detailed writeup.

On Tue,  5 Nov 2024 20:20, Gordon Steemson said:

> build system was a Power Mac G5 running Mac OS 10.5.8, and the
> compiler was Apple?s version of GCC
> 4.2.1 (mainly because it supports ?universal?, i.e. multi?platform,

That seems to be an old system but we have had always reports of
building GnuPG versions for all macOS versions without the need for code
changes (expect for minor bugs we fixed soon after the report).

I do not known whether Apple'ss gcc 4.2 is the part of XCode or if this
is an alternative toolchain.  Regarding universal binaries we have this
in the README of GnuPG *1.4*:

    Building Universal Binaries on Apple OS X
    -----------------------------------------

    You can build a universal ("fat") binary that will work on both
    PPC and Intel Macs with something like:

    ./configure CFLAGS="-arch ppc -arch i386" --disable-endian-check \
		--disable-dependency-tracking --disable-asm

    If you are doing the build on a OS X 10.4 (Tiger) PPC machine you
    may need to add "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" to
    those CFLAGS.  This additional isysroot is not necessary on Intel
    Tiger boxes, or any OS X 10.5 (Leopard) or later boxes.

> support software (such as cURL,
>            OpenSSH, and ld), I had to write the following patch:

GnuPG does not use OpenSSL or cURL.  Which version of GnuPG are you
trying to build?  Some bit rot for old macOS versions may of course
happened.

Maybe someone of the otehr macOS folks can shed some light on the
reported problems.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241106/af1e8523/attachment.sig>

From wk at gnupg.org  Fri Nov  8 08:31:33 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 08 Nov 2024 08:31:33 +0100
Subject: [patch] two typo fixes found by lintian
In-Reply-To: <6117997.u5xhZ7jtQd@jason> (Paul Boddie via Gnupg-devel's message
 of "Mon, 04 Nov 2024 22:53:40 +0100")
References: <Zyj8iA_firiO7LmV@argenau.bebt.de>
 <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de>
 <Zykp4mGTIFXAqyrU@argenau.bebt.de> <6117997.u5xhZ7jtQd@jason>
Message-ID: <87a5eambai.fsf@jacob.g10code.de>

On Mon,  4 Nov 2024 22:53, Paul Boddie said:

> Of course, one could also suggest the following:
>
> "Do not import secret keys."

I'll take this.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241108/b428da38/attachment.sig>

From yasu at utahime.org  Tue Nov 12 18:23:26 2024
From: yasu at utahime.org (Yasuhiro Kimura)
Date: Wed, 13 Nov 2024 02:23:26 +0900 (JST)
Subject: --enable-gpg-is-gpg2 option of configure is broken with 2.4.6
Message-ID: <20241113.022326.1616222758583835861.yasu@utahime.org>

Hello,

--enable-gpg-is-gpg2 option of configure is broken with 2.4.6. If the
script is invoked with the option, then `make install` fails as
following.

make[4]: Entering directory '/usr0/tmp/gnupg-2.4.6/doc'
incd="`test -f defsincdate || echo './'`defsincdate"; \
for file in gnupg7.texi gpg.texi gpgsm.texi gpg-agent.texi dirmngr.texi scdaemon.texi tools.texi wks.texi gpg-card.texi; do \
              ./yat2m  -I . --release "GnuPG 2.4.6" --source "GNU Privacy Guard 2.4" --store \
                  --date "`cat $incd 2>/dev/null`" \
          `test -f '$file' || echo './'`$file ; \
              ./yat2m  -I . --release "GnuPG 2.4.6" --source "GNU Privacy Guard 2.4" --store --html --gnupgorg \
                  --date "`cat $incd 2>/dev/null`" \
          `test -f '$file' || echo './'`$file ;\
        done
yat2m: writing 'gnupg.7'
yat2m: writing 'gnupg.7'
yat2m: writing 'gpg2.1'
yat2m: writing 'gpg2.1'
yat2m: writing 'gpgsm.1'
yat2m: writing 'gpgsm.1'
yat2m: writing 'gpg-agent.1'
yat2m: writing 'gpg-agent.1'
yat2m: writing 'dirmngr.8'
yat2m: writing 'dirmngr.8'
yat2m: writing 'scdaemon.1'
yat2m: writing 'scdaemon.1'
yat2m: writing 'watchgnupg.1'
yat2m: writing 'gpgv2.1'
yat2m: writing 'addgnupghome.8'
yat2m: writing 'gpgconf.1'
yat2m: writing 'applygnupgdefaults.8'
yat2m: writing 'gpg-preset-passphrase.1'
yat2m: writing 'gpg-connect-agent.1'
yat2m: writing 'dirmngr-client.1'
yat2m: writing 'gpgparsemail.1'
yat2m: writing 'gpgtar.1'
yat2m: writing 'gpg-mail-tube.1'
yat2m: writing 'gpg-check-pattern.1'
yat2m: writing 'watchgnupg.1'
yat2m: writing 'gpgv2.1'
yat2m: writing 'addgnupghome.8'
yat2m: writing 'gpgconf.1'
yat2m: writing 'applygnupgdefaults.8'
yat2m: writing 'gpg-preset-passphrase.1'
yat2m: writing 'gpg-connect-agent.1'
yat2m: writing 'dirmngr-client.1'
yat2m: writing 'gpgparsemail.1'
yat2m: writing 'gpgtar.1'
yat2m: writing 'gpg-mail-tube.1'
yat2m: writing 'gpg-check-pattern.1'
yat2m: writing 'gpg-wks-client.1'
yat2m: writing 'gpg-wks-server.1'
yat2m: writing 'gpg-wks-client.1'
yat2m: writing 'gpg-wks-server.1'
yat2m: writing 'gpg-card.1'
yat2m: writing 'gpg-card.1'
make[4]: Leaving directory '/usr0/tmp/gnupg-2.4.6/doc'
 /bin/mkdir -p '/usr0/tmp/gnupg/usr/local/share/man/man1'
 /bin/install -c -m 644 ./gpg.1 ./gpgv.1 gpgsm.1 gpg-agent.1 scdaemon.1 watchgnupg.1 gpgconf.1 gpg-preset-passphrase.1 gpg-connect-agent.1 gpgparsemail.1 gpgtar.1 gpg-mail-tube.1 gpg-wks-client.1 gpg-wks-server.1 dirmngr-client.1 gpg-card.1 gpg-check-pattern.1 '/usr0/tmp/gnupg/usr/local/share/man/man1'
/bin/install: cannot stat './gpg.1': No such file or directory
/bin/install: cannot stat './gpgv.1': No such file or directory
make[3]: *** [Makefile:725: install-man1] Error 1
make[3]: Leaving directory '/usr0/tmp/gnupg-2.4.6/doc'
make[2]: *** [Makefile:999: install-am] Error 2
make[2]: Leaving directory '/usr0/tmp/gnupg-2.4.6/doc'
make[1]: *** [Makefile:992: install] Error 2
make[1]: Leaving directory '/usr0/tmp/gnupg-2.4.6/doc'
make: *** [Makefile:631: install-recursive] Error 1

And attacheed patch fixes the issue.

Regards.

---
Yasuhiro Kimura
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg.patch
Type: text/x-patch
Size: 1563 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241113/8c13d7b2/attachment-0001.bin>

From gsteemso at gmail.com  Wed Nov 13 21:37:04 2024
From: gsteemso at gmail.com (Gordon Steemson)
Date: Wed, 13 Nov 2024 12:37:04 -0800
Subject: Things I had to do to make GnuPG et al compile
In-Reply-To: <87msicoe44.fsf@jacob.g10code.de>
References: <87msicoe44.fsf@jacob.g10code.de>
Message-ID: <C6303BAC-A874-485A-BBE0-3A8AF9B3D0AD@gmail.com>


My apologies, I have only just discovered that my reply to this had gone only to Werner and not to the mailing list.

Probably the single most important "this needs addressing" aspect of my report was the part about Python 3 integration.  As currently shipped it _cannot_ work, in a way completely unrelated to the newness or oldness of my machine and OS.  To re?terate:  GPGME invokes "setup.py" directly, which is now so heavily deprecated that it straight up doesn't work under Python 3.10.  Also, something about the process that steps through the various Pythons it locates (in order to correctly compile the bindings against each one) is not working, such that it creates a directory structure for each Python (in which to build the libraries), but only actually uses the first one.  Interestingly, copying the files thus compiled into the other directories in order to pretend it worked correctly does allow installation to proceed, and even seems to execute correctly with the wrong Python... I wouldn't want to trust that for anything critical, though.  I suspect there are important differences between extensions built for Python 2.7 vs. 3.10 or you wouldn't have bothered going to all that trouble in the first place.

> On Nov 6, 2024, at 2:21?AM, Werner Koch <wk at gnupg.org> wrote:
> 
> Thanks for the detailed writeup.

My pleasure!  I only hope it is useful in some way.

> On Tue,  5 Nov 2024 20:20, Gordon Steemson said:
> 
> I do not known whether Apple'ss gcc 4.2 is the part of XCode or if this
> is an alternative toolchain.

It was the compiler used by Xcode before Clang was developed, and is contemporary with the system.

>  Regarding universal binaries we have this
> in the README of GnuPG *1.4*:
> 
>    Building Universal Binaries on Apple OS X
[snip]

Yes, I know, that's part of why I was using that compiler instead of building a newer one first.  That part works fine.

Actually, the fact that part works fine is worthy of effusive praise!  Many projects out there seem to insist on recording the bit width of various integer types as constants during their ./configure step, which causes chaos in a universal binary because during such a build, longs and pointers are each both 32 and 64 bits wide at the same time (as controlled by conditional compilation on __LP64__).  GnuPG does not suffer from this problem, which saves *SO* much trouble it's not even funny.

>> support software (such as cURL,
>>           OpenSSH, and ld), I had to write the following patch:
> 
> GnuPG does not use OpenSSL or cURL.  Which version of GnuPG are you
> trying to build?  Some bit rot for old macOS versions may of course
> happened.

Yes, I know it doesn't, at least not directly.  I was building the latest release from the website.  I honestly don't recall what it was that a newer cURL helped with ? it may have been something else I was doing at the same time, for all I can tell without it in front of me (I am on my lunch break at work).

That said, it definitely does use OpenSSH (not OpenSSL) during one of the "make check" tests, though as you point out not in the actual program itself.  (It gave me a good surprise when that popped up; apparently whatever it was doing needed a more recent OpenSSH than the version current in 2005.  For obvious reasons that was not a thing I consider worthy of a bug report, merely a passing observation.)

> Maybe someone of the otehr macOS folks can shed some light on the
> reported problems.

That would be good.  Does anyone out there want to weigh in on this?

Gordon Steemson



From wiktor at metacode.biz  Thu Nov 14 09:29:40 2024
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 14 Nov 2024 09:29:40 +0100
Subject: Question about the adjustment of MPI values on gpg --import
Message-ID: <0e4e8bd3-1fa5-42a5-a87c-401348de931b@metacode.biz>

Hello,

I've got a question about handling of certain keys.

I've noticed that GnuPG on import "adjusts" some MPIs but if my reading 
of the spec is correct the adjustments breaks the spec alignment.

I managed to find a key where the last MPI (the S value of the EdDSA 
signature) has a high bit set:

$ gpg --dearmor < ee.asc | xxd | tail -n 4
000006d0: eab4 2954 a0a9 eeaa 19fb 45e4 62b2 78e1  ..)T......E.b.x.
000006e0: ebdd 196f ae00 f8fa 84f1 fdc7 c908 7ddb  ...o..........}.
000006f0: 0419 0dbb a934 ac0b d117 3b77 157c 5279  .....4....;w.|Ry
00000700: 05cc c5db c20f                           ......

Here, the length is "00 f8" and is followed by these bytes:

fa 84f1 fdc7 c908 7ddb 0419 0dbb a934 ac0b d117 3b77 157c 5279 05cc c5db 
c20f

The first byte has a leading non-zero bit:

 > 0xfa.toString(2)
'11111010'

So the length of the entire MPI is (in bits):

 > 'fa 84f1 fdc7 c908 7ddb 0419 0dbb a934 ac0b d117 3b77 157c 5279 05cc 
c5db c20f'.replace(/ +/g, '').length*4
248

That converted to hex gives us 0xf8.

Now, when the key gets imported and then exported the final field gets 
extended with a leading zero byte *and* the MPI length is set to "01 00" 
(256 in decimal).

$ gpg --export 4813CD31D15CC912 | xxd | tail -n 3
00000640: aa19 fb45 e462 b278 e1eb dd19 6fae 0100  ...E.b.x....o...
00000650: 00fa 84f1 fdc7 c908 7ddb 0419 0dbb a934  ........}......4
00000660: ac0b d117 3b77 157c 5279 05cc c5db c20f  ....;w.|Ry......

The rest of the MPI is left as it was. I think the additional zero byte 
is not that problematic (the spec doesn't seem to say in one way or 
another; the additional zero reminds me of the ASN.1 encoding...). But 
the spec is very clear that the length should be counted from the first 
non-zero bit and from my understanding it seems the length erroneously 
included the zero byte:

  > The length field of an MPI describes the length starting from its 
most significant non-zero bit. Thus, the MPI [00 02 01] is not formed 
correctly. It should be [00 01 01].

https://www.ietf.org/archive/id/draft-koch-librepgp-02.html#section-3.2

I'm not sure if I'm holding it wrong but before I submit a but report 
I'd like to hear your input if this looks like a bug or not. The test 
key is attached to this e-mail.

Thanks for your time and have a nice day!

Kind regards,
Wiktor
-------------- next part --------------
-----BEGIN PGP PRIVATE KEY BLOCK-----
Comment: EEFE 02C7 97AF C775 558D  A3BA 4813 CD31 D15C C912
Comment: foobar <foo at bar.xyz>

xVgEZzSiihYJKwYBBAHaRw8BAQdAjhs33uTNij023aLf8ylLwb7ecdKybZF6LsRi
sBx4eHEAAP4vcGDDVRn49+qH9flKhALQiQdVu8ZbwmXPry9h72C+jxKuwsARBB8W
CgCDBYJnNKKKBYkFpI+9AwsJBwkQSBPNMdFcyRJHFAAAAAAAHgAgc2FsdEBub3Rh
dGlvbnMuc2VxdW9pYS1wZ3Aub3JnrCMmsRx8d9HsrVGYq37VQUfiPvEedyd+q7xA
JI2HyxADFQoIApsBAh4BFiEE7v4Cx5evx3VVjaO6SBPNMdFcyRIAAErMAQCLnWg5
zpCC13rcj6lciHeQDGZ6WrsfdBoqQwj7u0c+1QD/XNDoCqVX/TrfWp0M4y5K55vX
XpvCWVazcSVG+ptS1gLNFGZvb2JhciA8Zm9vQGJhci54eXo+wsAUBBMWCgCGBYJn
NKKKBYkFpI+9AwsJBwkQSBPNMdFcyRJHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMu
c2VxdW9pYS1wZ3Aub3JnLC3U2UC0qdUXwFgJ3dw2ZUjJ9IoP6HTvJsLnWqhSw+4D
FQoIApkBApsBAh4BFiEE7v4Cx5evx3VVjaO6SBPNMdFcyRIAACzdAQD27HKtxxPV
LkhxXo51nTYFIW0f8TMT7HUIN+apHsxZQQD+KSiIty4p3VU+bds59Onz/UDTOa3/
kO4awlt4O3CEIAbHWARnNKKKFgkrBgEEAdpHDwEBB0A7xcGxFIU8rqSIL19f+bHM
JH19vZdDSVxdPn/vnJqMjAABAOel8BRs2CRFs6FIhE2izBrG0tLXwHsRQCJqEoZ1
mhgKD1XCwMUEGBYKATcFgmc0oooFiQWkj70JEEgTzTHRXMkSRxQAAAAAAB4AIHNh
bHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZxxYfEyDiuvSarUsnGm0vhLUkFkA
q7xUkpbXiWQ6K8X2ApsgvqAEGRYKAG8Fgmc0oooJEHCmvUYf8ZaQRxQAAAAAAB4A
IHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZ7Me7c6JZ8pmY6Ul9O04CL40
Q/b9fVhe30TGfo92/YnGFiEEAMexfFG1rq5i9RTMcKa9Rh/xlpAAAAi0AP9Ggjl3
BAqin5uJqs1EMYd8NFgnjvYFGcpyNvCY1RpK6AEAsFnhABAOsSXaAGXvAR4Mq5Zd
Ll+2g2oQfEYYiCB+fgYWIQTu/gLHl6/HdVWNo7pIE80x0VzJEgAAhAEBAORuiKkv
kThV7XsU8sTH4+0Q6jFkeeBtan7iyGcke4heAQCi3+upKwXZKlGPv/5BgCmP/RTh
4eu4pgAbDY+hwWwkB8dYBGc0oooWCSsGAQQB2kcPAQEHQEpuB6tqGgDc8EizPy3r
0ipvzXGEX/ogWmkEZ0yMpnfqAAD7BCazP8ZhFeaGrERevgm4UTT0UCCxgtkZmQqr
9FB1h2EPicLAxQQYFgoBNwWCZzSiigWJBaSPvQkQSBPNMdFcyRJHFAAAAAAAHgAg
c2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnv2Itxz+I6Wbx4gH/XwqwgTX0
TfiLduO6YdhL+QAHG8kCmwK+oAQZFgoAbwWCZzSiigkQDbLGCCtLsLZHFAAAAAAA
HgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnJXi9RWyBrWVqlTpPLwlV
zrEe/XryYnT8WNCukUeIwu0WIQS3HL1TC6231LgtOVoNssYIK0uwtgAAlQUBAM+4
dtKU6pr4st9Cf84aRnTTefqEKhi7/r6lSbTZe1EgAP97w4C9UsucyqiDa/cad2bj
W0OHMf95JlVbeOe9BY0yBBYhBO7+AseXr8d1VY2jukgTzTHRXMkSAADI8wEApLB0
o8t2jk7nojSsm44fBPe+eKs1NEko14aG0lU900oA/iZF51f+2xZWEtDueY5utZt+
rlucYxIDdXnGCSpKw7oLx10EZzSiihIKKwYBBAGXVQEFAQEHQIW6uKuk4sR5dEcc
PzK+t9gttOtj3oRaVYV0hXOc6Aw/AwEIBwAA/2OjmVgzib9/x8E4572SiXUfzn5c
C2GrTrJeWOWX+IWoEhnCwAUEGBYKAHgFgmc0oooFiQWkj70JEEgTzTHRXMkSRxQA
AAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZ6GfpchuhbxBSupd
fuRxIVdPKs4yYh1QGE4Y8nm/l7x4ApsMFiEE7v4Cx5evx3VVjaO6SBPNMdFcyRIA
ABDfAP0TxqDv9KhatU0V7eq0KVSgqe6qGftF5GKyeOHr3RlvrgD4+oTx/cfJCH3b
BBkNu6k0rAvRFzt3FXxSeQXMxdvCDw==
=4Aya
-----END PGP PRIVATE KEY BLOCK-----

From ametzler at bebt.de  Sun Nov 17 18:01:25 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 17 Nov 2024 18:01:25 +0100
Subject: please push libgpg-error 1.51 tag
Message-ID: <ZzohZd8VQk627HZX@argenau.bebt.de>

Hello,

libgpg-error seems to have been released but the tag has not yet been
pushed.

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From wk at gnupg.org  Mon Nov 18 08:47:01 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 18 Nov 2024 08:47:01 +0100
Subject: please push libgpg-error 1.51 tag
In-Reply-To: <ZzohZd8VQk627HZX@argenau.bebt.de> (Andreas Metzler's message of
 "Sun, 17 Nov 2024 18:01:25 +0100")
References: <ZzohZd8VQk627HZX@argenau.bebt.de>
Message-ID: <877c91j85m.fsf@jacob.g10code.de>

On Sun, 17 Nov 2024 18:01, Andreas Metzler said:
> libgpg-error seems to have been released but the tag has not yet been
> pushed.

Done.  Thanks for the reminder.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241118/3427330d/attachment.sig>

From dkg at fifthhorseman.net  Mon Nov 18 22:33:24 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 18 Nov 2024 16:33:24 -0500
Subject: Question about the adjustment of MPI values on gpg --import
In-Reply-To: <0e4e8bd3-1fa5-42a5-a87c-401348de931b@metacode.biz>
References: <0e4e8bd3-1fa5-42a5-a87c-401348de931b@metacode.biz>
Message-ID: <87serorzvf.fsf@fifthhorseman.net>

On Thu 2024-11-14 09:29:40 +0100, Wiktor Kwapisiewicz via Gnupg-devel wrote:

> I've noticed that GnuPG on import "adjusts" some MPIs but if my reading 
> of the spec is correct the adjustments breaks the spec alignment.

I've replicated Wiktor's results with GnuPG 2.4.6, but they are *not*
happening with 2.2.45.

I've reported this to the issue tracker here, with an additional reproducer:

   https://dev.gnupg.org/T7403

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241118/2f55dd19/attachment.sig>

From wiktor at metacode.biz  Wed Nov 20 09:10:29 2024
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 20 Nov 2024 09:10:29 +0100
Subject: Question about the adjustment of MPI values on gpg --import
In-Reply-To: <87zflupdj4.fsf@akagi.fsij.org>
References: <0e4e8bd3-1fa5-42a5-a87c-401348de931b@metacode.biz>
 <87serorzvf.fsf@fifthhorseman.net> <87zflupdj4.fsf@akagi.fsij.org>
Message-ID: <6118d871-54c9-47d3-95f5-ed59c3554310@metacode.biz>

On 20.11.2024 08:31, NIIBE Yutaka wrote:
> At that time, my intention was introducing Ed448 and X448 and making the
> things aligned (while the specification for EdSOMETHING for OpenPGP was
> not yet finished).  My intention was interoperability actually, but
> alas, opposite outcome.

Thanks for the explanation, Niibe. I understand your intention now.

Alternative design (which sadly wouldn't be backwards compatible) would 
be to avoid the MPI altogether and just have a fixed size field:

https://www.rfc-editor.org/rfc/rfc9580#name-algorithm-specific-fields-for-ed2

I'm just noting that for completeness, not suggesting you do that :)

Thanks again and have a nice day!

Kind regards,
Wiktor



From gniibe at fsij.org  Wed Nov 20 08:31:11 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 20 Nov 2024 16:31:11 +0900
Subject: Question about the adjustment of MPI values on gpg --import
In-Reply-To: <87serorzvf.fsf@fifthhorseman.net>
References: <0e4e8bd3-1fa5-42a5-a87c-401348de931b@metacode.biz>
 <87serorzvf.fsf@fifthhorseman.net>
Message-ID: <87zflupdj4.fsf@akagi.fsij.org>

Daniel Kahn Gillmor wrote:
> On Thu 2024-11-14 09:29:40 +0100, Wiktor Kwapisiewicz via Gnupg-devel wrote:
>
>> I've noticed that GnuPG on import "adjusts" some MPIs but if my reading 
>> of the spec is correct the adjustments breaks the spec alignment.
>
> I've replicated Wiktor's results with GnuPG 2.4.6, but they are *not*
> happening with 2.2.45.
>
> I've reported this to the issue tracker here, with an additional reproducer:
>
>    https://dev.gnupg.org/T7403

Thank you for creating the ticket.

IIUC, it's my badness/failure/embugment/something-negative for:
https://dev.gnupg.org/T4954

At that time, my intention was introducing Ed448 and X448 and making the
things aligned (while the specification for EdSOMETHING for OpenPGP was
not yet finished).  My intention was interoperability actually, but
alas, opposite outcome.

I'll continue on T7403.

Thank you for the reproducer, it's helpful.
--