Bug#816063: emacs24: TLS certificate validation is silently broken
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;)
#
(url-retrieve-synchronously "https://self-signed.badssl.com;)
#
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 libacl12.2.52-3
ii libasound2 1.1.0-1
ii libatk1.0-02.18.0-1
ii libc6 2.21-9
ii libcairo-gobject2 1.14.6-1
ii libcairo2 1.14.6-1
ii libdbus-1-31.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 libgif75.1.2-0.2
ii libglib2.0-0 2.46.2-3
ii libgnutls303.4.9-2
ii libgomp1 5.3.1-8
ii libgpm21.20.4-6.1+b2
ii libgtk-3-0 3.18.7-1
ii libice62:1.0.9-1+b1
ii libjpeg62-turbo1: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 libotf00.9.13-3
ii libpango-1.0-0 1.38.1-1
ii libpangocairo-1.0-01.38.1-1
ii libpng12-0 1.2.54-3
ii librsvg2-2 2.40.11-2
ii libselinux12.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 libxft22.3.2-1
ii libxinerama1 2:1.1.3-1+b1
ii libxml22.9.3+dfsg1-1
ii libxpm41:3.5.11-1+b1
ii libxrandr2 2:1.5.0-1
ii libxrender11: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
-- no debconf information
Bug#769191: xorg: apt-get dist-upgrade somehow reconfigured my system to use the nvidia driver, even though I have no nvidia hardware
-dev:amd64 (1.55.0+dfsg-1, automatic), libboost-serialization1.55-dev:amd64 (1.55.0+dfsg-1, automatic), libboost-atomic-dev:amd64 (1.55.0.2, automatic), libboost-thread1.55-dev:amd64 (1.55.0+dfsg-1, automatic), libboost-graph-parallel-dev:amd64 (1.55.0.2, automatic), libboost-exception-dev:amd64 (1.55.0.2, automatic), libboost-mpi1.55.0:amd64 (1.55.0+dfsg-1, automatic), libboost-serialization-dev:amd64 (1.55.0.2, automatic), libboost-locale-dev:amd64 (1.55.0.2, automatic) End-Date: 2014-06-01 13:06:06 Pretty weird... I spent a few minutes trying to track down what the relevant dependency chain might be, but ran out of time before I found anything. On Sat, Nov 22, 2014 at 1:02 PM, Simon McVittie s...@debian.org wrote: On Mon, 17 Nov 2014 at 21:47:12 +, Nathaniel Smith wrote: Here's my apt history files. history.log.1 has the big upgrade that caused the problem; history.log has the mucking about I did to fix it. OK, thanks. At the top of history.log.1 you have: Upgrade: ... nvidia-libopencl1:amd64 (340.46-1, 340.46-3) ... which results in the installation of a pile of nvidia stuff. I'm not sure why you would gain the other nvidia stuff at that point if you didn't have it already, because debdiff says nvidia-libopencl1_340.46-1_amd64.deb and nvidia-libopencl1_340.46-3_amd64.deb (from snapshot.debian.org) have identical metadata apart from version number and Installed-Size. however, nvidia-libopencl1_340.46-3_amd64.deb does have Recommends: nvidia-opencl-icd | opencl-icd so that would maybe explain it. Recursively following Depends and Recommends from nvidia-opencl-icd pulls in the whole nvidia stack. Next question, why did you have nvidia-opencl-icd in the first place? I suspect the answer is probably https://bugs.debian.org/739176 which has already been fixed. S -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769072: Bug#769191: xorg: apt-get dist-upgrade somehow reconfigured my system to use the nvidia driver, even though I have no nvidia hardware
Here's my apt history files. history.log.1 has the big upgrade that caused the problem; history.log has the mucking about I did to fix it. Notice that the big upgrade got interrupted in the middle by libaudio2 failing to install (#768651), so there was some 'apt-get install -f' and 'dpkg --configure -a' stuff in there before the dist-upgrade gets restarted. On Mon, Nov 17, 2014 at 9:26 PM, Simon McVittie s...@debian.org wrote: On Wed, 12 Nov 2014 at 02:08:34 +, Nathaniel J. Smith wrote: This evening I ran 'apt-get dist-upgrade' on my 'testing' system, rebooted, and found the system unusable -- it just came up with gdm3's Oh no! Something has gone wrong! screen. It turns out that the problem is that somehow, dist-upgrade reconfigured X to use the nvidia drivers for GLX -- e.g., from /var/log/messages: [...] Nov 12 01:47:35 branna gdm-Xorg-:0[4239]: (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) This sounds somewhat similar to #769072 (which is currently assigned to gnome-shell, and I only haven't reassigned it away because I'm not sure which nvidia-related package has the bug). The exact symptom is different, but the high-level situation (trying to use a mixture of Mesa and nVidia GL stuff after an upgrade) is similar. Perhaps they should be merged? Finding the offending upgrade in /var/log/apt would be useful; so would the details of the apt transaction(s) in which you removed the nvidia stuff. Michael, I assume you have out-of-band information that says #769481 is in fact the same as #769191? (I ask because you merged them, but it isn't obvious why from the bug log.) S -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org history.log.1 Description: Binary data Start-Date: 2014-11-12 01:51:35 Commandline: apt-get remove xserver-xorg-video-nvidia Remove: nvidia-driver:amd64 (340.46-3), xserver-xorg-video-nvidia:amd64 (340.46-3) End-Date: 2014-11-12 01:51:41 Start-Date: 2014-11-12 01:52:49 Commandline: apt-get autoremove Remove: libegl1-nvidia:amd64 (340.46-3), libgles2-nvidia:amd64 (340.46-3), libjansson4:amd64 (2.7-1), nvidia-settings:amd64 (340.46-2), libgl1-nvidia-glx:amd64 (340.46-3), libgles1-nvidia:amd64 (340.46-3), libnvidia-ml1:amd64 (340.46-3), libnvidia-eglcore:amd64 (340.46-3), libxnvctrl0:amd64 (340.46-2) End-Date: 2014-11-12 01:52:57 Start-Date: 2014-11-13 18:40:54 Commandline: apt-get install vagrant Install: ruby-i18n:amd64 (0.6.9-2, automatic), ruby-net-scp:amd64 (1.2.1-1, automatic), ruby-listen:amd64 (2.4.0-4, automatic), ruby-rb-inotify:amd64 (0.9.5-1, automatic), bsdtar:amd64 (3.1.2-9, automatic), ruby-dev:amd64 (2.1.0.4, automatic), ruby-timers:amd64 (1.1.0-2, automatic), ruby-childprocess:amd64 (0.5.5-1, automatic), vagrant:amd64 (1.6.5+dfsg1-2), ruby-net-ssh:amd64 (2.9.1-1, automatic), ruby-nokogiri:amd64 (1.6.3.1+ds-1, automatic), ruby2.1-dev:amd64 (2.1.4-1, automatic), ruby-erubis:amd64 (2.7.0-3, automatic), bundler:amd64 (1.7.4-1, automatic), ruby-celluloid:amd64 (0.15.2-2, automatic), ruby-log4r:amd64 (1.1.10-4, automatic), ruby-thor:amd64 (0.19.1-1, automatic), ruby-ffi:amd64 (1.9.6debian-2, automatic), ruby-net-http-persistent:amd64 (2.9-2, automatic) End-Date: 2014-11-13 18:41:05 Start-Date: 2014-11-13 18:42:31 Commandline: apt-get install virtualbox virtualbox-guest-additions-iso Install: virtualbox:amd64 (4.3.18-dfsg-1), virtualbox-dkms:amd64 (4.3.18-dfsg-1, automatic), virtualbox-guest-additions-iso:amd64 (4.3.18-1), virtualbox-qt:amd64 (4.3.18-dfsg-1, automatic), libvncserver0:amd64 (0.9.9+dfsg-6+b2, automatic), libgsoap5:amd64 (2.8.17-1, automatic) End-Date: 2014-11-13 18:42:56 Start-Date: 2014-11-13 18:55:48 Commandline: apt-get install linux-headers-amd64 Install: linux-headers-3.16-3-common:amd64 (3.16.5-1, automatic), linux-kbuild-3.16:amd64 (3.16-2, automatic), linux-headers-3.16-3-amd64:amd64 (3.16.5-1, automatic), linux-compiler-gcc-4.8-x86:amd64 (3.16.5-1, automatic), linux-headers-amd64:amd64 (3.16+62) End-Date: 2014-11-13 18:56:44 Start-Date: 2014-11-13 18:57:25 Commandline: apt-get install --reinstall virtualbox-dkms Reinstall: virtualbox-dkms:amd64 (4.3.18-dfsg-1) End-Date: 2014-11-13 18:58:12
Bug#468130: python-gobject-dbg: There is no convenient way to *use* the debugging pygobject library
Package: python-gobject-dbg Version: 2.14.1-1 Severity: grave Justification: renders package unusable Most -dbg packages are set up so that when running under gdb, the debugging libraries are automatically used. Not so for pygobject. After flailing around for a while, the *only* way I could come up with to cause the debugging-enabled .so to be loaded was by going in and renaming /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject_d.so to /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so (overwriting the existing _gobject.so symlink that dpkg and friends generated for the python-gobject package). Requiring users to rearrange files installed by dpkg is just awful. Failing to document how to do so makes it even worse. (Of course, perhaps there is some other way to magically get at the debug version of the library. If so, maybe it could be more prominently documented?) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431123: aptitude: Initializing package states takes very much longer than before +b1
On Tue, Jul 03, 2007 at 07:42:08AM -0700, Daniel Burrows wrote: On Mon, Jul 02, 2007 at 10:00:53PM -0700, Nathaniel Smith [EMAIL PROTECTED] was heard to say: On Sun, Jul 01, 2007 at 06:12:11PM -0700, Daniel Burrows wrote: Does installing the version in experimental fix the problem for you? Yes, the aptitude in experimental (0.4.4-5~2, which appears to be linked against apt 0.6.46.4-0.1, which is no longer in unstable?) works fine. Eh? I meant 0.4.5.3-1. Maybe that's not available on your architecture? Anyway, I'm preparing an upload to unstable, which should fix these problems for everyone. Ah, right, x86-64. The version that went into unstable today seems to be working fine. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431123: aptitude: Initializing package states takes very much longer than before +b1
On Sun, Jul 01, 2007 at 06:12:11PM -0700, Daniel Burrows wrote: Does installing the version in experimental fix the problem for you? Yes, the aptitude in experimental (0.4.4-5~2, which appears to be linked against apt 0.6.46.4-0.1, which is no longer in unstable?) works fine. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423947: lftp: postrm script fails if 'ftp' package is not installed
Package: lftp Version: 3.5.9-1 Severity: grave Justification: renders package unusable ~$ sudo dpkg -i /var/cache/apt/archives/lftp_3.5.10-1_i386.deb (Reading database ... 109953 files and directories currently installed.) Preparing to replace lftp 3.5.9-1 (using .../lftp_3.5.10-1_i386.deb) ... Unpacking replacement lftp ... No alternatives for ftp. dpkg: warning - old post-removal script returned error exit status 1 dpkg - trying script from the new package instead ... No alternatives for ftp. dpkg: error processing /var/cache/apt/archives/lftp_3.5.10-1_i386.deb (--install): subprocess new post-removal script returned error exit status 1 No alternatives for ftp. dpkg: error while cleaning up: subprocess post-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/lftp_3.5.10-1_i386.deb This also means that it cannot be removed by normal means, and that apt refuses to work until the mess is cleaned up. After forcing an install of the 'ftp' package, the 'lftp' package again can be upgraded. I suppose a simple fix would be to make lftp Depend: or Pre-Depend: on ftp, but that does not seem like the optimal solution. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lftp depends on: ii libc6 2.5-7 GNU C Library: Shared libraries ii libgcc1 1:4.1.2-6 GCC support library ii libgcrypt11 1.2.4-2LGPL Crypto library - runtime libr ii libgnutls13 1.6.2-2the GNU TLS library - runtime libr ii libgpg-error0 1.4-2 library for common error values an ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-2 GNU readline and history libraries ii libtasn1-30.3.9-1Manage ASN.1 structures (runtime) ii netbase 4.29 Basic TCP/IP networking system ii zlib1g1:1.2.3-14 compression library - runtime lftp recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote: On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote: ... 1. Is this more likely a bug in Boost or a bug in monotone? 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. I think this should include the boost maintainer, there has to be some way to safely select the proper compile flags. At least the Debian packages provide a threaded and non-threaded version, but the .so link points to the threaded version by default. If both versions are supposed to be usable equally for non-threaded application it suggest a bug in boost... Anyway, until there is some mechanism to select this safely, it's probably better to compile the application with the same flags as the library was. Right -- I tracked down the official word on this, which says: If your program is single-threaded and does not link to any libraries that might have used shared_ptr in its default configuration, you can #define the macro BOOST_SP_DISABLE_THREADS on a project-wide basis to switch to ordinary non-atomic reference count updates. (Defining BOOST_SP_DISABLE_THREADS in some, but not all, translation units is technically a violation of the One Definition Rule and undefined behavior. Nevertheless, the implementation attempts to do its best to accommodate the request to use non-atomic updates in those translation units. No guarantees, though.) ( http://www.boost.org/libs/smart_ptr/shared_ptr.htm ) So basically, if a program uses boost::shared_ptr, and also uses libraries that use boost::shared_ptr (including other boost libraries), then your program and those libraries must be compiled with the same BOOST_SP_DISABLE_THREADS setting. Unless you get lucky. (I guess it failing on less popular platforms in particular has something to do with the workarounds they mention in the second paragraph?) I'll probably make an upload today. So, to be sure, I'm going to remove -DBOOST_SP_DISABLE_THREADS, but leave -DBOOST_DISABLE_THREADS? Is that correct, or are both defines to be removed? That sounds correct. I suspect the reason _SP_ is split off as its own thing is exactly this... -- Nathaniel -- The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On Tue, Nov 21, 2006 at 02:04:07PM -0700, Shaun Jackman wrote: It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's cross-platform issues on Debian. Namely, that monotone fails to run (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on i386, amd64, ia64, alpha and powerpc [1]. [1] http://buildd.debian.org/build.php?pkg=monotone One suggested workaround (by Roman Zippel above) is to remove -DBOOST_SP_DISABLE_THREADS. The ChangeLog indicates that Nathaniel added this feature on 2005-09-30. Right, makes sense. Thanks, Roman, for tracking this down. So, my questions for the monotone mailing list are... 1. Is this more likely a bug in Boost or a bug in monotone? It is sort of an unfortunate fact of life. But monotone is the simplest place to work around it. 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? Yes, that should work fine, with only some slowdown. 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. Debian's freeze and release of Etch is imminent, and I'd like to nail this bug before then. Otherwise, Etch will ship with the last bug-free version of monotone, which was 0.28. I have not had a chance to run any benchmarks. It's certainly less than a factor of 2. Shipping with 0.28 would not be the end of the world (at least it's post-0.26, unlike IIRC latest ubuntu!), but I would say go ahead and do it. (If anyone wants to run some benchmarks of how monotone's speed changes on some interesting operations with and without -DBOOST_SP_DISABLE_THREADS, that would be cool; we added it as something that would give _some_ win with no downside, so we've never actually bothered to check whether the win is even measurable.) -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319149: Bug 319149
This is indeed a Boost/gcc 4.0 incompatibility, but it only affects code that monotone does not actually use; monotone 0.21's configure checks for boost 1.32 and does some preprocessor kluging to work around the problem. So, monotone 0.21 should fix this. -- Nathaniel -- Civil rights were not compatible with European unification. But I'm much happier now that all our strawberries are the same size. -- dark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
