Debian Bug report logs - #816063
emacs24: TLS certificate validation is silently broken

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Nathaniel Smith <njs@pobox.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: emacs24: TLS certificate validation is silently broken

Date: Fri, 26 Feb 2016 21:34:33 -0800

Package: emacs24
Version: 24.5+1-6+b1
Severity: serious
Tags: security
Justification: 5(b) of https://release.debian.org/testing/rc_policy.txt

Debian's emacs builds are linked against gnutls:

(gnutls-available-p)
t

By default, they aren't configured to validate TLS certificates,
leaving users open to trivial MITM attacks:

(require 'gnutls)
gnutls-verify-error
nil

(url-retrieve-synchronously "https://wrong.host.badssl.com")
#<buffer  *http wrong.host.badssl.com:443*>
(url-retrieve-synchronously "https://self-signed.badssl.com")
#<buffer  *http self-signed.badssl.com:443*>

Okay, fine, but at least it is easy to turn this on:

(setq gnutls-verify-error t)

There are even some nice docs explaining how and why to do this:
   https://glyph.twistedmatrix.com/2015/11/editor-malware.html
(Short version: if you aren't using https for the package servers --
#797477 -- and haven't enabled TLS checking, and ever run
package-install over coffee-shop wifi, then congratulations, you've
just allowed anyone within wifi range to execute arbitrary code on
your user account.)

However, Debian's emacs24 somehow manages to be so broken that turning
on cert verification via (setq gnutls-verify-error t) *doesn't
work*. The docs say it should work, and explain in detail how to
configure finding the CA trust store (this is configured correctly
out-of-the-box on Debian). And sometimes I've even had it fail on
https://wrong.host.badssl.com after setting this (but not
always). However, it always happily loads
https://self-signed.badssl.com, which means it's providing no
protection at all against MITM attacks.

Bottom line: even if you configure everything correctly, Debian's
emacs will still happily execute whatever random code your barista
gives you.

The only way I've found to work around this and get a minimally-secure
setup is to add the following extremely simple and obvious incantation
to my .emacs:

;; Monkeypatch emacs so that it doesn't think gnutls is compiled in
(if (fboundp 'gnutls-available-p)
    (fmakunbound 'gnutls-available-p))
;; Force emacs to use gnutls-cli *without* the --insecure flag it
;; defaults to. (Note that the --x509cafile argument here depends on
;; your distro; this is correct for Debian.)
(setq tls-program
      '("gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p %p %h"))
;; Not sure if this is necessary, but it certainly doesn't hurt
(setq tls-checktrust t)

and then doing 'apt install gnutls-bin'.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs24 depends on:
ii  emacs24-bin-common     24.5+1-6+b1
ii  gconf-service          3.2.6-3
ii  libacl1                2.2.52-3
ii  libasound2             1.1.0-1
ii  libatk1.0-0            2.18.0-1
ii  libc6                  2.21-9
ii  libcairo-gobject2      1.14.6-1
ii  libcairo2              1.14.6-1
ii  libdbus-1-3            1.10.6-1
ii  libfontconfig1         2.11.0-6.3
ii  libfreetype6           2.6.1-0.1
ii  libgconf-2-4           3.2.6-3
ii  libgdk-pixbuf2.0-0     2.32.3-1.2
ii  libgif7                5.1.2-0.2
ii  libglib2.0-0           2.46.2-3
ii  libgnutls30            3.4.9-2
ii  libgomp1               5.3.1-8
ii  libgpm2                1.20.4-6.1+b2
ii  libgtk-3-0             3.18.7-1
ii  libice6                2:1.0.9-1+b1
ii  libjpeg62-turbo        1:1.4.2-2
ii  libm17n-0              1.7.0-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-7+b1
ii  libmagickwand-6.q16-2  8:6.8.9.9-7+b1
ii  libotf0                0.9.13-3
ii  libpango-1.0-0         1.38.1-1
ii  libpangocairo-1.0-0    1.38.1-1
ii  libpng12-0             1.2.54-3
ii  librsvg2-2             2.40.11-2
ii  libselinux1            2.4-3
ii  libsm6                 2:1.2.2-1+b1
ii  libtiff5               4.0.6-1
ii  libtinfo5              6.0+20151024-2
ii  libx11-6               2:1.6.3-1
ii  libxft2                2.3.2-1
ii  libxinerama1           2:1.1.3-1+b1
ii  libxml2                2.9.3+dfsg1-1
ii  libxpm4                1:3.5.11-1+b1
ii  libxrandr2             2:1.5.0-1
ii  libxrender1            1:0.9.9-2
ii  zlib1g                 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  <none>

-- no debconf information

Message #10 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Nathaniel Smith <njs@pobox.com>

Cc: 816063@bugs.debian.org

Subject: Re: emacs24: TLS certificate validation is silently broken

Date: Thu, 10 Mar 2016 21:25:15 +0100

On Fri, Feb 26, 2016 at 09:34:33PM -0800, Nathaniel Smith wrote:
> Package: emacs24
> Version: 24.5+1-6+b1
> Severity: serious
> Tags: security
> Justification: 5(b) of https://release.debian.org/testing/rc_policy.txt
> 
> Debian's emacs builds are linked against gnutls:
> 
> (gnutls-available-p)
> t
> 
> By default, they aren't configured to validate TLS certificates,
> leaving users open to trivial MITM attacks:
> 
> (require 'gnutls)
> gnutls-verify-error
> nil
> 
> (url-retrieve-synchronously "https://wrong.host.badssl.com")
> #<buffer  *http wrong.host.badssl.com:443*>
> (url-retrieve-synchronously "https://self-signed.badssl.com")
> #<buffer  *http self-signed.badssl.com:443*>
> 
> Okay, fine, but at least it is easy to turn this on:
> 
> (setq gnutls-verify-error t)
> 
> There are even some nice docs explaining how and why to do this:
>    https://glyph.twistedmatrix.com/2015/11/editor-malware.html
> (Short version: if you aren't using https for the package servers --
> #797477 -- and haven't enabled TLS checking, and ever run
> package-install over coffee-shop wifi, then congratulations, you've
> just allowed anyone within wifi range to execute arbitrary code on
> your user account.)
> 
> However, Debian's emacs24 somehow manages to be so broken that turning
> on cert verification via (setq gnutls-verify-error t) *doesn't
> work*. The docs say it should work, and explain in detail how to
> configure finding the CA trust store (this is configured correctly
> out-of-the-box on Debian). And sometimes I've even had it fail on
> https://wrong.host.badssl.com after setting this (but not
> always). However, it always happily loads
> https://self-signed.badssl.com, which means it's providing no
> protection at all against MITM attacks.
> 
> Bottom line: even if you configure everything correctly, Debian's
> emacs will still happily execute whatever random code your barista
> gives you.

There don't appear to be any gnutls-specific patches in Debian's
emacs24 package, so this is most definitely an upstream bug.

Could you please report it upstream?

Cheers,
        Moritz

Message #15 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Tristan Seligmann <mithrandi@mithrandi.net>

To: 816063@bugs.debian.org

Subject: SNI

Date: Thu, 24 Mar 2016 19:15:07 +0000

[Message part 1 (text/plain, inline)]

The reason https://self-signed.badssl.com works is because Emacs 24 does
not do SNI; badssl.com serves up a cert valid for "*.badssl.com" in the
absence of SNI, which is perfectly valid for self-signed.badssl.com.

This is apparently fixed upstream already:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20465

[Message part 2 (text/html, inline)]

Message #20 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: Nathaniel Smith <njs@pobox.com>, 816063@bugs.debian.org

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Sun, 03 Jul 2016 12:18:24 -0500

Nathaniel Smith <njs@pobox.com> writes:

> And sometimes I've even had it fail on https://wrong.host.badssl.com
> after setting this (but not always).  However, it always happily loads
> https://self-signed.badssl.com, which means it's providing no
> protection at all against MITM attacks.

So with 24.5+1-6+b2, right now I'm seeing exceptions for both addresses
via emacs -Q:

  (require 'gnutls)
  (setq gnutls-verify-error t)
  (url-retrieve-synchronously "https://wrong.host.badssl.com")
  (url-retrieve-synchronously "https://self-signed.badssl.com")

But perhaps this could be the intermittent success you mention?


In any case, I'm investigating the patch

  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ccae04f205db7cffa0f247a463272f6c5af77122

mentioned here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20465

referred to via:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816063#15

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Message #25 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: Nathaniel Smith <njs@pobox.com>, 816063@bugs.debian.org

Cc: control@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Sun, 04 Sep 2016 13:13:59 -0500

tags +unreproducible
thanks

Rob Browning <rlb@defaultvalue.org> writes:

> Nathaniel Smith <njs@pobox.com> writes:
>
>> And sometimes I've even had it fail on https://wrong.host.badssl.com
>> after setting this (but not always).  However, it always happily loads
>> https://self-signed.badssl.com, which means it's providing no
>> protection at all against MITM attacks.
>
> So with 24.5+1-6+b2, right now I'm seeing exceptions for both addresses
> via emacs -Q:
>
>   (require 'gnutls)
>   (setq gnutls-verify-error t)
>   (url-retrieve-synchronously "https://wrong.host.badssl.com")
>   (url-retrieve-synchronously "https://self-signed.badssl.com")
>
> But perhaps this could be the intermittent success you mention?

As yet, both of these retrievals have always succeeded for me (just
tested again with emacs24-lucid 24.5+1-6+b2).

> In any case, I'm investigating the patch
>
>   http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ccae04f205db7cffa0f247a463272f6c5af77122
>
> mentioned here:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20465
>
> referred to via:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816063#15

While we might decide to add this patch anyway, so far it's not clear to
me that it's related to the core problem originally reported here.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Message #32 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Rob Browning <rlb@defaultvalue.org>, 816063@bugs.debian.org

Cc: Nathaniel Smith <njs@pobox.com>, control@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Wed, 22 Feb 2017 15:36:07 -0500

[Message part 1 (text/plain, inline)]

tags -1 -unreproducible

I can reproduce issues with certification verification in Emacs 24.5+1-8
in Debian Stretch. As documented here:

https://glyph.twistedmatrix.com/2015/11/editor-malware.html

The following script will yield an error:

(let ((bad-hosts
       (cl-loop for bad
             in `("https://wrong.host.badssl.com/"
                  "https://self-signed.badssl.com/")
             if (condition-case e
                    (url-retrieve
                     bad (lambda (retrieved) t))
                  (error nil))
             collect bad)))
  (if bad-hosts
      (error (format "tls misconfigured; retrieved %s ok"
                     bad-hosts))
    (url-retrieve "https://badssl.com"
                  (lambda (retrieved) t))))

The error is:

Debugger entered--Lisp error: (error "tls misconfigured; retrieved (https://wrong.host.badssl.com/ https://self-signed.badssl.com/) ok")
  signal(error ("tls misconfigured; retrieved (https://wrong.host.badssl.com/ https://self-signed.badssl.com/) ok"))
  error("tls misconfigured; retrieved (https://wrong.host.badssl.com/ https://self-signed.badssl.com/) ok")
  (if bad-hosts (error (format "tls misconfigured; retrieved %s ok" bad-hosts)) (url-retrieve "https://badssl.com" (function (lambda (retrieved) t))))
  (let ((bad-hosts (let* ((--cl-var-- (quote ("https://wrong.host.badssl.com/" "https://self-signed.badssl.com/"))) (bad nil) (--cl-var-- nil)) (while (consp --cl-var--) (setq bad (car --cl-var--)) (if (condition-case e (url-retrieve bad ...) (error nil)) (progn (setq --cl-var-- ...))) (setq --cl-var-- (cdr --cl-var--))) (nreverse --cl-var--)))) (if bad-hosts (error (format "tls misconfigured; retrieved %s ok" bad-hosts)) (url-retrieve "https://badssl.com" (function (lambda (retrieved) t)))))
  eval-region(192 615 t #[257 "\300\242b\210\301\207" [(615) (let ((bad-hosts (let* ((--cl-var-- ...) (bad nil) (--cl-var-- nil)) (while (consp --cl-var--) (setq bad ...) (if ... ...) (setq --cl-var-- ...)) (nreverse --cl-var--)))) (if bad-hosts (error (format "tls misconfigured; retrieved %s ok" bad-hosts)) (url-retrieve "https://badssl.com" (function (lambda (retrieved) t)))))] 2 "\n\n(fn IGNORE)"])  ; Reading at buffer position 615
  eval-defun-2()
  eval-defun(nil)
  call-interactively(eval-defun nil nil)
  command-execute(eval-defun)

In other words, by default, with Emacs 24.5 in Debian stretch right now,
visiting self-signed or hijacked certificates will yield no warning at
all.

Therefore, I currently have the following snippet in my .emacs to fix
X509 certification validation:

;; make sure we check against trusted X509 roots
;; requires python-certifi
;; see https://glyph.twistedmatrix.com/2015/11/editor-malware.html
(when (< emacs-major-version 25)
  (let ((trustfile
         (replace-regexp-in-string
          "\\\\" "/"
          (replace-regexp-in-string
           "\n" ""
           (shell-command-to-string "python -m certifi")))))
    (setq tls-program
          (list
           (format "gnutls-cli%s --x509cafile %s -p %%p %%h"
                   (if (eq window-system 'w32) ".exe" "") trustfile)))
    (setq gnutls-verify-error t)
    (setq gnutls-trustfiles (list trustfile))
    (setq gnutls-log-level 2)
    (setq tls-checktrust t)
    ;; disable builtin gnutls support completely, as it fails on checks:
    ;; http://emacs.stackexchange.com/a/18610
    (defun user/disable-gnutls (f &rest args) nil)
    (advice-add 'gnutls-available-p :around #'user/disable-gnutls)))

Emacs 25 doesn't have this problem: certificate validation works fine
there. Or, to be more accurate, it yields a warning like this:

Certificate information
Issued by:          *.badssl.com
Issued to:          BadSSL 
Hostname:           *.badssl.com
Public key:         RSA, signature: RSA-SHA256
Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
Security level:     Medium
Valid:              From 2016-08-08 to 2018-08-08
       
        
The TLS connection to self-signed.badssl.com:443 is insecure for the
following reasons:
         
certificate signer was not found (self-signed)
the certificate was signed by an unknown and therefore untrusted authority
certificate could not be verified
                 
Continue connecting? (No, Session-only, Always)
  
I am not sure what changed between Emacs 24 and 25, but it seems to me
Emacs 24 should absolutely be fixed before Stretch is released, or just
be removed from stretch.

A.

[signature.asc (application/pgp-signature, inline)]

Message #39 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: Antoine Beaupre <anarcat@debian.org>, 816063@bugs.debian.org

Cc: Nathaniel Smith <njs@pobox.com>, control@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>, Sean Whitton <spwhitton@spwhitton.name>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Wed, 22 Feb 2017 18:09:51 -0600

[Summary: say the word and I (and Sean, I strongly suspect) will
 immediately resume the (possibly minimal) work that remains before we
 can remove emacs24 from stretch.]

Antoine Beaupre <anarcat@debian.org> writes:

> I am not sure what changed between Emacs 24 and 25, but it seems to me
> Emacs 24 should absolutely be fixed before Stretch is released, or just
> be removed from stretch.

Well, of course broadly speaking, I'm still very much in favor of
removing emacs24 from stretch.

Sean and I put in a good bit of time toward that end before the most
recent freeze deadline, and thought we were going to make it:

  https://wiki.debian.org/Emacs25InStretch

but we were surprised at the "last minute" by some packages that "dak
-Rn emacs24" didn't report.  Likely my fault for (I assume)
misunderstanding dak's behavior.  I suspect that fixing the remaining
packages wouldn't be too hard, but we stopped worrying about it because
those uploads wouldn't have made the deadline.

In any case, if there's still any chance we can remove emacs24, I think
we'd all (users and contributors) be better off without having to carry
emacs24 through stretch.  (I think users would also be better off
without emacs and emacs-nox metapackages that point to 24, even if
emacs24 were still in stretch.)

And while I'm certainly willing to put in time to try to fix the current
issue for emacs24.  If it's non-trivial, I imagine that time would be
better spent finishing the removal.

However, I also understand that Emacs 25 may have been released too
close to the freeze (given the stability issues that we had to track
down) for that to be feasible.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Message #44 received at 816063@bugs.debian.org (full text, mbox, reply):

From: "Trent W. Buck" <trentbuck@gmail.com>

To: Antoine Beaupre <anarcat@debian.org>, 816063@bugs.debian.org

Cc: Rob Browning <rlb@defaultvalue.org>, Nathaniel Smith <njs@pobox.com>, control@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Thu, 23 Feb 2017 12:41:05 +1100

Antoine Beaupre wrote:
> tags -1 -unreproducible
>
> I can reproduce issues with certification verification in Emacs 24.5+1-8
> in Debian Stretch. As documented here:
>
> [...]
>
> I am not sure what changed between Emacs 24 and 25, but it seems to me
> Emacs 24 should absolutely be fixed before Stretch is released, or just
> be removed from stretch.

Stretch currently has both emacs24 and emacs25,
so is there any major downside to removing emacs24 from Stretch?

Message #49 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: "Trent W. Buck" <trentbuck@gmail.com>, 816063@bugs.debian.org

Cc: Rob Browning <rlb@defaultvalue.org>, Nathaniel Smith <njs@pobox.com>, control@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Wed, 22 Feb 2017 20:49:41 -0500

On 2017-02-23 12:41:05, Trent W. Buck wrote:
> Antoine Beaupre wrote:
>> tags -1 -unreproducible
>>
>> I can reproduce issues with certification verification in Emacs 24.5+1-8
>> in Debian Stretch. As documented here:
>>
>> [...]
>>
>> I am not sure what changed between Emacs 24 and 25, but it seems to me
>> Emacs 24 should absolutely be fixed before Stretch is released, or just
>> be removed from stretch.
>
> Stretch currently has both emacs24 and emacs25,
> so is there any major downside to removing emacs24 from Stretch?

Not from my perspective. I've been happily running emacs 25 since i
upgraded, without any significant issue.

I'm using Notmuch, Auctex, Markdown, Go modes and all sorts of other
random shit. It just works.

A.

-- 
Les plus beaux chants sont les chants de revendications
Le vers doit faire l'amour dans la tête des populations.
À l'école de la poésie, on n'apprend pas: on se bat!
                        - Léo Ferré, "Préface"

Message #54 received at 816063@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: "Trent W. Buck" <trentbuck@gmail.com>, Antoine Beaupre <anarcat@debian.org>, 816063@bugs.debian.org

Cc: Nathaniel Smith <njs@pobox.com>, Moritz Muehlenhoff <jmm@debian.org>, Sean Whitton <spwhitton@spwhitton.name>

Subject: Re: Bug#816063: emacs24: TLS certificate validation is silently broken

Date: Wed, 22 Feb 2017 19:59:41 -0600

"Trent W. Buck" <trentbuck@gmail.com> writes:

> Stretch currently has both emacs24 and emacs25,
> so is there any major downside to removing emacs24 from Stretch?

I think it would be fairly straightforward, though it might still
require a bit of work to fix the few reverse deps that dak didn't catch,
but Sean and I are now quite familiar with that process -- unless of
course the reverse deps just aren't compatible with 25.

FWIW, I'd probably be able to make/spend a good bit of time on this over
the next few weeks if it's actually still a possibility.  I'm fairly
certain that would be more effort now in exchange for *much* less effort
over the next year or two for any number of people.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Message #61 received at 816063-close@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: 816063-close@bugs.debian.org

Subject: Bug#816063: fixed in emacs24 24.5+1-9

Date: Sun, 16 Apr 2017 16:19:25 +0000

Source: emacs24
Source-Version: 24.5+1-9

We believe that the bug you reported is fixed in the latest version of
emacs24, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 816063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning <rlb@defaultvalue.org> (supplier of updated emacs24 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 16 Apr 2017 10:07:37 -0500
Source: emacs24
Binary: emacs24-lucid emacs24-lucid-dbg emacs24-nox emacs24-nox-dbg emacs24 emacs24-dbg emacs24-bin-common emacs24-common emacs24-el
Architecture: source amd64 all
Version: 24.5+1-9
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning <rlb@defaultvalue.org>
Changed-By: Rob Browning <rlb@defaultvalue.org>
Description:
 emacs24    - GNU Emacs editor (with GTK+ GUI support)
 emacs24-bin-common - GNU Emacs editor's shared, architecture dependent files
 emacs24-common - GNU Emacs editor's shared, architecture independent infrastructur
 emacs24-dbg - Debugging symbols for emacs24
 emacs24-el - GNU Emacs LISP (.el) files
 emacs24-lucid - GNU Emacs editor (with Lucid GUI support)
 emacs24-lucid-dbg - Debugging symbols for emacs24-lucid
 emacs24-nox - GNU Emacs editor (without GUI support)
 emacs24-nox-dbg - Debugging symbols for emacs24-nox
Closes: 816063
Changes:
 emacs24 (24.5+1-9) unstable; urgency=medium
 .
   * Improve gnutls security.  Remove --insecure and specify a trustfile.
     Add these upstream patches to fix the problem:
       0024-Remove-insecure-from-gnutls-cli-invocation.patch
       0025-Refactor-out-gnutls-trustfiles.patch
       0026-Make-tls.el-use-trustfiles-by-default.patch
     Partially addresses #816063.
 .
   * Stop using libgnutls.  Add a dependency on gnutls-cli, configure
     --without-gnutls, and remove the corresponding build dependency so
     the patches that were just added to improve SSL security will take
     effect by default.  Thanks to Nathaniel Smith for reporting the
     problem and Antoine Beaupre for providing code to reproduce
     it. (Closes: 816063)
Checksums-Sha1:
 ab2a269cd11cfa14dfb7e21031809667666259c3 2731 emacs24_24.5+1-9.dsc
 a71ab4a37a397dea4b26e47a1963395a32cb01e0 77788 emacs24_24.5+1-9.debian.tar.xz
 9f95ea0de4a5f3c7c8207f45e00399497376f434 259860 emacs24-bin-common-dbgsym_24.5+1-9_amd64.deb
 90a766391e86b73d4e78558787362813e64a8c7c 257506 emacs24-bin-common_24.5+1-9_amd64.deb
 327402bdd2c8d1af11557ca41f28f0462f21330e 12979388 emacs24-common_24.5+1-9_all.deb
 17269e5407967430ff2f32d3c920cb7148243109 4894782 emacs24-dbg_24.5+1-9_amd64.deb
 df83437771a75638be691c9829e49a989e38cd21 15442030 emacs24-el_24.5+1-9_all.deb
 e6427478a599a14ba20a9b72d4a73d9865035a9a 4945258 emacs24-lucid-dbg_24.5+1-9_amd64.deb
 22a76966667608628769d29a015e34e28ff65421 3550116 emacs24-lucid_24.5+1-9_amd64.deb
 ff2c7c2a5f11939057205a99123cfa3576e8a324 3589210 emacs24-nox-dbg_24.5+1-9_amd64.deb
 f9c5a96fcb07b0b6e330dcb710565a54adc6c719 3136848 emacs24-nox_24.5+1-9_amd64.deb
 075cd8366b2f383d5480e0dba03ddf7ec649c145 19213 emacs24_24.5+1-9_amd64.buildinfo
 7e6a089a0e3fd370e755b24aaa6ca389ce26f607 3540394 emacs24_24.5+1-9_amd64.deb
Checksums-Sha256:
 a5c6c0965215531e73e722209b87603266d4c78128a517c007a7a77a3060d7bb 2731 emacs24_24.5+1-9.dsc
 bc9ea11288b5d7f48ddc3826762d7dcc8a5b4611f35f3b5387081b27cd5ddb23 77788 emacs24_24.5+1-9.debian.tar.xz
 2945619ff7aeeee89c25aa3e263874d1b6bb29e1d12625098bec4d40189ddde6 259860 emacs24-bin-common-dbgsym_24.5+1-9_amd64.deb
 aa6cf519846ed119fb1520f2a283f1d6366c75a34fbca1db2553c1a2152f28ab 257506 emacs24-bin-common_24.5+1-9_amd64.deb
 39a0090be97b16930b69f41bacb23df254bfe4de2c6b1b8542b4852212b13a9b 12979388 emacs24-common_24.5+1-9_all.deb
 43ef96bb5c51fb8289a86b2f056747ccbd5cd50f8c6135214e0ae5a8172acae2 4894782 emacs24-dbg_24.5+1-9_amd64.deb
 d40cd1f199646f0e1e4057d2bf88d505d8a16dc59fdf06622c51f3bdde8dc2f0 15442030 emacs24-el_24.5+1-9_all.deb
 1e5c7a275c964ba923c71fc7bee61310055f1a42600a9169e944a2d343344859 4945258 emacs24-lucid-dbg_24.5+1-9_amd64.deb
 6a581dd6b309f73bf8ca7371ca96a404615a83060828c399c429b1584bc7995e 3550116 emacs24-lucid_24.5+1-9_amd64.deb
 d15389af1dd907695d1977829dfc303a95908bab2a7f7fd02d15282f6b855dd8 3589210 emacs24-nox-dbg_24.5+1-9_amd64.deb
 5823374dadcc4c97a9fd2a558f198dcf70f18778ce4714898e02e12901631a02 3136848 emacs24-nox_24.5+1-9_amd64.deb
 e8ef2f5cbdf5854346e1c19874c0b20220cee7e5e85a52d709f214186a1db782 19213 emacs24_24.5+1-9_amd64.buildinfo
 750cc04b69909313cd86bd3df79a5294b6e35b9afcd4e7954604b88dfa8970ca 3540394 emacs24_24.5+1-9_amd64.deb
Files:
 f0e35359b9345ee40e2642d232b2337c 2731 editors optional emacs24_24.5+1-9.dsc
 be12fa584792be33d6c80d8582cdd249 77788 editors optional emacs24_24.5+1-9.debian.tar.xz
 1e60affd93cca7bd35e7b9be0bb71d8d 259860 debug extra emacs24-bin-common-dbgsym_24.5+1-9_amd64.deb
 e0d9556865e822b184cb5632e099ec55 257506 editors optional emacs24-bin-common_24.5+1-9_amd64.deb
 c933bf1f4d94a277185d741445943683 12979388 editors optional emacs24-common_24.5+1-9_all.deb
 7bc02b613aa3c864eacf20340c398f7f 4894782 debug extra emacs24-dbg_24.5+1-9_amd64.deb
 e693901f1f17f5cc29f9cc286735f868 15442030 editors optional emacs24-el_24.5+1-9_all.deb
 db0c7ade112db58128d1dc3613db96cb 4945258 debug extra emacs24-lucid-dbg_24.5+1-9_amd64.deb
 b81dd69fb8052147f34b39f23513fbe4 3550116 editors optional emacs24-lucid_24.5+1-9_amd64.deb
 d6d9c3ddb912b64f7f3aaaf11ad1d000 3589210 debug extra emacs24-nox-dbg_24.5+1-9_amd64.deb
 d9f115e2fafead2cb967fd75d404ed32 3136848 editors optional emacs24-nox_24.5+1-9_amd64.deb
 269c37348b2c1c0608935680cb2e1758 19213 editors optional emacs24_24.5+1-9_amd64.buildinfo
 51fc04ac03f0479f123911a61a68dc21 3540394 editors optional emacs24_24.5+1-9_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEPTFSABe5ruOuhW+97vEWxVpaQvEFAljzlKUVHHJsYkBkZWZh
dWx0dmFsdWUub3JnAAoJEO7xFsVaWkLxnbEP/0rt/ZcoG2N6INZvma2i4h1SsmLE
Cq/LNfLQb2HAnM97Tp2tx1ZpLuiBVC/noJgtURtZXxSEf6o8uuiAmklLVN5LtvJE
ek9EceNYvu/9Kks226cg1zWoCEGoOrBs/AcqsboVhF1Sg2B2fLLmeedVPAzHMRT0
ElsfwEHaH5r7Uw0WkkHZeAG5y8XyIMLczeVy272qnDhvukOkXkAHYLAGA4OvzFnW
/NFFe7fz6s+PIyUZu/F6h7rnWtN4VTR0+X/xgBmEO9T3HExz5kPULRbnSD65bJ7j
YAdtWG4g5Nh1n7VefPpWfd4By83Ty8R7uFMUqPBou7/ek7gOo3ycX8NBhruadKV0
9Gmj2o6v+wbrq++WUN5xkQP14ea/j4i4A20EGedNW+5xdOZNPWahjXz74s3W4udD
mUj4mpqnAaGvcieyaKXqMird6jsyfSa/CrO3Dr9bLLrU5ZSJ7pfySD4lUlgJDmCJ
vv3UaS/uWzCvL2w1md6+bsUV6F0k6NXfqiZQ/iDV7pxsPoV0CGSC1mn3ZUmiJ9OX
IIYK1/Nh7tkaVEt+JmMbFPR0qhCemsLJsGNzhZ/j3SvBUGSHWeGgPMIEySS/AkFL
AmJOSgqnnNZys2jYLSEEiJZFc3fmdCQ+GwIRZ2E9x7DItHOO0c350+hbXxIxaE1+
Qy3XEwlWia2TEIWz
=lNkb
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.