<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 20/05/2018 20:16, Damien Goutte-Gattat via Gnupg-users wrote:<br>
    <blockquote
      cite="mid:31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org"
      type="cite">On 05/20/2018 02:51 PM, Dirk Gottschalk via
      Gnupg-users wrote:
      <br>
      <blockquote type="cite">It would be possible to implement
        something like --legacy to
        <br>
        re-enable the old functionality.
        <br>
      </blockquote>
      <br>
      For information, for the problem at hand, two things have been
      done in that direction:
      <br>
      <br>
      In GnuPG itself: GnuPG will now error out when attempting to
      decrypt *any* message that is not integrity-protected, *unless*
      the --ignore-mdc-error flag has been set. This has only been done
      in the master branch of GnuPG (to be released as GnuPG 2.3 at some
      point), *not* in the current stable 2.2 branch.
      <br>
      <br>
      In GpgME: GpgME will return a failure when attempting to decrypt
      *any* message that is not integrity-protected, inconditionnally
      and even if GnuPG itself only emits a warning.
      <br>
      <br>
      What this all means is that all clients using GpgME will lose the
      ability to decrypt old, unprotected message upon the next GpgME
      release (i.e., those clients will be completely immune to Efail
      even if they currently ignore the no-MDC warning). Users will
      still be able to decrypt such unprotected messages by calling gpg
      directly (with the --ignore-mdc-error flag, if needed).
      <br>
      <br>
      Clients that spawn gpg themselves without using GpgME will still
      be able to decrypt unprotected messages (and therefore, be
      potentially vulnerable to Efail if they don't pay attention to
      GnuPG warnings) until GnuPG 2.3 is released.
      <br>
    </blockquote>
    <br>
    This seems reasonable to me. It means that legacy decryption is
    still available in current and future code even if it requires users
    to take some kind of action.<br>
    <br>
    <blockquote
      cite="mid:31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org"
      type="cite">
      And more generally on the backward compatibility problem: to
      decrypt all kind of "legacy" messages there will always be the
      option of using GnuPG 1.4.x, which is still maintained especially
      for compatibility with 1990-era PGP (it notably retains support
      for things like PGP 2.6 keys or the MD5 hash algorithm).
      <br>
    </blockquote>
    <br>
    I presume that one day the 1.x.y code will reach end of life. If and
    when that happens, I strongly suspect that there will still be users
    who will need to decrypt legacy-encrypted data and I think it is
    important that they can still do this with a maintained (2.x.y) code
    base. (And I realise that this is easy for me to say since I'm not
    contributing to maintaining the code.) <br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Mark Rousell

PGP public key: <a class="moz-txt-link-freetext" href="http://www.signal100.com/markr/pgp">http://www.signal100.com/markr/pgp</a>
Key ID: C9C5C162
 
 
 
</pre>
  </body>
</html>