From christoph-klassen at mail.de Sun Jan 2 14:33:26 2022 From: christoph-klassen at mail.de (Christoph Klassen) Date: Sun, 2 Jan 2022 14:33:26 +0100 Subject: Mistake in GNU Privacy Handbook Message-ID: A happy new year to all of you! I'm not sure, if this is the right place to report mistakes/requests for the GNU Privacy Handbook. If yes: In the section "Validating other keys on your public keyring" (https://www.gnupg.org/gph/en/manual.html#AEN335) there is a table below figure 3-1. In the last row in the last column there are the four names Blake, Chloe, Elena, and Francis. But, since Dharma's key is also signed by Alice, it is also fully valid and should also be in this cell. Greetings, Christoph Klassen -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jan 3 08:19:26 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Jan 2022 08:19:26 +0100 Subject: [Announce] A New Future for GnuPG Message-ID: <871r1p1e2p.fsf@wheatstone.g10code.de> Hello and a Happy Gnu Year! It has been quite some time since my last status report on GnuPG. I have been quite busy working on the project but unfortunately rarely active on the usual channels. So, here is a new report telling what we did over the last two or three years. Please read at least the last section. A web version of this article is available at https://gnupg.org/blog/20220102-a-new-future-for-gnupg.html Some background =============== In the beginning GnuPG was a fun project I did in my spare time. After a few years this turned out to be a full time job and it was possible to acquire paid projects to maintain and further develop GnuPG. When the BSI (Germany's Federal Office for Information Security) migrated back from Linux to Windows, a need to migrate their end-to-end encryption solution, based on GnuPG and KMail, was needed. A call for bids for an Open Source solution was issued and our company, g10 Code, along with our friends at Intevation and KDAB received the contract. The outcome was Gpg4win, the meanwhile standard distribution of GnuPG for Windows. It turned out that the software used in Germany to protect restricted data at the VS-NfD level, called Chiasmus, showed its age. For example, the block length of 64 bits (like IDEA or 3DES) is not anymore secure for data of more than 150 MiB. Also the secret encryption algorithm has not anymore the confidence people used to have in it and due to lacking hardware support it is quite slow. A new call to bid for a replacement of that software was issued and we also with Intevation were granted the contract. Our solution was to update GnuPG and its frontends Kleopatra and GpgOL. After some thorough evaluation of our software (working title /Gpg4VS-NfD/) and the usual bureaucratic we received a first approval in January 2019. Meet GnuPG.com ============== I have been working with Andre Heinecke of Intevation GmbH since about 2010 on Gpg4win and some other projects. With the foreseeable approval of /Gpg4VS-NfD/ Andre then left Intevation and took over 40% of the g10 Code shares from my brother (I am holding the other 60%). We started to make a real product out of /Gpg4VS-NfD/. Thus we rented a new office to work desk by desk on this and hired staff for sales and marketing. We introduced the brand /GnuPG.com/ to have a better recognition of our product than by our legal name /g10 Code GmbH/. The software itself was re-branded as /GnuPG VS-Desktop?/ and distributed as an MSI packet for Windows and as an AppImage for Linux. Except for customer specific configuration files /GnuPG VS-Desktop/ is and will always be Open Source under the GNU General Public License. We also keep maintaining /Gpg4win/ as the community version. This is based on the the same source code as /GnuPG VS-Desktop/ but comes with more features due to the use of the latest development branch. The benefits for the customer to pay for /GnuPG VS-Desktop/ are: a commercial support contract, the guarantee of a long term maintained and approved version, customization options, community tested new features, and the per-approval required vendor for security updates. Also technically published for longer, it became only last year widely known, that the legacy Chiasmus software may not anymore be used for restricted communication from this year on. For the administration and also for the industry two option exist to migrate away from Chiasmus: the proprietary GreenBone software from /cryptovision GmbH/ and our Open Source software /GnuPG VS-Desktop/. The rush towards GnuPG VS-Desktop ================================= Since summer 2021 the phones of our sales team didn't stop ringing and we could bring in the fruits of our work. We were not aware how many different governmental agencies exist and how many of them have a need to protect data at the VS-NfD (restricted) level. And with those agencies also comes a huge private and corporate sector who also have to handle such communication. Although we support S/MIME, the majority of our customers decided in favor of the OpenPGP protocol, due to its higher flexibility and independence of a centralized public key infrastructure. A minor drawback is that for a quick start and easy migration from Chiasmus, many sites will use symmetric-only encryption (i.e. based on "gpg -c"). However, the now deployed software provides the foundation to move on to a comfortable public-key solution. In particular, our now smooth integration into Active Directory makes working with OpenPGP under Windows really nice. We were also able to partner with Rohde & Schwarz Cybersecurity GmbH for a smooth integration of GnuPG VS-Desktop with their smartcard administration system. We estimate that a quarter million workplaces will be equipped with GnuPG VS-Desktop and provide the users state of the art file and mail encryption. Our longer term plan is to equip all public agency workplaces with end-to-end encryption software - not only those with an immediate need for an approved VS-NfD solution. This should also fit well into the announced goal of the new German government to foster the development of Open Source. Kudos to all supporters ======================= For many years our work was mainly financed by donations and smaller projects. Now we have reached a point where we can benefit from a continuous revenue stream to maintain and extend the software without asking for donations or grants. This is quite a new experience to us and I am actually a bit proud to lead one of the few self-sustaining free software projects who had not to sacrifice the goals of the movement. Those of you with SEPA donations, please cancel them and redirect your funds to other projects which are more in need of financial support. The Paypal and Stripe based recurring donations have already been canceled by us. All you supporters greatly helped us to keep GnuPG alive and to finally setup a sustainable development model. *Thank you!* Salam-Shalom, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- g10 Code GmbH -=- GnuPG.com -=- AmtsGer. Wuppertal HRB 14459 Bergstr. 3a Gesch?ftsf?hrung Werner Koch D-40699 Erkrath https://gnupg.com USt-Id DE215605608 -------------- 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 liste at secarica.ro Tue Jan 4 14:55:52 2022 From: liste at secarica.ro (Cristian =?UTF-8?Q?Secar=C4=83?=) Date: Tue, 4 Jan 2022 15:55:52 +0200 Subject: issues with Unicode characters in UI dialogues (at least on Windows) Message-ID: <20220104155552.0000175d@secarica.ro> (message resent with links to snapshots instead of attached snapshots; the list rejected my previous message due to "Message body is too big: 97216 bytes with a limit of 60 KB"; hmm: 94 KiB too big in year 2022 ? this reminds me of the BBS era...) There are two type of Unicode issues related to some UI dialogues - at least on Windows (in my case version 10, 64bit). 1. Pure Unicode characters that are not present in 8-bit Windows codepage With reference to the snapshot https://www.secarica.ro/traduceri/misc/01_pinentry-qt_prompt_from_claws-mail_ro.png the translation for "Cancel" button contains the ? character (U+021B) that is not part of any 8-bit Windows codepage (let alone the current one) and because of that it displays a ? instead, which is common for 8-bit only (i.e. ancient) programs; more than that, as seen in the snapshot https://www.secarica.ro/traduceri/misc/02_pinentry-qt_prompt_from_claws-mail_ro_retry.png this happens also with the translated string "Bad Passphrase", which I guess it comes from the combination of these two strings: #: agent/call-pinentry.c:1566 agent/call-pinentry.c:1830 msgid "SETERROR %s (try %d of %d)" msgstr "SETERROR %s (?ncercarea %d din %d)" #: agent/call-pinentry.c:1622 agent/call-pinentry.c:1885 msgid "Bad Passphrase" msgstr "Fraz?-parol? gre?it?" To be noted that the rest of the strings in that dialog *are* correct, despite the presence of the same ? character elsewhere ("Introduce?i fraza-parol? etc.") These dialogues are related to Claws Mail, but the next ones are related to Mozilla Firefox and an installed extension called Mailvelope. 2. Mess with UTF-8 characters With reference to the snapshot https://www.secarica.ro/traduceri/misc/03_pinentry-qt_prompt_from_ff_ro_utf-u_error.png the translation of the main text is screwed at every UTF-8 character; at the same time, in the snapshot https://www.secarica.ro/traduceri/misc/04_pinentry-qt_prompt_from_ff_ro_utf-u_error_retry.png it can be observed a mix of problem from 1. (i.e. just out-of-8-bit-codepage issue on the red string) combined with this UTF-8 mess. *To be noted here the translated string that says "Not?: cerere de la browserul web."* This sting is this one: #: agent/command.c:823 msgid "Note: Request from the web browser." msgstr "Not?: cerere de la browserul web." 3. Just about the same dialogues, *except for a single difference*: on the above msgstr string, I eliminated the ? character, thus leaving the "Nota: cerere de la browserul web." string as pure ASCII only; now the UTF-8 mess no longer occur, only the out-of-8-bit-codepage issue remains: https://www.secarica.ro/traduceri/misc/05_pinentry-qt_prompt_from_ff_ro.png https://www.secarica.ro/traduceri/misc/06_pinentry-qt_prompt_from_ff_ro_retry.png That ? character triggers in somehow the UTF-8 mess that follows. Maybe this issue has something to do with this quite complex sting: #: g10/passphrase.c:529 msgid "" "%s\n" "\"%.*s\"\n" "%u-bit %s key, ID %s,\n" "created %s%s.\n" "%s" msgstr "" "%1$s\n" "?%3$.*2$s?\n" "cheie %5$s de %4$u de bi?i, ID %6$s,\n" "creat? ?n data de %7$s%8$s\n" "%9$s" 4. Again on Claws Mail, with reference to the snapshot https://www.secarica.ro/traduceri/misc/07_claws-mail_libgpg-error_utf-8_display_error_1.png an error string that is passed from libgpg-error is displayed wrong at UTF-8 encoded characters (this particular string is when canceling an attempt to decrypt a message). The error string comes from here: #: src/err-codes.h:127 msgid "Operation cancelled" msgstr "Opera?iune anulat?" This one has nothing to do with the out-of-8-bit-codepage, since the ? one *is* part of both CP1250 and ISO-8859-2 (while I am sure that the GTK+, on which Claws Mail is based, is, or should be, always Unicode). ?? Cristi -- Cristian Secar? https://www.secarica.ro From kloecker at kde.org Tue Jan 4 16:29:36 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 04 Jan 2022 16:29:36 +0100 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: <20220104155552.0000175d@secarica.ro> References: <20220104155552.0000175d@secarica.ro> Message-ID: <2165184.FksTbfuGOf@daneel> On Dienstag, 4. Januar 2022 14:55:52 CET Cristian Secar? wrote: > (message resent with links to snapshots instead of attached snapshots; the > list rejected my previous message due to "Message body is too big: 97216 > bytes with a limit of 60 KB"; hmm: 94 KiB too big in year 2022 ? this > reminds me of the BBS era...) Don't assume that everybody on this planet has a stable and fast internet connection. > There are two type of Unicode issues related to some UI dialogues - at least > on Windows (in my case version 10, 64bit). It would help if you told us what version of Gpg4win (?) you are using. It may also be better to file bug reports on https://dev.gnupg.org because this makes it much easier to track the different issues. And you can attach snapshots to the bug reports. Regards, Ingo -------------- 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 liste at secarica.ro Tue Jan 4 21:36:41 2022 From: liste at secarica.ro (Cristian =?UTF-8?Q?Secar=C4=83?=) Date: Tue, 4 Jan 2022 22:36:41 +0200 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: <2165184.FksTbfuGOf@daneel> References: <20220104155552.0000175d@secarica.ro> <2165184.FksTbfuGOf@daneel> Message-ID: <20220104223641.000048a4@secarica.ro> ?n data de Tue, 04 Jan 2022 16:29:36 +0100, Ingo Kl?cker a scris: > Don't assume that everybody on this planet has a stable and fast > internet connection. On the contrary: in year 2022 I consider safe to assume that a ~100 K e-mail message [1] is trivial for any available internet connection, even when reading the e-mail with, for example, a 12 years old Symbian based Nokia N8 over a 3G mobile network. If someone still uses a 14,4k modem (at best) for its computer, then that is *its* problem, not to the rest of the world ? not to mention that speed, in this particular case, is of no importance. 30-35 years ago, a single game on Commodore 64 or Sinclair Spectrum 48k/128k was loaded from audio cassette tape in ~3-5 minutes; not a big deal then, unimaginable by many today. > It would help if you told us what version of Gpg4win (?) you are > using. Gpg4win 4.0.0, installed clean ? i.e. no previous Gpg4win installed since last time the I reinstalled the OS. > It may also be better to file bug reports on https://dev.gnupg.org > because this makes it much easier to track the different issues. And > you can attach snapshots to the bug reports. I would have done that (bug report), but what component to consider for report ? First I observed those popup dialog encoding errors during GPA usage when I worked on its translation [2], only later I observed the same errors when interacting with other 'connected' programs; the title bar of the snapshots in question says "pinentry-qt", however, it seems to me (?) that the translated messages are gtk gettext (not Qt); I also assumed (?) that the error messages are distinct from pinentry itself and I also guess that Gpg4win is just a sort of a wrapper for the suite. [1] I just made a test: I forwarded my links-only message to a Gmail account, then I saved locally the Gmail page as is: the saved stuff has >10 MiB, so this amount was network traffic for only about 8 KiB of actual information. [2] https://dev.gnupg.org/T5753 Cristi -- Cristian Secar? https://www.secarica.ro From noloader at gmail.com Tue Jan 4 22:02:19 2022 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 4 Jan 2022 16:02:19 -0500 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: <20220104223641.000048a4@secarica.ro> References: <20220104155552.0000175d@secarica.ro> <2165184.FksTbfuGOf@daneel> <20220104223641.000048a4@secarica.ro> Message-ID: > > Don't assume that everybody on this planet has a stable and fast > > internet connection. > > On the contrary: in year 2022 I consider safe to assume that a ~100 K e-mail message [1] is trivial for any available internet connection, even when reading the e-mail with, for example, a 12 years old Symbian based Nokia N8 over a 3G mobile network. If someone still uses a 14,4k modem (at best) for its computer, then that is *its* problem, not to the rest of the world ? not to mention that speed, in this particular case, is of no importance. Related, https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds In the past Africa and Central America had some of the slowest speeds. They were still doing dial-up while a lot of places had moved to broadband. And take a look where the US is on the list: #25. We can thank the US Supreme Court for that. The idiots in the black robes declared 2 companies were enough for competition. Contrast that to South Korea, which has 6 providers veying for a consumer. South Korea is #2 on the list, and they can download a 3.5 GB image in about 7 seconds. And South Korean consumers pay about half the price of a US consumer with a slower connection. It should be no surprise the US Supreme Court screwed up again. They are the same asses that brought us Scott v Sandford, and declared black people were property and had no place in our democracy. That ruling still stands today; the Court has never fixed it. The Judicial Branch should be proud of itself. Jeff From rjh at sixdemonbag.org Tue Jan 4 23:20:14 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 4 Jan 2022 17:20:14 -0500 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: References: <20220104155552.0000175d@secarica.ro> <2165184.FksTbfuGOf@daneel> <20220104223641.000048a4@secarica.ro> Message-ID: > And take a look where the US is on the list: #25. We can thank the US > Supreme Court for that... Please, let's not turn this mailing list into a free-for-all for discussing United States government telecommunications policies. That's wildly off-topic. From eric at bktus.com Wed Jan 5 09:08:59 2022 From: eric at bktus.com (eric at bktus.com) Date: 05 Jan 2022 16:08:59 +0800 Subject: Some problems between GnuPG and Smart Card Message-ID: <20220105080859.3048C72316E@bktus.com> After three days of hard work, I solved the problem of sending mail using the OpenPGP/MIME protocol on the software. Now this email will not cause reading troubles.If there is anything wrong, please point it out, thank you. Now, I am here to raise a question. Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I have used almost all mainstream systems to communicate between my smart card and GnuPG, and found that some settings need to be added to the scdaemon configuration, or some other related libraries need to be installed. For some ordinary users who use smart cards, these unintuitive settings, or problems related to them, may undermine their confidence in continuing to use them. I found that there are many such solutions on the Internet, the problem I encountered has also been encountered by many others. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings. Or is there any mechanism that allows ordinary users to avoid these problems that they don't understand? I plug in the smart card and can edit card or move to card without doing any other operations. The above work I have done is mainly to show the writing operation intuitively to users through a graphical interface in the future, instead of letting them use the command line. However, these additional settings make me have to think that even if I make a suitable graphical interface, it may not work properly due to some setting problems that I don't know about. I had to temporarily suspend my plan and then turn to you for help. -------------- next part -------------- A non-text attachment was scrubbed... Name: 3AAF1C64137CEE57_sign_0.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From eric at bktus.com Wed Jan 5 09:24:08 2022 From: eric at bktus.com (eric at bktus.com) Date: 05 Jan 2022 16:24:08 +0800 Subject: Making contributions to the GPGME project Message-ID: <20220105082408.2A4BA7234C5@bktus.com> GPGME Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GPGME 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: Saturneric -------------- next part -------------- A non-text attachment was scrubbed... Name: 3AAF1C64137CEE57_sign_0.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 6 14:30:48 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Jan 2022 14:30:48 +0100 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: <20220104155552.0000175d@secarica.ro> ("Cristian \=\?utf-8\?Q\?Se\?\= \=\?utf-8\?Q\?car\=C4\=83\=22's\?\= message of "Tue, 4 Jan 2022 15:55:52 +0200") References: <20220104155552.0000175d@secarica.ro> Message-ID: <87k0fdvvnb.fsf@wheatstone.g10code.de> On Tue, 4 Jan 2022 15:55, Cristian Secar? said: > (message resent with links to snapshots instead of attached snapshots; > the list rejected my previous message due to "Message body is too big: > 97216 bytes with a limit of 60 KB"; hmm: 94 KiB too big in year 2022 ? 94 * 3094 = 284 MiB For just one message. That is far away from green computing. The actually content is only of interest for a very few subscribers, thus it is unfriendly to tamp their mailboxes. Sending an URL is better; for example using dev.gnupg.org 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 bernhard at intevation.de Mon Jan 10 10:50:27 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 10:50:27 +0100 Subject: How long does it take until a patch is responded to, also tracking a patch (Re: Question on patch submitted.) In-Reply-To: <05793579-7cf4-ad7c-b574-8c3b9433a553@bktus.com> References: <05793579-7cf4-ad7c-b574-8c3b9433a553@bktus.com> Message-ID: <202201101050.32918.bernhard@intevation.de> Hello Eric, Am Donnerstag 23 Dezember 2021 09:48:57 schrieb Saturneric: > if I submit a patch to this address via git send email, > when and how the patch will be processed. it depends on the time and priorities of the GnuPG developers. So it maybe processed within hours, days, weeks, months or not at all. One patch I've seen from you is about the gpgme documentation. In my experience Werner does a documentation run every few weeks, so this one maybe slow to be integrated. If you are addressing a problem (for you) and do not get an answer, you can ask again after a reasonable while (I'd say after a month in the example) or add the problem to the tracker at dev.gnupg.org, so it does not get forgotten. > Can I track the status of this patch? There is not explicit way of doing so that I am aware of. Following the mailinglist and the git repository with a "pattern-matching" maybe a workaround for this. Thanks for contributing to GnuPG! Because time of the developers is very scarce, they value all contributions, but may not be able to respond to all of them individually. 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 Mon Jan 10 11:05:30 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 11:05:30 +0100 Subject: Mistake in GNU Privacy Handbook In-Reply-To: References: Message-ID: <202201101105.38713.bernhard@intevation.de> Hi Christoph, Am Sonntag 02 Januar 2022 14:33:26 schrieb Christoph Klassen via Gnupg-devel: > I'm not sure, if this is the right place to report mistakes/requests for > the GNU Privacy Handbook. a good question, I don't know. In the preamble is lists "Please direct questions, bug reports, or suggestions concerning this manual to the maintainer, Mike Ashley ()." but the version being from 1999, I doubt that Mike still maintains it. It https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=blob;f=web/documentation/guides.org;h=2a08842388aaceb10226c5f56bb7ad9a14cd2e2e;hb=HEAD says 30 [[../../gph/en/gph.tar.gz][en]] ? 36 GPH is also available in the [[../download/git.org][source repository]]. but I cannot find it at https://git.gnupg.org/cgi-bin/gitweb.cgi or https://gnupg.org/ftp/gcrypt/gph/ So it must be somewhere else (and guides.org) shall be improved. 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 Mon Jan 10 11:23:54 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 11:23:54 +0100 Subject: Validating email signatures via a mailinglist (Re: Some problems between GnuPG and Smart Card) In-Reply-To: <20220105080859.3048C72316E@bktus.com> References: <20220105080859.3048C72316E@bktus.com> Message-ID: <202201101124.01597.bernhard@intevation.de> Am Mittwoch 05 Januar 2022 09:08:59 schrieb eric at bktus.com: > After three days of hard work, I solved the problem of sending mail using > the OpenPGP/MIME protocol on the software. Now this email will not cause > reading troubles.If there is anything wrong, please point it out. With two email applications, trying to verify your email I've received via the mailing list, I'll get an "invalid signature". One application is Mutt 1.10.1. To debug this, you can * try to verify the email you've gotten back from the mailinglist yourself. (If you do not get any, use a different mail account or enable copies of your own emails in the mailman options for you.) * use a different application than yours to compare creation and verification of OpenPGP/MIME messages * Compare the email that you have received from the mailinglist with the one that still verifies (e.g. in your outgoing folder). Sometimes mail transport (SMTP or Mailman) will break signatures usually because some email standard property was not fully followed. 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 Mon Jan 10 11:27:03 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 11:27:03 +0100 Subject: Some problems between GnuPG and Smart Card In-Reply-To: <20220105080859.3048C72316E@bktus.com> References: <20220105080859.3048C72316E@bktus.com> Message-ID: <202201101127.03648.bernhard@intevation.de> Am Mittwoch 05 Januar 2022 09:08:59 schrieb eric at bktus.com: > I have encountered many problems in adapting the graphical interface > interaction between Yubikey and gnupg. I am thinking about why some > settings need to be manually added to some additional settings. I have used > almost all mainstream systems to communicate between my smart card and > GnuPG, and found that some settings need to be added to the scdaemon > configuration, or some other related libraries need to be installed. Please describe the problems and the settings you have found each in greater detail. (Or refer to more detaile descriptions.) In some situations scdaemon (and other parts of GnuPG) can be improved in other situations there is a different solution. Thus the details matter. Best 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 Mon Jan 10 11:49:50 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 11:49:50 +0100 Subject: issues with Unicode characters in UI dialogues (at least on Windows) In-Reply-To: <20220104223641.000048a4@secarica.ro> References: <20220104155552.0000175d@secarica.ro> <2165184.FksTbfuGOf@daneel> <20220104223641.000048a4@secarica.ro> Message-ID: <202201101149.58175.bernhard@intevation.de> Cristian, thanks for helping GnuPG with the Romanian translation of GPA [2] and by reporting general issues! Note that GPA currently is a bit on the slow track, with Werner, its principal maintainer does not having much time for it. The main development effort goes into Kleopatra these days and GPA will probably be dropped from the Gpg4win installer, see https://lists.wald.intevation.org/pipermail/gpg4win-devel/2021-September/thread.html But I think your report maybe showing a problem also present in other components. Am Dienstag 04 Januar 2022 21:36:41 schrieb Cristian Secar?: > I would have done that (bug report), but what component to consider for > report ? One report should go to the pinentry and pinentry-qt component. (You can also report without category, if you are unsure, just describing the observations.) > First I observed those popup dialog encoding errors during GPA > usage when I worked on its translation [2], only later I observed the same > errors when interacting with other 'connected' programs; the title bar of > the snapshots in question says "pinentry-qt", however, it seems to me (?) > that the translated messages are gtk gettext (not Qt); I also assumed (?) > that the error messages are distinct from pinentry itself and I also guess > that Gpg4win is just a sort of a wrapper for the suite. Maybe you can do another development step by checking pinentry directly, e.g. try to call pinentry-qt.exe directly and do something like OK Pleased to meet you setcancel ?h ?h OK getpin help Control-Z And see which string may cause an unwanted behaviour and if other pinentry versions work better. (You then may need to pipe in the commands from a file, as I do not know what kind of transformations a powershell or command.com may do.) Best, Bernhard > [2] https://dev.gnupg.org/T5753 -- 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 James.Bottomley at HansenPartnership.com Fri Jan 14 14:47:59 2022 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 14 Jan 2022 08:47:59 -0500 Subject: [PATCH gnupg 0/1] Fix the TPM pinentry crash Message-ID: <9920c6e181507469b199bca999fd67792c4719eb.camel@HansenPartnership.com> The problem was reported here: https://lists.gnupg.org/pipermail/gnupg-devel/2021-December/035010.html And subsequent diagnosis revealed a problem with the way the TPM code is using the keygrip as a label for the secrets manager, which this patch fixes. James --- James Bottomley (1): agent: always use hexgrip when storing key password agent/call-tpm2d.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) -- 2.26.2 From James.Bottomley at HansenPartnership.com Fri Jan 14 14:49:33 2022 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 14 Jan 2022 08:49:33 -0500 Subject: [PATCH gnupg 1/1] agent: always use hexgrip when storing key password In-Reply-To: <9920c6e181507469b199bca999fd67792c4719eb.camel@HansenPartnership.com> References: <9920c6e181507469b199bca999fd67792c4719eb.camel@HansenPartnership.com> Message-ID: <14bf5bc97c7abb68512232dee853bc5281227ccf.camel@HansenPartnership.com> The current code uses the binary ctrl->keygrip, but all the passphrase storage engines expect this to be a string, so convert the binary keygrip to a hex one before passing it in as the keyid. This fixes a crash seen in some libsecret implementations where a non-ascii keyid isn't well handled. Signed-off-by: James Bottomley --- agent/call-tpm2d.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/agent/call-tpm2d.c b/agent/call-tpm2d.c index 6fae5d85a..1048c7d63 100644 --- a/agent/call-tpm2d.c +++ b/agent/call-tpm2d.c @@ -141,14 +141,17 @@ agent_tpm2d_writekey (ctrl_t ctrl, unsigned char **shadow_info, static gpg_error_t pin_cb (ctrl_t ctrl, const char *prompt, char **passphrase) { - *passphrase = agent_get_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER); + char hexgrip[2*KEYGRIP_LEN + 1]; + + bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip); + *passphrase = agent_get_cache (ctrl, hexgrip, CACHE_MODE_USER); if (*passphrase) return 0; return agent_get_passphrase(ctrl, passphrase, _("Please enter your passphrase, so that the " "secret key can be unlocked for this session"), prompt, NULL, 0, - ctrl->keygrip, CACHE_MODE_USER, NULL); + hexgrip, CACHE_MODE_USER, NULL); } int @@ -160,6 +163,7 @@ agent_tpm2d_pksign (ctrl_t ctrl, const unsigned char *digest, char line[ASSUAN_LINELENGTH]; membuf_t data; struct inq_parm_s inqparm; + char hexgrip[2*KEYGRIP_LEN + 1]; rc = start_tpm2d (ctrl); if (rc) @@ -183,7 +187,10 @@ agent_tpm2d_pksign (ctrl_t ctrl, const unsigned char *digest, inq_extra, &inqparm, NULL, NULL); if (!rc) - agent_put_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER, inqparm.pin, 0); + { + bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip); + agent_put_cache (ctrl, hexgrip, CACHE_MODE_USER, inqparm.pin, 0); + } xfree (inqparm.pin); @@ -208,6 +215,7 @@ agent_tpm2d_pkdecrypt (ctrl_t ctrl, const unsigned char *cipher, char line[ASSUAN_LINELENGTH]; membuf_t data; struct inq_parm_s inqparm; + char hexgrip[2*KEYGRIP_LEN + 1]; rc = start_tpm2d (ctrl); if (rc) @@ -231,7 +239,10 @@ agent_tpm2d_pkdecrypt (ctrl_t ctrl, const unsigned char *cipher, inq_extra, &inqparm, NULL, NULL); if (!rc) - agent_put_cache (ctrl, ctrl->keygrip, CACHE_MODE_USER, inqparm.pin, 0); + { + bin2hex (ctrl->keygrip, KEYGRIP_LEN, hexgrip); + agent_put_cache (ctrl, hexgrip, CACHE_MODE_USER, inqparm.pin, 0); + } xfree (inqparm.pin); -- 2.26.2 From epirat07 at gmail.com Fri Jan 21 20:12:26 2022 From: epirat07 at gmail.com (Marvin Scholz) Date: Fri, 21 Jan 2022 20:12:26 +0100 Subject: [PATCH Libgpg-error 1/2] syscfg: Add support for versioned darwin triplets Message-ID: <20220121191227.96396-1-epirat07@gmail.com> * src/mkheader.c (deversion_darwin_triplet): New. (canon_host_triplet): Remove version from triplet before alias lookup -- Darwin triples can have a version number in the os part, which would previously just fail the build even though the triplet is supported. --- src/mkheader.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/src/mkheader.c b/src/mkheader.c index 1d2ea20..f95e030 100644 --- a/src/mkheader.c +++ b/src/mkheader.c @@ -77,6 +77,45 @@ xstrdup (const char *string) return p; } +/* Darwin host triplets can have the darwin version at the + * end, which is inconvenient for the header triplet and alias + * resolving as it would mean adding a huge amount of different + * triplets where only the version number varies and having to + * update the list whenever a new darwin version emerges, + * so instead this function returns a new triplet with the version + * number removed, if it's a darwin triplet. Else it returns NULL. + */ +static char * +deversion_darwin_triplet (const char *triplet) +{ + size_t res_len; + char *res; + char *last_seq; + + last_seq = strrchr (triplet, '-'); + if (last_seq == NULL) + return NULL; + + // Advance past the dash + last_seq++; + if (strncmp ("darwin", last_seq, 6) != 0) + return NULL; + + // We have a darwin triplet, check if something version-like follows + last_seq += 6; + if (last_seq == NULL) + return NULL; + if (!(last_seq[0] >= '0' && last_seq[0] <= '9')) + return NULL; + + // Finally, strip the version + res_len = last_seq - triplet; + res = xmalloc (res_len + 1); + memcpy (res, triplet, res_len); + res[res_len] = '\0'; + + return res; +} /* Return a malloced string with TRIPLET. If TRIPLET has an alias * return that instead. In general build-aux/config.sub should do the @@ -123,6 +162,11 @@ canon_host_triplet (const char *triplet, int no_vendor_hack, char **r_os) const char *s; char *p; char *result; + char *deversioned_triplet; + + deversioned_triplet = deversion_darwin_triplet(triplet); + if (deversioned_triplet) + triplet = deversioned_triplet; for (i=0; tbl[i].name; i++) { @@ -178,6 +222,7 @@ canon_host_triplet (const char *triplet, int no_vendor_hack, char **r_os) break; } } + xfree(deversioned_triplet); return result; } -- 2.34.1 From epirat07 at gmail.com Fri Jan 21 20:12:27 2022 From: epirat07 at gmail.com (Marvin Scholz) Date: Fri, 21 Jan 2022 20:12:27 +0100 Subject: [PATCH Libgpg-error 2/2] syscfg: Add support for armv7-apple-darwin In-Reply-To: <20220121191227.96396-1-epirat07@gmail.com> References: <20220121191227.96396-1-epirat07@gmail.com> Message-ID: <20220121191227.96396-2-epirat07@gmail.com> * src/mkheader.c (canon_host_triplet): Add to table. -- --- src/mkheader.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mkheader.c b/src/mkheader.c index f95e030..01f1166 100644 --- a/src/mkheader.c +++ b/src/mkheader.c @@ -155,6 +155,8 @@ canon_host_triplet (const char *triplet, int no_vendor_hack, char **r_os) {"armv5-unknown-linux-musleabi" }, {"armv6-unknown-linux-musleabihf" }, + {"armv7-apple-darwin", "arm-apple-darwin"}, + { NULL } }; int i; -- 2.34.1 From romain.griffiths at gmail.com Sat Jan 22 09:57:03 2022 From: romain.griffiths at gmail.com (Romain Griffiths) Date: Sat, 22 Jan 2022 09:57:03 +0100 Subject: Feature Request: Add a --card parameter Message-ID: Hello, When having several identical Yubikeys, it's not possible to choose among them in a deterministic way. I use different local user for daily work and admin. I want 2 different Yubikeys to hold the keys for those identities, and have the 2 yubikeys plugged all-time. I can't use the reader-port parameter for this as both card reports the same reader name. $ echo scd getinfo reader_list | gpg-connect-agent --decode D 1050:0407:X:0 D 1050:0407:X:0 OK I did not succeed using the port number under usb neither, and I guess this number would change depending on the insertion order of the smartcards. Instead I would like to use the Application ID in gnupg/card_list number/SERIALNO: $ echo scd getinfo card_list | gpg-connect-agent S SERIALNO D2760001240103040006XXXXXXXX0000 OK e.g. setting up in scdaemon.conf: card D2760001240103040006XXXXXXXX0000 would select only this Yubikey for scdaemon operations. scdaemon should also not lock the other readers to that several log-in users could use their own Yubikey. Thank you. Romain From wk at gnupg.org Sun Jan 23 15:47:17 2022 From: wk at gnupg.org (Werner Koch) Date: Sun, 23 Jan 2022 15:47:17 +0100 Subject: Feature Request: Add a --card parameter In-Reply-To: (Romain Griffiths via Gnupg-devel's message of "Sat, 22 Jan 2022 09:57:03 +0100") References: Message-ID: <874k5ua4qy.fsf@wheatstone.g10code.de> On Sat, 22 Jan 2022 09:57, Romain Griffiths said: > When having several identical Yubikeys, it's not possible to choose > among them in a deterministic way. You don't need to. GnuPG selects the approriate Yubikey automagically. In afct, I often have several tokens inserted all wth different keys and the correct one is always selected: For gpg as weel as for ssh. You just need to use ghupg 2.3 or gpg4win 4.0 and don't set any reader-port. > scdaemon should also not lock the other readers to that several log-in > users could use their own Yubikey. Assuming that your are on Linux, you can setup udev rules to assign Yubikeys to users by granting the right permissions. But having several tokens on a multi-user machine is imho not a good idea. But I may have misunderstood your use-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 bad at bsd.de Mon Jan 24 18:39:20 2022 From: bad at bsd.de (Christoph Badura) Date: Mon, 24 Jan 2022 18:39:20 +0100 Subject: [PATCH] libgcrypt-macos-getentropy.patch: support make -n Message-ID: <20220124173919.GE23126@irregular-apocalypse.k.bsd.de> speedo.mk needs to run a handful of targets even in dry-run mode to actually see what is going to be done. --chris 1 file changed, 19 insertions(+), 19 deletions(-) build-aux/speedo.mk | 38 +++++++++++++++++++------------------- modified build-aux/speedo.mk @@ -136,66 +136,66 @@ help-wixlib: SPEEDOMAKE := $(MAKE) -f $(SPEEDO_MK) UPD_SWDB=1 native: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=release WITH_GUI=0 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=release WITH_GUI=0 all git-native: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=git WITH_GUI=0 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=git WITH_GUI=0 all this-native: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=this WITH_GUI=0 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=this WITH_GUI=0 all native-gui: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=release WITH_GUI=1 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=release WITH_GUI=1 all git-native-gui: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=git WITH_GUI=1 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=git WITH_GUI=1 all this-native-gui: check-tools - $(SPEEDOMAKE) TARGETOS=native WHAT=this WITH_GUI=1 all + +$(SPEEDOMAKE) TARGETOS=native WHAT=this WITH_GUI=1 all w32-installer: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 installer + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 installer git-w32-installer: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 installer + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 installer this-w32-installer: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ CUSTOM_SWDB=1 installer w32-wixlib: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 wixlib + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 wixlib git-w32-wixlib: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 wixlib + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 wixlib this-w32-wixlib: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ CUSTOM_SWDB=1 wixlib w32-source: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 dist-source + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 dist-source git-w32-source: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 dist-source + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=git WITH_GUI=0 dist-source this-w32-source: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=this WITH_GUI=0 \ CUSTOM_SWDB=1 dist-source w32-release: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ installer-from-source w32-msi-release: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ WITH_WIXLIB=1 installer-from-source w32-sign-installer: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ sign-installer w32-release-offline: check-tools - $(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ + +$(SPEEDOMAKE) TARGETOS=w32 WHAT=release WITH_GUI=0 SELFCHECK=0 \ CUSTOM_SWDB=1 pkgrep=${HOME}/b pkg10rep=${HOME}/b \ installer-from-source From wk at gnupg.org Mon Jan 24 22:37:46 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Jan 2022 22:37:46 +0100 Subject: [PATCH gnupg 0/1] Fix the TPM pinentry crash In-Reply-To: <9920c6e181507469b199bca999fd67792c4719eb.camel@HansenPartnership.com> (James Bottomley via Gnupg-devel's message of "Fri, 14 Jan 2022 08:47:59 -0500") References: <9920c6e181507469b199bca999fd67792c4719eb.camel@HansenPartnership.com> Message-ID: <87sftcke6t.fsf@wheatstone.g10code.de> On Fri, 14 Jan 2022 08:47, James Bottomley said: > And subsequent diagnosis revealed a problem with the way the TPM code > is using the keygrip as a label for the secrets manager, which this > patch fixes. Applied. Thanks, 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: