Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On Fri 2018-12-14 09:26:50 -0500, Antoine Beaupré wrote: > I have outlined the tradeoffs of this in the past. For me, the biggest > concern is that users will blindly install Enigmail from the app store > and that actually has security vulnerabilities because the jessie gpg > version is too old, as I understand it. Installing enigmail from addons.mozilla.org (what i think anarcat means by "the app store") raises not only concerns about gpg compatibility on jessie -- it also downloads and runs arbitrary binary code from the Internet: https://bugs.debian.org/891882 This is fixed in debian by a change in the defaults, but upstream appears to have no intention to change those defaults in the version in addons.mozilla.org. Leaving jessie users vulnerable to this would make me pretty sad. I appreciate the work that anarcat is doing here! --dkg signature.asc Description: PGP signature
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-14 09:08:42, Emilio Pozuelo Monfort wrote: > On 13/12/2018 21:14, Antoine Beaupré wrote: >> Hi, >> >> This is the latest update in the Thunderbird / Enigmail changes that are >> happening in jessie. I have built a series of test packages, partly from >> stretch (gnupg2, enigmail) and partly from backports (libassuan, >> libgcrypt, libgpg-error, npth) and uploaded them here: >> >> https://people.debian.org/~anarcat/debian/jessie-lts/ >> >> I need people to test those packages, and not just enigmail users. Some >> of those packages have pernicious and deep ramifications. I am >> particularly worried about libgcrypt, which is used for example by >> cryptsetup. > > I see that your tests have gone well so far (except for enigmail itself for > unrelated reasons as you explain). This is great work, and I don't mean to > push > back on it. However given the impact of these library updates, I was wondering > if we have considered to just mark enigmail as EOL in jessie? Obviously if we > can keep supporting stuff we should do that, but as you say these library > updates affect important unrelated rdeps so we need to weigh that. I have repeatedly considered this, and received almost zero feedback on the idea, other than "we should support our users", which I took as a go ahead to actually complete the backport. I have outlined the tradeoffs of this in the past. For me, the biggest concern is that users will blindly install Enigmail from the app store and that actually has security vulnerabilities because the jessie gpg version is too old, as I understand it. > BTW I have briefly looked at the versions you have backported, and I wonder > why > npth and libgpg-error have deb8u3 rather than deb8u1? An oversight. I also need to use dh-autoreconf in enigmail as I have been told it actually exists in jessie - not sure how I couldn't find it. :) > I haven't looked at your changes yet, but I will find some time to look at > them > and give these packages a try. Thanks! The more testing we get, the better off we'll be. :) A. -- No animal has more liberty than the cat; but it buries the mess it makes. The cat is the best anarchist. Until they learn that from the cat I cannot respect them. - For whom the bell tolls, Ernest Hemingway
Re: Jessie update of faad2?
Hi Ola, Ola Lundqvist wrote: > The Debian LTS team would like to fix the security issues which are > currently open in the Jessie version of faad2: > https://security-tracker.debian.org/tracker/CVE-2018-19502 > https://security-tracker.debian.org/tracker/CVE-2018-19503 > https://security-tracker.debian.org/tracker/CVE-2018-19504 (minor issue) as far as I know, there haven't been any patches published for these yet, right? Cheers, - Fabian
Re: GCC backport for atomic operations on armel
On 27/11/2018 17:18, Emilio Pozuelo Monfort wrote: > Hi, > > Currently llvm-toolchain-4.0 fails to build on armel [1] because std::future > is > broken there, see [2]. To fix this, I have backported the upstream patch to > not > require lock-free atomic ops (armel doesn't have them). This makes llvm build > fine, which should in turn allow rustc/cargo/firefox/thunderbird to build. My > biggest question is how to handle the symbol vers. I have added them to the > latest version that this gcc-4.9 has (GLIBCXX_3.4.19, CXXABI_1.3.7) whereas > the > upstream fix (and I suppose the libstdc++ in stretch) have them in a newer > version. I am not sure if having the symbols with a newer version when > upgrading > would be problematic, so I wonder if the patch as is would be fine, or if I > should stick to the version that stretch has (which would mean adding new tags > as jessie's GCC doesn't have those versions). Any thoughts? FTR: After some investigation and asking Aurelien about this, I looked into using the same version for these symbols than newer libstdc would have. So I looked at using the newer versions that GCC 4.9 doesn't really have, which gave me some problems. I then looked at stretch's libstdc++ and realised that these symbols are present in armel and have their original version (same one as in other architectures), as this patch wasn't applied yet to GCC. That means that for sid the version differs. However for jessie this simplifies things as we can just use the same version as in other arches, which will also match stretch's libstdc++, without having to mess with the symbol versioning. Cheers, Emilio
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 13/12/2018 21:14, Antoine Beaupré wrote: > Hi, > > This is the latest update in the Thunderbird / Enigmail changes that are > happening in jessie. I have built a series of test packages, partly from > stretch (gnupg2, enigmail) and partly from backports (libassuan, > libgcrypt, libgpg-error, npth) and uploaded them here: > > https://people.debian.org/~anarcat/debian/jessie-lts/ > > I need people to test those packages, and not just enigmail users. Some > of those packages have pernicious and deep ramifications. I am > particularly worried about libgcrypt, which is used for example by > cryptsetup. I see that your tests have gone well so far (except for enigmail itself for unrelated reasons as you explain). This is great work, and I don't mean to push back on it. However given the impact of these library updates, I was wondering if we have considered to just mark enigmail as EOL in jessie? Obviously if we can keep supporting stuff we should do that, but as you say these library updates affect important unrelated rdeps so we need to weigh that. BTW I have briefly looked at the versions you have backported, and I wonder why npth and libgpg-error have deb8u3 rather than deb8u1? I haven't looked at your changes yet, but I will find some time to look at them and give these packages a try. Cheers, Emilio
