Re: policykit-1 CVE-2018-19788 in jessie
Hi Santiago, On Thursday 20 December 2018 01:00 AM, Santiago Ruano Rincón wrote: > Dear Maintainers, > > (It seems my first attempt to send this mail failed. Sorry if you > received it twice) > > As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in > jessie. i.e. systemctl correctly doesn't allow me to stop services, and > pkexec blocks me from executing applications that need privileges. I couldn't reproduce in my jessie machine either. > Do you think is it safe to consider jessie as not-affected? Or is it > still worth to apply the patch? I think its okay to mark as not-affected. --abhijith
Re: policykit-1 CVE-2018-19788 in jessie
On Thu, Dec 20, 2018 at 03:11:49PM +0530, Abhijith PA wrote: > Hi Santiago, > > On Thursday 20 December 2018 01:00 AM, Santiago Ruano Rincón wrote: > > Dear Maintainers, > > > > (It seems my first attempt to send this mail failed. Sorry if you > > received it twice) > > > > As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in > > jessie. i.e. systemctl correctly doesn't allow me to stop services, and > > pkexec blocks me from executing applications that need privileges. > > I couldn't reproduce in my jessie machine either. > > > Do you think is it safe to consider jessie as not-affected? Or is it > > still worth to apply the patch? > > I think its okay to mark as not-affected. Don't mark issues as not-affected just because some specific reproducer doesn't trigger. This should only be done if source code analysis has shown it to be not affected. Cheers, MOritz
Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear Debian stretch Release Team, in Debian LTS, we are currently discussing a complex update of the freerdp (v1.1) package. The current status is this: * since March 2018 freerdp in stretch (and jessie) (Git snapshot of never released v1.1) is unusable against latest Windows servers. All Windows OS versions switched to RDP proto version 6 plus CredSSP version 3) and the freerdp versions in Debian jessie/stretch do not support that. * for people using Debian stretch, the only viable work-around is using freerdp2 from stretch-backports. * people using Debian jessie LTS don't have any options (except from upgrading to stretch and using freerdp2 from stretch-bpo). * currently, we know of four unfixed CVE issues in freerdp (v1.1) (that are fixed in buster's freerdp2. With my Debian LTS contributor hat on, I have started working on the open freerdp CVE issues (which luckily appeared in a Ubuntu security update, so not much work on this side) _and_ ... ... I have started backporting the required patches (at least these: [1,2,3]) to get RDP proto version 6 working in Debian jessie's freerdp v1.1 version. This complete endeavour for LTS only makes sense if the stable release team is open to accepting such a complex change to Debian stretch, too. While working on these patches, I regularly get feedback from FreeRDP upstream developer Bernhard Miklautz. The Git version [4] of the proposed upload is not yet ready. After feedback from Bernhard, I will have to backport various WinPR API calls that are used around the RDP proto v6 implementation. So this whole thing is still work in progress. The reason for this mail is: if the stable release team declines this update, then we neither will bring it to Debian jessie LTS. Please give me a beacon single (mainly a "yes, go ahead", or a "no, no way!"). Please let me know, if you need more info to consider. Cheers, Mike [1] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0010_add-support-for-credssp-version-3.patch [2] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0011_add-support-for-proto-version-6.patch [3] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0012-fix-nla-don-t-use-server-version.patch [4] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/tree/debian/stretch/updates -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-20 Daniel Kahn Gillmor wrote: [...] > On Wed 2018-12-19 11:59:46 -0500, Antoine Beaupré wrote: >> On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote: >>> libgcrypt is a bit more worrying, even after dropping most of the noise: >>> $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x >>> '*/tests/*' >>> | diffstat | tail -1 >>> 263 files changed, 51927 insertions(+), 14888 deletions(-) >> Yeah, that's my concern as well. >> Daniel, what do you think of that diff? Is that something we can >> reasonably review? How much can we expect stability in that upgrade? >> I know you stated before general principles of gpg vs lib / API >> stability, but I'd be curious to hear your thoughts on gcrypt, in this >> specific case. > I agree that an upgrade to gcrypt is the biggest risk here, and i'm not > sure how to evaluate it other than running what meager rdep test suites > we have in jessie. I don't know whether anyone who has been working on > ci.debian.net is following this discussion, but i think it points to > some really salient use cases for test infrastructure. How nice it > would be if a DD could upload a prospective package and say "please run > all test suites for reverse dependencies!" > Andreas Metzler (cc'ed here) has been a stalwart steward of gcrypt in > debian for many years, even after GnuTLS switched to nettle, and > probably has the best sense of what kind of system integration dangers > might lurk in the proposed upgrade for jessie. Perhaps he can comment > on it? [...] Hello, looking at my mail archive gcrypt updates since 1.6 (i.e. since the last soname bump) have been very painless. The only breakage in rdeps I found was #816104, going from 1.6 to 1.7. http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/4487 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: proposed removal of Enigmail from jessie/LTS
On Wed, Dec 19, 2018 at 05:03:26PM +, Holger Levsen wrote: > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... But the very basic idea of a LTS release is to avoid the risk of breakage. If suddenly all kinds of core libraries are getting updated in jessie (with minimal testing) I'd need to run extensive tests when deploying this change sensibly and if such extensive tests are needed, I could just as well upgrade to stable. We'd never do such a change in a regular oldstable/stable either. EOLing enigmail seems the only sensible option by far. After all, there's a solid alternative if there's actually remaining Enigmail users on jessie; upgrading to Stretch. Cheers, Moritz
Re: openssl 1.0 support on stretch LTS
On 2018/12/13 20:59, Emilio Pozuelo Monfort wrote: > On 06/12/2018 05:11, Haruki TSURUMOTO wrote: >> Hi, >> my questions intents >> Will get openssl1.0 package security-update by LTS team from 2020 to >> 2022-mid? >> (Only selected packages are supported in LTS surely) >> Debian stretch has two openssl pakcages. >> >> https://packages.debian.org/ja/source/stretch/openssl >> https://packages.debian.org/ja/source/stretch/openssl1.0 >> >> I think old one(openssl1.0) is difficult to maintenance after upstream >> support end.(31st December 2019) > > I believe we will have to support 1.0.2 as some important software (e.g. > openssh) use 1.0 in stretch. We will be backporting fixes, and other > distributors (Ubuntu LTS, RedHat) will probably have to support 1.0.x so we > can > share and reuse patches with them. I understood. Thank you! -- Haruki TSURUMOTO PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E signature.asc Description: OpenPGP digital signature
Re: Xen 4.4 updates vs. Xen Stretch backport
Hi, Holger, > Holger Levsen hat am 19. Dezember 2018 um 16:33 > geschrieben: > On Fri, Dec 07, 2018 at 01:32:49PM +0100, Peter Dreuw wrote: > > go to https://salsa.debian.org/security-tracker-team as a logged in user > and you will see a button "request access" (unless you are already a > member.) Thank you. I already got accepted for https://salsa.debian.org/security-tracker-team/security-tracker/project_members > > and the documentation at > > https://wiki.debian.org/LTS/Development#Prepare_security_updates_for_Jessie_LTS > > says, this list here is one of the three options to request this access. > > right. and it works :) Even more seriously, I just fixed the URL for the > first option on that page. > > How are the Xen 4.4 fixes coming along? I'm afraid, I have not make any advance yet. I was so busy getting every thing done in front of the coming holidays that I didn't find time to sit down and concentrate on this. I am really sorry for this. I'll be on vacation until 6th of January, 2019. I assume, will have a chance to start working focused on this when I'm back from vacation. All the best for Christmas and a happy new year to all of you out there! cheers, Peter -- Peter Dreuw Teamleiter Tel.: +49 2166 9901-155 Fax: +49 2166 9901-100 E-Mail: peter.dr...@credativ.de gpg fingerprint: 33B0 82D3 D103 B594 E7D3 53C7 FBB6 3BD0 DB32 ED41 https://www.credativ.de/ credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Re: proposed removal of Enigmail from jessie/LTS
fwiw, i agree with jmm that encouraging users to upgrade to stable is the best outcome here. The question is, what are we doing to the folks who (for whatever reason) can't make that switch. On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: > If suddenly all kinds of core libraries are getting updated in jessie > (with minimal testing) we're not talking about "all kinds of core libraries" -- we're talking about a very selected subset. And i don't think we're talking about "minimal testing", there has been a reasonable amount of testing. I think we ought to consider this specific case, rather than trying to make a systematized rule. > EOLing enigmail seems the only sensible option by far. the main issue with EOLing enigmail is that users will (instead of upgrading to stable) typically just use the version from addons.mozilla.org, which has both non-DFSG-free issues and significantly scary behavior (downloading and silently executing binaries from the web on the user's behalf). If we're EOLing thunderbird on jessie entirely, that'd be one thing (and i'd be ok with it). But EOLing enigmail on its own sounds like a route to trouble for enigmail users on jessie. --dkg signature.asc Description: PGP signature
