Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-02-22 00:46:56 [+0100], Emilio Pozuelo Monfort wrote:
> Thanks. Investigating the rest would be good. I guess most of those are just 
> for

So I made a list by the time I received that email I just managed to
work through it. I check most of them manually but by the end of it I
hacked something that checked if any of the libssl1.0.2 symbols were
used.
Anyway. Most of them do not use libssl at all. A few use for a
testsuite or load it at runtime. 
As next course of action I would make sure that each libssl1.0-dev
package has a bug to move it back to libssl-dev for Buster.
Is anything that blocks this bug from getting closed?

My protocol:
389-ds-base-1.3.5.15 Seems not to use it, had it from netsmp
alljoyn-gateway-1504-15.04~git20160606 seems not to use it.
alljoyn-services-1504-15.04 seems not to use it.
alljoyn-thin-client-1509-15.09a testsuite only probably
alljoyn-thin-client-1604-16.0 testsuite only probably
autofs-5.1.2 used once, probably no longer, as part of SASL
bro-aux-0.38 seem to check for it but not use it
cacti-spine-0.8.8h recommends openssl, probably for netsnmp reasons, does not 
user it.
carbon-c-relay-2.5 used libssl-dev for crypto but not is selfcontained. 
citus-6.0.1.PGDG recommends using openssl-devel but does not use opessl
connectome-workbench-1.2.3+git3-g7b83782 Recommends it, but it seems not using 
it.
cryfs-0.9.6 Depends on it, could use it but does not.
donkey-1.0.1 alt dep
drumgizmo-0.9.11 testsuite only
edbrowse-3.6.1 no longer using
fis-gtm-6.3-000A got disabled, fixed for 1.1, not enabled. #856984 opened
freebsd-utils-10.3~svn296373 #835806, not building at all
gfarm2fs-1.2.9.9 no libssl usage (openssl but no dep)
gnome-commander-1.4.8 seems not to use it
gnutls28-3.5.8 testsuite
guymager-0.8.3 depends on libssl for crypto reasons but use internal
havp-0.92a does not need it
hplip-3.16.11+repack0 looks like it does not use it
httraqt-1.4.8 does not need it, just a frontend for httrack
isc-dhcp-4.3.5: does not use it
isdnutils-3.25+dfsg1: does not user it
iva-1.0.8+ds: seems not to use it
lcmaps-plugins-jobrep-1.5.3 header exports only, no libs functions.
lgogdownloader-3.1 uses libcurl4-gnutls-dev, openssl crypto locks are nops with 
1.1
libapache-mod-log-sql-1.100 depends on it, seems not to use it
libasr-1.0.2 includes the header but does not make any use of it.
libdap-3.18.2 seems not to need it, moved to libcurl4-gnutls-dev
libfprint-0.6.0 does not use it, switched to nss
libgwenhywfar-4.15.3 libssl not found due multiarch lib layout.
libpam-ufpidentity-1.0 seems not to use it
libsecp256k1-0.1~20161228 testsuite
linux-grsec-4.9.10 does not look used.
lnav-0.8.1 does not need it
mcabber-1.0.4 does not use it
mitmproxy-0.18.2 uses only openssl, not libssl-dev
mysql++-3.2.2+pristine seems not to use it
mysql-connector-c++_1.1.7 seems not to use it.
openclonk-7.0 seems not to use it.
openntpd seems not use it. Check for arc4random (libbsd) and has builtin sha 
support
orafce-3.3.1 seems not to use it
percona-xtrabackup-2.2.3 not in testing
phantomjs-2.1.1+dfsg seems not to use it.
pldebugger-9.5.0-10-gd663a19 seems not to use it
profanity-0.5.0 seems not to use it.
pychef-0.2.3 does not user it.
pygresql-5.0.3 seems not to use it
pyopenssl_16.2.0-1 does not need it.
qpid-cpp-0.16 seems not to need it
quassel-0.12.4 maybe not, uses to check if QT supports ssl
quota-4.03 seems not to use it
racket-6.7 loaded at runtime
rhash-1.3.3 optional via dlopen and does not look for 1.0.2 or 1.1.
signond-8.59 seems not to use it
subcommander-2.0.0~b5p2 does not really use it, but prints openssl's version 
number
telepathy-rakia-0.8.0 seems not to use it
unar-1.10.1 is not using it.
user-mode-linux-4.9-1um: needs it during compile only
vdr-plugin-live-0.3.0+git20160123 seems not to need it
vsearch-2.3.4 does not use it.
websocketpp-0.7.0 ships header files
wget-1.19.1 only udeb
wimlib-1.11.0 could use crypto but does not
wine-1.8.6 seems not to use it.
wine-development-2.0 seems not to use it

> Thanks,
> Emilio

Sebastian

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-02-22 00:46:56 [+0100], Emilio Pozuelo Monfort wrote:
> > There are 78 packages in the unkown state. The first few I looked could
> > actually have their libssl-dev dependency dropped. khtml is the first
> > one which looked wrong. I will open a bug about that later. I didn't get
> > any further yet.
> 
> Thanks. Investigating the rest would be good. I guess most of those are just 
> for
> build-depends, but if there are any with bad depends (e.g. some -dev package
> unnecessarily depending on libssl*-dev) it'd be good to fix that for stretch,
> because of the conflicting libssl dev packages.

We shouldn't have any of those FTBFS in archive so I guess you mean
something outside of the archive. Anyway, if I find something I will
act.

> Sounds like things are under control now. The concern of -dev packages not 
> being
> co-installable is a valid one, but I guess we'll have to live with that.

Both openssl versions provide .pc files. So we could keep 1.1 as-is and
force the libssl1.0-dev users to use what the .pc file(s) says which
would include a different lib to link (say -lssl-1.0) and a different
spot for the header files.
We have 148 1.0 packages and 437 using 1.1 right now. That means we
would have to touch 148 packages for that (and most packages I touched
did not use the .pc file). I'm not sure it is worth it.  Also having
them not co-installable minimizes the risk that someone tries to pass
openssl's struct from one package to the other.

