trivial doc patch: "the the"
--- tools.texi- Sat May 19 18:52:35 2018
+++ tools.texi Sat May 19 18:52:45 2018
@@ -290,7 +290,7 @@
Apply the configuration settings listed in @var{file} to the
configuration files. If @var{file} has no suffix and no slashes the
command first tries to read a file with the suffix @code{.prf} from
-the the data directory (@code{gpgconf --list-dirs datadir}) before it
+the data directory (@code{gpgconf --list-dirs datadir}) before it
reads the file verbatim. A profile is divided into sections using the
bracketed component name. Each section then lists the option which
shall go into the respective configuration file.
--- gpgconf.1- Sat May 19 18:52:27 2018
+++ gpgconf.1 Sat May 19 18:53:12 2018
@@ -84,7 +84,7 @@
Apply the configuration settings listed in \fIfile\fR to the
configuration files. If \fIfile\fR has no suffix and no slashes the
command first tries to read a file with the suffix \fB.prf\fR from
-the the data directory (\fBgpgconf --list-dirs datadir\fR) before it
+the data directory (\fBgpgconf --list-dirs datadir\fR) before it
reads the file verbatim. A profile is divided into sections using the
bracketed component name. Each section then lists the option which
shall go into the respective configuration file.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
doc patches: spelling errors
--- gnupg.info-1- Sat May 19 19:01:41 2018 +++ gnupg.info-1Sat May 19 19:02:04 2018 @@ -2516,7 +2516,7 @@ below. A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported - algorithm). Signatures where the public key is not availabale are + algorithm). Signatures where the public key is not available are not listed; to see their keyids the command `--list-sigs' can be used. @@ -5184,7 +5184,7 @@ `--default-new-key-algo STRING' This option can be used to change the default algorithms for key generation. The STRING is similar to the arguments required for - the command `--quick-add-key' but slighly different. For example + the command `--quick-add-key' but slightly different. For example the current default of `"rsa2048/cert,sign+rsa2048/encr"' (or `"rsa3072"') can be changed to the value of what we currently call future default, which is `"ed25519/cert,sign+cv25519/encr"'. You --- gnupg.info-2- Sat May 19 19:07:27 2018 +++ gnupg.info-2Sat May 19 19:08:22 2018 @@ -332,7 +332,7 @@ This application adds read-only support for keys and certificates stored on a SmartCard-HSM (http://www.smartcard-hsm.com). - To generate keys and store certifiates you may use OpenSC + To generate keys and store certificates you may use OpenSC (https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM) or the tools from OpenSCDP (http://www.openscdp.org). @@ -2578,7 +2578,7 @@ linefeed to separate file names. `--openpgp' - This option has no effect becuase OpenPGP encryption and signing is + This option has no effect because OpenPGP encryption and signing is the default. `--cms' @@ -2722,7 +2722,7 @@ When used with the command `--receive' a single Web Key Service mail is processed. Commonly this command is used with the option `--send' -to directly send the crerated mails back. See below for an +to directly send the created mails back. See below for an installation example. The command `--cron' is used for regualr cleanup tasks. For example ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [openpgp-email] Efail - Possible Measures?
(Also cross-posting to Autocrypt) Patrick Brunschwig(patr...@enigmail.net)@Sat, May 19, 2018 at 06:47:08PM +0200: > In the light of the Efail vulnerability I am asking myself if it's > really needed to decrypt non-regular types of emails at all. In other > words, should we decrypt a multipart/encrypted MIME part at all if we > detect an irregular MIME structure? I used to parse stuff in a generic way in K-9 Mail at first, but changed it later (mid 2016?) to show decrypted data only in known mime structures. I planned to add support for other things as they came up, but so far I haven't received feedback about any incompatibilities. > 1. top-level MIME part is multipart/encrypted. This is the only mime structure I handle, any other pgp/mime structure will show up as an attachment. When displaying a decrypted mail, the decrypted payload is displayed like a normal message would. PGP/INLINE is handled only if the pgp data is the very first non-whitespace content, otherwise it won't be decrypted. If there are mime parts outside the encrypted payload, they are displayed as "unprotected attachments" that require an extra click to open. For the case of text/plain parts following the encrypted part, those are shown as "Unsigned Text" at the bottom and displayed in a text-only widget, nicely covering the use case of mailing list footers: https://matrix.org/_matrix/media/v1/download/stratum0.org/cKjeJctipgVjBEXIMvrqLlJL > 2. an attached email (Content-Type = message/rfc822) containing a > multipart/encrypted MIME part as direct child. I don't handle this. Does it come up for you? - V PS: Randomly signing this message. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig: > I have actually thought through this during a sleepless night, and I > believe that it could work as a quick and easy to implement *short term* > measure until the mail clients have fixed the HTML rendering. I do not think that HTML rendering could be fixed in a way that it would meet general security requirements. Mail clients rely on different rendering/browser engines that implement HTML/CSS as a living standard and with different features and interpretations of these standards. And probably none of these engines have been designed with security implications of tampered with HTML source code in mind. In my opinion this cannot be the basis for a secure mail client. A decrypted message part should never be embedded or displayed in other message parts of the same or any other message. And with embedded I mean embedded neither in raw nor parsed message parts (such as HTML DOMs). A decrypted message should always be displayed in its own secured sandbox. I'm quite sure that not following these rules will inevitably lead to doom. -- Just my 2 cents Alex ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Efail - Possible Measures?
> I would consider the following "regular" MIME structures: > > 1. top-level MIME part is multipart/encrypted. > 2. an attached email (Content-Type = message/rfc822) containing a > multipart/encrypted MIME part as direct child. We have been doing this in the past but changed it especially for Exchanges servers if I remember correctly, since they tend to wrap the multipart/encrypted mime part into other mime parts. Also I think it was at the Dreieich conference when I brought this issue up and was told that it is perfectly alright to have a multipart/encrypted part as a child part of other parts. It would however certainly fix this issue for PGP/MIME. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Efail - Possible Measures?
In the light of the Efail vulnerability I am asking myself if it's really needed to decrypt non-regular types of emails at all. In other words, should we decrypt a multipart/encrypted MIME part at all if we detect an irregular MIME structure? If we would not decrypt irregular MIME structures, there cannot be an issue with HTML displaying. This would be a good thing, if you're an addon and you can't change the application you live in. I know that some mail clients do this already, but all those clients that are affected by Efail apparently don't. I would consider the following "regular" MIME structures: 1. top-level MIME part is multipart/encrypted. 2. an attached email (Content-Type = message/rfc822) containing a multipart/encrypted MIME part as direct child. Does anyone know of other relevant types of message structures? Does anyone see a reason why NOT to do that? -Patrick signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Efail or OpenPGP is safer than S/MIME
On 05/19/2018 09:00 AM, Patrick Brunschwig wrote: > On 19.05.18 14:15, Werner Koch wrote: >> On Fri, 18 May 2018 12:18, patr...@enigmail.net said: >> >>> How far back will that solution work? I.e. is this supported by all >>> 2.0.x and 2.2.x versions of gpg? >> >> 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case >> 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't >> think that makes sense. > > Enigmail runs on many long-term Linux distributions that still ship > older, presumably patched, versions of GnuPG. For example, Red Hat EL > 6.9/Centos 6.9 contains GnuPG 2.0.14, but current versions of Thunderbird. > > GnuPG 2.0.x will therefore still be relevant for me for many years to come. > Me too! Red Hat Enterprise Linux Server release 6.9 (Santiago) thunderbird-52.7.0-1.el6_9.x86_64 gnupg2-2.0.14-8.el6.x86_64 Enigmail 2.0.4 -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jerseyhttp://linuxcounter.net ^^-^^ 09:40:01 up 2 days, 17:30, 2 users, load average: 4.15, 4.27, 4.46 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Efail or OpenPGP is safer than S/MIME
On 19.05.18 14:15, Werner Koch wrote: > On Fri, 18 May 2018 12:18, patr...@enigmail.net said: > >> How far back will that solution work? I.e. is this supported by all >> 2.0.x and 2.2.x versions of gpg? > > 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case > 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't > think that makes sense. Enigmail runs on many long-term Linux distributions that still ship older, presumably patched, versions of GnuPG. For example, Red Hat EL 6.9/Centos 6.9 contains GnuPG 2.0.14, but current versions of Thunderbird. GnuPG 2.0.x will therefore still be relevant for me for many years to come. -Patrick signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Efail or OpenPGP is safer than S/MIME
On Fri, 18 May 2018 12:18, patr...@enigmail.net said: > How far back will that solution work? I.e. is this supported by all > 2.0.x and 2.2.x versions of gpg? 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't think that makes sense. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpOXj5aCd8jL.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
