Thunderbird reading Werner mail structure about How to report issues and suggest changes to the Web Key Directory specification
On 2021-01-29 at 18:41 +0100, Daniele Nicolodi wrote: > Hello, > > this is only to report that Thunderbird 78.7.0 is unable to make > sense > of the MIME structure of Werner's email and it only visualizes the > mailing list footer as the body of the email. > > I don't know if the issue is with Thunderbird or with Werner's MUA, > although I suspect the first. > > Cheers, > Dan Hello Daniele It's probably an issue of Thunderbird, or maybe of your MTA. I have no issue with a different client. The original structure of Werner mail was: multipart/signed text/plain application/pgp-signature After going through the mailing list, it added the mailing list footer as another part, so it became multipart/mixed multipart/signed text/plain application/pgp-signature text/plain Maybe you can check if you can view an email with this structure in thunderbird source. If so, it's probably failing the "decryption" (signature checking, actually), and just returning an empty block there. Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help with GPGME keylisting not listing signatures
On Saturday, January 23, 2021 10:39:30 AM EST Ingo Klöcker wrote: > Did you have a look at GPGME's tests as working example code? There is a > test for listing signatures: > https://dev.gnupg.org/source/gpgme/browse/master/tests/gpg/t-keylist-sig.c Thanks, I didn't see that. Except for the difference that I read the keys from a gpgme_data_t connected to a stream instead of GnuPG's keyring, my code seems to match up with the test's way of doing things. With the debugging information on the invocation of gpg doesn't look abnormal, and trying in a fresh chroot gets me the same results, so it seems as though getting detailed signature data from a gpgme_data_t may not be possible. My example for testing is at https://salsa.debian.org/-/snippets/519 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing]
Hello, this is only to report that Thunderbird 78.7.0 is unable to make sense of the MIME structure of Werner's email and it only visualizes the mailing list footer as the body of the email. I don't know if the issue is with Thunderbird or with Werner's MUA, although I suspect the first. Cheers, Dan On 29/01/2021 16:09, Werner Koch via Gnupg-users wrote: > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Protect email experience not Subject:s (hypothesis, draft)
Hello, for many months now, my feeling is growing that encrypted subject headers in emails shift the security balance in the wrong direction. So I want to summarize and explore this hypothesis. Here are some draft thoughts and notes. Feedback welcome (either to me directly or on the list). Not sure yet, where to place all this, but in the best tradition I'll announce my intentions here and will follow up as I learn. Best Regards, Bernhard == Idea of protected headers. The subject of an email delives contents related to the body of the mail. To raise the confidentiality (as one aspect of security), it is proposed to do end-to-end encryption on the subject Header-Field. == Hypothesis The subject Header-Field is also meta data, needed to keep email usable. Or in other words: to support the availability aspect of security. Because email is the most popular decentral communication solution [5] compatibility with existing installations and existing ways of working for diverse user groups is more important than in other softwar contexts. From an implementers point of view, protected headers seem to make it more complicated and break some ways to implement good access to emails. Examples: * IMAP servers can search emails by subject. A feature that cannot be kept functional with inaccessible contents. * Fast access to filtering in clients by subject is broken, because it would mean indexes and indexes would need to come from a crypto secure store, one each per crypto context (private key). * There are many old or non-header-decrypting clients around, otherwise fine and stable. As observable metadata cannot be avoided totally, maybe the alternative to automating the Header-Fields is to help people manage the different levels of security they need per occasion. Thought experiment: If it is understood that the header section is like notes on a paper envelope, needed for mail transport and to be able to be seen by the transporting agents, this can be used to assess what can be learned from it. And then common ways of distracting from the contents can be used. (I write 'common ways', because this is a core of my concept about how to get end-to-end encryption - especially email - more usable: People already know social ways how to deal with different levels of confidentiality. Sofware application need not to hide it the aspects too much.) As a consequence encrypting the subject of an email can be seen as contributing only very little to the confidentiality. The whole exchange has to done so that it looks unsuspicous anyway. Potential conclusion: Encrypted subject headers contribute a little bit to confidentiality, but they also lower availability for many cases (by the implementation complications). They should not be send by default. == Valid use cases? Where the "Subject:" is a lot more than a writing on the envelope. * Example: a roundup-tracker fully run with OpenPGP/MIME mails, by default it changes the title of an issue and there can be commands to control the issue in the subject. (Also an example where backwards compatiblity failed.) Implementation idea: per recipient (group) settings to explicitely enable encrypted subjects for those groups and contexts where it is known to be more useful. == Material [1] https://github.com/autocrypt/memoryhole archived in favour of [2] lists some alternatives and links elder discussions [2] https://github.com/autocrypt/protected-headers Old source code repo of [3]? [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ "Header Protection for S/MIME draft-ietf-lamps-header-protection-02 (Last updated 2020-11-02)" also aiming at OpenPGP/MIME? [4] A widely spread version of Thunderbird v78 did not allow disabling the encryption of subjects. https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_can-i-disable-the-encryption-of-the-email-subject [5] Mahn, Jan, 2021, c't 2021/03 pp50-53 "Nichts zu verbergen? Sicher und vertraulich kommunizieren: Ein Grundrecht" https://www.heise.de/select/ct/2021/3/2030913061555053970 -- 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD specifiction: Where to channel reports and suggestions?
Am Freitag 29 Januar 2021 01:20:55 schrieb Ángel: > > I've reported concerns about the draft on https://dev.gnupg.org using > > the "wkd" tag, though that tag is also used for bug reports, feature > > requests, etc for the wkd implementation in GnuPG itself: > > > > https://dev.gnupg.org/project/profile/108/ As long as there is no other tag or subtag, `wkd` seems okay to me. The wiki or this mailinglist both seem to be okay, too. > > I don't know whether there is a preferred way to report concerns or > > suggest problems with the spec. Perhaps Werner can suggest what he > > prefers? > During this thread there were a few points that would be very > appropriate to have filled somewhere, at the very least so that they > don't get forgotten. Starting some fresh posts with summaries (or summaries on dev.gnupg.org) is helpful to me. I admit that I've lost the overview in the monster thread. It is hard to spot the arguments in the noise, this is why I suggest to split and summarize. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing]
On Thu, 28 Jan 2021 21:35, Daniel Kahn Gillmor said: > Maybe Werner can clarify what place he'd prefer and we can consolidate > the issue tracking there. Please send patches to gnupg-devel or if you need a bug tracker, use dev.gnupg.org with the wkd tag/project. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg cards
> ahead and copied the very same keys from the backup to the second. But > trying to actually use does not work, I get an error like: 'please > insert card: […]' So. > > What can I do to make gpg use the card as well (if possible) ? You see the prompt because gpg knows that you aready used the first card and asks for that card. The alternative would be to check whether the currently inserted card can be used, despite that its serial number does not match. IIRC, we have implemented this in 2.3 to be released in th next few weeks. What you can do with 2.2 is to delet the stub file which stores the serial number: gpg --with-keygrip -K shows you the keygrip of the respective file. Now check whether the file ~/.gnupg/private-keys-v1.d/.key has the string "shadowed-private-key". If so, delete this file and run "gpg --card-status". Such a file might look like this: --8<---cut here---start->8--- Token: 276000124010200FFFE372F791 OPENPGP.1 Label: My signing yellow signing yoken Key: (shadowed-private-key (ecc (curve Ed25519)(flags eddsa)(q #40CFBE4795E91CD7A26185F23430A7445712DD93185C3023B4646E963010263697#) (shadowed t1-v1 (#D276000124010200FFFE372F791# OPENPGP.1 --8<---cut here---end--->8--- which can be edited, or it might be some binary gibberish. In any case you should be able to check for the "shadowed-private-key" string. Note that such a file exists for each key. > Another thing I would really love to know is: Is it possible to use > the gpg card as smartcard for the system login as well? Right now I am You can use the poldi PAM module but it is somewhat limited. For proper support we would need to modify the screen locker and the display manager. > Last but not least I am still on a quest for a setup to use Full Disk > Encryption and Security Token to actually decrypt the Disk on boot. I use my card for many years for an encrypted partition. The tool is called g13 but it is not very polished and not easy to install. When building gnupg add --enable-g13 to configure. We have an open task to write a bit of docuemntation: https://dev.gnupg.org/T3423 . What's also missing are features to replace or add OpenPGP keys to a partition so that you can use several cards or an symmetric key for decryption (of the actual dmcrypt key). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing]
On Fri 2021-01-29 01:20:55 +0100, Ángel wrote: > Oh, nice. I had only located > https://gitlab.com/openpgp-wg/webkey-directory which stops at -08. This > one has been further updated. yep, see the thread starting at https://lists.gnupg.org/pipermail/gnupg-users/2019-October/062844.html and concluding at https://lists.gnupg.org/pipermail/gnupg-users/2019-November/063056.html for background on the two different repos. > It would be very useful to know where are issues expected to be raised. > During this thread there were a few points that would be very > appropriate to have filled somewhere, at the very least so that they > don't get forgotten. I agree that having a consistent and dedicated place for issues to be filed (if they're not addressed immediately) is useful. https://gitlab.com/openpgp-wg/webkey-directory/-/issues was intended to be that place after discussion with Werner, but it doesn't appear to have seen much use since it was created. Maybe Werner can clarify what place he'd prefer and we can consolidate the issue tracking there. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] [Security fix] Libgcrypt 1.9.1 relased
Hello! We have to announce the availability of Libgcrypt version 1.9.1. This version fixes a *critical security bug* in the recently released version 1.9.0. If you are already using 1.9.0 please update immediately to 1.9.1. 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. Impact and timeline === Only one released version is affected: - Libgcrypt 1.9.0 (released 2021-01-19) All other versions are not affected. On 2021-01-28 Tavis Ormandy contacted us to report a severe bug in 1.9.0 which he found while testing GnuPG: There is a heap buffer overflow in libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs. The bug was introduced during the the 1.9 development phase about two years ago with commit e76617cbab018dd8f41fd6b4ec6740b5303f7e13 (Reduce overhead on generic hash write function). Exploiting this bug is simple and thus immediate action for 1.9.0 users is required. A CVE-id has not yet been assigned. We track this bug at https://dev.gnupg.org/T5275. The 1.9.0 tarballs on our FTP server have been renamed so that scripts won't be able to get this version anymore. Solution If Libgcrypt versions 1.9.0 is in use please update immediately to version 1.9.1. If you are using the 1.8 LTS branch you are not affected. While you are checking anyway please make sure that you have at least 1.8.5. If you are using a development version build taken from our Git repository you need to update as well. NB: The use of non-released versions in a production environment is strongly discouraged. There is yet no released GnuPG version hich requires Libgcrypt 1.9 Noteworthy changes in Libgcrypt 1.9.1 = * Bug fixes: - *Fix exploitable bug* in hash functions introduced with 1.9.0. [#5275] - Return an error if a negative MPI is used with sexp scan functions. [#4964] - Check for operational FIPS in the random and KDF functions. [#5243] - Fix compile error on ARMv7 with NEON disabled. [#5251] - Fix self-test in KDF module. [#5254] - Improve assembler checks for better LTO support. [#5255] - Fix assember problem on macOS running on M1. [#5157] - Support older macOS without posix_spawn. [#5159] - Fix 32-bit cross build on x86. [#5257] - Fix non-NEON ARM assembly implementation for SHA512. [#5263] - Fix build problems with the cipher_bulk_ops_t typedef. [#5264] - Fix Ed25519 private key handling for preceding ZEROs. [#5267] - Fix overflow in modular inverse implementation. [#5269] - Fix register access for AVX/AVX2 implementations of Blake2. [#5271]. * Performance: - Add optimized cipher and hash functions for s390x/zSeries. - Use hardware bit counting functionx when available. * Internal changes: - The macOS getentropy syscall is used when available. [#5268] - Update DSA functions to match FIPS 186-3. [30ed9593f6] - New self-tests for CMACs and KDFs. [385a89e35b,7a0da24925] - Add bulk cipher functions for OFB and GCM modes. [f12b6788f2,f4e63e92dc] For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T5259 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.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.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.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.9.1.tar.bz2.sig libgcrypt-1.9.1.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
[Announce] [urgent] Stop using Libgcrypt 1.9.0 !
Hi! A severe bug was reported yesterday evening against Libgcrypt 1.9.0 which we released last week. A new version to fix this as weel as a couple of build problems will be released today. In the meantime please stop using 1.9.0. It seems that Fedora 34 and Gentoo are already using 1.9.0 . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-announce mailing list gnupg-annou...@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
