Bug#911740: nmu: freeimage_3.17.0+ds1-5+b5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi Release team, I think that the binNMU for freeimage against libraw19 did not work; the package has downloaded and installed libraw16 during build, instead of *19. Can you please check if if needed re-issue the binNMU? (I did not check whether other packages are affected too.) Many thanks, tobi nmu freeimage_3.17.0+ds1-5+b5 . alpha . unstable . -m "Rebuild against libraw19." -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Hi Adam-- On Tue 2018-10-23 16:18:05 +0100, Adam D. Barratt wrote: > Sure, but that's not what I said. My distinction was between including > the gnupg update in the point release versus pushing it more urgently > via stable-updates. I never implied the updates shouldn't be released at > all. thanks for the clarification, i didn't understand that distinction. I'm glad you're considering it at least for the point release. > FWIW I don't recognise that characterisation. Yes, I should have > confirmed the Security Team's intentions at an earlier point, but I > don't consider that buck-passing or the situation deadlocked. fwiw, i'd heard privately earlier from the security team that they don't see this fix as in their bailiwick, but they hadn't responded to my requests for comments in public on the BTS. So the deadlock misperception may have been due to what looked like a longer delay from my vantage point. I'm glad it's not deadlock! --dkg
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On Tue 2018-10-23 20:00:06 +0100, Adam D. Barratt wrote: > From discussions elsewhere, I understand that the "raw" upstream > enigmail - i.e. installed via upstream's addons service - is actually > already compatible with the new Thunderbird version, and the problem > only affects the Debian packages - is that correct? (Specifically, > upstream includes some kind of compatibility shim, which is not shipped > in our packages for DFSG reasons.) the version of enigmail shipped in the mozilla add-ons has at least two problems, both arguably DFSG-free-related, and both described in #909000, i believe. 0) it ships a pre-built copy of OpenPGP.js, which i have not been able to build directly in debian due to a deep dependency mess (see #787774) 1) by default it downloads a binary from the internet, stores it in the user's thunderbird profile, and executes it as the user without checking its integrity with anything beyond an HTTPS (see #891882) Encouraging users with sensitive communication needs to install something with either of these choices made this way is pretty problematic. And users who install enigmail from the add-on store will most likely never revert to the debian packages that fix these misfeatures :/ > Explicitly CCing KiBi is generally more effective, as -boot@ is a > fairly busy list at times. I imagine he'll want the SRM review > completed first, but that also depends on whether the changes actually > impact d-i's usage, which I'm not entirely clear on - could you provide > any insight there? d-i's usage is limited to gpgv; the gpgv-udeb is deliberately narrowly targeted, since all d-i needs from gpgv is (a) interpret the debian distro public keys, and (b) verify signatures on the apt manifests. None of the changes in this update should affect gpgv's behavior in either of these tasks. hope that helps to clarify, --dkg signature.asc Description: PGP signature
Bug#911244: stretch-pu: package publicsuffix/20181003.1334-0+deb9u1
On Sun 2018-10-21 11:47:51 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2018-10-17 at 11:13 -0400, Daniel Kahn Gillmor wrote: >> Please consider an update to publicsuffix in debian stretch. >> >> This package reflects the state of the network, and keeping it >> current >> is useful for all the packages that depend on it. > > Please go ahead. uploaded, thanks. --dkg
Processed: Re: Bug#910445: stretch-pu: package gnutls28/3.5.8-5+deb9u4
Processing control commands: > tags -1 + confirmed Bug #910445 [release.debian.org] stretch-pu: package gnutls28/3.5.8-5+deb9u4 Added tag(s) confirmed. -- 910445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910445 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#910445: stretch-pu: package gnutls28/3.5.8-5+deb9u4
Control: tags -1 + confirmed On Sat, 2018-10-06 at 14:43 +0200, Andreas Metzler wrote: > I would like to fix CVE-2018-10844 and CVE-2018-10845 in stretch. > Moritz has brought this up. Neither of us has strong feelings whether > it is better fix this via proposed-updates or via stretch-security. > However proposed-updates probably gets more public testing so we will > try this way. Please go ahead; thanks. Regards, Adam
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On Tue, 2018-10-23 at 10:35 -0400, Daniel Kahn Gillmor wrote: > The fact that the upstream-supported version of enigmail that works > with the upcoming stretch version of thunderbird depends on these > fixes is, as you say, another reason to suggest inclusion in debian > stretch. >From discussions elsewhere, I understand that the "raw" upstream enigmail - i.e. installed via upstream's addons service - is actually already compatible with the new Thunderbird version, and the problem only affects the Debian packages - is that correct? (Specifically, upstream includes some kind of compatibility shim, which is not shipped in our packages for DFSG reasons.) > > It's also going to need a d-i sign-off, because gnupg produces a > > udeb. > > I've added debian-b...@lists.debian.org in the hopes that someone > from there can supply a d-i sign-off. Explicitly CCing KiBi is generally more effective, as -boot@ is a fairly busy list at times. I imagine he'll want the SRM review completed first, but that also depends on whether the changes actually impact d-i's usage, which I'm not entirely clear on - could you provide any insight there? Regards, Adam
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On 2018-10-23 15:35, Daniel Kahn Gillmor wrote: Thanks to Adam for your ongoing work on the stable releases! I just wanted to clarify a few points here. On Tue 2018-10-23 08:57:08 +0100, Adam D. Barratt wrote: An issue is that the gnupg update itself doesn't really qualify for stable-updates any more than it qualifies for stable-security. The changes to gnupg itself are at best security improvements, which isn't justification for forcing all stretch users to install the new version as a matter of urgency - indeed, if the new version of enigmail weren't relying on new functionality no-one would be suggesting pushing gnupg so urgently - nor, I imagine, backporting all of the mentioned features. I would be pushing for a stable point release for GnuPG at least for the cryptographic defaults refresh, and the series of minor bugfixes that resolve outstanding problems. Sure, but that's not what I said. My distinction was between including the gnupg update in the point release versus pushing it more urgently via stable-updates. I never implied the updates shouldn't be released at all. [...] If that's the case, then either debian's policies or practices need to change, or debian needs to get a more capable maintainer for GnuPG who can figure out how to effectively navigate or avoid what feels like a buck-passing deadlock between two (maybe three) overworked/underresourced teams. I welcome any help in that regard. FWIW I don't recognise that characterisation. Yes, I should have confirmed the Security Team's intentions at an earlier point, but I don't consider that buck-passing or the situation deadlocked. Regards, Adam
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Thanks to Adam for your ongoing work on the stable releases! I just wanted to clarify a few points here. On Tue 2018-10-23 08:57:08 +0100, Adam D. Barratt wrote: > An issue is that the gnupg update itself doesn't really qualify for > stable-updates any more than it qualifies for stable-security. The > changes to gnupg itself are at best security improvements, which isn't > justification for forcing all stretch users to install the new version > as a matter of urgency - indeed, if the new version of enigmail weren't > relying on new functionality no-one would be suggesting pushing gnupg so > urgently - nor, I imagine, backporting all of the mentioned features. I would be pushing for a stable point release for GnuPG at least for the cryptographic defaults refresh, and the series of minor bugfixes that resolve outstanding problems. I brought up the idea of a cryptographic defaults refresh nearly a year ago [0], and it's overdue (my fault). i don't think it's responsible for us to ship a new stable installation in 2019 that by default creates 2048-bit RSA keys that claim to be valid through 2021. The problems with bugs like handling import of malformed keys (#906545), for example, are bad enough to have already caused extra labor in the form of stretch-backports maintenance to work around the fact that these bugs are present in debian stretch. Thanks are due to Roger Shimizu (cc'ed) for handling that ongoing task! Note that malformed keys are significantly more present today than they were when stretch was released, due to ongoing attacks on the keyserver infrastructure. :( The fact that the upstream-supported version of enigmail that works with the upcoming stretch version of thunderbird depends on these fixes is, as you say, another reason to suggest inclusion in debian stretch. > It's also going to need a d-i sign-off, because gnupg produces a udeb. I've added debian-b...@lists.debian.org in the hopes that someone from there can supply a d-i sign-off. I've done my best with this series of patches to minimize disruption to this critical part of debian stretch while still supporting the shifting network ecosystem that depends on it. If these changes cause any significant disruption, please point it out to me so that i can try to repair it. But if debian's policies and practices don't have a way to get these fixes to stable users who might depend on them for matters of critical security (even if the gnupg updates are not in themselves deemed to be critical security updates), then we're failing our stable users. If that's the case, then either debian's policies or practices need to change, or debian needs to get a more capable maintainer for GnuPG who can figure out how to effectively navigate or avoid what feels like a buck-passing deadlock between two (maybe three) overworked/underresourced teams. I welcome any help in that regard. All the best, --dkg [0] https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2017-October/006148.html signature.asc Description: PGP signature
Bug#910371: stretch-pu: package lxcfs/2.0.7-1.1
Hi, Am Sonntag, den 21.10.2018, 11:40 +0100 schrieb Adam D. Barratt: > Control: tags -1 + confirmed > > On Tue, 2018-10-09 at 15:52 +0200, Michael Banck wrote: > > On Sat, Oct 06, 2018 at 02:21:45PM +0200, Michael Banck wrote: > > > On Fri, Oct 05, 2018 at 05:18:51PM +0200, Michael Banck wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > Tags: stretch > > > > User: release.debian@packages.debian.org > > > > Usertags: pu > > > > > > > > Hi, > > > > > > > > I would like to upload a lxcfs NMU to stable, fixing Bug #885542. > > > > This > > > > would be useful for ci.debian.net autopkgtest, as ci.debian.net > > > > currenlty runs lxc from stable. > > > > > > PFA the debdiff. > > > > And another one, this time with the correct (I hope) versioning. > > > > Please go ahead. Thanks, done so now, hopefully correctly as I am not doing stable uploads a lot. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@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
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On 2018-10-21 12:48, Salvatore Bonaccorso wrote: Hi, On Sun, Oct 21, 2018 at 11:21:36AM +, Georg Faerber wrote: Hi, On 18-10-21 12:05:31, Moritz Mühlenhoff wrote: > That's all bugfixes related to enabling Enigmail and nothing in their > is itself security-related, so I think that's something for the point > update, not security.debian.org That's quite unfortunate to hear, and I don't share this opinion (even if this doesn't count in this case, I guess), for reasons outlined in the initial mail by dkg of this bug report in the "fixing enigmail" section. As of now, enigmail, which people use to secure their communication, is broken, therefore, IMHO, fixing it would be indeed a security fix. I spoke to quite some "end users" during the last weeks about this and heard the problems they've run into; personally, to not further delay this, I would very much appreciate if this could be handled via security.d.o. Some packages can be 'fast-tracked' from proposed-updates before a point release though still via the 'stable-updates' mechanism[1]. It was announced back in [2], and might be an option here if the SRM can be convinced it is needed (a.k.a if Adam gives it's okay here). An issue is that the gnupg update itself doesn't really qualify for stable-updates any more than it qualifies for stable-security. The changes to gnupg itself are at best security improvements, which isn't justification for forcing all stretch users to install the new version as a matter of urgency - indeed, if the new version of enigmail weren't relying on new functionality no-one would be suggesting pushing gnupg so urgently - nor, I imagine, backporting all of the mentioned features. It's also going to need a d-i sign-off, because gnupg produces a udeb. As a general note, in case anyone's actually reading this rather than just hitting reply - thank you for your interest, but at this point we really don't need repeated follow-ups telling us how you think this should be handled via the security archive - the Security Team have already indicated that it won't be - or how the Release Team aren't dealing with things quickly enough. I at least struggle for Debian time recently and need to be able to focus on the actual requests. I'm one of the people who wrote the guidelines for stable-updates, so I know what it says and what it means. :-) Regards, Adam
Bug#884635: transition: libupnp
Hello Sebastian, On 09/30/2018 10:09 AM, Sebastian Ramacher wrote: > On 2017-12-22 22:38:23, Uwe Kleine-König wrote: >> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote: >>> Currently there are two versions of libupnp in the archive: >>> >>> - src:libupnp providing the 1.6.x branch of libupnp which is considered >>>legacy by upstream >>> - src:pupnp-1.8 providing the 1.8.x branch of libupnp > > The list of open issues is down to: > >> - amule >>- FTBFS #884996 (patch) The patch was forwarded (https://github.com/amule-project/amule/issues/126), no response so far. The patch needs libupnp-1.6.25 or ..-1.8 which are both available in Debian. >> - djmount >>- FTBFS #884243 The upstream maintainer doesn't care any more and the Debian maintainer wrote in May "I lack of free time right now, but will engage on this as soon as I can.". Nothing happend so far. >> - gmrender-resurrect >>- FTBFS #884246 upnp-upstream supported here to come up with a patch. gmrender-resurrect was recently uploaded and not build-depends on libupnp1.8-dev and so is out of the hot path for this transition. >> - linphone >>- FTBFS #884247 Fixed in unstable. > Those still fail to build. > >> - gmediaserver >>- FTBFS #884245 > > RM requested. It would be great if https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=gmediaserver included this bug (#904833). > Considering that those packages had over 9 months to get fixed, I think we > should start the transition and RM the unfixed packages from testing. +1 I don't know what needs to be done from my side. I guess James and I have to prepare an upload of libupnp6 and libupnp1.8 where the libupnp-dev package moves from the former to the latter? According to https://wiki.debian.org/Teams/ReleaseTeam/Transitions we should wait for an ACK by the release team. Should I upload libupnp6 with libupnp-dev dropped to experimental? (pupnp-1.8 is in experimental providing libupnp-dev already.) Best regards Uwe signature.asc Description: OpenPGP digital signature
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Wow, thanks a lot for your awesome work on both enigmail and gnupg, dkg! I agree that this should be rolled out to users soon. The classic path of using "stretch-proposed-updates" means that it would land in the next point release (9.6). However, an ETA of that is "not yet planned", according to https://release.debian.org/ Using "stretch-updates", as Salvatore proposed, would accelerate this. This surely qualifies for the criteria described in the announcement. https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html However, it's probably "overqualified" for "stretch-updates", since one criteria is being "urgent and not of a security nature". I would argue that this is indeed "of a security nature". For one, it hardens scdaemon and updates cryptographic defaults, both are "of a security nature". Additionaly, it allows security updates (fixing vulnerabilities) for other packages (thunderbird, enigmail) to be shipped in Debian stable. Debian made the correct choice to ship updated ESR releases of firefox and thunderbird (and chromium) instead of trying to backport all cherry-picked CVE patches. IMHO, then it should also try to keep important dependencies working. Enigmail is widely used, essential for many thunderbird users - and "security" software. dkg has done a lot of work to package enigmail 2 work in Debian. In addition, dkg's packaging has an outstanding track record. And this gnupg update has been tested, as shown in the tickets. All in all, I'm for fast-tracking this via "stretch-security". Thanks, and keep up the good work! Daniel Kahn Gillmor: However, they do have security implications for stretch, because they are needed in order to support enigmail since the thunderbird 60 upgrade. -- ilf If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature
Bug#893189: llvm-defaults to llvm-7 ? [was: Re: Bug#893189: transition: llvm-defaults to llvm 6.0]
Hello Emilio and others, Le 23/06/2018 à 11:15, Emilio Pozuelo Monfort a écrit :>> >> Not yet, sorry. been busy with other things! > > Hi Sylvestre, any progress with this? Would be nice to bump llvm-defaults so > that we can start removing the old versions.I would like upload llvm-defaults > to propose version 7 as default for a few reasons: * llvm 6.0 upstream won't have a new upstream release * I have been focusing my Debian effort on 7 for a while, so, packaging is a much better shape * libc++ & openmp have been merged into llvm-toolchain-7. We would be able to remove libc++ and openmp; Both had some significant improvements as they have been merged in the main line. * a few packages are already using 7 (Postgresql, rust 1.30 and soon Firefox, which would make our life easier when we release) * 7 should be in testing very soon (tm), still building on mipsel * Remove everything but 6 & 7 from the archive to release with only two llvm versions. (maybe one if we are very lucky? :) Cheers, Sylvestre
