Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 10:55:19AM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 25/10/16 20:09, Moritz Muehlenhoff wrote: > > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > >> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > >>> > >>> I'm sorry but I'm going to have to nack this for Stretch, as much as I > >>> like to > >>> approve transitions and get new stuff in. I have looked at the opened > >>> bugs and > >>> I'm afraid this still is too disruptive. I have noticed that you have > >>> forwarded > >>> some of them and sent patches, and I appreciate that. We can do this > >>> early in > >>> the Buster cycle, so let's look at the status of this and prepare for the > >>> transition when Stretch gets released. > >> > >> Is having 2 version of OpenSSL in Stretch an option? > > > > We've discussed this within the security team and we'd be fine with > > a one-time exception to have two openssl releases in stretch; the API > > changes are clearly too invasive to cover the entire Debian archive, > > but 1.1 also carries sufficiently important new features (like support > > for chacha20/poly1305) to warrant the extra complexity. > > > > (It's the release team's call of course). > > 19:46 < nthykier> pochu: seen jmm_ reply to the libssl thread? > 19:46 < jcristau> adsb: yay for binary debdiffs in q-v! thanks a bunch. > 19:46 < pochu> yep > 19:47 < pochu> nthykier: so my concern was there was a big risk that we > wouldn't finish the transition intime, delaying the release. but if the > security > team is fine with (potentially, as I'll try not to) shipping both, then we > should be fine, and I think I'll ack it > 19:48 < pochu> of course we'll still try to get rid of the old one > 19:48 < nthykier> ack, I think that just made me pro on doing that as well > 19:48 < pochu> cool, good to see we're on the same page > > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze, and depending on how many > packages (and which ones, for risk management etc) are left to be fixed after > that, I may be happy to grant exceptions. But worst case we just ship both. > > But please, wait a little bit so that we can sort out the PIE fallout. You can > start preparing the updates and upload to experimental to clear NEW if you > want. > We'll let you know once it's ok to upload to sid. So it has been suggested that we keep the libssl-dev package at the 1.0.2 package and create a new -dev package for the 1.1 version. We could then lower the severity of the bugs to important again, and only the packages wanting to make use of 1.1 could switch then. I think the most important new security feature in the 1.1.0 version is the extended master secret support. There are also a bunch of others like the chacha20-poly1305 and x25519, but they're less important. All TLS using applications really should start ussing the EMS, not just a few that want to switch to 1.1. Kurt
NEW changes in stable-new
Processing changes file: potrace_1.12-1+deb8u1_arm64.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_armel.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_armhf.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_i386.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_mips.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_mipsel.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_powerpc.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_ppc64el.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_s390x.changes ACCEPT
NEW changes in stable-new
Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_amd64.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_arm64.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_armel.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_armhf.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_i386.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_mips.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_mipsel.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_powerpc.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_ppc64el.changes ACCEPT Processing changes file: asterisk_11.13.1~dfsg-2+deb8u1_s390x.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_amd64.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_arm64.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_armel.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_armhf.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_i386.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_mips.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_mipsel.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_powerpc.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_ppc64el.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u3_s390x.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_allonly.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_amd64.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_arm64.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_armel.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_armhf.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_i386.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_mips.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_mipsel.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_powerpc.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_ppc64el.changes ACCEPT Processing changes file: nginx_1.6.2-5+deb8u4_s390x.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_amd64.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_armel.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_armhf.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_i386.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_powerpc.changes ACCEPT Processing changes file: php5_5.6.26+dfsg-0+deb8u1_s390x.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_amd64.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_arm64.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_armel.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_armhf.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_i386.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_mips.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_mipsel.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_powerpc.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_ppc64el.changes ACCEPT Processing changes file: php5_5.6.27+dfsg-0+deb8u1_s390x.changes ACCEPT Processing changes file: potrace_1.12-1+deb8u1_amd64.changes ACCEPT
Bug#842013: jessie-pu: package potrace/1.12-1+deb8u1
Control: tags -1 + pending On Tue, 2016-10-25 at 18:49 +0200, Andrew Shadura wrote: > On 25/10/16 18:26, Adam D. Barratt wrote: > > On 2016-10-25 14:32, Andrew Shadura wrote: > >> On 25/10/16 15:31, Adam D. Barratt wrote: > >>> Control: tags -1 + confirmed > >>> > >>> On 2016-10-25 10:10, Andrew Shadura wrote: > I have prepared an upload fixing CVE-2016-8694, CVE-2016-8695, > CVE-2016-8696, CVE-2016-8697, CVE-2016-8698, CVE-2016-8699, > CVE-2016-8700, > CVE-2016-8701, CVE-2016-8702, CVE-2016-8703. [...] > Indeed, I uploaded a wrong .changes. Sorry for the noise, will re-upload > shortly. I've flagged that re-upload for acceptance; thanks. Regards, Adam
Processed: Re: Bug#842013: jessie-pu: package potrace/1.12-1+deb8u1
Processing control commands: > tags -1 + pending Bug #842013 [release.debian.org] jessie-pu: package potrace/1.12-1+deb8u1 Added tag(s) pending. -- 842013: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842013 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#842288: transition: gdal
On 10/28/2016 01:39 AM, Sebastiaan Couwenberg wrote: > On 10/27/2016 11:58 PM, Emilio Pozuelo Monfort wrote: >> On 27/10/16 20:10, Bas Couwenberg wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear Release Team, >>> >>> For the Debian GIS team I'd like to transition to GDAL 2.1.2. >>> >>> Like the previous transition to GDAL 2.1.1 (#830966), there is no SONAME >>> bump, only the virtual ABI package changed to account for the C++ symbol >>> changes. >>> >>> All reverse dependencies rebuilt successfully with GDAL 2.1.2 from >>> experimental as summarized below, except mysql-workbench whose build >>> dependencies are not installable (#840786), but it's not in testing due >>> to (#839356). >>> >>> libgdal-grass doesn't need a binNMU as the 2.1.2 version will be >>> uploaded to unstable instead. liblas likewise doesn't need a binNMU, >>> the version is experimental will be moved to unstable instead. >>> >>> Please also binNMU osgearth in experimental as part of the transition. >> >> Sounds good. Go ahead. > > Thanks for the super quick feedback again! > > gdal (2.1.2+dfsg-1), liblas (1.8.1-3) & libgdal-grass (2.1.2-1) have > been uploaded to unstable, and gdal was just accepted. Sometime tomorrow > the buildds should have installed the packages. The mips64el buildd just installed gdal (2.1.2+dfsg-1), it's now available on all release architectures and all ports where the build dependencies are installable. Looks like we're ready for the binNMUs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
NEW changes in stable-new
Processing changes file: mat_0.5.2-3+deb8u1_i386.changes REJECT
Re: Please reject mat 0.5.2-3+deb8u1
On Fri, 2016-10-28 at 17:00 +0200, intrigeri wrote: > Hi! > > I've uploaded mat 0.5.2-3+deb8u1 by mistake to the "jessie-security" > distribution on ssh.upload.debian.org, while it should have gone to > security-master.d.o. Looks like it has therefore landed in stable-new. > Please reject/remove it, and sorry for the burden! Thanks for letting us know - I've flagged it for rejection. Regards, Adam
Please reject mat 0.5.2-3+deb8u1
Hi! I've uploaded mat 0.5.2-3+deb8u1 by mistake to the "jessie-security" distribution on ssh.upload.debian.org, while it should have gone to security-master.d.o. Looks like it has therefore landed in stable-new. Please reject/remove it, and sorry for the burden! Cheers, -- intrigeri
Bug#842177: transition: hdf5
On 2016-10-26 19:12, Gilles Filippini wrote: On 2016-10-26 19:03, Sebastiaan Couwenberg wrote: On 10/26/2016 06:46 PM, Gilles Filippini wrote: I've checked the build of every reverse dependencies. These few ones are of concern: * libsis-jhdf5-java : unmaintained upstream - low popcon * pytables : doesn't support new hdf5 API - popcon about 3000 - no reverse dependencies * yorick-hdf5 : desing flaw - no support for 64bits integers - popcon about 300 - no reverse dependencies * insighttoolkit4 : in progress; looking for a box with enough RAM - rather low popcon * ants : in progress; build depends on insighttoolkit4 - raher low popcon From the above packages, the only real concern is pytables. A discussion is ongoing on debian-science@d.o, and I'm confident we'll find a solution before the Stretch freeze. pytables does have several reverse dependencies, who in turn have several reverse dependencies too. pytables in the dependency chain of geopandas, having it removed from stretch would be very sad. Ooops, sorry, I didn't noticed that. Actually I checked weeks ago and didn't remember there were reverse depends. My bad. But as said above, I'm confident we'll find a solution for pytables before the Strtch freeze. It would be removed from testing only for a while. insighttoolkit4 is in the dependency chain of otb, and like pytables having it removed from stretch would be very sad. Even more than pytables. I've successfully tested today a full insighttoolkit4 build for unstable on a stronger box than mine. I'll rebuild tomorrow against hdf5-1.10. I'm rather confident about this one too. Status update: insighttoolkit4: hdf5 libmincpatch provided via #842342 Thanks, _g.
Bug#827061: transition: openssl
On Tue, Oct 25, 2016 at 08:09:06PM +0200, Moritz Muehlenhoff wrote: > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > > On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > > > > > > I'm sorry but I'm going to have to nack this for Stretch, as much as I > > > like to > > > approve transitions and get new stuff in. I have looked at the opened > > > bugs and > > > I'm afraid this still is too disruptive. I have noticed that you have > > > forwarded > > > some of them and sent patches, and I appreciate that. We can do this > > > early in > > > the Buster cycle, so let's look at the status of this and prepare for the > > > transition when Stretch gets released. > > > > Is having 2 version of OpenSSL in Stretch an option? > > We've discussed this within the security team and we'd be fine with > a one-time exception to have two openssl releases in stretch; the API > changes are clearly too invasive to cover the entire Debian archive, > but 1.1 also carries sufficiently important new features (like support > for chacha20/poly1305) to warrant the extra complexity. What are actually the exact technical benefits of 1.1 that are relevant for the software in stretch? Which new features are desirable for all OpenSSL-using software, and for which new features is it a good option that only software using these features opts in to using 1.1? The only way to make chacha20/poly1305 available for all OpenSSL-using code in stretch would be to patch 1.0.2. Patches are available and LibreSSL ships this since the original release in July 2014, so that should be doable. Improvements to the defaults like #728504 (disable RC4 by default) can be backported to 1.0.2 even more easily. And these are things that really should be done in any case, unless stretch ships without 1.0.2 What is the situation regarding other important 1.1 features? > (It's the release team's call of course). > > Cheers, > Moritz cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
