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: 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: 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: (Andreas Metzler's message of "Mon, 4 Nov 2024 17:55:36 +0100") References: 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: 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: <87ttcnorjz.fsf@jacob.g10code.de> Message-ID: On 2024-11-04 Werner Koch 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: <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: <87ttcnorjz.fsf@jacob.g10code.de> <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de> Message-ID: On 2024-11-04 Bernhard Voelker 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: References: <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de> Message-ID: <6117997.u5xhZ7jtQd@jason> On Monday, 4 November 2024 21:09:06 CET Andreas Metzler wrote: > On 2024-11-04 Bernhard Voelker 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: <87ttcnorjz.fsf@jacob.g10code.de> <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.de> Message-ID: On 2024-11-04 Bernhard Voelker 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: 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 #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 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 #endif #include +#include #include #include @@ -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 #include #if defined(__APPLE__) && defined(__MACH__) +#ifdef __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1050 #include +#endif +#endif #ifdef __MAC_10_11 #include #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 +# 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 +# include + 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 +# endif #endif #ifdef HAVE_UNISTD_H # include 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: (Gordon Steemson via Gnupg-devel's message of "Tue, 5 Nov 2024 20:20:17 -0800") References: 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: 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: <6009f630-57ca-4c28-a74e-047559058a8f@bernhard-voelker.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: 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: 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: 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 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 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: 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: (Andreas Metzler's message of "Sun, 17 Nov 2024 18:01:25 +0100") References: 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: 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: 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. -- From lists at sapience.com Thu Nov 21 19:19:13 2024 From: lists at sapience.com (Genes Lists) Date: Thu, 21 Nov 2024 13:19:13 -0500 Subject: git server down? Message-ID: <5a7bc1900345bcb9b97e92efbff1d6d6ff27ba78.camel@sapience.com> FYI - looks down from where I am: ??https://dev.gnupg.org/source/gnupg.git -- Gene -------------- 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 alexander at kulbartsch.de Thu Nov 21 20:52:59 2024 From: alexander at kulbartsch.de (Alexander Kulbartsch) Date: Thu, 21 Nov 2024 20:52:59 +0100 Subject: git server down? In-Reply-To: <5a7bc1900345bcb9b97e92efbff1d6d6ff27ba78.camel@sapience.com> References: <5a7bc1900345bcb9b97e92efbff1d6d6ff27ba78.camel@sapience.com> Message-ID: <72377d0a-7af1-40e9-bc91-8b123152bcd5@kulbartsch.de> On 21.11.24 19:19, Genes Lists via Gnupg-devel wrote: > git server down? > https://dev.gnupg.org/source/gnupg.git Yes. Heavy scraping DOSed the server. Hopefully it'll be back up tomorrow. You can get the latest releases from here: https://gnupg.org/download/index.html -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x213E2CD3CABCF0B9.asc Type: application/pgp-keys Size: 681 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 wk at gnupg.org Fri Nov 22 14:52:52 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Nov 2024 14:52:52 +0100 Subject: [PATCH v1] gpgconf: Fix off-by-one bug In-Reply-To: <46a2497e9fb857b5006a78dfb4a1a3d5fa37be0a.1732217360.git.alx@kernel.org> (Alejandro Colomar's message of "Thu, 21 Nov 2024 20:30:44 +0100") References: <46a2497e9fb857b5006a78dfb4a1a3d5fa37be0a.1732217360.git.alx@kernel.org> Message-ID: <87a5dr8jez.fsf@jacob.g10code.de> On Thu, 21 Nov 2024 20:30, Alejandro Colomar said: > There's nothing using that extra +1, or I'm not seeing it. Better safe than sorry. Are you sure that all Unices implement getgroup correctly? 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 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