From jeroen at berkeley.edu Wed Feb 3 13:22:48 2021 From: jeroen at berkeley.edu (Jeroen Ooms) Date: Wed, 3 Feb 2021 13:22:48 +0100 Subject: GitHub mirrors Message-ID: I was wondering if somebody from the official GnuPG team wants to take over the Github mirrors at https://github.com/gpg I created these mirrors mostly a few years ago to make gnupg source code more visible and accessible to millions of users. There is a demand for this, the repositories are "followed" by hundreds of people. The mirroring script is basically a cron job that loops over the various gnupg repos and runs: git clone --mirror git://git.gnupg.org/${REPO}.git (cd $REPO; git push --mirror https://github.com/gpg/${REPO}.git) So it is very easy to do on any server, or github actions. From vuori at notcom.org Wed Feb 3 19:24:34 2021 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Wed, 03 Feb 2021 20:24:34 +0200 Subject: PIV APT parsing compatibility Message-ID: <87zh0hffxw.fsf@notcom.org> Re-sending this (with some edits) since I think the first attempt a few days ago disappeared due to a mail misconfig on my side: Hi, I was giving the PIV support in master a try last night, but the current code for parsing APT objects 0x4F and 0x79 stopped me short. It appears that SP-800-73-x is not too clear about the format of these objects. Many current cards (such as the Yubikey 5 series) apparently have only the PIX in DO 0x4F and only the RID in object 0x79/0x4F. However, other cards as well as the PivApplet Javacard applet have the full AID in 0x4F (which actually seems closer to what the standard says). PivApplet also has the full AID in 0x79/0x4F, but this is probably incorrect. (Here is a long discussion of the matter from an OpenSC author: https://github.com/arekinath/PivApplet/issues/43#issuecomment-772649709) Anyway, I think it would be useful for GnuPG 2.3 to support both formats, since both appear in the wild currently. I have attached the diff I used to make a PivApplet card pass the initial probe. It also still works for a Yubikey 5. (The retry counter in gpg-card also shows an error for PivApplet because app-piv.c queries the Global PIN even though the Discovery Object doesn't indicate support for it. I couldn't try actual sign/encrypt operations yet since card-keys.c can't read certs from gpg/gpgsm.) -Valtteri diff --git a/scd/app-piv.c b/scd/app-piv.c index 36324e630..d36c5c63f 100644 --- a/scd/app-piv.c +++ b/scd/app-piv.c @@ -3641,20 +3641,23 @@ app_select_piv (app_t app) } s = find_tlv (apt, aptlen, 0x4F, &n); - if (!s || n != 6 || memcmp (s, piv_aid+5, 4)) + /* Some cards (new Yubikey) return only the PIX, while others + * (old Yubikey, PivApplet) return the RID+PIX. */ + if (!s || !((n == 6 && memcmp (s, piv_aid+5, 4) == 0) || + (n == 11 && memcmp (s, piv_aid, 9) == 0))) { /* The PIX does not match. */ log_error ("piv: missing or invalid DO 0x4F in APT\n"); err = gpg_error (GPG_ERR_CARD); goto leave; } - if (s[4] != 1 || s[5] != 0) + if (s[n-2] != 1 || s[n-1] != 0) { log_error ("piv: unknown PIV version %u.%u\n", s[4], s[5]); err = gpg_error (GPG_ERR_CARD); goto leave; } - app->appversion = ((s[4] << 8) | s[5]); + app->appversion = ((s[n-2] << 8) | s[n-1]); s = find_tlv (apt, aptlen, 0x79, &n); if (!s || n < 7) @@ -3664,7 +3667,9 @@ app_select_piv (app_t app) goto leave; } s = find_tlv (s, n, 0x4F, &n); - if (!s || n != 5 || memcmp (s, piv_aid, 5)) + /* Some cards may also return the full AID instead of just + * the 5-byte RID here. */ + if (!s || !(n == 5 || n == 11) || memcmp (s, piv_aid, 5)) { /* The RID does not match. */ log_error ("piv: missing or invalid DO 0x79.4F in APT\n"); From bjk at luxsci.net Tue Feb 9 06:37:02 2021 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 8 Feb 2021 21:37:02 -0800 Subject: OpenPGP smartcard and supported curves Message-ID: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> Hi all, I have version 3.4 OpenPGP smartcard and am trying to get ed25519 keys working. I have tried generating a signing key on-card and also importing via the keytocard command of --card-edit with both methods returning an 'Invalid value' error. The nist keys work fine. Is this a limitation of the card? Thanks, -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kloecker at kde.org Tue Feb 9 08:58:04 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 09 Feb 2021 08:58:04 +0100 Subject: OpenPGP smartcard and supported curves In-Reply-To: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> References: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> Message-ID: <25208161.JTfsz8KkW3@breq> Hi, I think the gnupg-users mailing list would have been the more appropriate mailing list for your message. On Dienstag, 9. Februar 2021 06:37:02 CET Ben Kibbey wrote: > Hi all, > > I have version 3.4 OpenPGP smartcard and am trying to get ed25519 keys > working. I have tried generating a signing key on-card and also > importing via the keytocard command of --card-edit with both methods > returning an 'Invalid value' error. The nist keys work fine. Is this a > limitation of the card? Which version of gpg (gpg --version) are you using? Which commands did you use? What was the exact output? Did you try to track down the problem by enabling more verbose/debug output? The current development version which is going to become gpg 2.3 has seen a lot of improvements for smartcards. Since you are writing to the development mailing list, I suggest that you give gpg 2.3 a try (after compiling it yourself). I think "Invalid value" points more to a limitation of gpg (probably scdaemon) than a limitation of the card. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Tue Feb 9 08:33:53 2021 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 9 Feb 2021 08:33:53 +0100 Subject: OpenPGP smartcard and supported curves In-Reply-To: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> References: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> Message-ID: <7bf614c6-4e5d-87e2-3e5a-e5d50049b6e2@metacode.biz> Hi Ben, On 09.02.2021 06:37, Ben Kibbey wrote: > I have version 3.4 OpenPGP smartcard and am trying to get ed25519 keys > working. I have tried generating a signing key on-card and also > importing via the keytocard command of --card-edit with both methods > returning an 'Invalid value' error. The nist keys work fine. Is this a > limitation of the card? I haven't seen this error personally but just for completeness sake you may change the key card attribute if you didn't try that: $ gpg --edit-card gpg/card> admin gpg/card> key-attr Changing card key attribute for: Signature key Please select what kind of key you want: (1) RSA (2) ECC Your selection? 2 Please select which elliptic curve you want: (1) Curve 25519 (4) NIST P-384 Your selection? 1 gpg/card> generate (adapted from https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html ). Kind regards, Wiktor From wk at gnupg.org Tue Feb 9 10:07:22 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Feb 2021 10:07:22 +0100 Subject: OpenPGP smartcard and supported curves In-Reply-To: <7bf614c6-4e5d-87e2-3e5a-e5d50049b6e2@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Tue, 9 Feb 2021 08:33:53 +0100") References: <1612849024-2169279.69497302.f1195b3sq008791@rs161.luxsci.com> <7bf614c6-4e5d-87e2-3e5a-e5d50049b6e2@metacode.biz> Message-ID: <871rdppq2d.fsf@wheatstone.g10code.de> On Tue, 9 Feb 2021 08:33, Wiktor Kwapisiewicz said: > Please select which elliptic curve you want: > (1) Curve 25519 Note that this is for a Yubikey and not for Zeitcontrol card. The OpenPGP spec allows for Curve25519 but not all implementations support it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cb at gnupg.org Tue Feb 9 13:00:15 2021 From: cb at gnupg.org (Christoph Biedl) Date: Tue, 9 Feb 2021 13:00:15 +0100 Subject: GitHub mirrors In-Reply-To: References: Message-ID: <1612863616@msgid.g10code.com> Jeroen Ooms wrote... > I was wondering if somebody from the official GnuPG team wants to take > over the Github mirrors at https://github.com/gpg We're certainly interested in doing this, although the main purpose is visibility. So it would continue to be just a mirror. Please contact me or Werner so we can arrange things. Kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: cbiedl.asc Type: application/pgp-keys Size: 904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dashohoxha at gmail.com Wed Feb 10 21:59:38 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 10 Feb 2021 21:59:38 +0100 Subject: Implementing a WKS solution Message-ID: Hi, It seems to me that the wiki page of WKS is a bit outdated: https://wiki.gnupg.org/WKS The RFC description seems to be up to date, but it also says that it is a "draft". The manual pages of gpg-wks-server and gpg-wks-client may need some updates too. A page with information that seems outdated does not inspire confidence in people. Personally I believe that WKS works well, but I have seen people who are seeking alternative solutions because they say that it "never moved past the alpha stage". So, what is the status of WKS? Is it tested and safe? Another issue that I have come across is that procmail seems to be unmaintained for a long time (https://lwn.net/Articles/416901/). One of the recommended replacements is maildrop, which is also more readable, and a bit safer (because it saves mails to a temporary file first, before processing them). Has anyone tried it for WKS, or has any idea on how to convert the procmail recipe to a maildrop recipe? Actually I don't mind that procmail is unmaintained or less readable, as long as I have a recipe that works as expected, and I know that it has no safety or robustness problems. Finally, I am implementing a generic mail server solution with WKD+WKS support. It would be great if someone could help with checking that I am doing it correctly and safely: - https://gitlab.com/docker-scripts/postfix/-/blob/master/docs/3-wkd-wks.md - https://gitlab.com/docker-scripts/postfix/-/blob/master/cmd/wkd.sh - https://gitlab.com/docker-scripts/postfix/-/blob/master/scripts/wks.sh - https://gitlab.com/docker-scripts/postfix/-/blob/master/tests/test3.sh I have tested it myself and it works. But I am more interested in testing how safe it is if someone tries to break it. I don't doubt the strength of GPG or the WKS protocol, but I doubt my skills in Postfix configuration (which is quite complex to be honest). I am going to make a test mailserver installation soon, so that anyone interested may try to check it and identify any problems. Thanks, Dashamir From m at the13thletter.info Fri Feb 12 14:12:15 2021 From: m at the13thletter.info (Marco Ricci) Date: Fri, 12 Feb 2021 14:12:15 +0100 Subject: Ed25519 keys: what's stored in a secret key packet? Message-ID: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> Greetings! I'm having trouble verifying what exactly an OpenPGP secret key packet for Ed25519 keys is supposed to contain, i.e. what the fields in the secret key packet actually represent. I think that the spec [1] (and its later version [2]), if implemented literally, would cause part of the information necessary for signing to be lost. My understanding of Ed25519 is based on Brian Warner's presentation [3]: * Ed25519 keys start as a 32-byte seed `k`, which is hashed and divided into a left half `LH` and a right half `RH`. * `LH` is massaged into a secret scalar `a`, from which the public key `A` is derived via EC point multiplication. * Ed25519 signatures consist of two encoded EC points `R` and `S`. `R` depends solely on `r`, the DSA secret "random" integer (which in Ed25519 is deterministically computed from the message `M` and from `RH`). `S` is computed from `A`, `a`, `M`, `R` and `r`. In particular, from my understanding, Ed25519 signatures are deterministic, and require calculating or storing `RH` to achieve that goal; consequently, `k` or `RH` must be part of the secret key's wire format, because calculating `RH` without knowing `k` involves a large partial hash inversion and is thus cryptographically infeasible. The bit-fiddling on `LH` also guarantees that `a` is always divisible by 8. The EdDSA for OpenPGP spec [1] defines the wire format to only contain "an MPI of an integer representing the secret key, which is a scalar of the public EC point". This appears to describe the secret scalar `a`. In contrast, SSH, or more specifically the SSH agent protocol [4], defines the wire format of Ed25519 keys to contain the seed `k`. It is unclear to me how OpenPGP would ensure that Ed25519 signatures remain deterministic -- which I verified that they are -- if neither `k` nor `RH` is stored in the secret key material. Some testing with sample Ed25519 keys and GnuPG's `--list-packets` indicates that the range of possible values for the secret MPI value is actually consistent with `k`, but not with `a`, because not all sample MPI values were divisible by 8. Thus, my question: What exactly does the scalar in an OpenPGP Ed25519 secret key denote? The Ed25519 multiplicative scalar `a` such that the public key `A` is `a` times the Ed25519 base point? Or the seed `k` such that `a` and `RH` are derived from `SHA512(k)`? Thanks, and cheers, Marco [1]: https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-04#section-4 [2]: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-5.6.5 [3]: https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/ [4]: https://tools.ietf.org/html/draft-miller-ssh-agent-04#section-4.2.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From bertrand at jacquin.bzh Sat Feb 13 17:09:38 2021 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Sat, 13 Feb 2021 16:09:38 +0000 Subject: [PATCH] efl: ensure pinentry window is activated Message-ID: <20210213160938.300512-1-bertrand@jacquin.bzh> This ensure the new window displayed on screen is grabbed/focused and PIN is entered in the newly created window rather than shell or application with active focus which can lead to accidental PIN leak. --- efl/pinentry-efl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/efl/pinentry-efl.c b/efl/pinentry-efl.c index f1fb8b8149f8..2231b70a5c9e 100644 --- a/efl/pinentry-efl.c +++ b/efl/pinentry-efl.c @@ -542,11 +542,13 @@ create_window (void) evas_object_show (obj); elm_win_resize_object_add(win,obj); - evas_object_show(win); if(entry) elm_object_focus_set (entry, EINA_TRUE); + evas_object_show(win); + elm_win_activate(win); + if (pinentry->timeout > 0) timer = ecore_timer_add (pinentry->timeout, (Ecore_Task_Cb)timeout_cb, From bertrand at jacquin.bzh Sat Feb 13 16:37:54 2021 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Sat, 13 Feb 2021 15:37:54 +0000 Subject: [PATCH] efl: convert pinentry description to markup Message-ID: <20210213153754.299212-1-bertrand@jacquin.bzh> elm_object_text_set() is expecting markup text as input, leading all \n to not be displayed as new line, making the EFL pinentry box more difficult to read --- efl/pinentry-efl.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/efl/pinentry-efl.c b/efl/pinentry-efl.c index ca9969365dd9..f1fb8b8149f8 100644 --- a/efl/pinentry-efl.c +++ b/efl/pinentry-efl.c @@ -249,8 +249,8 @@ create_window (void) if (pinentry->title) { - txt = pinentry_utf8_to_local (pinentry->lc_ctype, - pinentry->title); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, + pinentry->title)); elm_win_title_set ( win, txt ); free (txt); } @@ -263,7 +263,7 @@ create_window (void) obj = elm_label_add(table); elm_label_line_wrap_set (obj, ELM_WRAP_WORD); - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->description); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->description)); len = strlen(txt)+20; // 20 chars for align tag aligned = calloc(len+1,sizeof(char)); if(aligned) @@ -284,7 +284,7 @@ create_window (void) { /* Error Label */ if (pinentry->error) - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->error); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->error)); else txt = ""; obj = elm_label_add(table); @@ -312,7 +312,7 @@ create_window (void) { /* Entry/Prompt Label */ obj = elm_label_add(table); - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->prompt); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->prompt)); elm_object_text_set(obj,txt); free (txt); evas_object_size_hint_weight_set(obj, 0, EVAS_HINT_EXPAND); @@ -356,8 +356,8 @@ create_window (void) { /* Quality Bar Label */ obj = elm_label_add(table); - txt = pinentry_utf8_to_local (pinentry->lc_ctype, - pinentry->quality_bar); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, + pinentry->quality_bar)); elm_object_text_set(obj,txt); free (txt); evas_object_size_hint_weight_set(obj, 0, EVAS_HINT_EXPAND); @@ -381,8 +381,8 @@ create_window (void) { /* Repeat Label */ obj = elm_label_add(table); - txt = pinentry_utf8_to_local (pinentry->lc_ctype, - pinentry->repeat_passphrase); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, + pinentry->repeat_passphrase)); elm_object_text_set(obj,txt); free (txt); evas_object_size_hint_weight_set(obj, 0, EVAS_HINT_EXPAND); @@ -440,10 +440,10 @@ create_window (void) if (pinentry->cancel || pinentry->default_cancel) { if(pinentry->cancel) - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->cancel); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->cancel)); else - txt = pinentry_utf8_to_local (pinentry->lc_ctype, - pinentry->default_cancel); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, + pinentry->default_cancel)); if(txt[0]=='_') elm_object_text_set(obj,txt+1); else @@ -488,9 +488,9 @@ create_window (void) if (pinentry->ok || pinentry->default_ok) { if(pinentry->ok) - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->ok); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->ok)); else - txt = pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->default_ok); + txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local (pinentry->lc_ctype, pinentry->default_ok)); if(txt[0]=='_') elm_object_text_set(obj,txt+1); else From James.Bottomley at HansenPartnership.com Sat Feb 13 21:17:31 2021 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 13 Feb 2021 12:17:31 -0800 Subject: Ed25519 keys: what's stored in a secret key packet? In-Reply-To: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> References: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> Message-ID: On Fri, 2021-02-12 at 14:12 +0100, Marco Ricci wrote: > Greetings! > > I'm having trouble verifying what exactly an OpenPGP secret key > packet for Ed25519 keys is supposed to contain, i.e. what the fields > in the secret key packet actually represent. I think that the spec > [1] (and its later version [2]), if implemented literally, would > cause part of the information necessary for signing to be lost. > > My understanding of Ed25519 is based on Brian Warner's presentation > [3]: > > * Ed25519 keys start as a 32-byte seed `k`, which is hashed and > divided into a left half `LH` and a right half `RH`. > > * `LH` is massaged into a secret scalar `a`, from which the public > key > `A` is derived via EC point multiplication. > > * Ed25519 signatures consist of two encoded EC points `R` and `S`. > `R` > depends solely on `r`, the DSA secret "random" integer (which in > Ed25519 is deterministically computed from the message `M` and > from > `RH`). `S` is computed from `A`, `a`, `M`, `R` and `r`. > > In particular, from my understanding, Ed25519 signatures are > deterministic, and require calculating or storing `RH` to achieve > that goal; consequently, `k` or `RH` must be part of the secret key's > wire format, because calculating `RH` without knowing `k` involves a > large partial hash inversion and is thus cryptographically > infeasible. The bit-fiddling on `LH` also guarantees that `a` is > always divisible by 8. Well 2^3 is the cofactor of the Bernstein curve, yes. > The EdDSA for OpenPGP spec [1] defines the wire format to only > contain "an MPI of an integer representing the secret key, which is a > scalar of the public EC point". This appears to describe the secret > scalar `a`. In contrast, SSH, or more specifically the SSH agent > protocol [4], defines the wire format of Ed25519 keys to contain the > seed `k`. It is unclear to me how OpenPGP would ensure that Ed25519 > signatures remain deterministic -- which I verified that they are -- > if neither `k` nor `RH` is stored in the secret key material. Some > testing with sample Ed25519 keys and GnuPG's `--list-packets` > indicates that the range of possible values for the secret MPI value > is actually consistent with `k`, but not with `a`, because not all > sample MPI values were divisible by 8. Firstly the EdDSA signature algorithm uses a private bit string K in the computation r = H(KM). Traditionally K is the high part of the hash of the private key (i.e. LH in your description above) to avoid having to rely on random numbers but the algorithm works equally well if K is simply a random number. As long as K remains unknown to anyone except the signer, the signature is secure and will verify correctly. > Thus, my question: What exactly does the scalar in an OpenPGP Ed25519 > secret key denote? The Ed25519 multiplicative scalar `a` such that > the public key `A` is `a` times the Ed25519 base point? Or the seed > `k` such that `a` and `RH` are derived from `SHA512(k)`? Is your problem with what the standard says or what gnupg actually does? Because what it does is store the encrypted s-expression of the private key in the key file exactly as libgcrypt supplies it and libgcrypt makes d one of the parameters of this s-expression. d is what you call k above: the random 32 bit number. libgcrypt correctly calculates the public key from the lower 32 bytes of the hash of k (i.e. RH above). See ecc-eddsa.c:_gcry_ecc_eddsa_genkey(). James -------------- 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 doug at rekt.email Sun Feb 14 05:43:23 2021 From: doug at rekt.email (Doug Richardson) Date: Sun, 14 Feb 2021 04:43:23 +0000 Subject: DCO for Doug Richardson Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Doug Richardson Public key available at one of the following: https://dougrichardson.us/pgp.asc https://keys.openpgp.org/vks/v1/by-fingerprint/63A29F3E95EBEDB04414A7288AA46ADA9C89C7E8 -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTODqzCLpkustLeyC2BPlP6QuuVKwUCYCipxAAKCRCBPlP6QuuV K/MoAQClsWD6tI/PgQbzBuPY+d352CH/LbSFgJk1llWGPI44FgD9F4hSdRPtA6u/ 70qHsglhKk05rD7dhYtc89PqCUSAJA0= =u1w2 -----END PGP SIGNATURE----- From m at the13thletter.info Sun Feb 14 11:07:20 2021 From: m at the13thletter.info (Marco Ricci) Date: Sun, 14 Feb 2021 11:07:20 +0100 Subject: Ed25519 keys: what's stored in a secret key packet? In-Reply-To: References: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> Message-ID: <7ed3c83b-d515-f038-bcce-83f561fa1afd@the13thletter.info> Greetings! Thus spoke James Bottomley: >> The bit-fiddling on `LH` also guarantees that `a` is >> always divisible by 8. > > Well 2^3 is the cofactor of the Bernstein curve, yes. I'm aware. I wanted to stress that `a` has range restrictions, and thus has a characteristic bit pattern when serialized as an OpenPGP MPI. > Firstly the EdDSA signature algorithm uses a private bit string K in > the computation r = H(KM). Traditionally K is the high part of the > hash of the private key (i.e. LH in your description above) to avoid > having to rely on random numbers but the algorithm works equally well > if K is simply a random number. As long as K remains unknown to anyone > except the signer, the signature is secure and will verify correctly. I'm aware, as well. I believe though that the normative EdDSA version is to use the `r = H(KM)` calculation. I see no indication in the EdDSA for OpenPGP spec that a non-standard version of determining `r` is used. > Is your problem with what the standard says or what gnupg actually > does? Because what it does is store the encrypted s-expression of the > private key in the key file exactly as libgcrypt supplies it and > libgcrypt makes d one of the parameters of this s-expression. d is > what you call k above: the random 32 bit number. The former, sort of. But this actually answers my question. Thanks. I couldn't sensibly determine what libgcrypt's output is and whether GnuPG transforms it or not before encoding it as an OpenPGP secret key packet. (I couldn't find any documentation on the s-expression shape, nor could I get GnuPG to actually emit the s-expression, so I gathered that to get my answer I'd have to write my own C program to interface libgcrypt, which I don't feel confident enough to attempt yet with my current level of familiarity with libgcrypt.) Knowing that libgcrypt yields the `d`/`k` value and that it ends up in the secret key packet clears my doubts on what those secret key packets really contain. But then the spec and GnuPG's behavior differ, no? And one of them should be fixed -- presumably the spec, because it's still a draft, and because IMO the current practice is saner than the spec. Should I file a proper report against the spec then? Regards, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Sun Feb 14 16:13:26 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 14 Feb 2021 16:13:26 +0100 Subject: Implementing a WKS solution In-Reply-To: References: Message-ID: On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha wrote: > Finally, I am implementing a generic mail server solution with WKD+WKS > support. It would be great if someone could help with checking that I > am doing it correctly and safely: > - https://gitlab.com/docker-scripts/postfix/-/blob/master/docs/3-wkd-wks.md > - https://gitlab.com/docker-scripts/postfix/-/blob/master/cmd/wkd.sh > - https://gitlab.com/docker-scripts/postfix/-/blob/master/scripts/wks.sh > - https://gitlab.com/docker-scripts/postfix/-/blob/master/tests/test3.sh > > I have tested it myself and it works. But I am more interested in > testing how safe it is if someone tries to break it. I don't doubt the > strength of GPG or the WKS protocol, but I doubt my skills in Postfix > configuration (which is quite complex to be honest). I am going to > make a test mailserver installation soon, so that anyone interested > may try to check it and identify any problems. I have installed a test mailserver for the domain `tst1.fs.al`. More details on this post: https://community.fsfe.org/t/testing-a-mail-server-with-wkd-wks-support/606 I am sure it has some problems, because I am not sure that everything is correct. Please help me to find and fix any problems. Happy #ilovefs day, and happy hacking. Dashamir From dashohoxha at gmail.com Sun Feb 14 16:24:54 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 14 Feb 2021 16:24:54 +0100 Subject: Implementing a WKS solution In-Reply-To: References: Message-ID: On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha wrote: > It seems to me that the wiki page of WKS is a bit outdated: > https://wiki.gnupg.org/WKS > The RFC description seems to be up to date, but it also says that it > is a "draft". The manual pages of gpg-wks-server and gpg-wks-client > may need some updates too. By the way, I am willing to help with updating these pages, if help is needed. From James.Bottomley at HansenPartnership.com Sun Feb 14 19:58:40 2021 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 14 Feb 2021 10:58:40 -0800 Subject: Ed25519 keys: what's stored in a secret key packet? In-Reply-To: <7ed3c83b-d515-f038-bcce-83f561fa1afd@the13thletter.info> References: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> <7ed3c83b-d515-f038-bcce-83f561fa1afd@the13thletter.info> Message-ID: On Sun, 2021-02-14 at 11:07 +0100, Marco Ricci wrote: > Greetings! > > Thus spoke James Bottomley: > > > The bit-fiddling on `LH` also guarantees that `a` is > > > always divisible by 8. > > > > Well 2^3 is the cofactor of the Bernstein curve, yes. > > I'm aware. I wanted to stress that `a` has range restrictions, and > thus has a characteristic bit pattern when serialized as an OpenPGP > MPI. > > > Firstly the EdDSA signature algorithm uses a private bit string K > > in the computation r = H(KM). Traditionally K is the high part of > > the hash of the private key (i.e. LH in your description above) to > > avoid having to rely on random numbers but the algorithm works > > equally well if K is simply a random number. As long as K remains > > unknown to anyone except the signer, the signature is secure and > > will verify correctly. > > I'm aware, as well. I believe though that the normative EdDSA version > is to use the `r = H(KM)` calculation. I see no indication in the > EdDSA for OpenPGP spec that a non-standard version of determining `r` > is used. libgcrypt uses K = LH The relevant code is ecc-eddsa.c:_gcry_ecc_eddsa_sign The only slight deviation gnupg does for elliptic curves is that it uses RFC6979 deterministic signatures for ECDSA. > > Is your problem with what the standard says or what gnupg actually > > does? Because what it does is store the encrypted s-expression of > > the private key in the key file exactly as libgcrypt supplies it > > and libgcrypt makes d one of the parameters of this s- > > expression. d is what you call k above: the random 32 bit number. > > The former, sort of. But this actually answers my question. Thanks. > I couldn't sensibly determine what libgcrypt's output is and whether > GnuPG transforms it or not before encoding it as an OpenPGP secret > key packet. (I couldn't find any documentation on the s-expression > shape, nor could I get GnuPG to actually emit the s-expression, so I > gathered that to get my answer I'd have to write my own C program to > interface libgcrypt, which I don't feel confident enough to attempt > yet with my current level of familiarity with libgcrypt.) Knowing > that libgcrypt yields the `d`/`k` value and that it ends up in the > secret key packet clears my doubts on what those secret key packets > really contain. > > But then the spec and GnuPG's behavior differ, no? And one of them > should be fixed -- presumably the spec, because it's still a draft, > and because IMO the current practice is saner than the spec. Should I > file a proper report against the spec then? Well, it's not really relevant any more: The spec is documenting the secring keypacket format, which isn't used by current gnupg (it started switching to the encrypted s-expression format in 2017). The current format is documented in agent/keyformat.txt James -------------- 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 m at the13thletter.info Mon Feb 15 00:08:57 2021 From: m at the13thletter.info (Marco Ricci) Date: Mon, 15 Feb 2021 00:08:57 +0100 Subject: Ed25519 keys: what's stored in a secret key packet? In-Reply-To: References: <268e091f-b2d3-59f2-2612-a87c9b59eed1@the13thletter.info> <7ed3c83b-d515-f038-bcce-83f561fa1afd@the13thletter.info> Message-ID: Greetings! Thus spoke James Bottomley: >> I'm aware, as well. I believe though that the normative EdDSA version >> is to use the `r = H(KM)` calculation. I see no indication in the >> EdDSA for OpenPGP spec that a non-standard version of determining `r` >> is used. > > libgcrypt uses K = LH > > The relevant code is ecc-eddsa.c:_gcry_ecc_eddsa_sign > > The only slight deviation gnupg does for elliptic curves is that it > uses RFC6979 deterministic signatures for ECDSA. The latter is good to know, thanks. I believe you on the former -- it looks plausible, given the libgcrypt code -- but I gave up trying to actually verify it. I find libgcrypt's code rather too opaque and confusing for me to follow. (But then I've touched libgcrypt for all of 10mins, I'm not too familiar with its coding style (names, data structures, etc.), and this kind of low-level C code isn't really my forte anyway.) >> But then the spec and GnuPG's behavior differ, no? And one of them >> should be fixed -- presumably the spec, because it's still a draft, >> and because IMO the current practice is saner than the spec. Should I >> file a proper report against the spec then? > > Well, it's not really relevant any more: The spec is documenting the > secring keypacket format, which isn't used by current gnupg (it started > switching to the encrypted s-expression format in 2017). Inasfar as GnuPG alone is concerned, maybe, but what about file exchange of secret keys between different OpenPGP implementations, say GnuPG and Thunderbird/RNP? My reason for worrying about secret key contents in the first place is because I ultimately want to share Ed25519 key material between OpenPGP and (Open)SSH, and perhaps other systems. And the most future-proof way of doing that is to attempt converting the "standard" key formats of the respective systems into one another. That use case would definitely benefit from a corrected spec. > The current format is documented in agent/keyformat.txt I'm starting to feel like I'm not doing my homework properly. Thanks again for the pointer, I'll give the v2.3+ text-based private key format a try. Regards, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Mon Feb 15 13:27:56 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 15 Feb 2021 12:27:56 +0000 Subject: [PATCH] efl: convert pinentry description to markup In-Reply-To: <20210213153754.299212-1-bertrand@jacquin.bzh> References: <20210213153754.299212-1-bertrand@jacquin.bzh> Message-ID: <20210215122756.nzybvf2xdql5r2qa@dynein.local.incenp.org> Hi, On Sat, Feb 13, 2021 at 03:37:54PM +0000, Bertrand Jacquin wrote: >+ txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local >(pinentry->lc_ctype, pinentry->title)); Not familiar with EFL, but shouldn?t it be the other way around? If the elm_entry_utf8_to_markup function expects UTF8 input (as the name implies), calling it *after* pinentry_utf8_to_local doesn?t look right? It seems to me that you should first convert to markup (which leaves the string in the original UTF-8 encoding), and *then* convert to the local encoding. Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Mon Feb 15 13:33:34 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 15 Feb 2021 12:33:34 +0000 Subject: [PATCH] efl: ensure pinentry window is activated In-Reply-To: <20210213160938.300512-1-bertrand@jacquin.bzh> References: <20210213160938.300512-1-bertrand@jacquin.bzh> Message-ID: <20210215123334.x3qx3d4kwmgpgoiz@dynein.local.incenp.org> Hi, On Sat, Feb 13, 2021 at 04:09:38PM +0000, Bertrand Jacquin wrote: >This ensure the new window displayed on screen is grabbed/focused and >PIN is entered in the newly created window rather than shell or >application with active focus which can lead to accidental PIN leak. Merged, thanks! Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From bertrand at jacquin.bzh Tue Feb 16 01:09:28 2021 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Tue, 16 Feb 2021 00:09:28 +0000 Subject: [PATCH] efl: convert pinentry description to markup In-Reply-To: <20210215122756.nzybvf2xdql5r2qa@dynein.local.incenp.org> References: <20210213153754.299212-1-bertrand@jacquin.bzh> <20210215122756.nzybvf2xdql5r2qa@dynein.local.incenp.org> Message-ID: Hi On Monday, February 15 2021 at 12:27:56 +0000, Damien Goutte-Gattat wrote: > Hi, > > On Sat, Feb 13, 2021 at 03:37:54PM +0000, Bertrand Jacquin wrote: > >+ txt = elm_entry_utf8_to_markup(pinentry_utf8_to_local > >(pinentry->lc_ctype, pinentry->title)); > > Not familiar with EFL, but shouldn?t it be the other way around? If the > elm_entry_utf8_to_markup function expects UTF8 input (as the name > implies), calling it *after* pinentry_utf8_to_local doesn?t look right? pinentry->description is inherited from SETDESC send by gpg-agent to pinentry. SETDESC content is defined from i18n_localegettext() which assume UTF-8 is used for encoding, however since this function a wrapper around gettext(), the encoding of libgpg-error .po file is authoritative here (which all are in git master). Which means, indeed there is no need to perform pinentry_utf8_to_local() at all since elm_entry_utf8_to_markup() is indeed expecting all input to be UTF-8 which we have guaranteed. Please find attached an updated patch, no change in behaviour. Cheers, Bertrand -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-efl-convert-pinentry-description-to-markup.patch Type: text/x-diff Size: 4335 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Feb 16 13:48:57 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 16 Feb 2021 12:48:57 +0000 Subject: [PATCH] efl: convert pinentry description to markup In-Reply-To: References: <20210213153754.299212-1-bertrand@jacquin.bzh> <20210215122756.nzybvf2xdql5r2qa@dynein.local.incenp.org> Message-ID: <20210216124857.a4oxliwx2x5lrceo@dynein.local.incenp.org> Hi, On Tue, Feb 16, 2021 at 12:09:28AM +0000, Bertrand Jacquin wrote: >Please find attached an updated patch, no change in behaviour. Looks good, merged. Thanks! Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dashohoxha at gmail.com Wed Feb 17 00:08:14 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 17 Feb 2021 00:08:14 +0100 Subject: Implementing a WKS solution In-Reply-To: References: Message-ID: On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha wrote: > Another issue that I have come across is that procmail seems to be > unmaintained for a long time (https://lwn.net/Articles/416901/). One > of the recommended replacements is maildrop, which is also more > readable, and a bit safer (because it saves mails to a temporary file > first, before processing them). Has anyone tried it for WKS, or has > any idea on how to convert the procmail recipe to a maildrop recipe? I replaced procmail by maildrop: https://gitlab.com/docker-scripts/postfix/-/commit/0351603cd55aae57f2fc82e3d13c7b18744f0b67 I am not sure if maildrop is better, but at least it seems to be still maintained: https://sourceforge.net/p/courier/mailman/courier-maildrop/?viewmonth=202102 Some useful pages that helped me to make the migration: - https://www.courier-mta.org/maildropex.html - http://toehold.blogspot.com/2004/05/migrating-from-procmail-to-maildrop.html - http://www.postfix.org/MAILDROP_README.html - https://www.courier-mta.org/maildrop/maildrop.html - https://www.courier-mta.org/maildrop/maildropfilter.html Regards, Dashamir From wk at gnupg.org Wed Feb 17 09:41:31 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Feb 2021 09:41:31 +0100 Subject: [Announce] Libgcrypt 1.9.2 relased Message-ID: <874kibkrwk.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.9.2. This is a maintenance release. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.9.2 ===================================== * Bug fixes: - Fix build problem for macOS in the random code. [#5268] - Fix building with --disable-asm on x86. [#5277] - Check public key for ECDSA verify operation. [#5282] - Make sure gcry_get_config (NULL) returns a nul-terminated string. [8716e4b2ad] - Fix a memory leak in the ECDH code. [289543544e] - Fix a reading beyond end of input buffer in SHA2-avx2. [24af2a55d8] * Other features: - New test driver to allow for standalone regression tests. [b142da4c88] For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T5276 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.2.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.9.2.tar.bz2 you would use this command: gpg --verify libgcrypt-1.9.2.tar.bz2.sig libgcrypt-1.9.2.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 libgcrypt-1.9.2.tar.bz2, you run the command like this: sha1sum libgcrypt-1.9.2.tar.bz2 and check that the output matches the first line from the this list: 29bd5d0a8f674d4521167dd518ef99b26d1e8f27 libgcrypt-1.9.2.tar.bz2 a2972134c55870264a136b37d51836926e13ce60 libgcrypt-1.9.2.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T5276 for updated information. Please also consult the archive of the gcrypt-devel 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 gcrypt-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME, and Gpg4win. We like to thank all the nice people who are helping Libgcrypt, be it testing, coding, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG and Libgcrypt in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel'at'gnupg.org mailing list. p.p.s 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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) rsa2048 2014-10-29 [expired: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) 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. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dashohoxha at gmail.com Wed Feb 17 23:19:42 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 17 Feb 2021 23:19:42 +0100 Subject: Implementing a WKS solution In-Reply-To: References: Message-ID: On Wed, Feb 17, 2021 at 12:08 AM Dashamir Hoxha wrote: > I replaced procmail by maildrop I dropped FROM_DAEMON check. Besides being ugly (in maildrop) it didn't work as expected. Upon thinking about it, it seems that it is needed in case a mail sent from gpg-wks-server is bounced back for some reason. But in this case gpg-wks-server should be able to detect that it is an invalid message and should discard it. So, FROM_DAEMON check is not necessary after all. Is my thinking correct? Dashamir From wk at gnupg.org Mon Feb 22 08:50:02 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Feb 2021 08:50:02 +0100 Subject: GnuPG 2.3 Beta Message-ID: <87wnv0ilsl.fsf@wheatstone.g10code.de> Hi! We plan to soon start with a GnuPG 2.3 series to slightly modernize GnuPG. We will need a few releases to fix still open bugs and to learn about new problems. Before we release 2.3.0 we consider it useful to have a wider beta tests to catch build problems etc. 2.3 is GnuPG Git master and is regulary used at least by us. However, building from Git is harder than building from a regular tarball or just using a Windows installer. Thus here is our Beta: https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2.sig You need the latest version of Libgcrypt and libgpg-error to build it. Windows users may want to try the installer at https://gnupg.org/ftp/gcrypt/binary/unstable/gnupg-w32-2.3.0-beta1598_20210221.exe https://gnupg.org/ftp/gcrypt/binary/unstable/gnupg-w32-2.3.0-beta1598_20210221.exe.sig As usual no guarantee for not breaking things. As long as no new options are used in the config files there should be no problem to move back to 2.2.27. Here is a list of new things which you do not find in 2.2.27: * A new experimental key database daemon is provided. To enable it put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in a SQLite database and make key lookup much faster. [To test this you need to export your public keys to a file, then put the option into gpg.conf and gpgsm.conf and import the keys again.] * New tool gpg-card as a flexible frontend for all types of supported smartcards. * New option --chuid for gpg, gpgsm, gpgconf, gpg-card, and gpg-connect-agent. * The gpg-wks-client tool is now installed under bin; a wrapper for its old location at libexec is also installed. * gpg: Switch to ed25519/cv25519 as default public key algorithms. * gpg: Verification results now depend on the --sender option and the signer's UID subpacket. [T4735] * gpg: Do not use any 64-bit block size cipher algorithm for encryption. Use AES as last resort cipher preference instead of 3DES. This can be reverted using --allow-old-cipher-algos. * gpg: Support AEAD encryption mode using OCB or EAX. * gpg: Support v5 keys and signatures. * gpg: Support curve X448 (ed448, cv448). * gpg: Allow use of group names in key listings. [e825aea2ba] * gpg: New option --full-timestrings to print date and time. * gpg: The legacy key discovery method PKA is no longer supported. The command --print-pka-records and the PKA related import and export options have been removed. * gpgsm: Add basic ECC support. * gpgsm: Support creation of EdDSA certificates. [#4888] * agent: Allow the use of "Label:" in a key file to customize the pinentry prompt. [5388537806] * agent: Support ssh-agent extensions for environment variables. With a patched version of OpenSSH this avoids the need for the "updatestartuptty" kludge. [224e26cf7b] * scd: Improve support for multiple card readers and tokens. * scd: Support PIV cards. * scd: Support the Telesec Signature Card v2.0 * scd: Support multiple application on certain smartcard. * scd: New option --application-priority. * dirmngr: Support a gpgNtds parameter in LDAP keyserver URLs. * The symcryptrun tool, a wrapper for the now obsolete external Chiasmus tool, has been removed. Please send bug report to this list. See https://dev.gnupg.org/T4417 for some work items we still want to address. Happy hacking. Your GnuPG hackers. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Mon Feb 22 09:49:10 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 22 Feb 2021 09:49:10 +0100 Subject: Implementing a WKS solution In-Reply-To: References: Message-ID: <202102220949.16954.bernhard@intevation.de> Hi Dashamir, Am Sonntag 14 Februar 2021 16:24:54 schrieb Dashamir Hoxha via Gnupg-devel: > On Wed, Feb 10, 2021 at 9:59 PM Dashamir Hoxha wrote: > > It seems to me that the wiki page of WKS is a bit outdated: > > https://wiki.gnupg.org/WKS > > The RFC description seems to be up to date, but it also says that it > > is a "draft". thanks for the hints. (I've did some simple updates.) Yes, a lot of drafts take a long while until they get to a more official status. In the case of WKS, I am not sure which working group is responsible and if it is active. Still, it is fine to use drafts, as WKS is a step further from WKD, it may take even more time to distribute. > > The manual pages of gpg-wks-server and gpg-wks-client > > may need some updates too. > > By the way, I am willing to help with updating these pages, > if help is needed. Help is always appreciated and it is a wiki, so you can just go ahead. Coordinate here, do not just replace stuff or call it official, but rather mark it or link additional information. The hint with procmail is certainly a good one, it would be useful to have a tested recipie without it, which is simple. 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, Dr. Jan-Oliver Wagner -------------- 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 dashohoxha at gmail.com Mon Feb 22 16:31:14 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 22 Feb 2021 16:31:14 +0100 Subject: Implementing a WKS solution In-Reply-To: <202102220949.16954.bernhard@intevation.de> References: <202102220949.16954.bernhard@intevation.de> Message-ID: On Mon, Feb 22, 2021 at 11:08 AM Bernhard Reiter wrote: > Help is always appreciated and it is a wiki, so you can just go ahead. > Coordinate here, do not just replace stuff or call it official, but rather > mark it or link additional information. Wiki is good, but a documentation system based on git flow (with merge requests, reviews, etc.) might be better. Anyway, I tried to register and login, but I failed. I have just published a WebKey server which can be integrated with a mail server as an external component, in order to provide WKD+WKS support for it: - https://gitlab.com/docker-scripts/webkey If I try to update the WKS docs I will use this one as a reference for the configurations, commands etc: - https://gitlab.com/docker-scripts/webkey/-/blob/master/scripts/setup.sh Basically I would recommend (or do) these changes: - Remove the instructions about Installing GnuPG from the source code, since this should be explained somewhere else; assume that the users can easily install GnuPG from a package. - Update the instructions for building a WKD and add the configuration of Apache2. - Update the instructions for building a WKS and replace procmail with maildrop. - Update the instructions for testing WKD/WKS and add some details about testing with Thunderbird+Enigmail. - Update the list of WKD/WKS solutions and add there https://gitlab.com/docker-scripts/webkey > The hint with procmail is certainly a good one, it would be useful to > have a tested recipie without it, which is simple. I am testing this maildrop recipe and it seems to work well: - https://gitlab.com/docker-scripts/webkey/-/blob/master/scripts/setup.sh#L121-137 By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems superfluous to me, since 'gpg-wks-server' already adds automatically the header 'Wks-Phase', which should be sufficient for detecting a loop. Am I missing something? Regards, Dashamir From dashohoxha at gmail.com Mon Feb 22 17:03:40 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 22 Feb 2021 17:03:40 +0100 Subject: Updating/improving the docs Message-ID: Hi, If you think that the GnuPG docs need to be updated or improved, either in form or in content, consider participating to Google Season of Docs: "Season of Docs 2021 will allow open source organizations to apply for a grant, based on their documentation needs. If selected, open source organizations will use their grant to hire a technical writer directly to complete their documentation project. Organizations will have up to six months to complete their documentation project." - https://developers.google.com/season-of-docs/docs/organization-application-hints - https://developers.google.com/season-of-docs/docs/timeline Technical writers don't have to be students (actually they are not supposed to be students). If the project proposal is accepted, I would be interested to work as a technical writer for this project. I would enjoy improving the docs of GnuPG, and at the same time the stipend would help me to survive. Thanks, Dashamir From rjh at sixdemonbag.org Mon Feb 22 17:03:49 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Feb 2021 11:03:49 -0500 Subject: GnuPG 2.3 Beta In-Reply-To: <87wnv0ilsl.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> Message-ID: > * A new experimental key database daemon is provided. To enable it > put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in > a SQLite database and make key lookup much faster. [To test this > you need to export your public keys to a file, then put the option > into gpg.conf and gpgsm.conf and import the keys again.] This will make some of my workflow much easier. Thank you! > * gpg: Switch to ed25519/cv25519 as default public key algorithms. Also welcome. > * gpg: Do not use any 64-bit block size cipher algorithm for > encryption. Use AES as last resort cipher preference instead of > 3DES. This can be reverted using --allow-old-cipher-algos. Overdue. Happy to see it! > * gpg: Support AEAD encryption mode using OCB or EAX. Overdue. Also happy to see this. :) Thank you for all your hard work! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mlnl at mailbox.org Mon Feb 22 17:15:48 2021 From: mlnl at mailbox.org (mlnl) Date: Mon, 22 Feb 2021 17:15:48 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87wnv0ilsl.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> Message-ID: <20210222171548.01860e31@localhost> Hi Werner, Werner Koch via Gnupg-devel wrote: >Before we release 2.3.0 we consider it useful to >have a wider beta tests to catch build problems etc. > >2.3 is GnuPG Git master and is regulary used at least by us. However, >building from Git is harder than building from a regular tarball or >just using a Windows installer. Thus here is our Beta: > > https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2 > https://gnupg.org/ftp/gcrypt/gnupg/unstable/gnupg-2.3.0-beta1598.tar.bz2.sig OK, have installed it under Debian Buster. Created a new test key with curve X448. Encrypt, verify and sign files in terminal works, the same with e-mails (with Claws Mail 3.17). Searching and importing your key over keyserver works. Works with Yubikey 4, Samhain HIDS, apt. Passphrase caching with Claws Mail doesn't work, i have to give the passphrase every time. GnuPG v2.3.0-beta1598 has been configured as follows: Revision: 54c1f2518 (21697) Platform: GNU/Linux (x86_64-pc-linux-gnu) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes (without internal CCID driver) G13: no Dirmngr: yes Keyboxd: yes Gpgtar: yes WKS tools: yes Protect tool: /usr/local/bin/gpg-protect-tool LDAP wrapper: /usr/local/bin/dirmngr_ldap Default agent: /usr/local/bin/gpg-agent Default pinentry: /usr/local/bin/pinentry Default scdaemon: /usr/local/bin/scdaemon Default keyboxd: (default) Default dirmngr: /usr/local/bin/dirmngr Dirmngr auto start: yes Readline support: yes LDAP support:yes TLS support: gnutls TOFU support:yes Tor support: yes -- mlnl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0x8777461F2A074EBC480D359419CC1C9E085B107A.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 346 bytes Desc: Digitale Signatur von OpenPGP URL: From wk at gnupg.org Mon Feb 22 19:39:26 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Feb 2021 19:39:26 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: (Robert J. Hansen via Gnupg-devel's message of "Mon, 22 Feb 2021 11:03:49 -0500") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> Message-ID: <87y2fggd5t.fsf@wheatstone.g10code.de> On Mon, 22 Feb 2021 11:03, Robert J. Hansen said: > This will make some of my workflow much easier. Thank you! Take care, it is not yet well tested. I am using it for some time now, though. >> * gpg: Support AEAD encryption mode using OCB or EAX. > > Overdue. Also happy to see this. :) Me too. Will take quite some time until keys with such preferences will be widely used. This implements a draft but we have done interop tests with 2 other implementations and thus I think it is safe to be used. It even seems that Phil Rogaway stopped paying the fees to the PTO and thus uncertainties over OCB mode should be void soon. So no need for any implementations to only provide EAX mode. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kloecker at kde.org Mon Feb 22 21:12:34 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 22 Feb 2021 21:12:34 +0100 Subject: Implementing a WKS solution In-Reply-To: References: <202102220949.16954.bernhard@intevation.de> Message-ID: <2201667.ElGaqSPkdT@collossus.localdomain> On Montag, 22. Februar 2021 16:31:14 CET Dashamir Hoxha via Gnupg-devel wrote: > By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems > superfluous to me, since 'gpg-wks-server' already adds automatically > the header 'Wks-Phase', which should be sufficient for detecting a > loop. Am I missing something? Well, X-WKS-Loop is a single purpose header. Wks-Phase is another header with specific purpose and semantics. It's usually not a good idea to (ab)use some header for a completely orthogonal second purpose. (Using one artifact for one purpose only is a general advice in software engineering.) What if in a later version phase tracking is solved differently? Then you are stuck with a header that is only used for loop detection and has the then completely inappropriate and confusing name Wks-Phase. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From dashohoxha at gmail.com Mon Feb 22 21:25:15 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 22 Feb 2021 21:25:15 +0100 Subject: Implementing a WKS solution In-Reply-To: <2201667.ElGaqSPkdT@collossus.localdomain> References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> Message-ID: On Mon, Feb 22, 2021 at 9:14 PM Ingo Kl?cker wrote: > > On Montag, 22. Februar 2021 16:31:14 CET Dashamir Hoxha via Gnupg-devel wrote: > > By the way, using the header 'X-WKS-Loop' with 'gpg-wks-server' seems > > superfluous to me, since 'gpg-wks-server' already adds automatically > > the header 'Wks-Phase', which should be sufficient for detecting a > > loop. Am I missing something? > > Well, X-WKS-Loop is a single purpose header. Wks-Phase is another header with > specific purpose and semantics. It's usually not a good idea to (ab)use some > header for a completely orthogonal second purpose. (Using one artifact for one > purpose only is a general advice in software engineering.) > > What if in a later version phase tracking is solved differently? Then you are > stuck with a header that is only used for loop detection and has the then > completely inappropriate and confusing name Wks-Phase. It seems to me that phase tracking, no matter how it is done, solves the loop problem as well, because 'gpg-wks-server' will discard a message if it is not in the correct sequence. That's why there is no need to check for a loop outside 'gpg-wks-server'. > > Regards, > Ingo > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Mon Feb 22 22:39:42 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Feb 2021 22:39:42 +0100 Subject: Implementing a WKS solution In-Reply-To: (Dashamir Hoxha via Gnupg-devel's message of "Mon, 22 Feb 2021 21:25:15 +0100") References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> Message-ID: <87sg5nhjdt.fsf@wheatstone.g10code.de> On Mon, 22 Feb 2021 21:25, Dashamir Hoxha said: > message if it is not in the correct sequence. That's why there is no > need to check for a loop outside 'gpg-wks-server'. Do not mix protocol layers - it is just stupid to do so. Mail is already garrulous enough and thus there is nothing to gain from saving a few header lines. BTW, procmail is one of the most reliable and matured mail tool. Together with uucp and a bulk of other standard software. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dashohoxha at gmail.com Tue Feb 23 06:26:23 2021 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 23 Feb 2021 06:26:23 +0100 Subject: Implementing a WKS solution In-Reply-To: <87sg5nhjdt.fsf@wheatstone.g10code.de> References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> <87sg5nhjdt.fsf@wheatstone.g10code.de> Message-ID: On Mon, Feb 22, 2021 at 10:40 PM Werner Koch wrote: > Do not mix protocol layers - it is just stupid to do so. Mail is > already garrulous enough and thus there is nothing to gain from saving a > few header lines. I am trying to make the procmail/maildrop recipe as simple as possible (but not simpler). I am not trying to save a few header lines. > BTW, procmail is one of the most reliable and matured mail tool. > Together with uucp and a bulk of other standard software. I have no reason to doubt this. Do you think that using procmail is better than using maildrop? By the way, I am not really sure that the way that I am using to integrate a mail server with the WKS server is the best or most easy one: https://gitlab.com/docker-scripts/webkey#configuration-on-the-mail-server I have just tried different postfix options until I found a way that works. Some review or feedback from any postfix experts would be useful. Thanks, Dashamir From rjh at sixdemonbag.org Tue Feb 23 07:40:44 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Feb 2021 01:40:44 -0500 Subject: Implementing a WKS solution In-Reply-To: <87sg5nhjdt.fsf@wheatstone.g10code.de> References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> <87sg5nhjdt.fsf@wheatstone.g10code.de> Message-ID: > BTW, procmail is one of the most reliable and matured mail tool. The last maintainer of procmail disagrees: https://marc.info/?l=openbsd-ports&m=141634350915839&w=2 From wk at gnupg.org Tue Feb 23 08:36:05 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 08:36:05 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <20210222171548.01860e31@localhost> (mlnl via Gnupg-devel's message of "Mon, 22 Feb 2021 17:15:48 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <20210222171548.01860e31@localhost> Message-ID: <87im6jgrru.fsf@wheatstone.g10code.de> On Mon, 22 Feb 2021 17:15, mlnl said: > OK, have installed it under Debian Buster. Created a new test key with > curve X448. Encrypt, verify and sign files in terminal works, the same > with e-mails (with Claws Mail 3.17). Searching and importing your key > over keyserver works. Works with Yubikey 4, Samhain HIDS, apt. Thanks for testing. What ist the Samhain HIDS - it does sound not like an OpenPGP card so you used it with S/MIME? > Passphrase caching with Claws Mail doesn't work, i have to give the > passphrase every time. That is strange because the caching is done in gpg-agent and independent of the Pinentry or an application using GnuPG (via GPGME in the Claws case). The most likely reason that it does not work is that the agent has been stopped before the next operation was done. I don't know why but sometimes systemd's removal of the /run/users/UID directory is a problem. Can you please add log-file /somewhere/gpg-agent/log verbose debug ipc into ~/.gnupg/gpg-agent.log, restart gpg-agent and try again. The log file should give some clues what's going wrong. You may add "debug cache" to trace the caching but I doubt that this is the case. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 23 08:58:14 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 08:58:14 +0100 Subject: Implementing a WKS solution In-Reply-To: (Robert J. Hansen via Gnupg-devel's message of "Tue, 23 Feb 2021 01:40:44 -0500") References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> <87sg5nhjdt.fsf@wheatstone.g10code.de> Message-ID: <87eeh7gqqx.fsf@wheatstone.g10code.de> On Tue, 23 Feb 2021 01:40, Robert J. Hansen said: > The last maintainer of procmail disagrees: Well, that is the opinion of a maintainer who worked on it for 2 or 3 years, expressed his opinion 13 years later, and meanwhile 7 more years passed by. Santiago Vila is still maintaining procmail for Debian and he did so for nearly 25 years. The last overflow detected by fuzzing was found and fixed in 2017. Agreed, procmail had its history of bugs back in the 90ies. But a lot of software had these problems and even the poster boy of severe bugs, sendmail, is nowadays a pretty solid thing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From m at the13thletter.info Tue Feb 23 10:48:43 2021 From: m at the13thletter.info (Marco Ricci) Date: Tue, 23 Feb 2021 10:48:43 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87wnv0ilsl.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> Message-ID: <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> Hi. Thus spoke Werner Koch: > * A new experimental key database daemon is provided. To enable it > put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in > a SQLite database and make key lookup much faster. [To test this > you need to export your public keys to a file, then put the option > into gpg.conf and gpgsm.conf and import the keys again.] Forgive my ignorance, but why exactly do you set up a new daemon for this? Just based on the description of the feature, I would have rather expected a shared library to be used for this, well, shared functionality. Why use a daemon instead? What sort of background work does the keybox daemon do that necessitates an unattended long-running background process? At the very least, it seems pretty overkill to me. Cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From m at the13thletter.info Tue Feb 23 10:49:26 2021 From: m at the13thletter.info (Marco Ricci) Date: Tue, 23 Feb 2021 10:49:26 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87y2fggd5t.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <87y2fggd5t.fsf@wheatstone.g10code.de> Message-ID: Hi. Thus spoke Werner Koch: >>> * gpg: Support AEAD encryption mode using OCB or EAX. >> >> Overdue. Also happy to see this. :) > > Me too. Will take quite some time until keys with such preferences > will be widely used. This implements a draft but we have done interop > tests with 2 other implementations and thus I think it is safe to be > used. Do these comments about interoperability/consensus apply to v5 keys, signatures and the X448 curve as well? Or are those still true draft features? Cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From cb at gnupg.org Tue Feb 23 11:09:45 2021 From: cb at gnupg.org (Christoph Biedl) Date: Tue, 23 Feb 2021 11:09:45 +0100 Subject: Implementing a WKS solution In-Reply-To: <87sg5nhjdt.fsf@wheatstone.g10code.de> References: <202102220949.16954.bernhard@intevation.de> <2201667.ElGaqSPkdT@collossus.localdomain> <87sg5nhjdt.fsf@wheatstone.g10code.de> Message-ID: <1614072818@msgid.g10code.com> Werner Koch via Gnupg-devel wrote... > BTW, procmail is one of the most reliable and matured mail tool. But at the same time using a complex and fragile configuration syntax. No problem if you see that every day and know all the ins and outs. But for me, user of procmail since 2004, every change I have to do, every few months or so, makes me nervous whether things will still work as expected. And reading other people's recipies can easily turn into headache. And I am biased due to a major desaster many, many years ago when a co-worker accidentially placed a newline character into the rc, resulting in, if memory serves me right, something like * ^Header: content which was valid procmail but went unnoticed until the next day. In other words, the procmailrc format is not something I would want to recommend anywhere. While still better than sendmail.cf or ircd "lines", it's too risky. Today's computing ressources are really sufficient enough to allow focussing on being more readable and less error-prone. Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 23 13:15:30 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 13:15:30 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: (Marco Ricci's message of "Tue, 23 Feb 2021 10:49:26 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <87y2fggd5t.fsf@wheatstone.g10code.de> Message-ID: <87tuq3f09p.fsf@wheatstone.g10code.de> On Tue, 23 Feb 2021 10:49, Marco Ricci said: > Do these comments about interoperability/consensus apply to v5 keys, > signatures and the X448 curve as well? Or are those still true draft X448 is too new and we have not done interop tests which we did for v5 keys and signatures (but less diligent than for AEAD). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 23 13:24:27 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Feb 2021 13:24:27 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> (Marco Ricci's message of "Tue, 23 Feb 2021 10:48:43 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> Message-ID: <87pn0rezus.fsf@wheatstone.g10code.de> On Tue, 23 Feb 2021 10:48, Marco Ricci said: > Forgive my ignorance, but why exactly do you set up a new daemon for > this? Just based on the description of the feature, I would have rather We use SQLite and transactions are very expensive if more than one process is accessing the DB. So what we do is what all other database engines do: run a single process with exclusive access to the DB. There is some overhead due to IPC but overall things are much faster. The reason why several processes need to access the DB is that there are often several gpg processes running and working on the same keyring. This needs to be synchronized. Without the keyboxd we lock the keyring and all other gpg and gpgsm processes need to wait until they can continue even with a read. This multi-process serialization slows down everything. Try running Kleopatra with a large keyring with and without keyboxd. It makes a huge difference. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From m at the13thletter.info Wed Feb 24 12:06:15 2021 From: m at the13thletter.info (Marco Ricci) Date: Wed, 24 Feb 2021 12:06:15 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87tuq3f09p.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <87y2fggd5t.fsf@wheatstone.g10code.de> <87tuq3f09p.fsf@wheatstone.g10code.de> Message-ID: <0b59caa1-71cd-0d3e-94e1-e44d132300af@the13thletter.info> Greetings. Thus spoke Werner Koch: > X448 is too new and we have not done interop tests which we did for v5 > keys and signatures (but less diligent than for AEAD). Then let me ask directly: if I generate an Ed448 key (packet), an ECDH X448 key (packet), or a general v5 key or v5 signature packet, using GnuPG 2.3beta, can I assume that when exporting such keys/signatures they (a) conform to RFC4880bis-10, and (b) they remain *valid* packets even when RFC4880bis is finalized? Or is the format still experimental? I took your previous commentary about AEAD to mean that EAX and OCB mode are pretty much final, as far as RFC4880bis is concerned, and that you're in the phase "we need multiple interoperable implementations in the wild so that we can add this to the RFC, so now we're releasing one such implementation". So what I'm actually wondering about is whether this holds for the v5 keys/signatures and X448 formats as well. Thanks, and cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From m at the13thletter.info Wed Feb 24 12:06:42 2021 From: m at the13thletter.info (Marco Ricci) Date: Wed, 24 Feb 2021 12:06:42 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87pn0rezus.fsf@wheatstone.g10code.de> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> <87pn0rezus.fsf@wheatstone.g10code.de> Message-ID: <7189376c-f71b-a5d0-f923-b7343a469865@the13thletter.info> Greetings. Thus spoke Werner Koch: > On Tue, 23 Feb 2021 10:48, Marco Ricci said: > >> Forgive my ignorance, but why exactly do you set up a new daemon for >> this? Just based on the description of the feature, I would have rather > > We use SQLite and transactions are very expensive if more than one > process is accessing the DB. So what we do is what all other database > engines do: run a single process with exclusive access to the DB. There > is some overhead due to IPC but overall things are much faster. I see. This makes me really sad... even though I can see the temptation to solve the performance issue this way. > The reason why several processes need to access the DB is that there are > often several gpg processes running and working on the same keyring. > This needs to be synchronized. Without the keyboxd we lock the keyring > and all other gpg and gpgsm processes need to wait until they can > continue even with a read. This multi-process serialization slows down > everything. I grepped the current git HEAD -- I have no idea which commit the beta is supposed to be, I couldn't find a tag or anything -- and saw that you don't use SQLite's WAL mode [1], which is designed for better reader/writer-concurrency than naive full file locking. Have you tried that already? From what the documentation says, SQLite's native Unix and Windows drivers can make use of shared-memory primitives on both systems, so you wouldn't need to go the slower route of synchronizing via full file locks... on Unix and Windows at least. [1]: https://sqlite.org/wal.html (I checked dev.gnupg.org, but couldn't find any mention of WAL mode.) (Or is the design already at the WONTFIX stage?) On that note: Both the beta and git HEAD require SQLite 3.7 in configure/configure.ac. But in T4510 you started shipping (requiring?) SQLite 3.28. Perhaps you need to update and/or re-evaluate which SQLite version you require at a minimum? This might then be a good time to check if requiring a newer SQLite and then using WAL mode solves your performance problems. Cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Feb 24 21:58:39 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Feb 2021 21:58:39 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <7189376c-f71b-a5d0-f923-b7343a469865@the13thletter.info> (Marco Ricci's message of "Wed, 24 Feb 2021 12:06:42 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> <87pn0rezus.fsf@wheatstone.g10code.de> <7189376c-f71b-a5d0-f923-b7343a469865@the13thletter.info> Message-ID: <87tuq1chds.fsf@wheatstone.g10code.de> On Wed, 24 Feb 2021 12:06, Marco Ricci said: > I see. This makes me really sad... even though I can see the temptation > to solve the performance issue this way. The overhead is really minimal. For example I tried descriptor forwarding instead of using inline data in the IPC. This did not make much of a difference and thus the code is not anymore used. > I grepped the current git HEAD -- I have no idea which commit the beta > is supposed to be, I couldn't find a tag or anything -- and saw that you gpgconf --show-versions | head -1 shows the commit. > don't use SQLite's WAL mode [1], which is designed for better > reader/writer-concurrency than naive full file locking. Have you tried > that already? From what the documentation says, SQLite's native Unix We use Sqlite for Tofu for quite some time and did some experiments. Given that gpg is short-living process you don't get any advantage from that. Really, a dedicted server process is the most robust and fastest solution. > (Or is the design already at the WONTFIX stage?) We need this and it was a long standing plan to unify the database storage. And we expected complains about yet another process ;-) > configure/configure.ac. But in T4510 you started shipping (requiring?) > SQLite 3.28. Perhaps you need to update and/or re-evaluate which SQLite Yeah, we should eventually update our copy. We have a copy of sqlite on our server due to our build process. > version you require at a minimum? This might then be a good time to > check if requiring a newer SQLite and then using WAL mode solves your Long running daemons can cache, shor tunning processes can't. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 24 22:15:24 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Feb 2021 22:15:24 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <0b59caa1-71cd-0d3e-94e1-e44d132300af@the13thletter.info> (Marco Ricci's message of "Wed, 24 Feb 2021 12:06:15 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <87y2fggd5t.fsf@wheatstone.g10code.de> <87tuq3f09p.fsf@wheatstone.g10code.de> <0b59caa1-71cd-0d3e-94e1-e44d132300af@the13thletter.info> Message-ID: <87pn0pcglv.fsf@wheatstone.g10code.de> On Wed, 24 Feb 2021 12:06, Marco Ricci said: > Then let me ask directly: if I generate an Ed448 key (packet), an ECDH > X448 key (packet), or a general v5 key or v5 signature packet, using I would not suggest to do this because there are to my knowledge no other implementations which can use that. OTOH, cv25519/ed25519 support is widely deployed and for example protonmail.com uses it for more than a year by default. BTW, for AEAD we have even read support in 2.2 so that if something goes wrong with AEAD preferences 2.2 can still receive such messages. > GnuPG 2.3beta, can I assume that when exporting such keys/signatures > they (a) conform to RFC4880bis-10, and (b) they remain *valid* packets > even when RFC4880bis is finalized? Or is the format still experimental? I can't know for sure but there are at least 3 mainstream implementations using this format (openpgp.js, rnp, gnupg). > I took your previous commentary about AEAD to mean that EAX and OCB mode > are pretty much final, as far as RFC4880bis is concerned, and that > you're in the phase "we need multiple interoperable implementations in > the wild so that we can add this to the RFC, so now we're releasing one We do have these implementaions adn did interop tests several years ago. There were just some disturbing actions in the WG so that the area director decided to start from scratch. > such implementation". So what I'm actually wondering about is whether > this holds for the v5 keys/signatures and X448 formats as well. We did fewer interop tests and the WG once had rough consensus. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 24 22:51:37 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Feb 2021 22:51:37 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <87tuq1chds.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-devel's message of "Wed, 24 Feb 2021 21:58:39 +0100") References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <0f946360-866a-da67-79e0-bb9c69358444@the13thletter.info> <87pn0rezus.fsf@wheatstone.g10code.de> <7189376c-f71b-a5d0-f923-b7343a469865@the13thletter.info> <87tuq1chds.fsf@wheatstone.g10code.de> Message-ID: <87k0qxcexi.fsf@wheatstone.g10code.de> On Wed, 24 Feb 2021 21:58, Werner Koch said: > Yeah, we should eventually update our copy. We have a copy of sqlite on > our server due to our build process. Oops, I misunderstood you. We actually use 3.28 but the configure does not require 3.28. I guess will update this so that ppl are forced to install a fixed copy on their system. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cb at gnupg.org Thu Feb 25 16:26:36 2021 From: cb at gnupg.org (Christoph Biedl) Date: Thu, 25 Feb 2021 16:26:36 +0100 Subject: GitHub mirrors In-Reply-To: References: Message-ID: <1614266579@msgid.g10code.com> Jeroen Ooms wrote... > I created these mirrors mostly a few years ago to make gnupg source > code more visible and accessible to millions of users. There is a > demand for this, the repositories are "followed" by hundreds of > people. The repositories have been brought under the maintainence of GnuPG in the past days, so they are no longer inofficial. Otherwise, the status has not changed: Please continue using the bug tracker or the mailing lists for communication. Thanks to Jeroen for allocating that namespace and keeping it in shape in the past, and again for the offer to transfer it to us. Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From m at the13thletter.info Thu Feb 25 16:40:48 2021 From: m at the13thletter.info (Marco Ricci) Date: Thu, 25 Feb 2021 16:40:48 +0100 Subject: GnuPG 2.3 Beta In-Reply-To: <20210222171548.01860e31@localhost> References: <87wnv0ilsl.fsf@wheatstone.g10code.de> <20210222171548.01860e31@localhost> Message-ID: Greetings. Another report on Debian/amd64. I tried a couple of build variations from scratch, using GCC 9.3.0 and all the latest tarballs from all dependencies (gnupg-2.3.0-beta1598, libassuan-2.5.4, libgcrypt-1.9.2, libgpg-error-1.41, libksba-1.5.0, npth-1.6, ntbtls-0.2.0 and sqlite-amalgamation-3340100). All dependencies were installed per-user, not system-wide, and only in a common build directory outside of /usr. SQLite 3.27.2 is also available system-wide. All components were configured with --with-libgpg-error-prefix=... etc. as applicable. GnuPG was further configured with --with-capabilities. * A normal (dynamically linked) build works just fine, for every component. Just like for mlnl. * A static build with LDFLAGS=-static works in all components except GnuPG itself, where neither the linked in libsqlite3.a nor libgpg-error.a can resolve the dlsym and pthread symbols. * A normal build with musl-gcc may or may not work; I couldn't properly test it due to the ntbtls issue below. I don't have clang installed, so no idea about that either. * Both the npth and gnupg configure scripts claim to support --with-libksba-prefix=DIR. Using that option has no effect. Using the option --with-ksba-prefix=DIR instead (i.e. without the "lib" prefix) works, and has the desired effect. * ntbtls configure claims to support --with-zlib=DIR. Using this has no effect; zlib is required to be in the standard location, else the build fails. * gnupg configure does not support specifying an alternate sqlite3 location; there is no --with-sqlite3-prefix or similar. My example build thus linked against SQLite 3.27 as provided by my system, instead of SQLite 3.34 as intended by me. Hope this helps. Cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Fri Feb 26 09:22:13 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 26 Feb 2021 09:22:13 +0100 Subject: [PATCH] gpgconf STABLE-BRANCH-2-2 deprecate option hint Message-ID: <202102260922.21071.bernhard@intevation.de> Use the description to flag an option as deprecated so this is displayed in GUI clients (like Kleopatra). Got a real user question about this, so the hint would help users. (But it may trigger translation changes, and I'm not sure what the policy of this is in STABLE-BRANCH-2-2) Bernhard diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c index 0618125cf..c1ded8f60 100644 --- a/tools/gpgconf-comp.c +++ b/tools/gpgconf-comp.c @@ -751 +751 @@ static gc_option_t gc_options_gpg[] = - "gnupg", N_("|URL|use keyserver at URL"), /* Deprecated - use dirmngr */ + "gnupg", N_("|URL|use keyserver at URL (deprecated - use Network settings)"), /* Deprecated - use dirmngr */ -------------- 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 Fri Feb 26 09:32:48 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 26 Feb 2021 09:32:48 +0100 Subject: procmail and maildrop for WKS? (Re: Implementing a WKS solution) In-Reply-To: <1614072818@msgid.g10code.com> References: <87sg5nhjdt.fsf@wheatstone.g10code.de> <1614072818@msgid.g10code.com> Message-ID: <202102260933.08706.bernhard@intevation.de> Am Dienstag 23 Februar 2021 11:09:45 schrieb Christoph Biedl via Gnupg-devel: > In other words, the procmailrc format is not something I would want to > recommend anywhere. Any changes to mail filtering must be tested. (Personally I found the syntax fine when using procmails many years ago. Then sieve was complex on different parts. Guess it is the problem that is complex.) If procmail itself does not have known flaws, then of course the programming style, language and config format maybe old style, but we can still recommend its usage, because of its widespread use and long time maturity. Naturally, it is cool to have alternative recipies for maildrop and other solutions, we must just see who maintains them. ;) Best 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, Dr. Jan-Oliver Wagner -------------- 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 Fri Feb 26 09:36:46 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 26 Feb 2021 09:36:46 +0100 Subject: Wiki as documentation (and registration problems) (was: Implementing a WKS solution) In-Reply-To: References: <202102220949.16954.bernhard@intevation.de> Message-ID: <202102260936.46466.bernhard@intevation.de> Am Montag 22 Februar 2021 16:31:14 schrieb Dashamir Hoxha via Gnupg-devel: > Wiki is good, but a documentation system based on git flow (with merge > requests, reviews, etc.) might be better. The wiki has a lower access barrier, so it is easier to make changes. On the other hand the information can be less reliable (because many people can just change it). Andre any myself keep an eye on changes a bit, so bad changes get reverted in a reasonable timeframe. > Anyway, I tried to register and login, but I failed. Please email me personally with the details if there is something wrong with the wiki registration. Best 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, Dr. Jan-Oliver Wagner -------------- 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 Fri Feb 26 11:00:28 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 26 Feb 2021 11:00:28 +0100 Subject: Updating/improving the docs In-Reply-To: References: Message-ID: <202102261100.35329.bernhard@intevation.de> Hi Dashamir, Am Montag 22 Februar 2021 17:03:40 schrieb Dashamir Hoxha via Gnupg-devel: > If you think that the GnuPG docs need to be updated or improved, > either in form or in content, consider participating to Google Season > of Docs thanks for the suggestion! We do believe that docs should be better, but it is very unlikely that we participate this particular funding program. To explain: The GnuPG development team has a long standing tradition to not advertise for Google by participating in their programs or by using their services. They use some of their "programs" to also gain mindshare and place themselfes in a good light. Aren't there some useful things done by Google for Free Software and cryptography? Yes, there are. This is a very large organisation and there are nice groups and individuals inside it, with some friendly and interesting technical projects. My scepticism is more about the course of the whole company and how its long term business interests and accumulated powers are contrary to a decentral, cooperating vision of information technology in the world. (However this is just stating it superficially, here on this mailinglist is not the right place to discuss in more detail, we'd be getting off-topic. I'm just mentioning it to aid your understanding.) Another difficulty with a project-based approach (that means goals and end and limited resources) is that it is not what the GnuPG ecosystem needs most in terms of improving the user experience. If we can avoid to write documentation, we should. The approach of a minimal documenation (like in the tradition of John M. Caroll) and the concept of self-explorability and don't-make-me-think usability are (in my view) more suited to a modern set of crypto based applications for end to end security. Approaching this would mean long term engagement and funding if it is done by professionals. Best 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, Dr. Jan-Oliver Wagner -------------- 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 noloader at gmail.com Fri Feb 26 10:05:11 2021 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Feb 2021 04:05:11 -0500 Subject: Wiki as documentation (and registration problems) (was: Implementing a WKS solution) In-Reply-To: <202102260936.46466.bernhard@intevation.de> References: <202102220949.16954.bernhard@intevation.de> <202102260936.46466.bernhard@intevation.de> Message-ID: On Fri, Feb 26, 2021 at 3:37 AM Bernhard Reiter wrote: > > Am Montag 22 Februar 2021 16:31:14 schrieb Dashamir Hoxha via Gnupg-devel: > > Wiki is good, but a documentation system based on git flow (with merge > > requests, reviews, etc.) might be better. > > The wiki has a lower access barrier, so it is easier to make changes. > On the other hand the information can be less reliable (because many people > can just change it). Andre any myself keep an eye on changes a bit, so bad > changes get reverted in a reasonable timeframe. Information management is hard. I find wikis are the best way to disseminate long term, less frequently changing information. In contrast, README's don't work. They have not worked in 50 years and they are not going to magically start working now. Mailing lists are good for immediate problems, like break fix. But mailing lists are harder to search and follow. Information is too disjoint and spread across multiple posts. Wikis have a confounding property (to me) that they always arrive at the right answer. It does not matter that contributors are not subject matter experts. The crowd always arrives at the right answer. Someone wrote a paper explaining the property, but I have never been able to locate it. Also see https://www.npr.org/sections/money/2015/08/07/430372183/episode-644-how-much-does-this-cow-weigh. Wikis are also well indexed by search engines so users who make an effort to search can readily find the information. In one experiment OpenSSL performed, the topic of "How to compile and install openssl" was tested. The subject used to get 10 to 20 questions a month on the OpenSSL mailing list. After adding a detailed wiki page on the subject, the mailing list questions dropped to nearly 0. I also find it a good habit to... When someone asks a question on the mailing list or Stack Overflow, add a topic about it in your wiki. When the next person asks the same question, provide a link to the topic in your wiki. Search engines pick up on those inward links and drive your canonical answer to the top. Then, users find your canonical answer more easily. Wikis also help relieve project maintainers from writing all the documentation themselves. If a project maintainer complains they don't have time, then they need to use the right tool for the job and learn to delegate to the crowd. Jeff From rjh at sixdemonbag.org Fri Feb 26 21:51:29 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Feb 2021 15:51:29 -0500 Subject: 2.3 keydb problems Message-ID: <5c72bba1-399d-a322-f8f7-b8108f349301@sixdemonbag.org> After switching to the new SQLite keydb, I can no longer list my keyring and things are a little weird. [rjh at localhost build]$ gpg -vvvv --list-keys gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: using character set 'utf-8' gpg: Note: RFC4880bis features are enabled. gpg: key 1E7A94D4E87F91D5: accepted as trusted key ... and there it hangs. No further output is generated. Any ideas? From wk at gnupg.org Sat Feb 27 16:48:21 2021 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Feb 2021 16:48:21 +0100 Subject: 2.3 keydb problems In-Reply-To: <5c72bba1-399d-a322-f8f7-b8108f349301@sixdemonbag.org> (Robert J. Hansen via Gnupg-devel's message of "Fri, 26 Feb 2021 15:51:29 -0500") References: <5c72bba1-399d-a322-f8f7-b8108f349301@sixdemonbag.org> Message-ID: <87o8g5a4vu.fsf@wheatstone.g10code.de> On Fri, 26 Feb 2021 15:51, Robert J. Hansen said: > gpg: key 1E7A94D4E87F91D5: accepted as trusted key > > ... and there it hangs. No further output is generated. No immediate idea. What you can do is to out log-file /somewhere/keyboxd.log verbose debug ipc,lookup int keyboxd.conf, gpgconf --kill keyxboxd, and try again. This should at least show where it hangs. Shalom-Salam, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Sat Feb 27 18:20:17 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 27 Feb 2021 12:20:17 -0500 Subject: 2.3 keydb problems In-Reply-To: <87o8g5a4vu.fsf@wheatstone.g10code.de> References: <5c72bba1-399d-a322-f8f7-b8108f349301@sixdemonbag.org> <87o8g5a4vu.fsf@wheatstone.g10code.de> Message-ID: > int keyboxd.conf, gpgconf --kill keyxboxd, and try again. This should > at least show where it hangs. gpgconf hanged while trying to kill keyboxd. Interesting. I 'sudo kill'ed the keyboxd process and tried again. It appears to be waiting forever for a stale lock: [rjh at localhost ~]$ tail -f keyboxd.log 2021-02-27 12:17:04 keyboxd[65434] listening on socket '/run/user/1000/gnupg/S.keyboxd' 2021-02-27 12:17:05 keyboxd[65435] waiting for lock (held by 535569) ... 2021-02-27 12:17:06 keyboxd[65435] waiting for lock (held by 535569) ... 2021-02-27 12:17:08 keyboxd[65435] waiting for lock (held by 535569) ... 2021-02-27 12:17:12 keyboxd[65435] waiting for lock (held by 535569) ... 2021-02-27 12:17:20 keyboxd[65435] waiting for lock (held by 535569) ... 2021-02-27 12:17:28 keyboxd[65435] waiting for lock (held by 535569) ... There is no process with PID 535569. The same stale lock is responsible for gpgconf not being able to kill the process. From rjh at sixdemonbag.org Sun Feb 28 06:52:47 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2021 00:52:47 -0500 Subject: 2.3 keydb problems In-Reply-To: References: <5c72bba1-399d-a322-f8f7-b8108f349301@sixdemonbag.org> <87o8g5a4vu.fsf@wheatstone.g10code.de> Message-ID: > I 'sudo kill'ed the keyboxd process and tried again.? It appears to > be waiting forever for a stale lock: The problem -- with the same error (waiting for a lock held by 535569) -- persists across reboots. I'm comfortable saying this is a serious bug. Want me to file it in git? From nicolas.fella at gmx.de Sun Feb 28 14:34:10 2021 From: nicolas.fella at gmx.de (Nicolas Fella) Date: Sun, 28 Feb 2021 14:34:10 +0100 Subject: [PATCH GnuPG 1/2] Keep temp files when opening images via xdg-open Message-ID: <20210228133411.127214-1-nicolas.fella@gmx.de> xdg-open spawns the user's preferred image viewer and then exits. Therefore we must not remove the temp file when it exits, otherwise by the time the actual image viewer is started the file doesn't exist any more. Signed-off-by: Nicolas Fella --- g10/photoid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/g10/photoid.c b/g10/photoid.c index 592d5e484..e6f0a41a6 100644 --- a/g10/photoid.c +++ b/g10/photoid.c @@ -287,7 +287,8 @@ get_default_photo_command(void) else if (!path_access ("display",X_OK)) return "display -title 'KeyID 0x%k' %i"; else if (getuid () && !path_access ("xdg-open", X_OK)) - return "xdg-open %i"; + /* xdg-open spawns the actual program and exits so we need to keep the temp file */ + return "xdg-open %I"; else return "/bin/true"; #endif -- 2.30.1 From nicolas.fella at gmx.de Sun Feb 28 14:34:11 2021 From: nicolas.fella at gmx.de (Nicolas Fella) Date: Sun, 28 Feb 2021 14:34:11 +0100 Subject: [PATCH GnuPG 2/2] Prefer opening images with xdg-open over display In-Reply-To: <20210228133411.127214-1-nicolas.fella@gmx.de> References: <20210228133411.127214-1-nicolas.fella@gmx.de> Message-ID: <20210228133411.127214-2-nicolas.fella@gmx.de> xdg-open respects the user's configured image viewer and is therefore preferred. display is still available as a fallback when xdg-open isn't available. Signed-off-by: Nicolas Fella --- g10/photoid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/g10/photoid.c b/g10/photoid.c index e6f0a41a6..1ba8190b9 100644 --- a/g10/photoid.c +++ b/g10/photoid.c @@ -284,11 +284,11 @@ get_default_photo_command(void) #else if (!path_access ("xloadimage", X_OK)) return "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"; - else if (!path_access ("display",X_OK)) - return "display -title 'KeyID 0x%k' %i"; else if (getuid () && !path_access ("xdg-open", X_OK)) /* xdg-open spawns the actual program and exits so we need to keep the temp file */ return "xdg-open %I"; + else if (!path_access ("display",X_OK)) + return "display -title 'KeyID 0x%k' %i"; else return "/bin/true"; #endif -- 2.30.1 From kloecker at kde.org Sun Feb 28 17:40:57 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 28 Feb 2021 17:40:57 +0100 Subject: [PATCH GnuPG 2/2] Prefer opening images with xdg-open over display In-Reply-To: <20210228133411.127214-2-nicolas.fella@gmx.de> References: <20210228133411.127214-1-nicolas.fella@gmx.de> <20210228133411.127214-2-nicolas.fella@gmx.de> Message-ID: <2489301.z5ICp2W6VN@breq> Hi Nicolas, any reason why xloadimage should still be preferred over xdg-open? Regards, Ingo On Sonntag, 28. Februar 2021 14:34:11 CET Nicolas Fella via Gnupg-devel wrote: > xdg-open respects the user's configured image viewer > and is therefore preferred. > > display is still available as a fallback when xdg-open > isn't available. > > Signed-off-by: Nicolas Fella > --- > g10/photoid.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/g10/photoid.c b/g10/photoid.c > index e6f0a41a6..1ba8190b9 100644 > --- a/g10/photoid.c > +++ b/g10/photoid.c > @@ -284,11 +284,11 @@ get_default_photo_command(void) > #else > if (!path_access ("xloadimage", X_OK)) > return "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"; > - else if (!path_access ("display",X_OK)) > - return "display -title 'KeyID 0x%k' %i"; > else if (getuid () && !path_access ("xdg-open", X_OK)) > /* xdg-open spawns the actual program and exits so we need to keep the > temp file */ return "xdg-open %I"; > + else if (!path_access ("display",X_OK)) > + return "display -title 'KeyID 0x%k' %i"; > else > return "/bin/true"; > #endif > -- > 2.30.1 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: