From kaie at kuix.de Wed Feb 1 17:13:19 2023 From: kaie at kuix.de (Kai Engert) Date: Wed, 1 Feb 2023 17:13:19 +0100 Subject: Interoperability with OpenPGP crypto-refresh Message-ID: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> Hello, I'm working on the Thunderbird email client and its email encryption functionality, which currently includes OpenPGP (using RNP) and S/MIME (using NSS). In my understanding, the OpenPGP working group intends to publish a refreshed version of the OpenPGP Internet standard. Based on the discussions on that list, I got the impression that multiple groups were able to reach consensus on evolving the OpenPGP specification. However, IIUC the GnuPG developers have concerns about the changes that are being considered in that specifications, and IIUC there is some uncertainty what this could mean for the future of the GnuPG software. I'd kindly like to ask: Does the GnuPG development team consider it a goal for future GnuPG software releases to preserve compatibility and interoperability when exchanging messages with other implementations of OpenPGP, such as implementations of the upcoming IETF specification? The reason why I'm asking: I'd like to understand if it will be possible for Thunderbird to exchange OpenPGP messages with both GnuPG and implementations of the upcoming IETF specification, using a single OpenPGP message format. Thanks and Regards Kai From wk at gnupg.org Wed Feb 1 18:40:27 2023 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Feb 2023 18:40:27 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> (Kai Engert via Gnupg-devel's message of "Wed, 1 Feb 2023 17:13:19 +0100") References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> Message-ID: <87wn51z3lg.fsf@wheatstone.g10code.de> Hi Kai, On Wed, 1 Feb 2023 17:13, Kai Engert said: > specification. However, IIUC the GnuPG developers have concerns about > the changes that are being considered in that specifications, and IIUC No, we have no concerns we will simply not implement the recently heavily changed "crypto refresh". These changes were done despite that the two major OpenPGP implementations had deployed the rfc4880bis (aka ?old crypto refresh?) changes years ago after having done interop testing between these implementations. In fact we deployed the code in the common and long tested way of first having the changes in the read-part deployed and only later to enable the write-part of the changes. The recent changes in the ?new crypto refresh? introduced a new level of complexity mainly to support the fragile and easy to get wrong GCM encryption mode. There is already now no more need for GCM because the patent on the way better and more secure OCB mode has been waived. Even for years royalty free licenses were granted in almost all domains and for all open source implementations for the OCB mode. Which GnuPG and RNP deployed years ago. Complexity is the worst enemy of security and OpenPGP is already complex enough. It is a Bad Idea to add extra complexity in whatever form. I strongly advise not to follow the path the IETF OpenPGP design committee has taken recently. The X.509 committee designed trouble should be enough of historic evidence to be warned. 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: 227 bytes Desc: not available URL: From kaie at kuix.de Wed Feb 1 19:42:38 2023 From: kaie at kuix.de (Kai Engert) Date: Wed, 1 Feb 2023 19:42:38 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <87wn51z3lg.fsf@wheatstone.g10code.de> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> Message-ID: <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> Hi Werner, On 01.02.23 18:40, Werner Koch wrote: > > No, we have no concerns we will simply not implement the recently > heavily changed "crypto refresh". thanks a lot for your quick reply and for your unambiguous statement. IIUC, RFC 4880bis contains specifications that are incompatible with the intended IETF OpenPGP crypto-refresh, such as v5 keys. Does that mean, if Thunderbird wants to remain compatible with all major implementations, then Thunderbird must stay at the functional level of RFC 4880, and must not use any functionality from newer specifications, neither from the upcoming IETF crypto-refresh, nor items that were added in RFC 4880bis on top of RFC 4880? Thanks and Regards, Kai From bwalzer at 59.ca Thu Feb 2 05:19:21 2023 From: bwalzer at 59.ca (Bruce Walzer) Date: Wed, 1 Feb 2023 22:19:21 -0600 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> Message-ID: On Wed, Feb 01, 2023 at 07:42:38PM +0100, Kai Engert via Gnupg-devel wrote: [...] > Does that mean, if Thunderbird wants to remain compatible with all major > implementations, then Thunderbird must stay at the functional level of RFC > 4880, and must not use any functionality from newer specifications, neither > from the upcoming IETF crypto-refresh, nor items that were added in RFC > 4880bis on top of RFC 4880? That sounds like a reasonable approach to me. Sometimes consensus can not be reached. Then changes are not really possible or practical. What exactly would the downside for Thunderbird be here? There certainly doesn't seem to be any huge crisis at this point in time. Perhaps another attempt can be made in 5 years or so with a better controlled process. The issues might be better defined by then and the focus would be sharper. Bruce From demiobenour at gmail.com Thu Feb 2 07:16:19 2023 From: demiobenour at gmail.com (Demi Marie Obenour) Date: Thu, 2 Feb 2023 01:16:19 -0500 Subject: [PATCH GnuPG] Fix handling of I/O errors Message-ID: <886b211e-e315-7804-3b6f-66abf81be37a@gmail.com> Errors writing to stdout, stderr, or the status file must result in a non-zero status code. Also BUG() if a CR or LF would be injected into the status stream, escape bytes above 126, add a log_assert(), check the return value of snprintf(), and escape backslashes in write_status_printf(). Finally, ensure that errors writing to the status file cause all status output to stop immediately. GnuPG-bug-id: T6185 Signed-off-by: Demi Marie Obenour --- g10/cpr.c | 188 ++++++++++++++++++++++++++++++++++++----------------- g10/gpg.c | 3 + g10/gpgv.c | 2 + g10/main.h | 1 + 4 files changed, 134 insertions(+), 60 deletions(-) diff --git a/g10/cpr.c b/g10/cpr.c index 79eff314375f07380f7752736ddf2613dbe8b378..f60c745bf98a6536aa048f2685ef3341664b4bb8 100644 --- a/g10/cpr.c +++ b/g10/cpr.c @@ -49,14 +49,17 @@ progress_cb (void *ctx, const char *what, int printchar, int current, int total) { char buf[50]; + int res; (void)ctx; if ( printchar == '\n' && !strcmp (what, "primegen") ) - snprintf (buf, sizeof buf, "%.20s X 100 100", what ); + res = snprintf (buf, sizeof buf, "%.20s X 100 100", what ); else - snprintf (buf, sizeof buf, "%.20s %c %d %d", - what, printchar=='\n'?'X':printchar, current, total ); + res = snprintf (buf, sizeof buf, "%.20s %c %d %d", + what, printchar=='\n'?'X':printchar, current, total ); + if ((unsigned)res >= sizeof buf) + abort(); write_status_text (STATUS_PROGRESS, buf); } @@ -140,24 +143,41 @@ write_status ( int no ) write_status_text( no, NULL ); } +int +check_status_error (void) +{ + if (!statusfp) + return 0; + if (!es_fflush (statusfp) && !es_ferror(statusfp)) + return 0; + if (opt.exit_on_status_write_error) + g10_exit (1); + if (statusfp != es_stdout && statusfp != es_stderr) + es_fclose(statusfp); + statusfp = NULL; + return 1; +} /* Write a status line with code NO followed by the string TEXT and * directly followed by the remaining strings up to a NULL. Embedded - * CR and LFs in the strings (but not in TEXT) are C-style escaped.*/ + * CR and LFs in the strings and TEXT are C-style escaped.*/ void write_status_strings (int no, const char *text, ...) { va_list arg_ptr; const char *s; + int err = 0; if (!statusfp || !status_currently_allowed (no) ) return; /* Not enabled or allowed. */ - es_fputs ("[GNUPG:] ", statusfp); - es_fputs (get_status_string (no), statusfp); + if (es_fputs ("[GNUPG:] ", statusfp) || + es_fputs (get_status_string (no), statusfp)) + goto bad; if ( text ) { - es_putc ( ' ', statusfp); + if ( es_putc ( ' ', statusfp) != ' ' ) + goto bad; va_start (arg_ptr, text); s = text; do @@ -165,19 +185,24 @@ write_status_strings (int no, const char *text, ...) for (; *s; s++) { if (*s == '\n') - es_fputs ("\\n", statusfp); + err = es_fputs ("\\n", statusfp); else if (*s == '\r') - es_fputs ("\\r", statusfp); + err = es_fputs ("\\r", statusfp); + else if (*s == '\\') + err = es_fputs ("\\\\", statusfp); else - es_fputc (*(const byte *)s, statusfp); + err = es_fputc (*(const byte *)s, statusfp); + if (err == EOF) + goto bad; } } while ((s = va_arg (arg_ptr, const char*))); va_end (arg_ptr); } es_putc ('\n', statusfp); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); + +bad: + check_status_error(); } @@ -190,6 +215,7 @@ write_status_strings2 (ctrl_t dummy, int no, ...) { va_list arg_ptr; const char *s; + int err = 0; (void)dummy; @@ -198,29 +224,33 @@ write_status_strings2 (ctrl_t dummy, int no, ...) va_start (arg_ptr, no); - es_fputs ("[GNUPG:] ", statusfp); - es_fputs (get_status_string (no), statusfp); + if (es_fputs ("[GNUPG:] ", statusfp) || + es_fputs (get_status_string (no), statusfp)) + goto bad; while ((s = va_arg (arg_ptr, const char*))) { - if (*s) - es_putc (' ', statusfp); + if (*s && es_putc (' ', statusfp) != ' ') + goto bad; for (; *s; s++) { if (*s == '\n') - es_fputs ("\\n", statusfp); + err = es_fputs ("\\n", statusfp); else if (*s == '\r') - es_fputs ("\\r", statusfp); + err = es_fputs ("\\r", statusfp); + else if (*s == '\\') + err = es_fputs ("\\\\", statusfp); else - es_fputc (*(const byte *)s, statusfp); + err = es_fputc (*(const byte *)s, statusfp); + if (err == EOF) + goto bad; } } es_putc ('\n', statusfp); va_end (arg_ptr); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); - +bad: + check_status_error(); return 0; } @@ -239,45 +269,52 @@ write_status_printf (int no, const char *format, ...) { va_list arg_ptr; char *buf; + int err = 0; if (!statusfp || !status_currently_allowed (no) ) return; /* Not enabled or allowed. */ - es_fputs ("[GNUPG:] ", statusfp); - es_fputs (get_status_string (no), statusfp); + va_start (arg_ptr, format); + if (es_fputs ("[GNUPG:] ", statusfp) || + es_fputs (get_status_string (no), statusfp)) + goto bad; if (format) { - es_putc ( ' ', statusfp); - va_start (arg_ptr, format); + if (es_fputc ( ' ', statusfp ) != ' ') + goto bad; buf = gpgrt_vbsprintf (format, arg_ptr); if (!buf) - log_error ("error printing status line: %s\n", - gpg_strerror (gpg_err_code_from_syserror ())); + { + log_error ("error printing status line: %s\n", + gpg_strerror (gpg_err_code_from_syserror ())); + goto bad; + } else { - if (strpbrk (buf, "\r\n")) + if (strpbrk (buf, "\r\n\\")) { const byte *s; - for (s=buf; *s; s++) + for (s=buf; *s && err != EOF; s++) { if (*s == '\n') - es_fputs ("\\n", statusfp); + err = es_fputs ("\\n", statusfp); else if (*s == '\r') - es_fputs ("\\r", statusfp); + err = es_fputs ("\\r", statusfp); + else if (*s == '\\') + err = es_fputs ("\\\\", statusfp); else - es_fputc (*s, statusfp); + err = es_fputc (*s, statusfp); } } - else - es_fputs (buf, statusfp); + else if (es_fputs (buf, statusfp)) + goto bad; gpgrt_free (buf); } - - va_end (arg_ptr); } es_putc ('\n', statusfp); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); +bad: + check_status_error(); + va_end (arg_ptr); } @@ -288,10 +325,12 @@ write_status_error (const char *where, gpg_error_t err) if (!statusfp || !status_currently_allowed (STATUS_ERROR)) return; /* Not enabled or allowed. */ + if (!where || strpbrk(where, "\r\n")) + BUG(); + es_fprintf (statusfp, "[GNUPG:] %s %s %u\n", get_status_string (STATUS_ERROR), where, err); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); + check_status_error(); } @@ -302,10 +341,12 @@ write_status_errcode (const char *where, int errcode) if (!statusfp || !status_currently_allowed (STATUS_ERROR)) return; /* Not enabled or allowed. */ + if (!where || strpbrk(where, "\r\n")) + BUG(); + es_fprintf (statusfp, "[GNUPG:] %s %s %u\n", get_status_string (STATUS_ERROR), where, gpg_err_code (errcode)); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); + check_status_error(); } @@ -315,6 +356,9 @@ write_status_failure (const char *where, gpg_error_t err) { static int any_failure_printed; + if (!where || strpbrk(where, "\r\n")) + BUG(); + if (!statusfp || !status_currently_allowed (STATUS_FAILURE)) return; /* Not enabled or allowed. */ if (any_failure_printed) @@ -322,8 +366,7 @@ write_status_failure (const char *where, gpg_error_t err) any_failure_printed = 1; es_fprintf (statusfp, "[GNUPG:] %s %s %u\n", get_status_string (STATUS_FAILURE), where, err); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); + check_status_error(); } @@ -342,14 +385,19 @@ write_status_text_and_buffer (int no, const char *string, int lower_limit = ' '; size_t n, count, dowrap; - if (!statusfp || !status_currently_allowed (no)) - return; /* Not enabled or allowed. */ + if (string && strpbrk(string, "\r\n")) + BUG(); if (wrap == -1) { lower_limit--; wrap = 0; } + else if (wrap < 0) + BUG(); + + if (!statusfp || !status_currently_allowed (no) ) + return; /* Not enabled or allowed. */ text = get_status_string (no); count = dowrap = first = 1; @@ -357,16 +405,20 @@ write_status_text_and_buffer (int no, const char *string, { if (dowrap) { - es_fprintf (statusfp, "[GNUPG:] %s ", text); + if (es_fprintf (statusfp, "[GNUPG:] %s ", text) != strlen(text) + 10) + goto bad; count = dowrap = 0; if (first && string) { - es_fputs (string, statusfp); - count += strlen (string); + size_t size = strlen (string); + if (es_fwrite (string, 1, size, statusfp) != size) + goto bad; + count += size; /* Make sure that there is a space after the string. */ - if (*string && string[strlen (string)-1] != ' ') + if (*string && string[size-1] != ' ') { - es_putc (' ', statusfp); + if (es_putc (' ', statusfp) != ' ') + goto bad; count++; } } @@ -375,33 +427,38 @@ write_status_text_and_buffer (int no, const char *string, for (esc=0, s=buffer, n=len; n; s++, n--) { if (*s == '%' || *(const byte*)s <= lower_limit - || *(const byte*)s == 127 ) + || *(const byte*)s >= 127 ) esc = 1; if (wrap && ++count > wrap) dowrap=1; if (esc || dowrap) break; } - if (s != buffer) - es_fwrite (buffer, s-buffer, 1, statusfp); + log_assert(s >= buffer); + if (s != buffer && es_fwrite (buffer, 1, s-buffer, statusfp) != s-buffer) + goto bad; if ( esc ) { - es_fprintf (statusfp, "%%%02X", *(const byte*)s ); + if (es_fprintf (statusfp, "%%%02X", *(const byte*)s ) != 4) + goto bad; s++; n--; } buffer = s; len = n; if (dowrap && len) - es_putc ('\n', statusfp); + { + es_putc ('\n', statusfp); + if (check_status_error()) + return; + } } while (len); es_putc ('\n',statusfp); - if (es_fflush (statusfp) && opt.exit_on_status_write_error) - g10_exit (0); +bad: + check_status_error(); } - void write_status_buffer (int no, const char *buffer, size_t len, int wrap) { @@ -703,3 +760,14 @@ cpr_get_answer_okay_cancel (const char *keyword, } } } + +int +check_io_error (void) +{ + return 0; + opt.exit_on_status_write_error = 0; + if (es_fflush(es_stdout) || es_fflush(es_stderr) || + check_status_error() || es_ferror(es_stdin) || + es_ferror(es_stdout) || es_ferror(es_stderr)) + log_error("I/O error"); +} diff --git a/g10/gpg.c b/g10/gpg.c index b9a81510fc967eac557a9fceefbdcef481c11f3b..1982b39cc85a91dc867514b393bc0eb5139a4d09 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -5365,6 +5365,9 @@ main (int argc, char **argv) release_armor_context (afx); FREE_STRLIST(remusr); FREE_STRLIST(locusr); + + check_io_error(); + g10_exit(0); return 8; /*NEVER REACHED*/ } diff --git a/g10/gpgv.c b/g10/gpgv.c index ceded4af9e62f59acd970feb2d349aa47a4c352d..9d4f7b55ef07b05d2334afc987ed63848b83424a 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -281,6 +281,8 @@ main( int argc, char **argv ) keydb_release (ctrl->cached_getkey_kdb); xfree (ctrl); + check_io_error(); + /* cleanup */ g10_exit (0); return 8; /*NOTREACHED*/ diff --git a/g10/main.h b/g10/main.h index 62d2651be502a2fec710ac682fe5fc77cb47cf99..c08a839ff7c131a4e4e05e421390d4381c20bc65 100644 --- a/g10/main.h +++ b/g10/main.h @@ -216,6 +216,7 @@ void write_status_text_and_buffer ( int no, const char *text, const char *buffer, size_t len, int wrap ); void write_status_begin_signing (gcry_md_hd_t md); +int check_io_error (void); int cpr_enabled(void); -- 2.39.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1.asc Type: application/pgp-keys Size: 4885 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From demiobenour at gmail.com Thu Feb 2 07:19:50 2023 From: demiobenour at gmail.com (Demi Marie Obenour) Date: Thu, 2 Feb 2023 01:19:50 -0500 Subject: [PATCH GnuPG] Disallow compressed signatures and certificates Message-ID: Compressed packets have significant attack surface, due to the potential for both denial of service (zip bombs and the like) and for code execution via memory corruption vulnerabilities in the decompressor. Furthermore, I am not aware of any implementation that uses them in keys or detached signatures. Therefore, disallow their use in such contexts entirely. This includes signatures that are part of a cleartext-signed message. When parsing detached signatures, forbid any packet that is not a signature or marker packet. When parsing keys, return an error when encountering a compressed packet, instead of decompressing the packet. When parsing a cleartext-signed message, the signature (and any data that follows it) is treated as a detached signature. Furthermore, certificates, keys, and signatures are not allowed to contain partial-length or indeterminate-length packets. Reject those in parse_packet, rather than activating the partial-length filter code. Tests for changes to signature processing are included. Tests for changes to key and certificate processing have not yet been implemented. GnuPG-bug-id: T5993 Signed-off-by: Demi Marie Obenour --- g10/import.c | 18 +------- g10/mainproc.c | 35 ++++++++++++++- g10/packet.h | 2 + g10/parse-packet.c | 45 ++++++++++++++++++- tests/openpgp/compressed-sig-inline.asc | 15 +++++++ tests/openpgp/compressed-sig.asc | 11 +++++ tests/openpgp/indeterminate-length-inline.asc | 14 ++++++ tests/openpgp/indeterminate-length.asc | 10 +++++ tests/openpgp/partial-len-inline.asc | 14 ++++++ tests/openpgp/partial-len.asc | 10 +++++ tests/openpgp/verify.scm | 32 +++++++++++++ 11 files changed, 187 insertions(+), 19 deletions(-) create mode 100644 tests/openpgp/compressed-sig-inline.asc create mode 100644 tests/openpgp/compressed-sig.asc create mode 100644 tests/openpgp/indeterminate-length-inline.asc create mode 100644 tests/openpgp/indeterminate-length.asc create mode 100644 tests/openpgp/partial-len-inline.asc create mode 100644 tests/openpgp/partial-len.asc diff --git a/g10/import.c b/g10/import.c index 9fab46ca65a8bd81ac9f1a240a60eeb5f4b2b987..20fdfedf12c46b7f6bf0c047ac277337ed606f15 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1043,22 +1043,8 @@ read_block( IOBUF a, unsigned int options, switch (pkt->pkttype) { case PKT_COMPRESSED: - if (check_compress_algo (pkt->pkt.compressed->algorithm)) - { - rc = GPG_ERR_COMPR_ALGO; - goto ready; - } - else - { - compress_filter_context_t *cfx = xmalloc_clear( sizeof *cfx ); - pkt->pkt.compressed->buf = NULL; - if (push_compress_filter2 (a, cfx, - pkt->pkt.compressed->algorithm, 1)) - xfree (cfx); /* e.g. in case of compression_algo NONE. */ - } - free_packet (pkt, &parsectx); - init_packet(pkt); - break; + rc = GPG_ERR_UNEXPECTED; + goto ready; case PKT_RING_TRUST: /* Skip those packets unless we are in restore mode. */ diff --git a/g10/mainproc.c b/g10/mainproc.c index 4710386eafee7cc3894698cde4bb2537a322c658..992e3d088985efee717280dd4666bc2970af7647 100644 --- a/g10/mainproc.c +++ b/g10/mainproc.c @@ -105,6 +105,7 @@ struct mainproc_context has been seen. */ unsigned int data:1; /* Any data packet seen */ unsigned int uncompress_failed:1; + unsigned int in_cleartext:1; /* In cleartext of cleartext signature */ } any; }; @@ -170,6 +171,7 @@ add_onepass_sig (CTX c, PACKET *pkt) { kbnode_t node; + log_assert(!(c->sigs_only && c->signed_data.used)); if (c->list) /* Add another packet. */ add_kbnode (c->list, new_kbnode (pkt)); else /* Insert the first one. */ @@ -187,6 +189,7 @@ add_gpg_control (CTX c, PACKET *pkt) /* New clear text signature. * Process the last one and reset everything */ release_list(c); + c->any.in_cleartext = 1; } if (c->list) /* Add another packet. */ @@ -1118,8 +1121,16 @@ proc_compressed (CTX c, PACKET *pkt) int rc; /*printf("zip: compressed data packet\n");*/ - if (c->sigs_only) - rc = handle_compressed (c->ctrl, c, zd, proc_compressed_cb, c); + if( literals_seen ) + { + log_error ("Compressed packet follows literal data packet\n"); + rc = gpg_error (GPG_ERR_BAD_DATA); + } + else if( c->sigs_only ) + { + log_assert(!c->signed_data.used); + rc = handle_compressed (c->ctrl, c, zd, proc_compressed_cb, c); + } else if( c->encrypt_only ) rc = handle_compressed (c->ctrl, c, zd, proc_encrypt_cb, c); else @@ -1638,6 +1649,7 @@ do_proc_packets (CTX c, iobuf_t a) c->iobuf = a; init_packet(pkt); init_parse_packet (&parsectx, a); + parsectx.sigs_only = c->sigs_only && c->signed_data.used; while ((rc=parse_packet (&parsectx, pkt)) != -1) { any_data = 1; @@ -1649,11 +1661,27 @@ do_proc_packets (CTX c, iobuf_t a) if (gpg_err_code (rc) == GPG_ERR_INV_PACKET && opt.list_packets == 0) break; + + if (gpg_err_code (rc) == GPG_ERR_UNEXPECTED) + { + write_status_text( STATUS_UNEXPECTED, "0" ); + goto leave; + } continue; } newpkt = -1; + if (c->any.in_cleartext) + { + /* Just finished a clear-text signature's plaintext */ + if (pkt->pkttype != PKT_PLAINTEXT) + log_bug("Armor parser produced packet type %d where %d expected", + pkt->pkttype, PKT_PLAINTEXT); + c->any.in_cleartext = 0; + parsectx.sigs_only = 1; + } if (opt.list_packets) { + log_assert(!c->sigs_only); switch (pkt->pkttype) { case PKT_PUBKEY_ENC: proc_pubkey_enc (c, pkt); break; @@ -1667,6 +1695,9 @@ do_proc_packets (CTX c, iobuf_t a) } else if (c->sigs_only) { + log_assert(pkt->pkttype == PKT_SIGNATURE || + pkt->pkttype == PKT_MARKER || + !c->signed_data.used); switch (pkt->pkttype) { case PKT_PUBLIC_KEY: diff --git a/g10/packet.h b/g10/packet.h index eeea9b450facad03188d4b87485b8fb25398f48d..6de0685b61e0098cc92f8ae0e98d897614a736fe 100644 --- a/g10/packet.h +++ b/g10/packet.h @@ -660,6 +660,7 @@ struct parse_packet_ctx_s int free_last_pkt; /* Indicates that LAST_PKT must be freed. */ int skip_meta; /* Skip ring trust packets. */ unsigned int n_parsed_packets; /* Number of parsed packets. */ + int sigs_only; /* Only accept detached signature packets */ }; typedef struct parse_packet_ctx_s *parse_packet_ctx_t; @@ -670,6 +671,7 @@ typedef struct parse_packet_ctx_s *parse_packet_ctx_t; (a)->free_last_pkt = 0; \ (a)->skip_meta = 0; \ (a)->n_parsed_packets = 0; \ + (a)->sigs_only = 0; \ } while (0) #define deinit_parse_packet(a) do { \ diff --git a/g10/parse-packet.c b/g10/parse-packet.c index a033732ecf97dfd14ad55d940de6ff5936829caa..af641694797a19881dde40435d9712d8ecc603cd 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -738,6 +738,20 @@ parse (parse_packet_ctx_t ctx, PACKET *pkt, int onlykeypkts, off_t * retpos, case PKT_ENCRYPTED_MDC: case PKT_ENCRYPTED_AEAD: case PKT_COMPRESSED: + if (ctx->sigs_only) + { + log_error (_("partial length packet of type %d in detached " + "or cleartext signature\n"), pkttype); + rc = gpg_error (GPG_ERR_INV_PACKET); + goto leave; + } + if (onlykeypkts) + { + log_error (_("partial length packet of type %d in keyring\n"), + pkttype); + rc = gpg_error (GPG_ERR_INV_PACKET); + goto leave; + } iobuf_set_partial_body_length_mode (inp, c & 0xff); pktlen = 0; /* To indicate partial length. */ partial = 1; @@ -767,6 +781,20 @@ parse (parse_packet_ctx_t ctx, PACKET *pkt, int onlykeypkts, off_t * retpos, /* This isn't really partial, but we can treat it the same in a "read until the end" sort of way. */ partial = 1; + if (ctx->sigs_only) + { + log_error (_("indeterminate length packet of type %d in detached " + "or cleartext signature\n"), pkttype); + rc = gpg_error (GPG_ERR_INV_PACKET); + goto leave; + } + if (onlykeypkts) + { + log_error (_("indeterminate length packet of type %d in" + " keyring\n"), pkttype); + rc = gpg_error (GPG_ERR_INV_PACKET); + goto leave; + } if (pkttype != PKT_ENCRYPTED && pkttype != PKT_PLAINTEXT && pkttype != PKT_COMPRESSED) { @@ -828,7 +856,22 @@ parse (parse_packet_ctx_t ctx, PACKET *pkt, int onlykeypkts, off_t * retpos, goto leave; } - if (with_uid && pkttype == PKT_USER_ID) + if (ctx->sigs_only) + switch (pkttype) + { + case PKT_SIGNATURE: + case PKT_MARKER: + break; + default: + log_error(_("Packet type %d not allowed in detached " + "or cleartext signature\n"), + pkttype); + iobuf_skip_rest (inp, pktlen, partial); + *skip = 1; + rc = gpg_error (GPG_ERR_BAD_DATA); + goto leave; + } + else if (with_uid && pkttype == PKT_USER_ID) /* If ONLYKEYPKTS is set to 2, then we never skip user id packets, even if DO_SKIP is set. */ ; diff --git a/tests/openpgp/compressed-sig-inline.asc b/tests/openpgp/compressed-sig-inline.asc new file mode 100644 index 0000000000000000000000000000000000000000..3420ee1b8c50da4b7da9140d1089f06cacf18610 --- /dev/null +++ b/tests/openpgp/compressed-sig-inline.asc @@ -0,0 +1,15 @@ > diff --git a/tests/openpgp/compressed-sig.asc b/tests/openpgp/compressed-sig.asc new file mode 100644 index 0000000000000000000000000000000000000000..15d6e73b696c38aff7591366046b01c28a7e9f74 --- /dev/null +++ b/tests/openpgp/compressed-sig.asc @@ -0,0 +1,11 @@ +-----BEGIN PGP SIGNATURE----- +Comment: This is a signature (of the empty file) wrapped in a compressed +Comment: packet. Such signatures must be rejected to prevent DoS +Comment: attacks. + +ogAAAJYB65jIwiDGwWAppsjC0P0yfP1vewn2ee0/jNjKJorezGBhZUrexSUuLZOV +n5Gnl52ampeY51CSWlyil55XWpCul1+UzsDFKQBTnfiV4X/G+ysmcvsLn7lX3Dof +zPNjjWhRXtyV3IP/q81YuR+HnjjOyPD+7f3Y7Dmfr/+beFCV/WvAc9YFDetCgv5F +fz/kbHxF+QILAA== +=3bBP +-----END PGP SIGNATURE----- diff --git a/tests/openpgp/indeterminate-length-inline.asc b/tests/openpgp/indeterminate-length-inline.asc new file mode 100644 index 0000000000000000000000000000000000000000..8674063028c732a9b1e5b87d87b2cadd25622839 --- /dev/null +++ b/tests/openpgp/indeterminate-length-inline.asc @@ -0,0 +1,14 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA256 + + +-----BEGIN PGP SIGNATURE----- +Comment: This signature is encoded as an indeterminate length packet, +Comment: which is forbidden. + +iwQAFggAORYhBACL6Vev+z8YB56H+DIGdpEV2WgEBQJjyfwrGxxqb2huLmtlZW5h +bkB0ZXN0LmdudXBnLm9yZwAKCRAyBnaRFdloBMWaAQC9wiaOsM5QxSkoAFLypqdN +KXS0SWXpmmvK5h5aIE6igQD+PLEBHomZltQkNR/V/TYOBmT4G153RfHV5tHooLy0 +9Q0= +=Xhaf +-----END PGP SIGNATURE----- diff --git a/tests/openpgp/indeterminate-length.asc b/tests/openpgp/indeterminate-length.asc new file mode 100644 index 0000000000000000000000000000000000000000..e79dcc42afd267ff1be16a25135d926636e6044b --- /dev/null +++ b/tests/openpgp/indeterminate-length.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP SIGNATURE----- +Comment: This signature is encoded as an indeterminate length packet, +Comment: which is forbidden. + +iwQAFggAORYhBACL6Vev+z8YB56H+DIGdpEV2WgEBQJjyfwrGxxqb2huLmtlZW5h +bkB0ZXN0LmdudXBnLm9yZwAKCRAyBnaRFdloBMWaAQC9wiaOsM5QxSkoAFLypqdN +KXS0SWXpmmvK5h5aIE6igQD+PLEBHomZltQkNR/V/TYOBmT4G153RfHV5tHooLy0 +9Q0= +=Xhaf +-----END PGP SIGNATURE----- diff --git a/tests/openpgp/partial-len-inline.asc b/tests/openpgp/partial-len-inline.asc new file mode 100644 index 0000000000000000000000000000000000000000..d3a66ec389abca8d9c27c842f152d07d651a1c2d --- /dev/null +++ b/tests/openpgp/partial-len-inline.asc @@ -0,0 +1,14 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA256 + + +-----BEGIN PGP SIGNATURE----- +Comment: This signature uses partial-length encoding, which is +Comment: not allowed. + +yOcB65jIwiDGwWAppsjC0P0yfP1vewn2ee0/jNjKJorezGBhZUrexSUuLZOVn5Gn +l52ampeY51CSWlyil55XWpCul1+UzsDFKQBTnfiV4X/G+ysmcvsLn7lX3DofzPNj +jWhRXtyV3IP/q81YuR+HnjjOyPD+7f3Y7Dmfr/+beFCV/RVrwHPWBQ3rQoL+RX8/ +5Gx8RfkCCwA= +=Ph+8 +-----END PGP SIGNATURE----- diff --git a/tests/openpgp/partial-len.asc b/tests/openpgp/partial-len.asc new file mode 100644 index 0000000000000000000000000000000000000000..24c966d1bf5a30a3731c8be02cfc00bd01dfc07d --- /dev/null +++ b/tests/openpgp/partial-len.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP SIGNATURE----- +Comment: This signature uses partial-length encoding, which is +Comment: not allowed. + +yOcB65jIwiDGwWAppsjC0P0yfP1vewn2ee0/jNjKJorezGBhZUrexSUuLZOVn5Gn +l52ampeY51CSWlyil55XWpCul1+UzsDFKQBTnfiV4X/G+ysmcvsLn7lX3DofzPNj +jWhRXtyV3IP/q81YuR+HnjjOyPD+7f3Y7Dmfr/+beFCV/RVrwHPWBQ3rQoL+RX8/ +5Gx8RfkCCwA= +=Ph+8 +-----END PGP SIGNATURE----- diff --git a/tests/openpgp/verify.scm b/tests/openpgp/verify.scm index afa6b6a213cc583aca38417c426695786bd16f53..57d02a81e9cc2b781fb86c996d36e503545cfa6e 100755 --- a/tests/openpgp/verify.scm +++ b/tests/openpgp/verify.scm @@ -70,6 +70,38 @@ (fail "verification succeeded but should not"))) '(bad_ls_asc bad_fols_asc bad_olsf_asc bad_ools_asc)) +(info "Checking that compressed signatures are rejected") +(call-check `(,(tool 'gpg) --quiet --yes --import + ,(in-srcdir "tests" "openpgp" "samplekeys" "silent-running.asc"))) + +(let ((check-stderr + (lambda (msg file expected detached) + (info "Checking that" msg "are rejected") + (let* ((what `(,(tool 'gpg) --verify + ,(in-srcdir "tests" "openpgp" file) + ,@(if detached (list "/dev/null") '()))) + (result (call-with-io what ""))) + (if (and (= 2 (:retcode result)) + (string-contains? (:stderr result) expected)) + (:stderr result) + (throw (string-append (stringify what) " returned unexpected status " + (number->string (:retcode result))) + (:stderr result))))))) + (check-stderr "indeterminate length packets in detached signatures" "indeterminate-length.asc" + "gpg: indeterminate length packet of type 2 in detached or cleartext signature\n" #t) + (check-stderr "indeterminate length packets in cleartext signatures" "indeterminate-length-inline.asc" + "gpg: indeterminate length packet of type 2 in detached or cleartext signature\n" #f) + (check-stderr "compressed detached signatures" "compressed-sig.asc" + "gpg: Packet type 8 not allowed in detached or cleartext signature\n" #t) + (check-stderr "compressed cleartext signatures" "compressed-sig-inline.asc" + "gpg: Packet type 8 not allowed in detached or cleartext signature\n" #f) + (check-stderr "partial-length packets in detached signatures" "partial-len.asc" + "gpg: partial length packet of type 8 in detached or cleartext signature\n" + #t) + (check-stderr "partial-length packets in cleartext signatures" "partial-len-inline.asc" + "gpg: partial length packet of type 8 in detached or cleartext signature\n" + #f)) + ;;; Need to import the ed25519 sample key used for ;;; the next two tests. -- 2.39.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1.asc Type: application/pgp-keys Size: 4885 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From calestyo at scientia.org Thu Feb 2 06:12:57 2023 From: calestyo at scientia.org (Christoph Anton Mitterer) Date: Thu, 02 Feb 2023 06:12:57 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> Message-ID: <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> On Wed, 2023-02-01 at 22:19 -0600, Bruce Walzer wrote: > On Wed, Feb 01, 2023 at 07:42:38PM +0100, Kai Engert via Gnupg-devel > wrote: > [...] > > Does that mean, if Thunderbird wants to remain compatible with all > > major > > implementations, then Thunderbird must stay at the functional level > > of RFC > > 4880, and must not use any functionality from newer specifications, > > neither > > from the upcoming IETF crypto-refresh, nor items that were added in > > RFC > > 4880bis on top of RFC 4880? > > That sounds like a reasonable approach to me. Sounds rather like the worst approach to me. Staying at the level that is in principle already insufficient in several places. > Sometimes consensus can not be reached. Then changes are not really > possible or practical. What exactly would the downside for > Thunderbird be here? Not getting any new algorithms? The WG seems to have done quite a good job, and crypto-refresh provides many things that are wanted. It has AEAD algos, it has Ed25519 and Ed448,... SHA1 seems to be mostly gone (in the place where it was mandatory). Is there any *real* problem about it containing GCM?! Its chapter 9.6. makes OCB mandatory - EAX and GCM are optional. If one doesn't like to implement GCM because of it's fragility - don't implement it. But that alone seems a poor reason to effectively split the community and fork OpenPGP (and by that probably help killing it). draft-koch-openpgp-2015-rfc4880bis-00, OTOH, lacks at least Ed448. It also still comes only with S2K as KDF, despite there being considerably better alternatives (I mean Argon2 would be the natural candidate, but probably all finalists from the PHC would be a much better choice than S2K). May not be a big issue for Thunderbird, but for anyone who wants to do symmetric session keys, that's really some bad news - and IMO in no way understandable. Passively following the WG, many people there seem to believe that the crypto-refresh process was quite open for anyone and seem to consider the competing/conflicting draft at best unfortunate or rather made in bad faith. I'd kinda hope that Thunderbird follows (only) what the Working Group will eventually release as the next version of the standard. Otherwise one could just toss the whole standard and make it a ecosystem defined by solely one party, whichever that s. Cheers, Chris. From kaie at kuix.de Thu Feb 2 09:31:04 2023 From: kaie at kuix.de (Kai Engert) Date: Thu, 2 Feb 2023 09:31:04 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: On 02.02.23 06:12, Christoph Anton Mitterer wrote: > > I'd kinda hope that Thunderbird follows (only) what the Working Group > will eventually release as the next version of the standard. Thunderbird is a tool to enable users to communicate. If a significant amount of Thunderbird users wants to exchange messages with users of GnuPG, then Thunderbird must not send messages that are incompatible with GnuPG. In the same way, Thunderbird must not send messages that GnuPG understands, but that other major implements of OpenPGP cannot understand. Today, my opinion is, I don't want Thunderbird to pick one of the sides. I'm asking the OpenPGP community to work together and find a standard that works for everyone. Thanks and Regards, Kai From wk at gnupg.org Thu Feb 2 10:26:48 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2023 10:26:48 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> (Christoph Anton Mitterer's message of "Thu, 02 Feb 2023 06:12:57 +0100") References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: <87sffozacn.fsf@wheatstone.g10code.de> On Thu, 2 Feb 2023 06:12, Christoph Anton Mitterer said: > The WG seems to have done quite a good job, and crypto-refresh provides > many things that are wanted. Up until summer 2021. > Is there any *real* problem about it containing GCM?! Its chapter 9.6. Yes, I explained it. This adds a lot of extra complexity to the protocol to mitigate for the fragile GCM. That does not affect just GCM but also OCB. > draft-koch-openpgp-2015-rfc4880bis-00, OTOH, lacks at least Ed448. Will be added. Actually GnUPG supports x448 for quite some time. > It also still comes only with S2K as KDF, despite there being > considerably better alternatives (I mean Argon2 would be the natural OpenPGP is a protocol used mainly for public key encryption. The S2K is mainly used for impedance matching. Using it to make brute forcing of passphrases harder is not its primary goal. And in fact it can't be used in real world applications: For symmetric encryption the a full entropy passphrase should be used. Any delays or extensive requirement of resources (memory, CPU) is counterproductive in the real world. You use symmetric-only encryption either for automating tasks which requires speed and thus implementations may not be resource hog. Or for mass sending of encrypting data to a large group of recipients. In that case the recipients have all kind of different machine types and you can't assume that they all have some big-memory system to quickly do the S2K. They want to work fast and there are use cases where dozens of messages are received per second - not a suitable target for Argon2 or any other long running KDF. For protecting the private key - well, this should be done but it is not in the scope of OpenPGP, which describes an on-the-wire protocol and not a particular implementations. Sending a private key in the OpenPGP format is anyway not a good idea to still existing weaknesses in the protocol - the common wisdom is to use symmetric-only encryption (with a full-entropy password) to convey a private key. Or use another public key. > May not be a big issue for Thunderbird, but for anyone who wants to do > symmetric session keys, that's really some bad news - and IMO in no way No. The real world works in a different way. See above. > Passively following the WG, many people there seem to believe that the > crypto-refresh process was quite open for anyone and seem to consider > the competing/conflicting draft at best unfortunate or rather made in It is not a competing one but it is the state of things from summer 2021 which all paricipants of the DT had agreed upon back then. Actually with some minor modification it is the very same as what we had in 2021 and which had been implemented and interop tested already in 2018. 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: 227 bytes Desc: not available URL: From deloptes at gmail.com Thu Feb 2 14:28:48 2023 From: deloptes at gmail.com (deloptes) Date: Thu, 2 Feb 2023 14:28:48 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: Hi, But that alone seems a poor reason to effectively split the community > and fork OpenPGP (and by that probably help killing it). > > I was thinking exactly the same aside the technical part. At the end community splits, software is not compatible any more and all is broken. It seems it happens every 10y or so with this or that software. Is it so hard to find a way to complete something together? (I ask it in rhetoric way and I do not mean here GnuPG). I hope however, you keep compatibility and user experience as top priority. BR -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Thu Feb 2 15:49:05 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 2 Feb 2023 14:49:05 +0000 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: On 2 Feb 2023, at 08:31, Kai Engert via Gnupg-devel wrote: > > I'm asking the OpenPGP community to work together and find a standard that works for everyone. I?d like to whole-heartedly second this. It is not only client software that will be forced to make unpalatable decisions if the standard forks, but also keyservers. Hockeypuck relies heavily on Protonmail?s fork of gopenpgp. Protonmail are invested in crypto-refresh and will certainly implement the new RFC when it is finalised. Hockeypuck does not have the developer resources to maintain yet another fork of gopenpgp, and so will have little choice but to track upstream. This would mean that the vast majority of synchronising keyservers, including keyserver.ubuntu.com (gnupg?s default keyserver) would not be able to handle v5 keys created by gnupg. Hagrid's dependency on sequoia-pgp means that keys.openpgp.org would also similarly be unavailable, leaving gnupg users without a reliable keyserver service. Conversely, keys created using the new RFC could not be processed by gnupg-wks-server, potentially forcing individual users to conform to a domain-wide policy re the split. This is not simply a case of a standard forking, because neither side ends up owning sufficient share of the pieces to rebuild a functional ecosystem. This prospect is IMO unthinkable, and would set OpenPGP back by many years, with potentially irrevocable consequences. I don?t believe that the technical disagreements are insurmountable if there exists sufficient political will to bridge the gaps. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bwalzer at 59.ca Thu Feb 2 17:02:39 2023 From: bwalzer at 59.ca (Bruce Walzer) Date: Thu, 2 Feb 2023 10:02:39 -0600 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: On Thu, Feb 02, 2023 at 06:12:57AM +0100, Christoph Anton Mitterer wrote: > On Wed, 2023-02-01 at 22:19 -0600, Bruce Walzer wrote: > > On Wed, Feb 01, 2023 at 07:42:38PM +0100, Kai Engert via Gnupg-devel > > wrote: > > [...] > > > Does that mean, if Thunderbird wants to remain compatible with all > > > major > > > implementations, then Thunderbird must stay at the functional level > > > of RFC > > > 4880, and must not use any functionality from newer specifications, > > > neither > > > from the upcoming IETF crypto-refresh, nor items that were added in > > > RFC > > > 4880bis on top of RFC 4880? > > > > That sounds like a reasonable approach to me. > > Sounds rather like the worst approach to me. Staying at the level that > is in principle already insufficient in several places. > > > > Sometimes consensus can not be reached. Then changes are not really > > possible or practical. What exactly would the downside for > > Thunderbird be here? > > Not getting any new algorithms? But why would this be a issue that needs to be addressed now? What advantages would the new algorithms provide to the users of Thunderbird? Would those advantages make up for the incompatibility problems caused by the introduction of new incompatible algorithms? For long term standards, procrastination is almost always a virtue... > > The WG seems to have done quite a good job, and crypto-refresh provides > many things that are wanted. > It has AEAD algos, OCB has the advantage that it is faster and thus better for huge files. The other proposed modes don't seem to have any particular advantage. Thunderbird is a messaging application where the messages are limited to lengths of 10s of MB. So performance is not an issue. So it would make the most sense to stick to the existing standardized authenticated encyption mode as specified in RFC4880 to provide the best level of compatibility for the users. So the AEAD modes are not really useful here. > it has Ed25519 and Ed448,... The advantage of curves over RSA for the users of Thundebird is the shorter key length. The length of Ed448 is significantly longer than Ed25519. So why standarize both? The super long keys of post quantum cryptography would make this all insignificant so it would make sense to wait a while and see how the quantum stuff pans out. SHA1 seems to be mostly > gone (in the place where it was mandatory). How does making SHA1 gone provide any value to the users of Thunderbird? The only attack I am aware of that relates is Sha-mbles. It is wildly impractical the the point that most users would not care. It can be resolved simply by upgrading existing keys in a way that does not cause the user to lose their PGP identity. No changes to the existing standard are required. > > Is there any *real* problem about it containing GCM?! Its chapter 9.6. > makes OCB mandatory - EAX and GCM are optional. > If one doesn't like to implement GCM because of it's fragility - don't > implement it. Unless someone sends one of the users a message encrypted with EAX or GCM. Then you have to implement it. This might happen where a user uses an implementation that supports EAX/GCM to generate a key with EAX/GCM in the preferences but then uses a different implementation that does not support EAX/GCM. This is normal PGP usage as identities refer to people, not devices. Having EAX/GCM be optional actually makes things worse. I have personally encountered this problem in the wild, and no new modes have even been standardized yet. [...] > It also still comes only with S2K as KDF, despite there being > considerably better alternatives (I mean Argon2 would be the natural > candidate, but probably all finalists from the PHC would be a much > better choice than S2K). Argon2 seems a fairly poor choice here. It is fairly memory hungry which could cause the users to encounter interoperability problems. An Argon2 implementation will just blow up with an out of memory error. There is a fairly common argument out there that Argon2 is not optimal for situations where the time required to derive the key is limited to less than a secone. GPG uses 0.1 seconds as a target for example. Something cache hard might be a better choice. Currently single core processor performance seems to be at a plateau, so this is, again, not a crisis for any Thunderbird user. Bruce From steffen at sdaoden.eu Thu Feb 2 18:21:25 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 02 Feb 2023 18:21:25 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: <20230202172125.-gwg0%steffen@sdaoden.eu> deloptes wrote in : |But that alone seems a poor reason to effectively split the community |> and fork OpenPGP (and by that probably help killing it). |> |> I was thinking exactly the same aside the technical part. At the end |community splits, software is not compatible any more and all is broken. It |seems it happens every 10y or so with this or that software. |Is it so hard to find a way to complete something together? (I ask it in |rhetoric way and I do not mean here GnuPG). |I hope however, you keep compatibility and user experience as top priority. 4880bis was "current" from 2015 to somewhen in 2021 (says Werner Koch). I as a spectator downloaded "draft 00" from July 6, 2016 on the 7th of July 2016. It includes things like Ed25519. That is around six full years (for Werner Koch -- to me it became apparent no sooner but 2022) --- a very long time in software development. Software had been written and was in widespread use for many years. That is, as i see it, especially the most widely used implementations ship code for a long time, and are interoperable in that. (Werner Koch has explicitly stated this in a message in this thread.) I am not an expert regarding OpenPGP. (And most that i did know i have forgotten.) So there might be things that can be improved in the OpenPGP format on top of what "V5" did say. Creating something that is incompatible with what was envisioned as "V5" i do not understand given the long time that passed. I would have understood if some small compatible improvements would have been made, and anything else been moved to a "V6". But then i had the gut feeling that in the working group there was "laughter" regarding this "V5" / "V6" thing in that everything is "V5" now, and it is not what was in 4880bis for many years anyway. Other participants of the group even create biased compatibility overviews that looked to me moreover as (helpless, imho) tries to build up a pressure scenario in favour of crypto-refresh (even before there was crypto-refresh it could have been). I find this overly uncooperative, and anyway outstanding in all the WGs i (have) track(ed), _for_sure_. Maybe sometimes a small step is better than a big hit. P.S.: #?0|kent:tls-openssl.git$ git grep -i argon master master:doc/designs/thread-api.md: - Some algorithms are designed to be run in parallel (Argon2); #?0|kent:tls-openssl.git$ git log --oneline master -- doc/designs/thread-api.md d55fc027b9 Add thread pool design document (phase 1) #?0|kent:tls-openssl.git$ git log -1 d55fc027b9 | sed -e 2,7p';d' Author: Hugo Landau AuthorDate: 2022-07-25 13:51:42 +0100 Commit: Tomas Mraz CommitDate: 2022-11-14 12:21:22 +0100 Add thread pool design document (phase 1) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From calestyo at scientia.org Fri Feb 3 02:55:54 2023 From: calestyo at scientia.org (Christoph Anton Mitterer) Date: Fri, 03 Feb 2023 02:55:54 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: On Thu, 2023-02-02 at 09:31 +0100, Kai Engert wrote: > If a significant amount of Thunderbird users wants to exchange > messages > with users of GnuPG, then Thunderbird must not send messages that are > incompatible with GnuPG. > > In the same way, Thunderbird must not send messages that GnuPG > understands, but that other major implements of OpenPGP cannot > understand. Well that's what the open standardisation processes would have been there for. GnuPG, just as any other stakeholders, had (and I guess still have) the chance to participate. When the competing draft arose, numerous voice in the WG expressed the wish for GnuPG to "come back" and work on areas of conflict. If it left that processes to continue on it's own, well fine, but there cannot be any expectation that all others follow. Standardisation is also always about making compromises, and not about the biggest stakeholder wins. > Today, my opinion is, I don't want Thunderbird to pick one of the > sides. Which ultimately means that users of TB would still suffer compatibility issues (with any user of incompatible new stuff from either the standard or GnuPG) ... plus not getting any of such modernish stuff (especially AEAD). > I'm asking the OpenPGP community to work together and find a standard > that works for everyone. Well that surely would be the best, but from what one could have read so far from representatives it doesn't seem as if that's going to happen. There is apparently enough desire in all that what the crypto-refresh adds and what draft-koch-openpgp-2015-rfc4880bis-00 doesn't have, that all it's proponents (which seemed to be a majority on the list - except GnuPG) don't want to throw away >year of work. And GnuPG seems to have also chosen it's path, at least from what one could have read so far. In the end we may just see both competing standards die and maybe OpenPG with it. Cheers, Chrs. From deloptes at gmail.com Fri Feb 3 09:21:07 2023 From: deloptes at gmail.com (deloptes) Date: Fri, 3 Feb 2023 09:21:07 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <87wn51z3lg.fsf@wheatstone.g10code.de> <7b25ce89-ba83-c64c-6476-d3a8d94bba76@kuix.de> <8629ac58197b47460c450bd85a62f306bc6e2f82.camel@scientia.org> Message-ID: > > In the end we may just see both competing standards die and maybe > OpenPG with it. > this is the feeling I get following this thread. it is very disturbing. It is happening just like many others before and from those many others it is hard to expect any different outcome. BR -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Feb 7 13:11:21 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Feb 2023 13:11:21 +0100 Subject: [openpgp] draft-koch-openpgp-2015-rfc4880bis-01 Message-ID: <877cwty8t2.fsf@wheatstone.g10code.de> An embedded message was scrubbed... From: Werner Koch Subject: [openpgp] draft-koch-openpgp-2015-rfc4880bis-01 Date: Tue, 07 Feb 2023 10:59:53 +0100 Size: 8769 URL: -------------- next part -------------- -- 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: 227 bytes Desc: not available URL: From jwilk at jwilk.net Tue Feb 7 16:18:33 2023 From: jwilk at jwilk.net (Jakub Wilk) Date: Tue, 7 Feb 2023 16:18:33 +0100 Subject: [openpgp] draft-koch-openpgp-2015-rfc4880bis-01 In-Reply-To: <877cwty8t2.fsf@wheatstone.g10code.de> References: <877cwty8t2.fsf@wheatstone.g10code.de> Message-ID: <20230207151833.tfrdz4bcnqqisg64@jwilk.net> * Werner Koch, 2023-02-07 13:11: >For the actual commits see: >https://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git Is there a way to clone this repo over HTTPS? Gitweb points to , which is 404. -- Jakub Wilk From wk at gnupg.org Tue Feb 7 16:54:30 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Feb 2023 16:54:30 +0100 Subject: [openpgp] draft-koch-openpgp-2015-rfc4880bis-01 In-Reply-To: <20230207151833.tfrdz4bcnqqisg64@jwilk.net> (Jakub Wilk's message of "Tue, 7 Feb 2023 16:18:33 +0100") References: <877cwty8t2.fsf@wheatstone.g10code.de> <20230207151833.tfrdz4bcnqqisg64@jwilk.net> Message-ID: <871qn1xyh5.fsf@wheatstone.g10code.de> On Tue, 7 Feb 2023 16:18, Jakub Wilk said: > Is there a way to clone this repo over HTTPS? Gitweb points to > , which is 404. Sorry, no. I don't think it is useful to have all repos in phrabricator. All of my commits there are anyway signed; much better than any arbitrary TLS authentication. 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: 227 bytes Desc: not available URL: From bernhard at intevation.de Mon Feb 20 18:17:51 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 20 Feb 2023 18:17:51 +0100 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> Message-ID: <3482572.iIbC2pHGDl@kymo.gruen> Am Donnerstag, 2. Februar 2023, 15:49:05 CET schrieb Andrew Gallagher via Gnupg-devel: > On 2 Feb 2023, at 08:31, Kai Engert via Gnupg-devel wrote: > > I'm asking the OpenPGP community to work together and find a standard that > > works for everyone. > I?d like to whole-heartedly second this. You are part of the community, I do not think that pledges will help. What we can do is to work out the arguments, so more people can follow them and join a constructive search for a good and well reasoned paths forward. > Hockeypuck relies heavily on Protonmail?s fork of gopenpgp. Protonmail are > invested in crypto-refresh and will certainly implement the new RFC when it > is finalised. Hockeypuck does not have the developer resources to maintain > yet another fork of gopenpgp, and so will have little choice but to track > upstream. Given that openpgp-2015-rfc4880bis is simpler to implement, because having less variants, that is an argument for it. I guess that Hockeypuck/gopenpgp is closer to support it anyway, maybe already supporting it. What would be needed to implemented it in hockeypuck?` Regards Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Feb 23 16:43:32 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 23 Feb 2023 16:43:32 +0100 Subject: Key rollovers, overlapping (Re: WKD: returns only one pubkey (and why)) In-Reply-To: <87tu0d7fwq.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> Message-ID: <202302231643.33394.bernhard@intevation.de> Am Donnerstag 26 Januar 2023 11:23:49 schrieb Simon Josefsson via Gnupg-devel: > While we could recommend doing hard-stop key rollovers where you revoke > the earlier key at the same time you migrate to the new key, I don't > think that is a common habit nor am I sure this is even a good idea. > Does anyone think we should recommend that? Not me. I think we should allow time-overlapping pubkeys for an email-address (and any other UID) and thus recommend _smooth_ key rollovers. Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Feb 23 16:53:31 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 23 Feb 2023 16:53:31 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87cz7075us.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <87tu0d7fwq.fsf@josefsson.org> <87cz7075us.fsf@josefsson.org> Message-ID: <202302231653.31858.bernhard@intevation.de> Am Freitag 27 Januar 2023 09:13:15 schrieb Simon Josefsson via Gnupg-devel: > my goal is to come up with the best/safest text to write in a software > release on how to verify OpenPGP signatures for the tarball. > > Currently I'm using the text below, which recommends 'gpg > --locate-external-key' as the preferred mechanism and normally that uses > WKD and will try to refresh the key from the server (otherwise people > get old cached keys from local key storage). ?I like the simplicity and > UX of this approach. If the email address has the same domain as the downloading domain of the package, it all is controlled by the same entity. It would make more sense to have a second paths to building trust in a public key. One source of trust would be that you already have an old pub key from a previous download. Another practice I hope to establish is that clients will from time to time query a keyserver about the pubkey to have a chance to see if there is a revokation for the pubkey, they'll get from the email provider and to have a chance to detect malicious acts by the email provider itself. > This mechanism must be able to retrieve all > currently valid keys for a particular e-mail address, otherwise people > will complain not finding the right key. This only is a problem if an old tarball is to be verified. One way to build trust could be to get the new, current, recommended pubkey from the WKD and then retrieve the other pubkey from a keyserver and a signature from the WKD pubkey. Would only work if keyserver would carry 3rd party signatures again. > Second to using the e-mail, maybe retrieving by key id should be > preferred because that is more stable. ?However there aren't really any > stable working keyid-based OpenPGP key search engines left, are there? Sure, a number of them: https://spider.pgpkeys.eu/ e.g. https://keyserver2.gnupg.org/ Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Feb 24 10:02:58 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Feb 2023 10:02:58 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <20230128225012.v74tzxb73yfjpjvb@jwilk.net> (Jakub Wilk's message of "Sat, 28 Jan 2023 23:50:12 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> <87cz7075us.fsf@josefsson.org> <20230128225012.v74tzxb73yfjpjvb@jwilk.net> Message-ID: <871qmfpha5.fsf@wheatstone.g10code.de> On Sat, 28 Jan 2023 23:50, Jakub Wilk said: > Beware that this may import unrelated keys to your keyring: > https://bugs.debian.org/909755 Nope (see also https://dev.gnupg.org/T3398). The security of GnUPG OpenPGP keys does not rely on the keys in a certain database but soley on key signatures. The whole idea of using "curated keyrings" for general purposes is entirely wrong. If you do this, you should at least disable dirmngr and don't use any frontends or tools which might import keys (e.g. taken from a mail). The only standard use of "curated keyrings" is with gpgv which - for that reason - uses a dedicated file name (trustedkeys.kbx or trustedkeys.gpg). 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: 227 bytes Desc: not available URL: From andrewg at andrewg.com Fri Feb 24 19:25:55 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 24 Feb 2023 18:25:55 +0000 Subject: Interoperability with OpenPGP crypto-refresh In-Reply-To: <3482572.iIbC2pHGDl@kymo.gruen> References: <68095aa8-4f30-9e54-f7e3-519008cd92ef@kuix.de> <3482572.iIbC2pHGDl@kymo.gruen> Message-ID: On 20/02/2023 17:17, Bernhard Reiter wrote: > Am Donnerstag, 2. Februar 2023, 15:49:05 CET schrieb Andrew Gallagher via > Gnupg-devel: >> Hockeypuck relies heavily on Protonmail?s fork of gopenpgp. Protonmail are >> invested in crypto-refresh and will certainly implement the new RFC when it >> is finalised. Hockeypuck does not have the developer resources to maintain >> yet another fork of gopenpgp, and so will have little choice but to track >> upstream. > > Given that openpgp-2015-rfc4880bis is simpler to implement, because having > less variants, that is an argument for it. That might have been an argument for supporting *only* -bis, but that particular boat has sailed. We now have even more variants, not less. The choice for hockeypuck now is not between crypto-refresh and -bis, but between crypto-refresh and crypto-refresh-plus-bis. AFAICT, most of the significant modifications that need to be made to hockeypuck?s own code, such as support for longer fingerprints, are similar in both proposals and only need to be implemented once (or once-and-a-bit). The divergent parts, such as signature verification, are mainly in gopenpgp, and the crypto-refresh version of that will come regardless. > I guess that Hockeypuck/gopenpgp is > closer to support it anyway, maybe already supporting it. > What would be needed to implemented it in hockeypuck?` Either Protonmail adds -bis support to their fork of gopenpgp, or someone else re-forks their fork to to add it and commits to supporting it long term. That "someone else" is unfortunately not going to be me as I have neither the skillset nor spare capacity. :-( A From Qi.Chen at windriver.com Tue Feb 28 06:52:19 2023 From: Qi.Chen at windriver.com (Chen Qi) Date: Tue, 28 Feb 2023 13:52:19 +0800 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version Message-ID: <20230228055219.12798-1-Qi.Chen@windriver.com> python setuptools >=66.0.0 treats '-unknown' as an invalid version. The error message is as below: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '1.18.0-unknown' Remove the '-unknown' suffix to fix this issue. Signed-off-by: Chen Qi --- autogen.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 9b361581..d5cccd2a 100755 --- a/autogen.sh +++ b/autogen.sh @@ -266,7 +266,7 @@ if [ "$myhost" = "find-version" ]; then else ingit=no beta=yes - tmp="-unknown" + tmp="" rev="0000000" rvd="0" fi -- 2.17.1 From Qi.Chen at windriver.com Tue Feb 28 07:09:49 2023 From: Qi.Chen at windriver.com (Chen Qi) Date: Tue, 28 Feb 2023 14:09:49 +0800 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version Message-ID: <20230228060949.3116-1-Qi.Chen@windriver.com> python setuptools >=66.0.0 treats '-unknown' as an invalid version. The error message is as below: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '1.18.0-unknown' Remove the '-unknown' suffix to fix this issue. Signed-off-by: Chen Qi --- autogen.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 9b361581..d5cccd2a 100755 --- a/autogen.sh +++ b/autogen.sh @@ -266,7 +266,7 @@ if [ "$myhost" = "find-version" ]; then else ingit=no beta=yes - tmp="-unknown" + tmp="" rev="0000000" rvd="0" fi -- 2.17.1 From wk at gnupg.org Tue Feb 28 08:08:04 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Feb 2023 08:08:04 +0100 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: <20230228060949.3116-1-Qi.Chen@windriver.com> (Chen Qi via Gnupg-devel's message of "Tue, 28 Feb 2023 14:09:49 +0800") References: <20230228060949.3116-1-Qi.Chen@windriver.com> Message-ID: <875ybmjmi3.fsf@wheatstone.g10code.de> On Tue, 28 Feb 2023 14:09, Chen Qi said: > Remove the '-unknown' suffix to fix this issue. This is in the repo for a reason. Regular builds from the released tarball don't have this. 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: 227 bytes Desc: not available URL: From Qi.Chen at windriver.com Tue Feb 28 07:05:28 2023 From: Qi.Chen at windriver.com (Chen Qi) Date: Tue, 28 Feb 2023 14:05:28 +0800 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version Message-ID: <20230228060528.22720-1-Qi.Chen@windriver.com> python setuptools >=66.0.0 treats '-unknown' as an invalid version. The error message is as below: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '1.18.0-unknown' Remove the '-unknown' suffix to fix this issue. Signed-off-by: Chen Qi --- autogen.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 9b361581..d5cccd2a 100755 --- a/autogen.sh +++ b/autogen.sh @@ -266,7 +266,7 @@ if [ "$myhost" = "find-version" ]; then else ingit=no beta=yes - tmp="-unknown" + tmp="" rev="0000000" rvd="0" fi -- 2.17.1 From Qi.Chen at windriver.com Tue Feb 28 08:22:46 2023 From: Qi.Chen at windriver.com (Chen, Qi) Date: Tue, 28 Feb 2023 07:22:46 +0000 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: <875ybmjmi3.fsf@wheatstone.g10code.de> References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> Message-ID: I'm using gpgme-1.18.0.tar.bz2. I'm not building from git repo. Also, I'm using cross-compile, more specially a Yocto environment. I don't know much about gpgme. Could you please tell me why this function will not be called when building from tarball? Regards, Qi -----Original Message----- From: Werner Koch Sent: Tuesday, February 28, 2023 3:08 PM To: Chen Qi via Gnupg-devel Cc: Chen, Qi Subject: Re: [gpgme][PATCH] autogen.sh: remove '-unknown' in version On Tue, 28 Feb 2023 14:09, Chen Qi said: > Remove the '-unknown' suffix to fix this issue. This is in the repo for a reason. Regular builds from the released tarball don't have this. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein From wk at gnupg.org Tue Feb 28 08:30:03 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Feb 2023 08:30:03 +0100 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: (Qi via Gnupg-devel Chen's message of "Tue, 28 Feb 2023 07:22:46 +0000") References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> Message-ID: <87zg8yi6x0.fsf@wheatstone.g10code.de> On Tue, 28 Feb 2023 07:22, Chen, Qi said: > I don't know much about gpgme. Could you please tell me why this > function will not be called when building from tarball? You ran the script. This is only needed if you want to build a new configure script. ./configure make make install # usually as root is the canonical triple jump to build software 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: 227 bytes Desc: not available URL: From Qi.Chen at windriver.com Tue Feb 28 08:43:22 2023 From: Qi.Chen at windriver.com (Chen, Qi) Date: Tue, 28 Feb 2023 07:43:22 +0000 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: <87zg8yi6x0.fsf@wheatstone.g10code.de> References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> <87zg8yi6x0.fsf@wheatstone.g10code.de> Message-ID: Thanks. You're right. We're building a new configure script. Is it not expected for users using tarball? Regards, Qi -----Original Message----- From: Werner Koch Sent: Tuesday, February 28, 2023 3:30 PM To: Chen, Qi via Gnupg-devel Cc: Chen, Qi Subject: Re: [gpgme][PATCH] autogen.sh: remove '-unknown' in version On Tue, 28 Feb 2023 07:22, Chen, Qi said: > I don't know much about gpgme. Could you please tell me why this > function will not be called when building from tarball? You ran the script. This is only needed if you want to build a new configure script. ./configure make make install # usually as root is the canonical triple jump to build software Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein From wk at gnupg.org Tue Feb 28 09:12:36 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Feb 2023 09:12:36 +0100 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: (Qi via Gnupg-devel Chen's message of "Tue, 28 Feb 2023 07:43:22 +0000") References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> <87zg8yi6x0.fsf@wheatstone.g10code.de> Message-ID: <87r0uai4y3.fsf@wheatstone.g10code.de> On Tue, 28 Feb 2023 07:43, Chen, Qi said: > Thanks. You're right. We're building a new configure script. Is it not > expected for users using tarball? The whole point of providing a configure script is to test the capabilities of the system and build the software according to these capabilities. Creating a new configure is a maintainer task and only needed if you change Makefiles or want to make changes to the configuration system. This is usually done in the Git checkout and the version suffix will then be something with -betaNNNN 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: 227 bytes Desc: not available URL: From cllang at redhat.com Tue Feb 28 10:44:28 2023 From: cllang at redhat.com (Clemens Lang) Date: Tue, 28 Feb 2023 10:44:28 +0100 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: <87zg8yi6x0.fsf@wheatstone.g10code.de> References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> <87zg8yi6x0.fsf@wheatstone.g10code.de> Message-ID: <871FFC18-D009-4DFE-952D-64AA50213639@redhat.com> Hi Werner, Werner Koch via Gnupg-devel wrote: > On Tue, 28 Feb 2023 07:22, Chen, Qi said: > >> I don't know much about gpgme. Could you please tell me why this >> function will not be called when building from tarball? > > You ran the script. This is only needed if you want to build a new > configure script. > > ./configure > make > make install # usually as root > > is the canonical triple jump to build software There are a few distribution build systems out there that will always re-generate configure scripts from configure.ac, and Yocto (as mentioned by the reporter) is one of them. They do this because some projects have been slow in updating their dependencies which occasionally causes problems with the configure scripts, because macros from those dependencies are being copied into ./configure, and re-generating the scripts fixes this. This often addresses problems on new architectures, for example. It would be helpful if GnuPG and gpgme could support re-creation of the configure scripts from the tarballs. Qi: You could delete configure.ac before do_configure, which makes autotools.bbclass avoid the autoreconf [1]. [1] https://git.yoctoproject.org/poky/tree/meta/classes-recipe/autotools.bbclass#n174 HTH, Clemens From wk at gnupg.org Tue Feb 28 15:00:08 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Feb 2023 15:00:08 +0100 Subject: [gpgme][PATCH] autogen.sh: remove '-unknown' in version In-Reply-To: <871FFC18-D009-4DFE-952D-64AA50213639@redhat.com> (Clemens Lang's message of "Tue, 28 Feb 2023 10:44:28 +0100") References: <20230228060949.3116-1-Qi.Chen@windriver.com> <875ybmjmi3.fsf@wheatstone.g10code.de> <87zg8yi6x0.fsf@wheatstone.g10code.de> <871FFC18-D009-4DFE-952D-64AA50213639@redhat.com> Message-ID: <87356pj3fb.fsf@wheatstone.g10code.de> On Tue, 28 Feb 2023 10:44, Clemens Lang said: > It would be helpful if GnuPG and gpgme could support re-creation of the > configure scripts from the tarballs. No, we don't do this on purpose. We use our version of the M4 macros and we have seen in the past that they had regression which introduced hard to find bugs in GnuPG. Thus we don't support anything else than what we delivered in the release tarballs. Viele Gr??e, Werner Koch -- 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: 227 bytes Desc: not available URL: