Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: > Control: tags 962669 moreinfo > > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > > > Just to confirm - will the certificates be automatically re- > > > > added (assuming that users have either the automatically trust > > > > or prompt options enabled)? > > > > > > (stretch-pu report cc'ed, since same applies) > > > > > > Excellent question. I believe we're going to hit #743339 > > > "Previously removed certificates not added again". I had not > > > found a reasonable fix for that case in general, to preserve a > > > user's selections. > > > Maybe a "good enough" fix will have to do for the specific ones > > > added back. > > > > OK. > > > > In that case, how does this seem as an SUA text? [...] > > use the affected certificates, you may need to manually enable them > > by running "dpkg-reconfigure ca-certificates" as root. > > > > This does not work in various embedded scenarios. Wouldn't embedded setups be more likely to have a hard-coded configuration? > Would it work to force-enable them in /etc/ca-certificates.conf > from the preinst when upgrading from old-version matching 20200601* ? I'll leave the technical answer to Michael. Practically, it's then not great for users who had intentionally removed the certificates - or simply decided not to trust them in the first place - prior to the upgrade. I'm not sure how we could distinguish the cases automatically. > Unrelated to that, please keep the Python 2 -> 3 build dependency > change out of this emergency update. ACK. Regards, Adam
Bug#962694: RM: janus/0.6.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please drop janus from Debian stable (Buster): Upstream explicitly do not commit to long-term maintenance: https://github.com/meetecho/janus-gateway/commit/eac063c - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl7jMt4ACgkQLHwxRsGg ASH8Ag/8DVrxeiMMIezWlaoAyEJXNFs5yW9dwn1FoF4QkQ2AWCYakfKIG7n496Uc GAYgUFiieI61UojZ0I8r/8HMfkN8x+3CvTFbzzH0L6O3/9yf3e4PSRr0KjrGKBk8 j6/MzvpzLOn6kBYYs9ajT/zu8kE7kpZpLsmD+gwdIL07qy3jRfQtPL0pKDTns4xk Sjz2R2+1hhaj4OI7kHGiBujVRtPoRSZAs1+wlyd4JPUj3oO+Uuqo4yTp6PCdd6xb iG++1T1Fr/hjXOAPXHqMr1pdgU3izE7Vks+jipawbn+hQcaZpll+kO98NYsMcpPO KHFez1tK6PhTdatD6qmw2tAXn1xqvETLlHEQobCHjV9IBRkHHYo+duw3Zp1lbETc nBwOcKWJS8AT7YoHcFukI3S1d2pf+anV5qwRtuau+A8Lnl7LCBK/TLQOn4abzYGR NeyCkwQy9RSXRLW9cUpaAcPxUAgUCSF0/cgm8+zSXACP0u3EyFIiWnCS3JtXMNcV LxMKQzWEt833MZetcShjNnD2Ls+3UbkTS8XcHvSodXjzxChGgzw9GNj/vQzWsp1Y 1bPNErsrDKnmfqj/8OUGMj/Gglgs687TMp/WiYw7qhghOwaO2O84qtVLj2F7aQhC 0UyTDWyT6l2QUrp6ZzSxODmyqBF5GSpC+V3OJ/RzhIon/0CLdmk= =6SjL -END PGP SIGNATURE-
Processed: tagging 962694
Processing commands for cont...@bugs.debian.org: > tags 962694 + buster Bug #962694 [release.debian.org] RM: janus/0.6.1-1 Added tag(s) buster. > thanks Stopping processing here. Please contact me if you need assistance. -- 962694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962694 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 962694 to RM: janus -- RoM; not supportable for the lifetime of a stable release ...
Processing commands for cont...@bugs.debian.org: > retitle 962694 RM: janus -- RoM; not supportable for the lifetime of a stable > release Bug #962694 [release.debian.org] RM: janus/0.6.1-1 Changed Bug title to 'RM: janus -- RoM; not supportable for the lifetime of a stable release' from 'RM: janus/0.6.1-1'. > tags 962694 + pending Bug #962694 [release.debian.org] RM: janus -- RoM; not supportable for the lifetime of a stable release Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 962694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962694 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#960495: transition: gdal
On 2020-06-12 06:51:57 +0200, Sebastiaan Couwenberg wrote: > On 6/11/20 10:07 PM, Sebastian Ramacher wrote: > > On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote: > >> On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote: > >>> On 6/10/20 9:46 PM, Sebastian Ramacher wrote: > Please go ahead with the upload to unstable. > >>> > >>> Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable. > >> > >> The rebuild are looking good so far > >> > >> Please also binNMU postgis in experimental. > > > > Scheduled. > > Thanks. > > Some packages were (re)built with the old gdal: > > * octave-mapping on mips64el Rescheduled. I forgot to set dw for octave-mapping. > * libgdal-grass on armel, mips64el & mipsel They weren't built with the old version of gdal, but with libgdal-dev 3.1.0+dfsg-1 installed. How did they end up with a dependency on libgdal26 (>= 3.1.0)? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
NEW changes in stable-new
Processing changes file: gnutls28_3.6.7-4+deb10u4_sourceonly.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_all.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_amd64.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_arm64.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_armel.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_armhf.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_i386.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_mips.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_mips64el.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_mipsel.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_ppc64el.changes ACCEPT Processing changes file: gnutls28_3.6.7-4+deb10u4_s390x.changes ACCEPT
NEW changes in stable-new
Processing changes file: intel-microcode_3.20200609.1~deb10u1_multi.changes ACCEPT Processing changes file: intel-microcode_3.20200609.2~deb10u1_multi.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_source.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_all.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_amd64.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_arm64.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_armhf.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_i386.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_mips.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_mips64el.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_mipsel.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_ppc64el.changes ACCEPT Processing changes file: nodejs_10.21.0~dfsg-1~deb10u1_s390x.changes ACCEPT Processing changes file: roundcube_1.3.13+dfsg.1-1~deb10u1_source.changes ACCEPT Processing changes file: roundcube_1.3.13+dfsg.1-1~deb10u1_all.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_source.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_all.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_amd64.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_arm64.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_i386.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_mips64el.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_ppc64el.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb10u1_s390x.changes ACCEPT
Bug#960495: transition: gdal
On 6/12/20 10:21 AM, Sebastian Ramacher wrote: > On 2020-06-12 06:51:57 +0200, Sebastiaan Couwenberg wrote: >> On 6/11/20 10:07 PM, Sebastian Ramacher wrote: >>> On 2020-06-11 20:37:58 +0200, Sebastiaan Couwenberg wrote: On 6/11/20 6:46 AM, Sebastiaan Couwenberg wrote: > On 6/10/20 9:46 PM, Sebastian Ramacher wrote: >> Please go ahead with the upload to unstable. > > Thanks, gdal (3.1.0+dfsg-1) was just uploaded to unstable. The rebuild are looking good so far Please also binNMU postgis in experimental. >>> >>> Scheduled. >> >> Thanks. >> >> Some packages were (re)built with the old gdal: >> >> * octave-mapping on mips64el > > Rescheduled. I forgot to set dw for octave-mapping. > >> * libgdal-grass on armel, mips64el & mipsel > > They weren't built with the old version of gdal, but with libgdal-dev > 3.1.0+dfsg-1 installed. How did they end up with a dependency on > libgdal26 (>= 3.1.0)? Most likely because grass hadn't been rebuilt with the new gdal yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
NEW changes in oldstable-new
Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_source.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_all.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_amd64.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_arm64.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_armhf.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_i386.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_ppc64el.changes ACCEPT Processing changes file: firefox-esr_68.9.0esr-1~deb9u1_s390x.changes ACCEPT Processing changes file: intel-microcode_3.20200609.1~deb9u1_multi.changes ACCEPT Processing changes file: intel-microcode_3.20200609.2~deb9u1_multi.changes ACCEPT Processing changes file: mysql-connector-java_5.1.49-0+deb9u1_amd64.changes ACCEPT Processing changes file: roundcube_1.2.3+dfsg.1-4+deb9u5_source.changes ACCEPT Processing changes file: roundcube_1.2.3+dfsg.1-4+deb9u5_all.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_source.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_all.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_amd64.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_i386.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_ppc64el.changes ACCEPT Processing changes file: thunderbird_68.9.0-1~deb9u1_s390x.changes ACCEPT
Bug#962707: transition: qhull
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: jspri...@debian.org Dear release team, I would like to transition qhull 2020.1, which has a properly bumped upstream SONAME now. The ben tracker is good: https://release.debian.org/transitions/html/auto-qhull.html The API has had a few additions but no incompatible changes or removals since 2019.1, and all reverse dependencies build fine on amd64, so I don't expect any trouble. Cheers Timo
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote: > On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: > > Control: tags 962669 moreinfo > > > > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: > > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > > > > Just to confirm - will the certificates be automatically re- > > > > > added (assuming that users have either the automatically trust > > > > > or prompt options enabled)? > > > > > > > > (stretch-pu report cc'ed, since same applies) > > > > > > > > Excellent question. I believe we're going to hit #743339 > > > > "Previously removed certificates not added again". I had not > > > > found a reasonable fix for that case in general, to preserve a > > > > user's selections. > > > > Maybe a "good enough" fix will have to do for the specific ones > > > > added back. > > > > > > OK. > > > > > > In that case, how does this seem as an SUA text? > [...] > > > use the affected certificates, you may need to manually enable them > > > by running "dpkg-reconfigure ca-certificates" as root. > > > > > > > This does not work in various embedded scenarios. > > Wouldn't embedded setups be more likely to have a hard-coded > configuration? The official way to hardcode CA configuration would be through debconf or /etc/ca-certificates.conf, which runs into #743339. If you are really security-focussed you might pin the actual certificate instead of trusing a CA. For the average embedded device the only thing that matters about ca-certificates is something like "https works". > > Would it work to force-enable them in /etc/ca-certificates.conf > > from the preinst when upgrading from old-version matching 20200601* ? This could actually be done in the postinst before the debconf configuration, something like sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" /etc/ca-certificates.conf for all affected certificates when $2 matches 20200601* > I'll leave the technical answer to Michael. > > Practically, it's then not great for users who had intentionally > removed the certificates - or simply decided not to trust them in the > first place - prior to the upgrade. I'm not sure how we could > distinguish the cases automatically. The default is to trust all new certificates, so this is what the vast majority of users are using. #743339 is primarily about this kind of remove+readd in the package being the only way how any installed certificate could end up being deactivated in the default situation. This is permanent damage that can lead to nasty problems months or years later. There are likely some users somewhere who have manually activated or deactivated these specific certificates, but this is nothing we can handle correctly in both directions now. > > Unrelated to that, please keep the Python 2 -> 3 build dependency > > change out of this emergency update. > > ACK. > > Regards, > > Adam cu Adrian
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On 6/12/20 7:36 AM, Adrian Bunk wrote: On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote: On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: Control: tags 962669 moreinfo On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: On 6/11/20 1:33 PM, Adam D. Barratt wrote: Just to confirm - will the certificates be automatically re- added (assuming that users have either the automatically trust or prompt options enabled)? (stretch-pu report cc'ed, since same applies) Excellent question. I believe we're going to hit #743339 "Previously removed certificates not added again". I had not found a reasonable fix for that case in general, to preserve a user's selections. Maybe a "good enough" fix will have to do for the specific ones added back. OK. In that case, how does this seem as an SUA text? [...] use the affected certificates, you may need to manually enable them by running "dpkg-reconfigure ca-certificates" as root. This does not work in various embedded scenarios. Wouldn't embedded setups be more likely to have a hard-coded configuration? The official way to hardcode CA configuration would be through debconf or /etc/ca-certificates.conf, which runs into #743339. If you are really security-focussed you might pin the actual certificate instead of trusing a CA. For the average embedded device the only thing that matters about ca-certificates is something like "https works". Would it work to force-enable them in /etc/ca-certificates.conf from the preinst when upgrading from old-version matching 20200601* ? This could actually be done in the postinst before the debconf configuration, something like sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" /etc/ca-certificates.conf for all affected certificates when $2 matches 20200601* This is what I was working on last night, there is an old dpkg --compare-versions example in postinst, and that is similar to the action I had in mind. I intend to sed all in the list we blacklisted, since they remain in the bundle, so we're not here next week with another of the date or intermediate exceptions in NSS. If there is objection to this, please let me know. I'll leave the technical answer to Michael. Practically, it's then not great for users who had intentionally removed the certificates - or simply decided not to trust them in the first place - prior to the upgrade. I'm not sure how we could distinguish the cases automatically. The default is to trust all new certificates, so this is what the vast majority of users are using. #743339 is primarily about this kind of remove+readd in the package being the only way how any installed certificate could end up being deactivated in the default situation. This is permanent damage that can lead to nasty problems months or years later. There are likely some users somewhere who have manually activated or deactivated these specific certificates, but this is nothing we can handle correctly in both directions now. This is exactly the kind of behavior I think we'd like to preserve, so we don't stomp on a previous intentional trust setting and blindly enable, but I think this specific list of blacklisted certs being re-enabled, if specifically 20200601* is installed should work. The default "yes" trust and re-enable of these may be the "good enough" fix, while #743339 is still an issue. That should hit way over 80% use case, if we consider an 80/20 split. For what it's worth, with additional testing after this, I believe I may have found one of the "save but disable' causes of #743339, after staring at ca-certificates.conf creation, upgrades, etc in postinst and the debconf ca-certificates.config contents. It won't fix existing trust ^!'s, but would help on future root removals - later on that bug.. Unrelated to that, please keep the Python 2 -> 3 build dependency change out of this emergency update. ACK. Will do, thank you both. Kind regards, Michael
Bug#962722: nmu: md4c_0.4.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, The last upload of md4c went through NEW and thus I'm requesting a binNMU to have the amd64 packages rebuilt on buildd, such that the package can transition to testing. nmu md4c_0.4.4-1 . amd64 . unstable . -m "Rebuild amd64 package on the buildd so it can transition." -- Med vänliga hälsningar Patrick Franz
Bug#962722: marked as done (nmu: md4c_0.4.4-1)
Your message dated Fri, 12 Jun 2020 22:55:53 +0200 with message-id <20200612205553.gf2...@ramacher.at> and subject line Re: Bug#962722: nmu: md4c_0.4.4-1 has caused the Debian Bug report #962722, regarding nmu: md4c_0.4.4-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 962722: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962722 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, The last upload of md4c went through NEW and thus I'm requesting a binNMU to have the amd64 packages rebuilt on buildd, such that the package can transition to testing. nmu md4c_0.4.4-1 . amd64 . unstable . -m "Rebuild amd64 package on the buildd so it can transition." -- Med vänliga hälsningar Patrick Franz --- End Message --- --- Begin Message --- On 2020-06-12 20:44:23 +0200, Patrick Franz wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hi, > > The last upload of md4c went through NEW and thus I'm requesting a binNMU to > have the amd64 packages rebuilt on buildd, such that the package can > transition to testing. > > nmu md4c_0.4.4-1 . amd64 . unstable . -m "Rebuild amd64 package on the buildd > so it can transition." Scheduled, but binNMUed everywhere since the package provides MA: same binaries. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