> Thanks,
> Emilio

Sebastian

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

On 22/02/17 00:28, Sebastian Andrzej Siewior wrote:
> On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote:
>> At this point, it seems clear to me that we're getting nowhere fast.
>> With the freeze looming in a few days, this is growing to be a very big
>> risk for the stretch release.
> 
> Where do we stand on the openssl transition from the perspective of
> people who think it is not done yet?
> 
> The transition tracker for 1.0 shows three packages red. They depend on
> "libssl-dev | libssl1.0-dev" and it builds against 1.1. Do want them to
> decide properly?

I think that's alright.

> The transition tracker for 1.1 shows 11 packages. Except for pyrit all
> are out of testing and have more than just one RC bug which is not
> relevant to the transition. And pyrit just didn't make it on i386.

Hopefully it gets fixed, but otherwise it's not a key package so it will
eventually get dropped from testing.

> There are 78 packages in the unkown state. The first few I looked could
> actually have their libssl-dev dependency dropped. khtml is the first
> one which looked wrong. I will open a bug about that later. I didn't get
> any further yet.

Thanks. Investigating the rest would be good. I guess most of those are just for
build-depends, but if there are any with bad depends (e.g. some -dev package
unnecessarily depending on libssl*-dev) it'd be good to fix that for stretch,
because of the conflicting libssl dev packages.

Sounds like things are under control now. The concern of -dev packages not being
co-installable is a valid one, but I guess we'll have to live with that.

Thanks,
Emilio

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote:
> At this point, it seems clear to me that we're getting nowhere fast.
> With the freeze looming in a few days, this is growing to be a very big
> risk for the stretch release.

Where do we stand on the openssl transition from the perspective of
people who think it is not done yet?

The transition tracker for 1.0 shows three packages red. They depend on
"libssl-dev | libssl1.0-dev" and it builds against 1.1. Do want them to
decide properly?

The transition tracker for 1.1 shows 11 packages. Except for pyrit all
are out of testing and have more than just one RC bug which is not
relevant to the transition. And pyrit just didn't make it on i386.

There are 78 packages in the unkown state. The first few I looked could
actually have their libssl-dev dependency dropped. khtml is the first
one which looked wrong. I will open a bug about that later. I didn't get
any further yet.

> Cheers,
> Julien

Sebastian

Bug#827061: transition: openssl

[Ondřej Surý]

JFTR cyrus-sasl2 should not fail with openssl 1.0, so I'll fix that
quickly if needed.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Fri, Feb 3, 2017, at 13:45, Sebastian Andrzej Siewior wrote:
> On 2017-02-01 22:18:07 [+0100], Sebastian Andrzej Siewior wrote:
> > Currently I am rebuilding testing with the same set of package against
> > libssl-dev provided by libssl1.0-dev. After that I retry the failed
> > packages above where I am not sure why they failed (mostly I suspect the
> > parallel) case.
> > Do you want a complete testing rebuild or another set of packages?
> 
> it is at [0] and a retry of all failed with -j1 at [1]. I had just a
> quick look:
> - perl fails in the test suite but that ist "okay". It builds against
>   1.0 but it B-D are built against 1.1 and perl exposes the openssl ABI
>   as-is. So rebuilding it in the right order should avoid it.
> 
> - a few packages like cfengine3, ldns, freelan, duo-unix, dogecoin,
>   dsniff and cyrus-sasl2 seem like they compile with 1.1 but do not
>   compile against 1.0 since they expect 1.1 functions to be around.
>   There may be more, I had a quick look. The build succeeded with 1.1
>   earlier.
> 
> - some of globus-* and lcmaps-* packages fail and I am not sure if they
>   can't deal with 1.0 anymore or if it is similar to perl where
>   everything has to be moved to 1.0 in the right order.
> 
> [0]
> https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0/
> [1]
> https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0-retry/
> 
> > > Cheers,
> > > Julien
> 
> Sebastian

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-02-01 22:18:07 [+0100], Sebastian Andrzej Siewior wrote:
> Currently I am rebuilding testing with the same set of package against
> libssl-dev provided by libssl1.0-dev. After that I retry the failed
> packages above where I am not sure why they failed (mostly I suspect the
> parallel) case.
> Do you want a complete testing rebuild or another set of packages?

it is at [0] and a retry of all failed with -j1 at [1]. I had just a
quick look:
- perl fails in the test suite but that ist "okay". It builds against
  1.0 but it B-D are built against 1.1 and perl exposes the openssl ABI
  as-is. So rebuilding it in the right order should avoid it.

- a few packages like cfengine3, ldns, freelan, duo-unix, dogecoin,
  dsniff and cyrus-sasl2 seem like they compile with 1.1 but do not
  compile against 1.0 since they expect 1.1 functions to be around.
  There may be more, I had a quick look. The build succeeded with 1.1
  earlier.

- some of globus-* and lcmaps-* packages fail and I am not sure if they
  can't deal with 1.0 anymore or if it is similar to perl where
  everything has to be moved to 1.0 in the right order.

[0] 
https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0/
[1] 
https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0-retry/

> > Cheers,
> > Julien

Sebastian

Bug#827061: transition: openssl

[Holger Levsen]

On Thu, Feb 02, 2017 at 09:49:15PM +0100, Sebastian Andrzej Siewior wrote:
> what is wrong with passing -j16 to sbuild? Other packages, that do not
> support parallel building, don't do it.

yeah, exactly.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-02-02 22:26:35 [+0200], Adrian Bunk wrote:
> The kannel package does not claim to support parallel building.
> 
> If you attempt parallel building on that,
> then any build failures are your fault.

what is wrong with passing -j16 to sbuild? Other packages, that do not
support parallel building, don't do it.

> cu
> Adrian

Sebastian

Bug#827061: transition: openssl

[Adrian Bunk]

On Thu, Feb 02, 2017 at 09:09:56PM +0100, Sebastian Andrzej Siewior wrote:
>...
> > You can go to http://reproducible.debian.net/$srcpkgname and see for 
> > yourself
> > whether they build fine in our environment. If they do, you can rule out
> > "parallel" as causing this…
> 
> I see. I looked at kannel. The -j1 version:
>...
> That "flow object not accepted by port" seems not to be the issue but
> the fact, that wtls.tmp is reused and probably removed too early.

The kannel package does not claim to support parallel building.

If you attempt parallel building on that,
then any build failures are your fault.

> Sebastian

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

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-02-02 16:54:08 [+], Holger Levsen wrote:
>  
> I'm surprised to see that many packages failing to build in parallel, as we're
> building everything in parallel and I dont remember such failures recentl.y

So retried them with -j1 [0] and:
- passed:
 boxbackup 0.11.1~r2837-4
 erlang 19.2.1+dfsg-1
 gridsite 2.3.2-3
 kannel-sqlbox 0.7.2-4
 kannel 1.4.4-4
 mailsync 5.2.2-3.1
 netkit-telnet-ssl 0.17.41+0.2-2
 nmh 1.6-16
 postfix 3.1.4-3
 pure-ftpd 1.0.43-3
 qtwebsockets-opensource-src 5.7.1~20161021-4
 r-cran-rsclient 0.7-3-2
 rserve 1.7-3-3
 vde2 2.3.2+r586-2.1

- still failing:
 mongodb 3.2.11-2
 nova 14.0.0-3
 openvswitch 2.6.2~pre+git20161223-3
 pyrit 0.4.0-7
 python-asyncssh 1.8.1-2
 ruby2.3 2.3.3-1

and the failing ones do not look obvious.

[0] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-retry/

> You can go to http://reproducible.debian.net/$srcpkgname and see for yourself
> whether they build fine in our environment. If they do, you can rule out
> "parallel" as causing this…

I see. I looked at kannel. The -j1 version:

|sed 
"s/#FIGTYPE#/.png/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" 
doc/wtls/wtls.xml > doc/wtls/wtls.tmp
|openjade -V nochunks -t sgml -d 
/usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl 
/usr/share/xml/declaration/xml.dcl doc/wtls/wtls.tmp > doc/wtls/wtls.html
|rm -f doc/wtls/wtls.tmp
…
|sed 
"s/#FIGTYPE#/.ps/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" 
doc/wtls/wtls.xml > doc/wtls/wtls.tmp
|cd `dirname doc/wtls/wtls.xml` && openjade -o `basename doc/wtls/wtls`.rtf -t 
rtf -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl 
/usr/share/xml/declaration/xml.dcl `basename doc/wtls/wtls`.tmp
|rm -f doc/wtls/wtls.tmp

and the -j16:
|sed 
"s/#FIGTYPE#/.png/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" 
doc/wtls/wtls.xml > doc/wtls/wtls.tmp
|openjade -o doc/wtls/wtls.tex -t tex -d 
/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl 
/usr/share/xml/declaration/xml.dcl doc/wtls/wtls.tmp
|openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E:
 flow object not accepted by port; only display flow objects accepted
|openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E:
 flow object not accepted by port; only display flow objects accepted
|openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E:
 flow object not accepted by port; only display flow objects accepted
|rm -f doc/wtls/wtls.tmp
|openjade -o doc/alligata/alligata.tex -t tex -d 
/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl 
/usr/share/xml/declaration/xml.dcl doc/alligata/alligata.tmp
|rm -f doc/wtls/wtls.tmp
…
|ranlib libwmlscript.a
|openjade:E: cannot find "doc/wtls/wtls.tmp"; tried "doc/wtls/wtls.tmp", 
"/usr/local/share/sgml/doc/wtls/wtls.tmp", "/usr/share/sgml/doc/wtls/wtls.tmp"
|openjade:/usr/share/xml/declaration/xml.dcl:190:1:E: end of document in prolog
|rm -f doc/wtls/wtls.tmp

That "flow object not accepted by port" seems not to be the issue but
the fact, that wtls.tmp is reused and probably removed too early.

> -- 
> cheers,
>   Holger

Sebastian

Bug#827061: transition: openssl

[Holger Levsen]

On Wed, Feb 01, 2017 at 10:18:07PM +0100, Sebastian Andrzej Siewior wrote:
> - boxbackup_0.11.1~r2837-4
>   parallel issue?
> - erlang 1:19.2.1+dfsg-1
>   parallel issue?
> - kannel 1.4.4-4 
>   parallel issue?
> - kannel-sqlbox 0.7.2-4 
>   parallel issue?
> - mailsync 5.2.2-3.1
>   parallel?
> - netkit-telnet-ssl 0.17.41+0.2-2
>   parallel?
> - postfix 3.1.4-3
>   parallel?
> - pure-ftpd 1.0.43-3
>   parallel?
> - pyrit 0.4.0-7
>   parallel? testsuite
> - r-cran-rsclient 0.7-3-2 
>   parallel?
> - rserve 1.7-3-3
>   parallel?
> - krat 1:2.2cvs20100105-true-dfsg-6.1
>   parallel?
 
I'm surprised to see that many packages failing to build in parallel, as we're
building everything in parallel and I dont remember such failures recentl.y

You can go to http://reproducible.debian.net/$srcpkgname and see for yourself
whether they build fine in our environment. If they do, you can rule out
"parallel" as causing this…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote:
> At this point, it seems clear to me that we're getting nowhere fast.
> With the freeze looming in a few days, this is growing to be a very big
> risk for the stretch release.

I rebuild testing, with the subset of:
 grep-dctrl -FDepends libssl1.0.2 Packages -sSource -n | awk '{print $1}' > List
 grep-dctrl -FDepends libssl1.1 Packages -sSource -n | awk '{print $1}' >> List
 grep-dctrl -FDepends openssl Packages -sSource -n | awk '{print $1}' >> List
 grep-dctrl -FBuild-Depends,Build-Depends-Indep -w libssl-dev -o -w openssl 
Sources -sPackage -n >> List
 grep-dctrl -FBuild-Depends,Build-Depends-Indep -w libssl1.0-dev Sources 
-sPackage -n >> List

as of today. The result is at [0]. Let me go over results of the failed
packages:
- bind9 1:9.10.3.dfsg.P4-10.1
  1.1 issue, unstable has 1:9.10.3.dfsg.P4-11 with libssl1.0-dev

- boxbackup_0.11.1~r2837-4
  parallel issue?

- clamav 0.99.2+dfsg-5
  #852894, curl related

- erlang 1:19.2.1+dfsg-1
  parallel issue?

- gridsite 2.3.2-2
  /usr/bin/ld: cannot find -lgridsite
  unstable has newer version

- gvpe 2.25-3
  missing zlib-dev, #850983, unstable has fixed version

- httest 2.4.8-1.1
  1.1 issue, unstable has 2.4.18-1.1 with libssl1.0-dev

- kamailio 4.4.4-1
  missing dependcy, #852905, unstable has fixed version

- kannel 1.4.4-4 
  parallel issue?

- kannel-sqlbox 0.7.2-4 
  parallel issue?

- lcmaps-plugins-verify-proxy 1.5.4-2
  1.1 issue, unstable has fixed version

- lcmaps-plugins-voms 1.6.2-2
  1.1 issue, unstable has fixed version

- m2crypto 0.24.0-1
  1.1 issue, no fix yet (#827068)

- mailsync 5.2.2-3.1
  parallel?

- mongodb 1:3.2.11-2
  testsuite killed

- netkit-telnet-ssl 0.17.41+0.2-2
  parallel?

- nmh 1.6-16 
  most of testsuite fails?

- nova 2:14.0.0-3
  testsuite fails?

- ntp 1:4.2.8p9+dfsg-2
  not openssl related, fixed in unstable, #851803

- openvswitch 2.6.2~pre+git20161223-3 
  testsuite failure, probably due to br0 on the test box.

- php7.0 7.0.14-2
  curl check, unstable has the fixed version

- postfix 3.1.4-3
  parallel?

- pure-ftpd 1.0.43-3
  parallel?

- pyrit 0.4.0-7
  parallel? testsuite

- python-asyncssh
  testsuite, X?

- qtwebsockets-opensource-src 5.7.1~20161021-4
  testsuite failed

- r-cran-rsclient 0.7-3-2 
  parallel?

- rserve 1.7-3-3
  parallel?

- ruby2.3 2.3.3-1
  parallel?, testsuite failure, maybe harmless

- sbsigntool 0.6-3.1 
  linker failre, unstable has fixed, #842446

- swi-prolog 7.2.3+dfsg-5
  fails the testsuite, #852892

- sx 2.0+ds-3 
  fails the testsuite, #852888 

- krat 1:2.2cvs20100105-true-dfsg-6.1
  parallel?

- tpm-tools 1.3.8-2
  1.1 related, looks like two RC bugs related

- vde2 2.3.2+r586-2.1
  parallal?

- wpa 2.5-2+v2.4-3
  1.1 related, unstable should be fixed.

Currently I am rebuilding testing with the same set of package against
libssl-dev provided by libssl1.0-dev. After that I retry the failed
packages above where I am not sure why they failed (mostly I suspect the
parallel) case.
Do you want a complete testing rebuild or another set of packages?
 
[0] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing/

> Cheers,
> Julien

Sebastian

Bug#827061: transition: openssl

[Moritz Mühlenhoff]

On Sat, Jan 28, 2017 at 07:37:09PM +0100, Julien Cristau wrote:
> On Sat, Jun 11, 2016 at 20:59:53 +0200, Kurt Roeckx wrote:
> 
> > OpenSSL will soon release a new upstream version with a new
> > soname.  This new version will break various packages, see:
> > https://lists.debian.org/debian-devel/2016/06/msg00205.html
> > 
> > I'm currently not sure when the release will be ready.  I would
> > like to start this transition as soon as possible, but probably
> > after it's actually released.  I don't expect this to take long.
> > 
> At this point, it seems clear to me that we're getting nowhere fast.
> With the freeze looming in a few days, this is growing to be a very big
> risk for the stretch release.

Why? The last time I saw it status it was down to something like
five packages in question.

What new RC bugs related to the transition?

Cheers,
Moritz

Bug#827061: transition: openssl

[Julien Cristau]

On Sat, Jun 11, 2016 at 20:59:53 +0200, Kurt Roeckx wrote:

> OpenSSL will soon release a new upstream version with a new
> soname.  This new version will break various packages, see:
> https://lists.debian.org/debian-devel/2016/06/msg00205.html
> 
> I'm currently not sure when the release will be ready.  I would
> like to start this transition as soon as possible, but probably
> after it's actually released.  I don't expect this to take long.
> 
At this point, it seems clear to me that we're getting nowhere fast.
With the freeze looming in a few days, this is growing to be a very big
risk for the stretch release.

I believe we should cut our losses, go back to shipping libssl-dev as
1.0.2 for stretch, and rebuild the world.  I think this is 1) less work
than actually getting ourselves out of the current mess, and 2) likely
to get us to a better state for stretch users, who won't have to deal
with half the archive's -dev package indirectly conflicting with the
other half.

I'm willing to prepare a new openssl1.0 package to take over libssl-dev
and openssl binaries.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#827061: transition: openssl: Unrelated updates to rdep packages?

[Emilio Pozuelo Monfort]

On 10/12/16 14:08, Christian Seiler wrote:
> Hi,
> 
> On 10/26/2016 10:55 AM, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
> 
> I have a quick question now that the transition is ongoing: is it OK
> for me to upload a new version of open-isns (B-D: libssl-dev) that's
> unrelated to this transition? (New upstream version, some debconf
> translations; all severity <= normal.) Both OpenSSL 1.1 and 1.0 have
> migrated to testing a while back, and open-isns compiles with either
> one of those (though it hasn't been binNMU'd yet), so I don't think
> this will cause any problems - but the text in the package tracker
> says I should wait with unrelated uploads until the transition is
> completed, so I thought I'd ask first.

Yes, that is fine.

We should probably update the transition trackers so they aren't exported and
the PTS doesn't show that warning (export = false in the .ben files).

Cheers,
Emilio

Bug#827061: transition: openssl: Unrelated updates to rdep packages?

[Christian Seiler]

Hi,

On 10/26/2016 10:55 AM, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed

I have a quick question now that the transition is ongoing: is it OK
for me to upload a new version of open-isns (B-D: libssl-dev) that's
unrelated to this transition? (New upstream version, some debconf
translations; all severity <= normal.) Both OpenSSL 1.1 and 1.0 have
migrated to testing a while back, and open-isns compiles with either
one of those (though it hasn't been binNMU'd yet), so I don't think
this will cause any problems - but the text in the package tracker
says I should wait with unrelated uploads until the transition is
completed, so I thought I'd ask first.

Thanks!

Regards,
Christian

Bug#827061: transition: openssl

[Adrian Bunk]

On Thu, Dec 01, 2016 at 09:15:44PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote:
> > Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
> > give a reasonably small superset of all packages that need a binNMU?
> 
> Do you mean something like
>  is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ 
> /libssl1.0-dev/;
> 
> which results in [0] ? This gives you all packages with a B-D libssl-dev
> and D libssl1.0.2 like [1] but also lists package which do not depend on
> libssl-dev.
>...

Yes, that's what I had in mind.

Note that this is a superset of all packages requiring binNMUs,
and it is not expected to become all-green in stretch.

> Sebastian

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

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote:
> Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
> give a reasonably small superset of all packages that need a binNMU?

Do you mean something like
 is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ /libssl1.0-dev/;

which results in [0] ? This gives you all packages with a B-D libssl-dev
and D libssl1.0.2 like [1] but also lists package which do not depend on
libssl-dev.
Otherwise please give a ben config and will add it.

[0] https://breakpoint.cc/openssl-trans/html/openssl_need_upload.html
[1] https://breakpoint.cc/openssl-trans/html/openssl.html

> cu
> Adrian

Sebastian

Bug#827061: transition: openssl

[Adrian Bunk]

On Wed, Nov 30, 2016 at 07:43:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote:
> > I've been playing with ben. I tried a few things and this is the best I
> > was able to achieve [0]:
> > 
> > title = "openssl 1.0";
> > is_affected = .build-depends ~ /libssl1.0-dev/;
> > is_good = .depends ~ /libssl1.0.2/;
> > is_bad = .depends ~ /libssl1.1/;
> > 
> > And
> > 
> > title = "openssl 1.1";
> > is_affected = .build-depends ~ /libssl-dev/;
> > is_good = .depends ~ /libssl1\.1/;
> > is_bad = .depends ~ /libssl1\.0\.2/;
> 
> This does not cover packages which link against 1.0.2 but do not depend
> on libssl-dev (but inherit their dependencies).
> So it is up to you what you setup but something should be done because
> the auto tracker is gone.

Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
give a reasonably small superset of all packages that need a binNMU?

> Sebastian

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

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote:
> I've been playing with ben. I tried a few things and this is the best I
> was able to achieve [0]:
> 
> title = "openssl 1.0";
> is_affected = .build-depends ~ /libssl1.0-dev/;
> is_good = .depends ~ /libssl1.0.2/;
> is_bad = .depends ~ /libssl1.1/;
> 
> And
> 
> title = "openssl 1.1";
> is_affected = .build-depends ~ /libssl-dev/;
> is_good = .depends ~ /libssl1\.1/;
> is_bad = .depends ~ /libssl1\.0\.2/;

This does not cover packages which link against 1.0.2 but do not depend
on libssl-dev (but inherit their dependencies).
So it is up to you what you setup but something should be done because
the auto tracker is gone.

Sebastian

Re: Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Niels Thykier]

Afif Elghraoui:
> 
> 
> على الأحد 20 تشرين الثاني 2016 ‫23:05، كتب Niels Thykier:
>> Which source packages are we talking about?
> 
> gridengine and ori. In the case of gridengine, we have a contributed
> patch, but it has not been applied upstream or seen more than
> compile-testing. In the case of ori, upstream's plan is to drop the
> dependency on openssl, but I don't know when this will happen.
> 
> Thanks and regards
> Afif
> 

Feel free to go ahead with these two packages.

Thanks,
~Niels

Re: Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Afif Elghraoui]

على الأحد 20 تشرين الثاني 2016 ‫23:05، كتب Niels Thykier:
> Which source packages are we talking about?

gridengine and ori. In the case of gridengine, we have a contributed
patch, but it has not been applied upstream or seen more than
compile-testing. In the case of ori, upstream's plan is to drop the
dependency on openssl, but I don't know when this will happen.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Niels Thykier]

Afif Elghraoui:
> Hi,
> 
> I'm maintaining two packages affected by this transition. So far, I've
> just been monitoring the situation, as I share many of the concerns that
> have been raised on -devel.
> 
> Is it an acceptable solution to instead build-depend on libbsl1.0-dev,
> downgrade the severity of the FTBFS with 1.1.0 bug to important, and
> unblock the transition by it?
> 
> Many thanks and regards
> Afif
> 

Hi,

Which source packages are we talking about?

~Niels

Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Afif Elghraoui]

Hi,

I'm maintaining two packages affected by this transition. So far, I've
just been monitoring the situation, as I share many of the concerns that
have been raised on -devel.

Is it an acceptable solution to instead build-depend on libbsl1.0-dev,
downgrade the severity of the FTBFS with 1.1.0 bug to important, and
unblock the transition by it?

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-10-26 10:55:19 [+0200], Emilio Pozuelo Monfort wrote:
> 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.

I've been playing with ben. I tried a few things and this is the best I
was able to achieve [0]:

title = "openssl 1.0";
is_affected = .build-depends ~ /libssl1.0-dev/;
is_good = .depends ~ /libssl1.0.2/;
is_bad = .depends ~ /libssl1.1/;

And

title = "openssl 1.1";
is_affected = .build-depends ~ /libssl-dev/;
is_good = .depends ~ /libssl1\.1/;
is_bad = .depends ~ /libssl1\.0\.2/;

The first one will keep a list of all packages that want to stay with
1.0.2. The bad state of the second tracker should keep track of
everything that needs action.
You might also want to add [1] if you think it is usefull here.

I noticed that people close the bug referenced in [1] and stay with
1.0.2. Shouldn't they just unblock this transition bug and downgrade
severity to important?

[0] it seems ben can't match something like ".build-depends ~
/libssl-dev/ & .depends ~ /libssl1.0.2/" but this would allow to
keep everything in one page.
[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org

> Cheers,
> Emilio

Sebastian

Bug#827061: transition: openssl

[Kurt Roeckx]

On Sun, Oct 30, 2016 at 10:18:32PM +0200, Adrian Bunk wrote:
> 
> If everything that is important in 1.1.0 should be used by all
> users of OpenSSL in stretch, then the best solution for stretch
> is to ship only 1.0.2 and add all desired features there.

And I guess you're going to add all those features, and support
them?


Kurt

Bug#827061: transition: openssl

[Adrian Bunk]

Disclaimer:
I am not a member of the release team, and I am only speaking for myself.

On Sat, Oct 29, 2016 at 02:28:12AM +0200, Kurt Roeckx wrote:
>...
> 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.

This implies that OpenSSL 1.0.2 in stretch has to support EMS.

Reality is that a significant part of the archive will likely
use 1.0.2 in stretch, and planning should not be based on the
unlikely case that everything compiles and works smoothly with 1.1.0

The soft freeze is only 2 months away, and therefore a complete 
transition to 1.1.0 in stretch would imply that libssl1.0.2 must be 
removed from testing in November if it should not delay the whole 
release - I'd expect there will be plenty of runtime bugs in both 
OpenSSL itself and the 1.1.0 support of various users that will
require debugging and fixing, and runtime testing of everything
has to start ASAP.

If everything that is important in 1.1.0 should be used by all
users of OpenSSL in stretch, then the best solution for stretch
is to ship only 1.0.2 and add all desired features there.

1.0.2 is also LTS, and has upstream security support for an additional 
16 months after upstream support for 1.1.0 has ended.

I am aware that this is not a nice solution, but since there does not 
seem to be a realistic 1.1.0-only solution without impact on the release 
schedule it might be the best among the available options.

> Kurt

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

Bug#827061: transition: openssl

[Kurt Roeckx]

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

Bug#827061: transition: openssl

[Adrian Bunk]

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

Bug#827061: transition: openssl

[Tino Mettler]

On Wed, Oct 26, 2016 at 10:55:19 +0200, Emilio Pozuelo Monfort wrote:

> 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

Hi,

packages that currently FTBFS will be removed from testing in 2 weeks. 
The freeze deadline for re-entry is January 5th.  With the migration
delay the fixed package should be uploaded until the end of December,
where may people will be on holiday I guess (both Debian and Upstream
developers).

So I think it's desirable for many maintainers to have a fixed package
in Sid before Christmas or they will have to ask for a freeze
exception. I'd be glad if this is announced more prominent, e.g on the
debian-devel-announce mailing list.

Regards,
Tino

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-10-26 21:31:26 [+0200], Kurt Roeckx wrote:
> > Is this situation
> > supported or should we expect things to break? This can easily happen if an 
> > app
> > links against a library libA which uses openssl 1.0, and against libB which 
> > uses
> > openssl 1.1.
> 
> When linking you actually get a warning.
> 
> As far as I know, it should only break when they use dlopen().
> They most likely won't be using dlvsym() in that case and then it
> can pick any version. It could of course also break if they do
> very weird things.

One of the weird things would be probably if libA allocate a SSL pointer
and passes it to libB.

> Kurt

Sebastian

Bug#827061: transition: openssl

[Kurt Roeckx]

On Wed, Oct 26, 2016 at 08:53:56PM +0200, Emilio Pozuelo Monfort wrote:
> 
> Adrian Bunk asked whether mixing both OpenSSL versions into the same address
> space works fine. Is OpenSSL using symbol versioning?

Yes, and all symbols have a different version name in 1.0.2 and
1.1.0. (What is actually the important thing.)

> Is this situation
> supported or should we expect things to break? This can easily happen if an 
> app
> links against a library libA which uses openssl 1.0, and against libB which 
> uses
> openssl 1.1.

When linking you actually get a warning.

As far as I know, it should only break when they use dlopen().
They most likely won't be using dlvsym() in that case and then it
can pick any version. It could of course also break if they do
very weird things.

But I guess we'll have to see if something breaks or not.


Kurt

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

On 26/10/16 10:55, 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.
> 
> BTW I noticed Fedora has started this transition as well, so they may have 
> some
> patches that we are missing in the BTS.
> 
> Also, please bump all the bugs to serious.

Adrian Bunk asked whether mixing both OpenSSL versions into the same address
space works fine. Is OpenSSL using symbol versioning? Is this situation
supported or should we expect things to break? This can easily happen if an app
links against a library libA which uses openssl 1.0, and against libB which uses
openssl 1.1.

Cheers,
Emilio

Processed: Re: Bug#827061: transition: openssl

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #827061 [release.debian.org] transition: openssl
Added tag(s) confirmed.

-- 
827061: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

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.

BTW I noticed Fedora has started this transition as well, so they may have some
patches that we are missing in the BTS.

Also, please bump all the bugs to serious.

Cheers,
Emilio

Bug#827061: transition: openssl

[Moritz Muehlenhoff]

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).

Cheers,
Moritz

Bug#827061: transition: openssl

[Kurt Roeckx]

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?

I could upload an openssl102 source package that provides an
libssl1.0.2-dev package, so that packages that aren't ready to
move to the 1.1.0 version can build-depend on that instead.


Kurt

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

Hi Kurt,

On 12/10/16 22:47, Kurt Roeckx wrote:
> On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote:
>> On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote:
>>> On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
 On 11/06/16 20:59, Kurt Roeckx wrote:
> OpenSSL will soon release a new upstream version with a new
> soname.  This new version will break various packages, see:
> https://lists.debian.org/debian-devel/2016/06/msg00205.html
>
> I'm currently not sure when the release will be ready.  I would
> like to start this transition as soon as possible, but probably
> after it's actually released.  I don't expect this to take long.

 405 packages failed to build during your test rebuild AFAICS. That's going 
 to
 take some time to sort out...

> If I'm ready to upload it to unstable, can I start this
> transition?  Are there things you want me to do?

 Please upload to experimental first and let us know when that's happened.
>>>
>>> It's in experimental already.  The test suite only fails
>>> on hurd, for some reason it's not finding the engine.  I still
>>> need to look at that.
>>>
 We will also need bugs filed, with severity important for now.
>>>
>>> Sure, I'll start on that if I find the time.
>>>
 Also it may be useful if you can get us the intersection between the 
 packages
 that failed to build and the key packages[1] (see "Final list of 3302 key 
 source
 packages" in that file).
>>>
>>> That actually seem to be 3247 source package.  Anyway, the list is
>>> below.
>>
>> So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
>> been working on the key packages, to get them to build with
>> OpenSSL 1.1.0.  You can see that status of that at:
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org
>>
>> Most of the packages are really trivial to fix, but some do
>> require that you fix the same issues in many different places and
>> it can take some time to fix it.
>>
>> I would like to motivate more people to work on this by either
>> marking those bugs as RC, or uploading it to unstable.
> 
> Ping.

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.

Cheers,
Emilio

Bug#827061: transition: openssl

[Kurt Roeckx]

On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote:
> On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote:
> > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
> > > On 11/06/16 20:59, Kurt Roeckx wrote:
> > > > OpenSSL will soon release a new upstream version with a new
> > > > soname.  This new version will break various packages, see:
> > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html
> > > > 
> > > > I'm currently not sure when the release will be ready.  I would
> > > > like to start this transition as soon as possible, but probably
> > > > after it's actually released.  I don't expect this to take long.
> > > 
> > > 405 packages failed to build during your test rebuild AFAICS. That's 
> > > going to
> > > take some time to sort out...
> > > 
> > > > If I'm ready to upload it to unstable, can I start this
> > > > transition?  Are there things you want me to do?
> > > 
> > > Please upload to experimental first and let us know when that's happened.
> > 
> > It's in experimental already.  The test suite only fails
> > on hurd, for some reason it's not finding the engine.  I still
> > need to look at that.
> > 
> > > We will also need bugs filed, with severity important for now.
> > 
> > Sure, I'll start on that if I find the time.
> > 
> > > Also it may be useful if you can get us the intersection between the 
> > > packages
> > > that failed to build and the key packages[1] (see "Final list of 3302 key 
> > > source
> > > packages" in that file).
> > 
> > That actually seem to be 3247 source package.  Anyway, the list is
> > below.
> 
> So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
> been working on the key packages, to get them to build with
> OpenSSL 1.1.0.  You can see that status of that at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org
> 
> Most of the packages are really trivial to fix, but some do
> require that you fix the same issues in many different places and
> it can take some time to fix it.
> 
> I would like to motivate more people to work on this by either
> marking those bugs as RC, or uploading it to unstable.

Ping.


Kurt

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-09-18 21:33:43 [+0200], Kurt Roeckx wrote:
> 
> So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
now a month and a few days now.

> been working on the key packages, to get them to build with
> OpenSSL 1.1.0.  You can see that status of that at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org

22 are tagged patch.

> Most of the packages are really trivial to fix, but some do
> require that you fix the same issues in many different places and
> it can take some time to fix it.

yup.

> I would like to motivate more people to work on this by either
> marking those bugs as RC, or uploading it to unstable.

besides the above status for the key packages there is also
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org

which covers all of them.

> Kurt

Sebastian

Bug#827061: transition: openssl

[Kurt Roeckx]

On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote:
> On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
> > On 11/06/16 20:59, Kurt Roeckx wrote:
> > > OpenSSL will soon release a new upstream version with a new
> > > soname.  This new version will break various packages, see:
> > > https://lists.debian.org/debian-devel/2016/06/msg00205.html
> > > 
> > > I'm currently not sure when the release will be ready.  I would
> > > like to start this transition as soon as possible, but probably
> > > after it's actually released.  I don't expect this to take long.
> > 
> > 405 packages failed to build during your test rebuild AFAICS. That's going 
> > to
> > take some time to sort out...
> > 
> > > If I'm ready to upload it to unstable, can I start this
> > > transition?  Are there things you want me to do?
> > 
> > Please upload to experimental first and let us know when that's happened.
> 
> It's in experimental already.  The test suite only fails
> on hurd, for some reason it's not finding the engine.  I still
> need to look at that.
> 
> > We will also need bugs filed, with severity important for now.
> 
> Sure, I'll start on that if I find the time.
> 
> > Also it may be useful if you can get us the intersection between the 
> > packages
> > that failed to build and the key packages[1] (see "Final list of 3302 key 
> > source
> > packages" in that file).
> 
> That actually seem to be 3247 source package.  Anyway, the list is
> below.

So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
been working on the key packages, to get them to build with
OpenSSL 1.1.0.  You can see that status of that at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org

Most of the packages are really trivial to fix, but some do
require that you fix the same issues in many different places and
it can take some time to fix it.

I would like to motivate more people to work on this by either
marking those bugs as RC, or uploading it to unstable.


Kurt

Bug#827061: transition: openssl

[Christoph Berg]

Re: Kurt Roeckx 2016-09-16 <20160916054549.2wjl4xzb2eyg6...@roeckx.be>
> > do you expect the transition to be done for stretch?
> 
> I really would like to have it in stretch.  I don't want to have
> the same situtation like we had with 1.0.2 that didn't make it it
> to jessie.

Nod, thanks for confirming.

> > I'm asking because the PostgreSQL people want to know if they need to
> > add support for OpenSSL 1.1 in the older release branches (9.2 ..
> > 9.4), or if patching 9.5 .. 10 is enough for now.
> 
> I guess they want to provide binaries for all their releases on
> apt.postgresql.org?

That's exactly the reason, yes. (And "they" is me ;)

Christoph


signature.asc
Description: PGP signature

Bug#827061: transition: openssl

[Kurt Roeckx]

On Thu, Sep 15, 2016 at 11:44:42PM +0200, Christoph Berg wrote:
> Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be>
> > > > If I'm ready to upload it to unstable, can I start this
> > > > transition?  Are there things you want me to do?
> > > 
> > > Please upload to experimental first and let us know when that's happened.
> > 
> > It's in experimental already.  The test suite only fails
> > on hurd, for some reason it's not finding the engine.  I still
> > need to look at that.
> 
> Hi,
> 
> do you expect the transition to be done for stretch?

I really would like to have it in stretch.  I don't want to have
the same situtation like we had with 1.0.2 that didn't make it it
to jessie.

> I'm asking because the PostgreSQL people want to know if they need to
> add support for OpenSSL 1.1 in the older release branches (9.2 ..
> 9.4), or if patching 9.5 .. 10 is enough for now.

I guess they want to provide binaries for all their releases on
apt.postgresql.org?  

> (Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems
> unlikely, but just to confirm?)

This is not my plan.


Kurt

Bug#827061: transition: openssl

[Christoph Berg]

Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be>
> > > If I'm ready to upload it to unstable, can I start this
> > > transition?  Are there things you want me to do?
> > 
> > Please upload to experimental first and let us know when that's happened.
> 
> It's in experimental already.  The test suite only fails
> on hurd, for some reason it's not finding the engine.  I still
> need to look at that.

Hi,

do you expect the transition to be done for stretch?

I'm asking because the PostgreSQL people want to know if they need to
add support for OpenSSL 1.1 in the older release branches (9.2 ..
9.4), or if patching 9.5 .. 10 is enough for now.

(Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems
unlikely, but just to confirm?)

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#827061: transition: openssl

[Kurt Roeckx]

On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
> On 11/06/16 20:59, Kurt Roeckx wrote:
> > OpenSSL will soon release a new upstream version with a new
> > soname.  This new version will break various packages, see:
> > https://lists.debian.org/debian-devel/2016/06/msg00205.html
> > 
> > I'm currently not sure when the release will be ready.  I would
> > like to start this transition as soon as possible, but probably
> > after it's actually released.  I don't expect this to take long.
> 
> 405 packages failed to build during your test rebuild AFAICS. That's going to
> take some time to sort out...
> 
> > If I'm ready to upload it to unstable, can I start this
> > transition?  Are there things you want me to do?
> 
> Please upload to experimental first and let us know when that's happened.

It's in experimental already.  The test suite only fails
on hurd, for some reason it's not finding the engine.  I still
need to look at that.

> We will also need bugs filed, with severity important for now.

Sure, I'll start on that if I find the time.

> Also it may be useful if you can get us the intersection between the packages
> that failed to build and the key packages[1] (see "Final list of 3302 key 
> source
> packages" in that file).

That actually seem to be 3247 source package.  Anyway, the list is
below.


Kurt


bind9
clamav
curl
cyrus-sasl2
freebsd-utils
freerdp
gsoap
gst-plugins-bad1.0
kde4libs
kdelibs4support
kopete
krb5
libcrypt-openssl-rsa-perl
libevent
libexosip2
libmicrohttpd
libmsn
libnet-ssleay-perl
libssh
links2
m2crypto
mariadb-client-lgpl
neon27
net-snmp
nghttp2
nginx
nmap
nodejs
ntp
openhpi
openipmi
opensc
openssh
openvpn
opusfile
php5
pkcs11-helper
postfix
postgresql-9.5
pulseaudio
pypy
python-cryptography
qca2
qt4-x11
qtbase-opensource-src
rdesktop
ruby2.3
sendmail
serf
socat
spamassassin
spdylay
spice
spice-gtk
stunnel4
tcpdump
transmission
unbound
uw-imap
vde2
virtualbox
virtuoso-opensource
wget
wpa
xmlsec1
xmms2

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

On 11/06/16 20:59, Kurt Roeckx wrote:
> OpenSSL will soon release a new upstream version with a new
> soname.  This new version will break various packages, see:
> https://lists.debian.org/debian-devel/2016/06/msg00205.html
> 
> I'm currently not sure when the release will be ready.  I would
> like to start this transition as soon as possible, but probably
> after it's actually released.  I don't expect this to take long.

405 packages failed to build during your test rebuild AFAICS. That's going to
take some time to sort out...

> If I'm ready to upload it to unstable, can I start this
> transition?  Are there things you want me to do?

Please upload to experimental first and let us know when that's happened.

We will also need bugs filed, with severity important for now.

Also it may be useful if you can get us the intersection between the packages
that failed to build and the key packages[1] (see "Final list of 3302 key source
packages" in that file).

Cheers,
Emilio

[1] https://udd.debian.org/cgi-bin/key_packages.cgi

Bug#827061: transition: openssl

[Kurt Roeckx]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

OpenSSL will soon release a new upstream version with a new
soname.  This new version will break various packages, see:
https://lists.debian.org/debian-devel/2016/06/msg00205.html

I'm currently not sure when the release will be ready.  I would
like to start this transition as soon as possible, but probably
after it's actually released.  I don't expect this to take long.

If I'm ready to upload it to unstable, can I start this
transition?  Are there things you want me to do?


Kurt