Discussion:
OpenSSL 1.1.0
Kurt Roeckx
2016-06-11 12:30:37 UTC
Permalink
Hi,

The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.

It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.

There is an upstream wiki page for this at:
https://wiki.openssl.org/index.php/1.1_API_Changes

If things aren't clear, you have questions, are there are missing
access functions please contact us.

I've uploaded packages to experimental, so you can use those to
test things.

We did a rebuild of all packages build-depending on libssl-dev.
You can see the result of that here:
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/


Here is a dd-list for packages that failed to build, not all of them
are related to changes in OpenSSL:

A. Jesse Jiryu Davis <***@mongodb.com>
libmongoc

Adam Conrad <***@0c3.net>
cyrus-sasl2 (U)

Adam Majer <***@zombino.com>
isc-kea
mosquitto-auth-plugin

Afif Elghraoui <***@debian.org>
gridengine (U)

Afif Elghraoui <***@ghraoui.name>
ori

Alan Baghumian <***@technotux.org>
balsa (U)

Alberto Garcia <***@igalia.com>
megatools

Alberto Gonzalez Iniesta <***@inittab.org>
linux-ftpd-ssl (U)
netkit-ftp-ssl (U)
netkit-telnet-ssl (U)
openvpn

Alessandro Ghedini <***@debian.org>
curl
isync (U)
libnet-ssleay-perl (U)

Alessio Di Mauro <***@yubico.com>
yubico-piv-tool (U)

Alessio Treglia <***@debian.org>
crtmpserver (U)

Alexander Reichle-Schmehl <***@debian.org>
httperf

Alexander Wirt <***@debian.org>
cgit
citadel (U)
icinga2 (U)
nsca-ng
webcit (U)

Alexander Zangerl <***@debian.org>
nmh

Amul Shah <***@fisglobal.com>
fis-gtm (U)

Anders Waananen <***@nbi.dk>
canl-c++ (U)
nordugrid-arc (U)

Andreas Cadhalpun <***@googlemail.com>
clamav (U)

Andreas Henriksson <***@fatal.se>
balsa (U)
xchat-gnome (U)

Andreas Tille <***@debian.org>
alpine (U)
dcmtk (U)
fis-gtm (U)
gdcm (U)
ginkgocadx (U)
iva (U)
r-bioc-rtracklayer (U)
r-cran-openssl (U)
xrdp (U)

Andres Mejia <***@debian.org>
crtmpserver (U)

Andrew Ayer <***@andrewayer.name>
git-crypt

Andrew Pollock <***@debian.org>
grpc (U)

Andrew Shadura <***@debian.org>
libdigidoc

Andrew Starr-Bochicchio <***@debian.org>
libtorrent-rasterbar (U)

Andriy Beregovenko <***@jet.kiev.ua>
crtmpserver (U)

Android tools Maintainer <android-tools-***@lists.alioth.debian.org>
android-platform-system-core
android-tools

Android Tools Maintainers <android-tools-***@lists.alioth.debian.org>
android-tools

Angus Lees <***@debian.org>
cargo (U)

Anibal Monsalve Salazar <***@debian.org>
libevent
pidentd

Ansgar Burchardt <***@debian.org>
libcrypt-openssl-x509-perl (U)
simutrans (U)

Anthony Fok <***@debian.org>
golang-github-yosssi-ace (U)

Anthony Prades <***@chezouam.net>
cyrus-imapd (U)
cyrus-imapd-2.4 (U)

Antoine Beaupré <***@debian.org>
atheme-services
atheme-services (U)

Antonio Radici <***@debian.org>
cfengine2
cfengine3

Antonio Terceiro <***@debian.org>
ruby2.3
vboot-utils

Antti Järvinen <***@katiska.org>
classified-ads

Apollon Oikonomopoulos <***@debian.org>
dovecot (U)
haproxy (U)
mongodb (U)

Arnaud Cornet <***@debian.org>
bip (U)
haproxy

Arno Töll <***@debian.org>
apache2 (U)
lighttpd (U)
trafficserver

Aron Xu <***@debian.org>
libofetion (U)
pidgin-openfetion (U)
spdylay (U)
trafficserver (U)

Asheesh Laroia <***@asheesh.org>
alpine

Asias He <***@gmail.com>
libofetion (U)

Athena Capital Research <acr-***@athenacr.com>
pion

Aurelien Jarno <***@debian.org>
freebsd-utils (U)

Axel Beckert <***@debian.org>
links2
links2 (U)
xymon (U)

Balint Reczey <***@balintreczey.hu>
kodi (U)
pulseaudio (U)

Barak A. Pearlmutter <***@debian.org>
ettercap
fossil

Bartosz Fenski <***@debian.org>
skipfish

Bas Couwenberg <***@debian.org>
postgis (U)

Bas Couwenberg <***@xs4all.nl>
postgis (U)

Bastiaan Franciscus van den Dikkenberg <***@dikkenberg.net>
burp

Bastian Kleineidam <***@debian.org>
libpam-mount

Bdale Garbee <***@gag.com>
bind9 (U)
ntp (U)

Ben Pfaff <***@debian.org>
openvswitch (U)

Benjamin Barenblat <***@mit.edu>
urweb

Benjamin Drung <***@debian.org>
xmms2

Benjamin Kaduk <***@mit.edu>
krb5 (U)

Benoît Knecht <***@fsfe.org>
libtorrent (U)

Bernd Zeimetz <***@debian.org>
open-vm-tools
pgbouncer (U)

Bertrand Marc <***@gmail.com>
libmicrohttpd

Boris Pek <tehnick-***@mail.ru>
uhub

Boris Pek <***@debian.org>
eiskaltdcpp

Brett Parker <***@sommitrealweird.co.uk>
pound

Brian Lin <***@cs.wisc.edu>
condor (U)

Brian May <***@debian.org>
librabbitmq (U)

Bryan Sutula <***@hp.com>
openhpi

Bryan Sutula <***@hpe.com>
openhpi

Caitlin Matos <***@zoho.com>
attic

Carsten Leonhardt <***@debian.org>
bacula (U)

CAS packaging team <pkg-cas-***@lists.alioth.debian.org>
libapache2-mod-auth-cas

Casper Gielen <casper-***@gielen.name>
validns

Charles Plessy <***@debian.org>
m2crypto (U)

Chris Leishman <***@leishman.org>
libneo4j-client

Chris Taylor <***@debian.org>
socat

Christian Hofstaedtler <***@debian.org>
ike
ipsec-tools (U)
pdns (U)
pdns-recursor (U)
ruby2.3 (U)

Christian M. Amsüss <***@fsfe.org>
pam-ssh-agent-auth

Christoph Berg <***@debian.org>
dacs
pgadmin3 (U)
pgbouncer (U)
pgpool2 (U)
postgresql-9.5 (U)
xymon

Christoph Egger <***@debian.org>
freebsd-utils (U)

Christoph Martin <***@uni-mainz.de>
netkit-telnet-ssl (U)

Christophe Monniez <***@fccu.be>
afflib (U)

Christopher Hoskin <***@gmail.com>
libcrypt-openssl-pkcs10-perl (U)
libcrypt-openssl-pkcs12-perl (U)

Christos Trochalakis <***@ideopolis.gr>
nginx (U)

ClamAV Team <pkg-clamav-***@lists.alioth.debian.org>
clamav
libclamunrar

Cleto Martín <***@debian.org>
zeroc-ice (U)

Clint Adams <***@debian.org>
mod-authn-webid
simutrans (U)

Clint Adams <***@gnu.org>
simutrans (U)

Colin Tuckley <***@debian.org>
mixmaster
trustedqsl (U)

Colin Watson <***@debian.org>
openssh (U)

Condor Developers <condor-***@cs.wisc.edu>
condor

Cristian Greco <***@debian.org>
libtorrent-rasterbar
poco
poco (U)

Cyril Lavier <***@davromaniak.eu>
nginx (U)

Dain Nilsson <***@yubico.com>
yubico-piv-tool (U)

Damien Raude-Morvan <***@debian.org>
opennebula (U)
tomcat-native (U)

Damyan Ivanov <***@debian.org>
libcrypt-openssl-dsa-perl (U)
libcrypt-openssl-rsa-perl (U)
libcrypt-openssl-x509-perl (U)
libnet-ssleay-perl (U)

Daniel Echeverry <***@gmail.com>
hydra (U)
ophcrack

Daniel Kahn Gillmor <***@fifthhorseman.net>
getdns (U)
tcpcrypt

Daniel Pocock <***@pocock.com.au>
asterisk (U)
sipxtapi (U)
turnserver (U)

Daniel Pocock <***@pocock.pro>
coturn (U)
qpid-proton (U)
reconserver (U)
resiprocate (U)

Daniel Schepler <***@debian.org>
mariadb-client-lgpl (U)

Daniel Stender <***@debian.org>
m2crypto

Daniel Walrond <***@djw.org.uk>
opensmtpd (U)

Danny Edel <***@danny-edel.de>
borgbackup

Darryl L. Pierce <***@redhat.com>
qpid-proton (U)

Dave Beckett <***@debian.org>
nghttp2

Dave Love <***@liverpool.ac.uk>
gridengine (U)

David Bremner <***@debian.org>
racket

David Martínez Moreno <***@debian.org>
hhvm (U)

David Paleino <***@debian.org>
gambas3 (U)

Debian ACE+TAO maintainers <pkg-ace-***@lists.alioth.debian.org>
ace

Debian Apache Maintainers <debian-***@lists.debian.org>
apache2
apr-util

Debian Authentication Maintainers <pkg-auth-***@lists.alioth.debian.org>
yubico-piv-tool

Debian Bacula Team <pkg-bacula-***@lists.alioth.debian.org>
bacula

Debian Bitcoin Packaging Team <pkg-bitcoin-***@lists.alioth.debian.org>
bitcoin
litecoin

Debian Bitcoin Team <pkg-bitcoin-***@lists.alioth.debian.org>
libsecp256k1

Debian BOINC Maintainers <pkg-boinc-***@lists.alioth.debian.org>
boinc

Debian Chinese Team <chinese-***@lists.alioth.debian.org>
fqterm
libofetion
pidgin-openfetion

Debian Citadel Team <pkg-citadel-***@lists.alioth.debian.org>
citadel
webcit

Debian CORBA Team <pkg-corba-***@lists.alioth.debian.org>
omniorb-dfsg

Debian Cyrus SASL Team <pkg-cyrus-sasl2-debian-***@lists.alioth.debian.org>
cyrus-sasl2

Debian Cyrus Team <pkg-cyrus-imapd-debian-***@lists.alioth.debian.org>
cyrus-imapd
cyrus-imapd-2.4

Debian DNS Packaging <pkg-dns-***@lists.alioth.debian.org>
dnsval
getdns
ldns
nsd
opendnssec
unbound

Debian Edu Packaging Team <debian-edu-pkg-***@lists.alioth.debian.org>
italc

Debian Erlang Packagers <pkg-erlang-***@lists.alioth.debian.org>
erlang

Debian Forensics <forensics-***@lists.alioth.debian.org>
afflib
yara

Debian FreeIPA Team <pkg-freeipa-***@lists.alioth.debian.org>
certmonger
freeipa

Debian Games Team <pkg-games-***@lists.alioth.debian.org>
simutrans

Debian GIS Project <pkg-grass-***@lists.alioth.debian.org>
postgis

Debian GNOME Maintainers <pkg-gnome-***@lists.alioth.debian.org>
balsa
xchat-gnome

Debian Go Packaging Team <pkg-go-***@lists.alioth.debian.org>
golang-github-hashicorp-serf
golang-github-yosssi-ace

Debian Grid Engine Maintainers <pkg-gridengine-***@lists.alioth.debian.org>
gridengine

Debian Hamradio Maintainers <debian-***@lists.debian.org>
trustedqsl

Debian HAProxy Maintainers <pkg-haproxy-***@lists.alioth.debian.org>
haproxy

Debian Haskell Group <pkg-haskell-***@lists.alioth.debian.org>
haskell-blogliterately
haskell-hsopenssl

Debian HHVM packaging team <pkg-hhvm-***@lists.alioth.debian.org>
hhvm

Debian Java Maintainers <pkg-java-***@lists.alioth.debian.org>
netty-tcnative
tomcat-native

Debian Javascript Maintainers <pkg-javascript-***@lists.alioth.debian.org>
nodejs

Debian KDE Extras Team <pkg-kde-***@lists.alioth.debian.org>
kvirc

Debian Krap Maintainers <debian-qt-***@lists.debian.org>
virtuoso-opensource

Debian lighttpd maintainers <pkg-lighttpd-***@lists.alioth.debian.org>
lighttpd

Debian Med Packaging Team <debian-med-***@lists.alioth.debian.org>
dcmtk
fis-gtm
gdcm
ginkgocadx
iva
r-bioc-rtracklayer
r-cran-openssl

Debian Middleware Maintainers <pkg-middleware-***@lists.alioth.debian.org>
qpid-proton

Debian Multimedia Maintainers <pkg-multimedia-***@lists.alioth.debian.org>
crtmpserver
kodi

Debian MySQL Maintainers <pkg-mysql-***@lists.alioth.debian.org>
galera-3
mariadb-client-lgpl

Debian Nagios Maintainer Group <pkg-nagios-***@lists.alioth.debian.org>
icinga2

Debian NTP Team <pkg-ntp-***@lists.alioth.debian.org>
ntp

Debian OCaml Maintainers <debian-ocaml-***@lists.debian.org>
ocaml-ssl
ocsigenserver

Debian OpenNebula Maintainers <pkg-opennebula-***@lists.alioth.debian.org>
opennebula

Debian OpenSC Maintainers <pkg-opensc-***@lists.alioth.debian.org>
engine-pkcs11
libp11
opensc
pkcs11-helper

Debian OpenSSH Maintainers <debian-***@lists.debian.org>
openssh

Debian Perl Group <pkg-perl-***@lists.alioth.debian.org>
libcrypt-openssl-dsa-perl
libcrypt-openssl-pkcs10-perl
libcrypt-openssl-pkcs12-perl
libcrypt-openssl-rsa-perl
libcrypt-openssl-x509-perl
libcrypt-smime-perl
libnet-ssleay-perl
libpoe-filter-ssl-perl

Debian PHP Maintainers <pkg-php-***@lists.alioth.debian.org>
php5
php7.0

Debian PHP PECL Maintainers <pkg-php-***@lists.alioth.debian.org>
php-mongodb

Debian PostgreSQL Maintainers <pkg-postgresql-***@lists.alioth.debian.org>
pgadmin3
pgbouncer
pgpool2
postgresql-9.5

Debian PowerDNS Maintainers <pkg-pdns-***@lists.alioth.debian.org>
pdns
pdns-recursor

Debian Privacy Tools Maintainers <pkg-privacy-***@lists.alioth.debian.org>
ricochet-im

Debian QA Group <***@qa.debian.org>
anon-proxy
boxbackup
ekg
ekg2
httperf
mod-authn-webid
opencryptoki
partimage
samdump2
sendmail
trousers
turnserver
virtuoso-opensource
wvstreams

Debian Qt/KDE Maintainers <debian-qt-***@lists.debian.org>
kde4libs
kopete
qca2
qt4-x11
qtbase-opensource-src

Debian Science Maintainers <debian-science-***@lists.alioth.debian.org>
root-system

Debian Shib Team <pkg-shibboleth-***@lists.alioth.debian.org>
xml-security-c
xmltooling

Debian Virtualbox Team <pkg-virtualbox-***@lists.alioth.debian.org>
virtualbox

Debian VoIP Team <pkg-voip-***@lists.alioth.debian.org>
asterisk
coturn
kamailio
libexosip2
libre
libzrtpcpp
pjproject
ptlib
reconserver
resiprocate
sipxtapi
stunserver
turnserver
yate

Debian VSquare Team <pkg-vsquare-***@lists.alioth.debian.org>
vde2

Debian wpasupplicant Maintainers <pkg-wpa-***@lists.alioth.debian.org>
wpa

Debian XMPP Maintainers <pkg-xmpp-***@lists.alioth.debian.org>
jabberd2

Debian/Kubuntu Qt/KDE Maintainers <debian-qt-***@lists.debian.org>
kde4libs
kdelibs4support
kopete

Debian/Ubuntu wpasupplicant Maintainers <pkg-wpa-***@lists.alioth.debian.org>
wpa

Denis Briand <***@denis-briand.fr>
pgadmin3 (U)

Dennis van Dok <***@nikhef.nl>
lcas-lcmaps-gt4-interface
lcmaps
lcmaps-plugins-verify-proxy
lcmaps-plugins-voms

Di-Shi Sun <di-***@transnexus.com>
osptoolkit (U)

Diane Trout <***@debian.org>
kde4libs (U)

Diane Trout <***@ghic.org>
dnssec-trigger (U)

Dima Barsky <***@debian.org>
m2crypto

Dima Kogan <***@secretsauce.net>
tcpflow

Dimitri John Ledkov <***@ubuntu.com>
libica

Dmitry Bogatov <***@gnu.org>
haskell-blogliterately (U)

Dmitry E. Oboukhov <***@debian.org>
libtorrent (U)
nginx (U)

Dmitry Shachnev <***@debian.org>
qtbase-opensource-src (U)
xchat-gnome (U)

Dmitry Smirnov <***@debian.org>
gfarm
ginkgocadx (U)
litecoin (U)

Dominic Hargreaves <***@earth.li>
libcrypt-openssl-dsa-perl (U)

Dominik George <***@naturalnet.de>
xrdp

Dovecot Maintainers <jaldhar-***@debian.org>
dovecot

Eduard Bloch <***@debian.org>
encfs

Elías Alejandro Año Mendoza <***@gmail.com>
uget

Emanuele Rocca <***@debian.org>
spdylay

Emilio Pozuelo Monfort <***@debian.org>
xchat-gnome (U)

Emmanuel Bourg <***@apache.org>
netty-tcnative (U)

Enrico Tassi <***@debian.org>
lua-sec

Eric Dorland <***@debian.org>
engine-pkcs11
engine-pkcs11 (U)
libp11
libp11 (U)
opensc
opensc (U)
pam-p11
pkcs11-helper
pkcs11-helper (U)

Eshat Cakar <***@eshat.de>
kde4libs (U)
kopete (U)

Eugen Dedu <***@pu-pm.univ-fcomte.fr>
ptlib (U)

Eva Ramon Salinas <***@empanadilla.net>
httest

Fabian Fagerholm <***@debian.org>
cyrus-sasl2 (U)

Fabien Boucher <***@gmail.com>
libxr

Fabio Tranchitella <***@debian.org>
dovecot (U)
nginx (U)

Fabrizio Regalli <***@fabreg.it>
gnupg-pkcs11-scd

Faidon Liambotis <***@debian.org>
asterisk (U)
hhvm (U)
radsecproxy
yate (U)

Fathi Boudra <***@debian.org>
kde4libs (U)
kopete (U)
qt4-x11 (U)
qtbase-opensource-src (U)

Felipe Sateler <***@debian.org>
pulseaudio (U)

Felix Geyer <debfx-***@fobos.de>
virtualbox (U)

Felix Geyer <***@debian.org>
qca2 (U)

Ferenc Wagner <***@niif.hu>
xmltooling (U)

Ferenc Wágner <***@niif.hu>
xml-security-c (U)
xmltooling (U)

Fetchmail Maintainers <pkg-fetchmail-***@lists.alioth.debian.org>
fetchmail

Filippo Giunchedi <***@debian.org>
vde2 (U)

Florian Schlichting <***@zedat.fu-berlin.de>
libcrypt-smime-perl (U)

Florian Schlichting <***@debian.org>
libcrypt-smime-perl (U)

Floris Bruynooghe <***@devork.be>
omniorb-dfsg (U)

Francesco Paolo Lovergine <***@debian.org>
aolserver4-nsopenssl
imapfilter
postgis (U)
proftpd-dfsg
proftpd-dfsg (U)

Francisco Moya <***@debian.org>
zeroc-ice

Franck Joncourt <***@debian.org>
libnet-ssleay-perl (U)

Frank B. Brokken <***@rug.nl>
bobcat

Gambas Debian Maintainers <pkg-gambas-***@lists.alioth.debian.org>
gambas3

Gennaro Oliva <***@na.icar.cnr.it>
slurm-llnl

George Danchev <***@spnet.net>
bobcat (U)

George Kiagiadakis <***@gmail.com>
kde4libs (U)
kopete (U)

Georges Khaznadar <***@debian.org>
qupzilla

Gergely Nagy <***@madhouse-project.org>
syslog-ng (U)

Gergely Pilisi <***@gmail.com>
eclipse-titan

Gert Wollny <***@gmail.com>
dcmtk (U)
gdcm (U)
ginkgocadx (U)

Gianfranco Costamagna <***@yahoo.it>
boinc (U)
ettercap (U)
websocketpp

Gianfranco Costamagna <***@debian.org>
boinc (U)
borgbackup (U)
casablanca
virtualbox (U)
websocketpp

Gilles Filippini <***@debian.org>
navit

GNU/kFreeBSD Maintainers <debian-***@lists.debian.org>
freebsd-utils

Goswin von Brederlow <goswin-v-***@web.de>
ifstat

gregor herrmann <***@debian.org>
libcrypt-openssl-x509-perl (U)
libnet-ssleay-perl (U)

Groonga Project <***@groonga.org>
groonga

gRPC Package Maintainers <grpc-***@google.com>
grpc

Guido Trotter <***@debian.org>
vde2 (U)

Guo Yixuan <***@gmail.com>
boinc (U)

Guus Sliepen <***@debian.org>
tinc

Gürkan Sengün <***@phys.ethz.ch>
links2
pen (U)

Hamish Moffatt <***@debian.org>
trustedqsl (U)

Hans Zandbelt <***@pingidentity.com>
libapache2-mod-auth-openidc

Hans-Christoph Steiner <***@eds.org>
android-platform-system-core (U)
android-tools (U)
sqlcipher

HAYASHI Kentaro <***@clear-code.com>
groonga (U)

Hector Garcia <***@debian.org>
fetchmail (U)

Henrique de Moraes Holschuh <***@debian.org>
cyrus-imapd (U)
cyrus-imapd-2.4 (U)

Hideki Yamane <***@debian.org>
net-snmp (U)

Hilko Bengen <***@debian.org>
bro
nmap
sslsplit
yara (U)

Holger Levsen <***@debian.org>
tlsdate (U)

HTCondor Developers <condor-***@cs.wisc.edu>
condor

Ian Beckwith <***@debian.org>
ckermit
linux-ftpd-ssl
netkit-ftp-ssl
netkit-telnet-ssl

Ian Haywood <***@haywood.id.au>
gambas3 (U)

Ian Jackson <***@chiark.greenend.org.uk>
curl (U)

Ivo De Decker <***@debian.org>
libapache2-mod-auth-pubtkt

Jacob Appelbaum <***@appelbaum.net>
tlsdate

Jaime Melis <***@fdi.ucm.es>
opennebula (U)

Jaime Robles <***@debian.org>
trustedqsl (U)

Jaldhar H. Vyas <***@debian.org>
dovecot (U)

James Marsh <***@jamesmarsh.net>
utopia-documents (U)

James McCoy <***@debian.org>
racket (U)
serf (U)

Jan Dittberner <***@debian.org>
wpa (U)

Jan Hauke Rahm <***@debian.org>
bacula (U)

Jan Niehusmann <***@debian.org>
qca2 (U)

Jan Wagner <***@cyconet.org>
icinga2 (U)

Janos Guljas <***@debian.org>
uwsgi
uwsgi (U)

Jean Baptiste Favre <***@jbfavre.org>
trafficserver (U)

Jelmer Vernooij <***@debian.org>
dovecot (U)

Jeremy Lainé <***@m4x.org>
asterisk (U)
pjproject (U)

Jerome Benoit <***@rezozer.net>
libpam-ssh

Jerry Stueve <***@arrl.net>
trustedqsl (U)

Jesse Rhodes <***@drubo.net>
hexchat

Joachim Breitner <***@debian.org>
haskell-hsopenssl (U)

Joao Eriberto Mota Filho <***@debian.org>
afflib (U)
yara (U)

Jochen Friedrich <***@scram.de>
isakmpd
net-snmp (U)

Joel Johnson <***@lixil.net>
dovecot (U)

John Goerzen <***@complete.org>
bacula

John V. Belmonte <***@debian.org>
xmlsec1

Jonas Smedegaard <***@jones.dk>
asterisk (U)
bitcoin (U)
kannel-sqlbox
libsecp256k1 (U)
nodejs (U)
pinot
pjproject (U)
uwsgi (U)

Jonathan McDowell <***@earth.li>
libtorrent (U)

Jonathan Yu <***@cpan.org>
libcrypt-openssl-rsa-perl (U)

Joost van Baal-Ilic <***@debian.org>
validns (U)

Jorge Soares <***@gmail.com>
iva (U)

Jose Carlos Garcia Sogo <***@debian.org>
yate (U)

Jose Luis Rivas <***@debian.org>
libtorrent

Jose Luis Tallon <***@adv-solutions.net>
up-imapproxy

Jose M Calhariz <***@netvisao.pt>
amanda

Jose M Calhariz <***@calhariz.com>
amanda

Jose Parrella <***@debian.org>
nginx
nginx (U)

Josip Rodin <joy-***@debian.org>
freeradius

Josselin Mouette <***@debian.org>
balsa (U)
xchat-gnome (U)

Josue Abarca <***@debian.org>
siege

José L. Redrejo Rodríguez <***@debian.org>
gambas3 (U)

José Manuel Santamaría Lema <***@gmail.com>
kde4libs (U)

Juergen Salk <***@debian.org>
dcmtk (U)

Julien Kauffmann <***@freelan.org>
freelan (U)

Julián Moreno Patiño <***@debian.org>
hydra
ophcrack (U)

Jérémy Lal <***@melix.org>
mongodb (U)
nodejs (U)

Jörg Frings-Fürst <***@jff-webhosting.net>
ipmitool
ipmiutil
simutrans (U)

Jörgen Hägg <***@debian.org>
conserver

Kai Wasserbäch <***@debian.org>
kvirc (U)

Kai-Chung Yan <***@gmail.com>
android-platform-system-core (U)

Kamal Mostafa <***@whence.com>
trustedqsl (U)

Kari Pahula <***@debian.org>
tntnet

Kartik Mistry <***@debian.org>
ayttm
nginx
nginx (U)

Kees Cook <***@debian.org>
duo-unix

Keith Winstein <***@mit.edu>
mahimahi

Kel Modderman <***@otaku42.de>
wpa (U)

Keng-Yu Lin <***@lexical.tw>
dogecoin

Kentaro Hayashi <***@clear-code.com>
groonga (U)

Kevin Smith <***@kismith.co.uk>
swift-im (U)

Khalid Aziz <***@debian.org>
openhpi (U)

Kilian Krause <***@debian.org>
asterisk (U)
libexosip2 (U)
libzrtpcpp (U)
ptlib (U)
stunserver (U)
yate (U)

Klas Lindfors <***@yubico.com>
yubico-piv-tool (U)

Krzysztof Burghardt <***@burghardt.pl>
poco

Krzysztof Krzyzaniak (eloy) <***@debian.org>
lighttpd (U)

Kurt Roeckx <***@roeckx.be>
epic5
ntp (U)

LaMont Jones <***@debian.org>
bind9
postfix

Laszlo Boszormenyi (GCS) <***@debian.hu>
freerdp (U)
syslog-ng (U)

Laszlo Boszormenyi (GCS) <***@debian.org>
android-tools (U)
fetchmail
grpc (U)
libwebsockets (U)
mongodb
neon27
ori (U)
qpid-cpp
rdesktop
socat
stunnel4 (U)
sx
syslog-ng (U)

Laszlo Kajan <***@debian.org>
gridengine (U)

Laurent Bigonville <***@debian.org>
balsa (U)
libssh

Lennart Weller <***@ring0.de>
s3backer

Leo Costela <***@debian.org>
libevent (U)
transmission
transmission (U)

LI Daobing <***@debian.org>
fqterm (U)
qterm

Liang Guo <***@debian.org>
spice
spice-gtk

Lifeng Sun <***@gmail.com>
root-system (U)

Lior Kaplan <***@debian.org>
php5 (U)
php7.0 (U)

Lisandro Damián Nicanor Pérez Meyer <***@debian.org>
kde4libs (U)
qt4-x11 (U)
qtbase-opensource-src (U)
virtuoso-opensource (U)

Loic Minier <***@dooz.org>
balsa (U)

Louis Zuckerman <***@louiszuckerman.com>
glusterfs (U)

Loïc Minier <***@debian.org>
android-tools (U)

Luca Bigliardi <***@artha.org>
vde2 (U)

Luca Bruno <***@debian.org>
cargo (U)

Luca Capello <***@pca.it>
bacula (U)

Lucas Kanashiro <***@gmail.com>
libpoe-filter-ssl-perl (U)

Luciano Bello <***@debian.org>
medusa

Ludovic Rousseau <***@debian.org>
pam-pkcs11

Ludovico Gardenghi <***@debian.org>
vde2 (U)

Luis Ibanez <***@kitware.com>
fis-gtm (U)

Luis Rodrigo Gallardo Cruz <***@debian.org>
stunnel4

Luk Claes <***@debian.org>
curl (U)
ipmitool (U)

Luke Faraone <***@debian.org>
alpine (U)

Magnus Holmgren <***@debian.org>
libdkim
prayer
ssvnc
uw-imap

Maia Kozheva <***@ubuntu.com>
libdc0

Maintainers of GStreamer packages <pkg-gstreamer-***@lists.alioth.debian.org>
gst-plugins-bad1.0

Marc Dequènes (Duck) <***@DuckCorp.org>
bip (U)

Marc Haber <mh+debian-***@zugschlus.de>
pdns (U)
pdns-recursor (U)

Marc Singer <***@debian.org>
shellinabox

Marco d'Itri <***@linux.it>
inn2

Marco Nenciarini <***@debian.org>
dovecot (U)
pgpool2 (U)

Marek Brudka <***@aster.pl>
ace (U)

Mark Hymers <***@debian.org>
freeradius (U)
gridengine (U)

Mark Purcell <***@debian.org>
asterisk (U)
kvirc (U)
libexosip2 (U)
libzrtpcpp (U)
ptlib (U)
yate (U)

Mark W. Eichin <***@thok.org>
owl

Markus Frosch <***@debian.org>
icinga2 (U)

Markus Schade <***@gmail.com>
yadifa

Markus Wanner <***@bluegap.ch>
asio
postgis (U)

Martin Pitt <***@debian.org>
postgresql-9.5 (U)

Martin Zobel-Helas <***@debian.org>
dacs (U)

Marvin Stark <***@der-marv.de>
sslscan

Mathieu Malaterre <***@debian.org>
dcmtk (U)
gdcm (U)

Mats Erik Andersson <***@gisladisker.se>
linux-ftpd-ssl
netkit-ftp-ssl
netkit-telnet-ssl

Matt Grant <***@mattgrant.net.nz>
ipsec-tools (U)

Matthew Grant <***@gmail.com>
ipsec-tools

Matthew Johnson <***@debian.org>
ipmitool

Matthew Vernon <***@debian.org>
openssh (U)

Matthijs Mohlmann <***@cacholong.nl>
pdns

Matthijs Möhlmann <***@cacholong.nl>
pdns (U)
pdns-recursor (U)

Mattia Monga <***@debian.org>
tkrat

Mattia Rizzolo <***@debian.org>
libpodofo

Mattias Ellert <***@fysast.uu.se>
arc-gui-clients
canl-c
canl-c++
cgsi-gsoap
davix
dcap
globus-ftp-client
globus-gass-copy
globus-gram-job-manager
globus-gsi-callback
globus-gsi-cert-utils
globus-gsi-credential
globus-gsi-openssl-error
globus-gsi-proxy-core
globus-gsi-proxy-ssl
globus-gsi-sysconfig
globus-gssapi-gsi
globus-openssl-module
globus-proxy-utils
gridsite
gsoap
lcgdm
myproxy
nordugrid-arc
voms

Maxime Chatelle <***@rxsoft.eu>
poco (U)

Maximiliano Curia <***@debian.org>
kde4libs (U)
kdelibs4support (U)
kopete (U)
qca2 (U)
virtuoso-opensource (U)

Mehdi Dogguy <***@debian.org>
slurm-llnl (U)

Micah Anderson <***@debian.org>
atheme-services (U)
bitcoin (U)
libcrypt-openssl-x509-perl (U)

Michael Banck <***@debian.org>
gridengine (U)

Michael Biebl <***@debian.org>
balsa (U)

Michael Fladischer <***@debian.org>
librabbitmq

Michael Fladischer <***@fladi.at>
librabbitmq

Michael Gilbert <***@debian.org>
bind9 (U)
lighttpd (U)

Michael Hanke <***@debian.org>
condor (U)

Michael Lustfield <***@lustfield.net>
nginx (U)

Michael Meskes <***@debian.org>
citadel (U)
clamav (U)
virtualbox (U)
webcit (U)

Michael Stapelberg <***@debian.org>
simple-tpm-pk11
unworkable

Michael Tautschnig <***@debian.org>
clamav (U)
libclamunrar (U)

Michael Tokarev <***@tls.msk.ru>
spice (U)

Michele Baldessari <***@pupazzo.org>
libapache2-mod-auth-cas (U)

Mikael Magnusson <***@users.sourceforge.net>
libzrtpcpp (U)
yate (U)

Mike Gabriel <***@debian.org>
freerdp
italc (U)
libssh (U)
libzypp
xrdp (U)

Mike Markley <***@markley.org>
opendkim
opendkim (U)

Mike Mestnik <cheako+***@mikemestnik.net>
atheme-services

Mischa Salle <***@nikhef.nl>
lcas-lcmaps-gt4-interface (U)
lcmaps (U)
lcmaps-plugins-verify-proxy (U)
lcmaps-plugins-voms (U)

Modestas Vainius <***@debian.org>
kde4libs (U)
kopete (U)
qca2 (U)
qt4-x11 (U)
qtbase-opensource-src (U)

Muammar El Khatib <***@debian.org>
tcltls

Murat Demirten <***@debian.org>
ettercap (U)

Net-SNMP Packaging Team <pkg-net-snmp-***@lists.alioth.debian.org>
net-snmp

Neutron Soutmun <***@gmail.com>
slowhttptest

Nick Andrik <***@gmail.com>
kismet

Nick Rusnov <***@debian.org>
nmh (U)

Nico Golde <***@debian.org>
fetchmail (U)

Nicolas Boullis <***@debian.org>
isync

Nicolas Dandrimont <***@crans.org>
ocsigenserver (U)

NIIBE Yutaka <***@fsij.org>
libopkele

Niko Tyni <***@debian.org>
libcrypt-openssl-x509-perl (U)

Noah Meyerhans <***@debian.org>
ipsec-tools (U)
net-snmp (U)
spamassassin

Noèl Köthe <***@debian.org>
openipmi

Noël Köthe <***@debian.org>
openipmi
wget

Olaf van der Spek <***@gmail.com>
lighttpd (U)

Oleg Moskalenko <***@gmail.com>
coturn (U)

Oleksandr Moskalenko <***@debian.org>
libpodofo

Ondrej Surý <***@debian.org>
botan1.10
courier (U)
cyrus-imapd (U)
cyrus-imapd-2.4 (U)
cyrus-sasl2 (U)
datovka
dnssec-trigger
dnsval
dnsval (U)
getdns (U)
ldns
ldns (U)
libisds
nsd
nsd (U)
opendnssec
opendnssec (U)
php-mongodb (U)
php5 (U)
php7.0 (U)
softhsm2
zeroc-ice (U)

Open vSwitch developers <***@openvswitch.org>
openvswitch

Otavio Salvador <***@debian.org>
freerdp (U)

Otto Kekäläinen <***@debian.org>
galera-3 (U)

ownCloud for Debian maintainers <pkg-owncloud-***@lists.alioth.debian.org>
owncloud-client

Patrick Gansterer <***@paroga.com>
poco (U)

Patrick Matthäi <***@debian.org>
glusterfs
znc

Patrick Ouellette <***@debian.org>
trustedqsl (U)

Patrick Winnertz <***@debian.org>
italc (U)

Pau Garcia i Quiles <***@elpauer.org>
ace (U)
libmsn
witty

Paul Martin <***@debian.org>
milter-greylist

Peter Eisentraut <***@debian.org>
ntp (U)
pgbouncer (U)
postgresql-9.5 (U)

Peter Palfrader <***@debian.org>
tor

Peter Pentchev <***@ringlet.net>
libwebsockets
stunnel4

Peter Samuelson <***@p12n.org>
apache2 (U)
apr-util (U)
serf

Philipp Huebner <***@debian.org>
erlang-p1-tls

Pierre Chifflier <***@debian.org>
sbsigntool
sslsniff
tpm-tools
trousers

Pierre Habouzit <***@debian.org>
lighttpd (U)

Pierre-Louis Bonicoli <pierre-***@gmx.fr>
bip

Pino Toscano <***@debian.org>
qt4-x11 (U)
qtbase-opensource-src (U)

pkg-ipsec-tools team <pkg-ipsec-tools-***@lists.alioth.debian.org>
ipsec-tools

Prach Pongpanich <***@debian.org>
haproxy (U)

Prach Pongpanich <***@gmail.com>
haproxy (U)

ProFTPD Maintainance Team <pkg-proftpd-***@lists.alioth.debian.org>
proftpd-dfsg

Pulseaudio maintenance team <pkg-pulseaudio-***@lists.alioth.debian.org>
pulseaudio

Ramakrishnan Muthukrishnan <***@debian.org>
curl
libre (U)

Raphael Geissert <***@debian.org>
php5 (U)

Razvan Crainea <***@opensips.org>
opensips

Raúl Benencia <***@kalgan.cc>
bro (U)

Raúl Sánchez Siles <***@gmail.com>
kvirc (U)

Reinhard Tartler <***@tauware.de>
boxbackup

Remko Tronçon <***@el-tramo.be>
swift-im (U)

Rene Mayorga <***@debian.org.sv>
libexosip2 (U)

Rene Mayrhofer <***@debian.org>
strongswan
strongswan (U)

Ritesh Raj Sarraf <***@debian.org>
virtualbox (U)

Robert Edmonds <***@debian.org>
unbound (U)
wrk

Robert Millan <***@debian.org>
freebsd-utils (U)

Robert S. Edmonds <***@debian.org>
unbound

Roberto C. Sanchez <***@connexer.com>
cyrus-sasl2 (U)
pion (U)

Robie Basak <***@canonical.com>
bind9 (U)

Roger A. Light <***@atchoo.org>
mosquitto

Rogério Brito <***@ime.usp.br>
libtorrent (U)

Roland Stigge <***@antcom.de>
gnubiff
vtun

Rolf Leggewie <***@rolf.leggewie.biz>
freelan

Romain Beauxis <***@rastageeks.org>
linuxdcpp

Romain Francoise <***@debian.org>
strongswan (U)
tcpdump

Ron Lee <***@debian.org>
opusfile

Russ Allbery <***@debian.org>
krb5 (U)
webauth
xml-security-c (U)
xmltooling (U)

Rust Maintainers <pkg-rust-***@lists.alioth.debian.org>
cargo

Ryan Kavanagh <***@debian.org>
opensmtpd
opensmtpd-extras

Rémi Palancher <***@rezib.org>
slurm-llnl (U)

Rémi Vanicat <***@debian.org>
xmms2 (U)

Salvatore Bonaccorso <***@debian.org>
libcrypt-openssl-rsa-perl (U)
libcrypt-openssl-x509-perl (U)
lnav
nodau
yapet

Sam Hartman <***@debian.org>
barnowl
freeradius (U)
krb5
libradsec
moonshot-gss-eap
moonshot-trust-router

Samuel Mimram <***@debian.org>
ocaml-ssl (U)
ocsigenserver (U)

Sandro Knauß <***@sandroknauss.de>
owncloud-client (U)

Sandro Tosi <***@debian.org>
transmission

Santiago Garcia Mantinan <***@debian.org>
yate (U)

Sascha Steinbiss <***@steinbiss.name>
iva (U)

Scott Howard <***@debian.org>
bitcoin (U)

Scott Kitterman <***@kitterman.com>
clamav (U)
getdns (U)
opendkim
opendkim (U)
postfix (U)

Sean Finney <***@debian.org>
php5 (U)

Sebastian Andrzej Siewior <***@breakpoint.cc>
clamav (U)
libclamunrar (U)

Sebastian Dröge <***@debian.org>
gst-plugins-bad1.0 (U)

Sebastian Reichel <***@debian.org>
s3backer (U)

Sergei Golovan <***@debian.org>
erlang (U)
tcltrf

Sergey B Kirpichev <***@gmail.com>
libapache2-mod-qos
monit

Shachar Shemesh <***@debian.org>
rsyncrypto

Shih-Yuan Lee (FourDollars) <***@gmail.com>
kore

Simon Horman <***@debian.org>
openvswitch (U)
perdition

Simon Josefsson <***@josefsson.org>
jabberd2 (U)
libre (U)
yubico-piv-tool (U)

Sjoerd Simons <***@debian.org>
gst-plugins-bad1.0 (U)
pulseaudio (U)

Soeren Sonnenburg <***@debian.org>
dmg2img

Soren Hansen <***@ubuntu.com>
opennebula (U)

Stefan Bauer (Cubewerk GmbH) <***@cubewerk.de>
sbnc

Stefan Fritsch <***@debian.org>
apache2 (U)
apr-util (U)

Stefan Handschuh <***@googlemail.com>
android-platform-system-core (U)

Stefan Hornburg (Racke) <***@linuxia.de>
courier
pure-ftpd

Stefan Lippers-Hollmann <s.l-***@gmx.de>
wpa (U)

Stefano Rivera <***@debian.org>
pypy

Steffen Moeller <***@debian.org>
boinc (U)

Steinar H. Gunderson <***@debian.org>
apache2 (U)

Stephen Frost <***@debian.org>
postgis (U)

Stephen Gran <***@debian.org>
clamav (U)
freeradius (U)
libclamunrar (U)

Stephen Kitt <***@debian.org>
mail-notification
osslsigncode

Steve M. Robbins <***@debian.org>
gdcm (U)

Steven Chamberlain <***@pyro.eu.org>
freebsd-utils (U)

Stig Sandbeck Mathisen <***@debian.org>
hitch

strongSwan Maintainers <pkg-swan-***@lists.alioth.debian.org>
strongswan

Stéphane Glondu <***@debian.org>
ocaml-ssl (U)
ocsigenserver (U)

Sune Vuorela <***@pusling.com>
qt4-x11 (U)
qtbase-opensource-src (U)

Sune Vuorela <***@debian.org>
kde4libs (U)
kopete (U)
qtbase-opensource-src (U)
virtuoso-opensource (U)

Swift Package Maintainer <***@swift.im>
swift-im

Sylvestre Ledru <***@debian.org>
hubicfuse
imapfilter (U)

syslog-ng maintainers <syslog-ng-***@lists.alioth.debian.org>
syslog-ng

SZALAY Attila <***@debian.org>
libzorpll
syslog-ng (U)
zorp

Sébastien Jodogne <***@gmail.com>
gdcm (U)

Takuo Kitame <***@debian.org>
stone

TANIGUCHI Takaki <***@debian.org>
gvpe

The Utopia Project <***@utopiadocs.com>
utopia-documents

Theodore Y. Ts'o <***@mit.edu>
isync (U)

Thijs Kinkhorst <***@debian.org>
libapache2-mod-auth-cas (U)
php5 (U)
php7.0 (U)

Thom May <***@debian.org>
apache2 (U)

Thomas Anders <***@users.sourceforge.net>
net-snmp (U)

Thomas Calderon <***@gmail.com>
caml-crush

Thomas Girard <***@free.fr>
ace (U)
omniorb-dfsg (U)

Thomas Goirand <***@goirand.fr>
libapache-mod-log-sql

Thomas Goirand <***@debian.org>
libapache-mod-log-sql
qpid-proton (U)

Thomas Leonard <***@gmail.com>
zeroinstall-injector

Thorsten Alteholz <***@alteholz.de>
alljoyn-core-1504
fis-gtm (U)
ginkgocadx (U)

Tianon Gravi <***@debian.org>
golang-github-hashicorp-serf (U)

Timo Aaltonen <***@debian.org>
certmonger (U)
freeipa (U)
gss-ntlmssp
libapache2-mod-auth-gssapi

Timo Jyrinki <***@debian.org>
qt4-x11 (U)
qtbase-opensource-src (U)

Tino Mettler <tino+***@tikei.de>
xca

Tollef Fog Heen <***@debian.org>
apache2 (U)

Tomas Pospisek <***@sourcepole.ch>
mailsync

Tomasz Buchert <***@debian.org>
nghttp2 (U)

tony mancill <***@debian.org>
bobcat (U)

Torsten Marek <***@debian.org>
lighttpd (U)

TransNexus, Inc. <***@transnexus.com>
osptoolkit

Tristan Seligmann <***@debian.org>
python-cryptography

Troy Heber <***@debian.org>
lastpass-cli

Tzafrir Cohen <***@debian.org>
asterisk (U)
kamailio (U)
pjproject
pjproject (U)
yate (U)

Ulises Vitulli <***@debian.org>
mailavenger

Unit 193 <***@ubuntu.com>
alpine (U)

uWSGI packaging team <pkg-uwsgi-***@lists.alioth.debian.org>
uwsgi

Vasudev Kamath <***@copyninja.info>
libre (U)

Victor Seva <***@torreviejawireless.org>
kamailio (U)
monit (U)

Victor Seva <***@debian.org>
kamailio (U)

Vincent Bernat <***@debian.org>
haproxy (U)
libevhtp
pen
xrdp

Vincent Sanders <***@debian.org>
netsurf

Wilfried Goesgens <***@outgesourced.org>
citadel (U)
webcit (U)

Willem van den Akker <***@wilsoft.nl>
jabberd2 (U)

William Dauchy <***@gmail.com>
php5 (U)

William Vera <***@billy.com.mx>
dsniff

Xavier Roche <***@httrack.com>
httrack

Ximin Luo <***@debian.org>
android-tools (U)
cpp-netlib
ricochet-im (U)

Ximin Luo <***@pwned.gg>
cpp-netlib

Yaroslav Halchenko <***@onerussian.com>
utopia-documents (U)

Yu Guanghui <***@debian.org>
qterm (U)

Yves-Alexis Perez <***@debian.org>
strongswan (U)

ZeroC, Inc. <***@zeroc.com>
zeroc-ice
Robert Edmonds
2016-06-11 15:36:44 UTC
Permalink
Post by Kurt Roeckx
unbound (U)
Thanks. Opened a bug report with upstream:

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=777
--
Robert Edmonds
***@debian.org
Jérémy Lal
2016-06-11 17:41:25 UTC
Permalink
Post by Kurt Roeckx
Hi,
The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.
It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.
https://wiki.openssl.org/index.php/1.1_API_Changes
If things aren't clear, you have questions, are there are missing
access functions please contact us.
I've uploaded packages to experimental, so you can use those to
test things.
Is an openssl 1.1.0 transition scheduled before release freeze ?

Jérémy
Kurt Roeckx
2016-06-11 18:44:53 UTC
Permalink
Post by Jérémy Lal
Post by Kurt Roeckx
Hi,
The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.
It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.
https://wiki.openssl.org/index.php/1.1_API_Changes
If things aren't clear, you have questions, are there are missing
access functions please contact us.
I've uploaded packages to experimental, so you can use those to
test things.
Is an openssl 1.1.0 transition scheduled before release freeze ?
I really would like it to make in the next release, so that would
be yes.


Kurt
Antti Jarvinen
2016-06-11 17:33:07 UTC
Permalink
Post by Kurt Roeckx
The release of OpenSSL 1.1.0 is getting nearer.
Thanks for the warning, I'm finding myself listed.. For the
problematic package I maintain the API changes are already fixed
upstream but is there any idea about schedule when (at latest) the
fixing version should be included?

The list itself was fairly impressive :)

--
Antti Järvinen
Kurt Roeckx
2016-06-11 18:50:37 UTC
Permalink
Post by Antti Jarvinen
Post by Kurt Roeckx
The release of OpenSSL 1.1.0 is getting nearer.
Thanks for the warning, I'm finding myself listed.. For the
problematic package I maintain the API changes are already fixed
upstream but is there any idea about schedule when (at latest) the
fixing version should be included?
I have no schedule currently about when we're going to release
openssl. We're already behind our own release schedule, but we're
only fixing things at the moment.

I don't want to maintain an openssl 1.0.2 package, so I assume
that soon after the transition starts you'll have to get your
package fixed to stay in testing, but that's clearly something I
need to discuss with the release team.


Kurt
Guus Sliepen
2016-06-14 11:11:58 UTC
Permalink
Post by Kurt Roeckx
The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.
It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.
While I think these changes are very good, upgrading is not trivial.
Especially not if, as an upstream project, you want to stay compatible
with older versions of OpenSSL as well; at least with 1.0.1/1.0.2,
because many distributions use that in their stable releases.
Post by Kurt Roeckx
tinc
Luckily, with tinc I can get away with doing some autoconf checks to see
if BN_GENCB_new()/_free() and RSA_set0_key() exist, and if not provide
my own versions. And I'll have to check compatibility with LibreSSL as
well. It's just so you know that it's not as trivial as you make it
sound.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <***@debian.org>
Jérémy Lal
2016-06-29 00:05:37 UTC
Permalink
Post by Guus Sliepen
Post by Kurt Roeckx
The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.
It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.
While I think these changes are very good, upgrading is not trivial.
Especially not if, as an upstream project, you want to stay compatible
with older versions of OpenSSL as well; at least with 1.0.1/1.0.2,
because many distributions use that in their stable releases.
Post by Kurt Roeckx
tinc
Luckily, with tinc I can get away with doing some autoconf checks to see
if BN_GENCB_new()/_free() and RSA_set0_key() exist, and if not provide
my own versions. And I'll have to check compatibility with LibreSSL as
well. It's just so you know that it's not as trivial as you make it
sound.
The openssl release strategy page [1] states:
Version 1.1.0 will be supported until 2018-04-30.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

Considering the dates, upstream authors using openssl 1.0.2 might not
migrate to the new api until 1.0.2 end of life.
Is it reasonnable, for security and human resources sake, to carry hundreds
of patches for a transition that will happen much more safely and naturally
later ?

Also in my opinion as well, the required work is not so trivial - qt,
nodejs, and also
software not in debian like lua's jwt package all require quite some time
with
probably low-quality results far from what upstream authors would do.

Cheers,
Jérémy


[1]
https://www.openssl.org/policies/releasestrat.html
Moritz Mühlenhoff
2016-06-29 19:49:40 UTC
Permalink
Post by Jérémy Lal
Version 1.1.0 will be supported until 2018-04-30.
Version 1.0.2 will be supported until 2019-12-31 (LTS).
Considering the dates, upstream authors using openssl 1.0.2 might not
migrate to the new api until 1.0.2 end of life.
Is it reasonnable, for security and human resources sake, to carry hundreds
of patches for a transition that will happen much more safely and naturally
later ?
Certainly. 1.1 brings a lot of internal changes which will be beneficial in
the long run. And of course's there a wide range of 1.1 features which will b
e important during the lifetime of stretch (e.g. chacha20/poly1305 support).

Cheers,
Moritz
Pau Garcia i Quiles
2016-06-29 20:38:24 UTC
Permalink
Post by Jérémy Lal
Post by Jérémy Lal
Version 1.1.0 will be supported until 2018-04-30.
Version 1.0.2 will be supported until 2019-12-31 (LTS).
Considering the dates, upstream authors using openssl 1.0.2 might not
migrate to the new api until 1.0.2 end of life.
Is it reasonnable, for security and human resources sake, to carry
hundreds
Post by Jérémy Lal
of patches for a transition that will happen much more safely and
naturally
Post by Jérémy Lal
later ?
Certainly. 1.1 brings a lot of internal changes which will be beneficial in
the long run. And of course's there a wide range of 1.1 features which will b
e important during the lifetime of stretch (e.g. chacha20/poly1305 support).
I beg to disagree.

IMHO the mandatory migration to OpenSSL 1.1.0 is happening too soon.

Most upstreams have do not support 1.1.0 yet, and have no plans to support
it in months. This will force Debian maintaners to rewrite OpenSSL code,
which is a very sensitive part and may turn an (upstream) secure
application into an insecure application due to incorrect patches.

If possible, I would rather have both 1.0.2 and 1.1.0 in the archive, and
move to 1.1.0 as upstream moves. I do not feel comfortable at all touching
security-related stuff, it's not my specialty. Even less if we are talking
about OpenSSL, known not to be the most friendly and intuitive APIs.
--
Pau Garcia i Quiles
http://www.elpauer.org
Gert Wollny
2016-06-29 22:56:44 UTC
Permalink
Post by Pau Garcia i Quiles
If possible, I would rather have both 1.0.2 and 1.1.0 in the archive,
and move to 1.1.0 as upstream moves. I do not feel comfortable at all
touching security-related stuff, it's not my specialty. Even less if
we are talking about OpenSSL, known not to be the most friendly and
intuitive APIs.
I'd like to second this. Working on a patch for qt4 taught me that this
transition is not going to be easy, and in this very case especially so
since during the qt4 package build no test suite is run to verify that
the changes don't break anything. 

I can understand that supporting two version of the library would be a
quite a burden, this is quite clear from just looking a the large
number of patches both packages carry, but considering that the Stretch
freeze is supposed to happen in less than six month, forcing a
transition now doesn't seem to be such a good idea to me.

best, 
Gert 
Russ Allbery
2016-06-30 00:46:19 UTC
Permalink
Post by Pau Garcia i Quiles
Most upstreams have do not support 1.1.0 yet, and have no plans to
support it in months. This will force Debian maintaners to rewrite
OpenSSL code, which is a very sensitive part and may turn an (upstream)
secure application into an insecure application due to incorrect
patches.
Yeah, Shibboleth upstream had a similar reaction to the ones reported
here: they want to work on it, someone has started looking at it, but
since 1.0 is supported for several more years, they weren't expecting it
to be an immediate issue and weren't planning on pushing to finish the
support until late 2017.

My guess from seeing the changes for INN is that the vast majority of
packages, which use OpenSSL in a glancing or fairly straightforward way,
won't be difficult to convert. But security and cryptographic software
that uses OpenSSL heavily and makes extensive use of its less common
corners may require quite a bit of work. (I think most of it is
mechanical, but lots of mechanical changes are also high-risk because
they're mind-numbing and it's easy to make a small mistake that slips
through unnoticed.)
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Stig Sandbeck Mathisen
2016-06-14 19:23:00 UTC
Permalink
hitch
Thanks. Bug filed upstream at
https://github.com/varnish/hitch/issues/100
--
Stig Sandbeck Mathisen
Lisandro Damián Nicanor Pérez Meyer
2016-06-27 13:04:24 UTC
Permalink
Post by Kurt Roeckx
Hi,
The release of OpenSSL 1.1.0 is getting nearer. Some packages
will no longer build with the new version without changes. Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.
[snip]
Post by Kurt Roeckx
qt4-x11 (U)
qtbase-opensource-src (U)
I'm afraid this are not good news from the Qt side.

= Qt 4

Qt 4 is dead upstream, so we have two choices:

- Someone to come up with a patch.
- Remove libSSL usage, causing a nightmare for many Qt4-based apps that are
still in the archive.

I have learned the Qt does a heavy usage of libSSL, so porting might not be
trivial. For whatever of the two possible choices above I would not mind going
ahead with them for Buster, but for Stretch I think it's too late. Even if we
had a patch I would really want some time to let users check everything works
as expected, and we are currently have less than 6 months already :-/

= Qt 5

The Qt 5 situation is similar, except releasing Qt5 without ssl support is,
I'm afraid, a non-go. The Qt upstream in charge of the ssl code said he
*might* probably have libssl 1.1.0 support ready for 5.8 [note] which will
happen too [late] for releasing Stretch. Having a non-official patch might be
doable, but we still need someone to code it and time to test it. Again, with
the current Stretch time frame, I don't think that's doable.

[note] It's worth to note that he is not working on simply adapting the new
code but a complete rewrite of the SSL usage in Qt, so even if we had a patch
I don't think we could have him reviewing it in the short time.

[late] End of year as early.

Thanks to Sune Vuorela for asking upstream about this :)
--
Evite los parámetros estáticos. Si son inevitables, haga que el emisor
y el receptor negocien un valor.
Andrew S. Tanenbaum, de su libro "Computer Networks"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Debian Bug Tracking System
2016-06-27 13:09:04 UTC
Permalink
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Debian Qt/KDE Maintainers <debian-qt-***@lists.debian.org>

If you wish to submit further information on this problem, please
send it to ***@bugs.debian.org.

Please do not send mail to ***@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.
--
828522: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Debian Bug Tracking System
2016-06-27 13:09:06 UTC
Permalink
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Debian Qt/KDE Maintainers <debian-qt-***@lists.debian.org>

If you wish to submit further information on this problem, please
send it to ***@bugs.debian.org.

Please do not send mail to ***@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.
--
828523: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828523
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Gert Wollny
2016-06-27 14:01:05 UTC
Permalink
Hello, 
Post by Lisandro Damián Nicanor Pérez Meyer
= Qt 4
- Someone to come up with a patch.
I volunteer to look into this. From what I've seen in DCMTK, the
changes are not too intrusive, most of the time it is just replacing
direct access to member variables with access functions because the
structures are now opaque.  

Best, 
Gert 
Lisandro Damián Nicanor Pérez Meyer
2016-06-27 15:41:45 UTC
Permalink
Post by Gert Wollny
Hello,
Post by Lisandro Damián Nicanor Pérez Meyer
= Qt 4
- Someone to come up with a patch.
I volunteer to look into this. From what I've seen in DCMTK, the
changes are not too intrusive, most of the time it is just replacing
direct access to member variables with access functions because the
structures are now opaque.
That's very appreciated, thanks!
--
18: Como se pueden evitar los problemas de alimentacion electrica
* No coma cerca de un enchufe
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Sune Vuorela
2016-06-27 19:51:59 UTC
Permalink
Post by Gert Wollny
Hello, 
Post by Lisandro Damián Nicanor Pérez Meyer
= Qt 4
- Someone to come up with a patch.
I volunteer to look into this. From what I've seen in DCMTK, the
changes are not too intrusive, most of the time it is just replacing
direct access to member variables with access functions because the
structures are now opaque.  
I would suggest talking to upstream, getting something working with qt5,
then backporting that patch.

/Sune
Gert Wollny
2016-06-27 20:45:19 UTC
Permalink
Post by Sune Vuorela
Post by Gert Wollny
Hello, 
Post by Lisandro Damián Nicanor Pérez Meyer
= Qt 4
- Someone to come up with a patch.
I volunteer to look into this. From what I've seen in DCMTK, the
changes are not too intrusive, most of the time it is just
replacing direct access to member variables with access functions
because the structures are now opaque.  
I would suggest talking to upstream, getting something working with
qt5, then backporting that patch.
Considering that Qt5 upstream is doing a complete rewrite of the
OpenSSL code, I think it is better to patch  Qt4 and then see whether
this can be forward ported to Qt5 without too much hassle. 

Besides, I've already identified all places that need patching within
Qt4. 

best, 
Gert
Christian Seiler
2016-06-29 02:15:39 UTC
Permalink
This post might be inappropriate. Click to display it.
Kurt Roeckx
2016-06-29 08:29:34 UTC
Permalink
Post by Christian Seiler
Post by Kurt Roeckx
https://wiki.openssl.org/index.php/1.1_API_Changes
If things aren't clear, you have questions, are there are missing
access functions please contact us.
I'm currently packaging a piece of software (open-isns, [1]) that uses
libcrypto functions internally. While trying to make sure that it will
compile against OpenSSL 1.1 (and hence be binNMU-able), most of the
things were straight-forward (opaque structures now requiring getters),
but I have encountered the following issue that doesn't appear to be
completely trivial to me: the software uses DSA+SHA1 as its signature
algoritm [2], and effectively boils down to the following code to
md_ctx = EVP_MD_CTX_new();
EVP_SignInit(md_ctx, EVP_dss1());
EVP_DigestUpdate(md_ctx, /* stuff */);
EVP_SignFinal(md_ctx, signature, &sig_len, pkey);
EVP_MD_CTX_free(md_ctx);
(Verification is analogous with VerifyInit/VerifyFinal.)
The problem is that EVP_dss1() doesn't exist anymore in OpenSSL 1.1. If
I understand the man page correctly, EVP_dss1 is a hack in really old
OpenSSL versions (how old btw.?) to support SHA1 signatures with DSA,
because back then the hash algorithms were tied to the public key
algorithms.
So is it correct to simply replace EVP_dss1() with EVP_sha1() in the
above code and it will still produce DSA signatures? Or do I have to do
something else to achieve the same results?
I'm not sure why they were removed at this time and not just
replaced by a #define.

Using EVP_sha1() is the correct replacement for EVP_dss1(),
as the manpage says.


Kurt
Christian Seiler
2016-06-29 08:31:12 UTC
Permalink
Post by Kurt Roeckx
Post by Christian Seiler
So is it correct to simply replace EVP_dss1() with EVP_sha1() in the
above code and it will still produce DSA signatures? Or do I have to do
something else to achieve the same results?
I'm not sure why they were removed at this time and not just
replaced by a #define.
Using EVP_sha1() is the correct replacement for EVP_dss1(),
as the manpage says.
Great, many thanks!

Regards,
Christian
James Cloos
2016-11-05 13:08:51 UTC
Permalink
Is anyone keeping track of when the various packages which depend on
openssl expect to upload versions compiled against 1.1?

I'd like to take advantage of x25519 and chacha20-poly1305 for various
tls-using servers...

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Bernd Zeimetz
2016-11-13 21:03:03 UTC
Permalink
Hi,

so whats your suggestions to solve issues like I have with
open-vm-tools: Most build-dependencies switch to 1.1.0 - but one
(libxml-security-c-dev) sticks with 1.0, as far as I've seen in the bts
because shibboleth won't be able to use 1.1.0.

Not shipping open-vm-tools is not an option, as it will break support
for Debian on basically all installations under a vmware hypervisor.
Which are a lot.

Whats your suggestion?


Best regards,

Bernd

P.S. imho the time for the openssl transition was the worst one possible
at all, it *will* result in security bugs and/or a delayed release.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Ondřej Surý
2016-11-14 12:26:44 UTC
Permalink
And this is happening all over places (apache2 vs php7.0) - I don't
think we can have a partial transition. It's now all or nothing.

Cheers,
--
Ondřej Surý <***@sury.org>
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
Post by Bernd Zeimetz
Hi,
so whats your suggestions to solve issues like I have with
open-vm-tools: Most build-dependencies switch to 1.1.0 - but one
(libxml-security-c-dev) sticks with 1.0, as far as I've seen in the bts
because shibboleth won't be able to use 1.1.0.
Not shipping open-vm-tools is not an option, as it will break support
for Debian on basically all installations under a vmware hypervisor.
Which are a lot.
Whats your suggestion?
Best regards,
Bernd
P.S. imho the time for the openssl transition was the worst one possible
at all, it *will* result in security bugs and/or a delayed release.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
+ signature.asc
1k (application/pgp-signature)
Lisandro Damián Nicanor Pérez Meyer
2016-11-14 13:45:50 UTC
Permalink
Post by Ondřej Surý
And this is happening all over places (apache2 vs php7.0) - I don't
think we can have a partial transition. It's now all or nothing.
I've said it before, I say it again: this transition should *not* have
happened at this point of the release cycle.

Don't get me wrong: I do perfectly understand why people would like to have
the new libssl around, but switching libssl-dev *now* was definitely not a
good idea. Doing it as soon as we start with buster is another story.

And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.

And if we *really* need to switch to libssl1.1 then we *really* need to delay
the release by 6 months as a very minimum, maybe 1 year.
--
mathematician, n.:
Some one who believes imaginary things appear right before your i's.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Adam Borowski
2016-11-14 14:37:00 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Ondřej Surý
And this is happening all over places (apache2 vs php7.0) - I don't
think we can have a partial transition. It's now all or nothing.
I've said it before, I say it again: this transition should *not* have
happened at this point of the release cycle.
Another issue: 1.0.2 is a LTS, supported until 2019-12-31, while 1.1.0 a
short-lived release with upstream support only until 2018-08-31.
--
A true bird-watcher waves his tail while doing so.
Adam Borowski
2016-11-16 16:23:29 UTC
Permalink
Post by Adam Borowski
Another issue: 1.0.2 is a LTS, supported until 2019-12-31, while 1.1.0 a
short-lived release with upstream support only until 2018-08-31.
Hmm... a different interpretation of these two data points:

Stretch's EOL is projected for May 2022 (LTS), and even regular support will
exceed the EOL of either of the above openssl branches. It'll be a lot
easier to backport fixes from 1.1.1+ to 1.1.0 than 1.0.2, and security
issues that don't apply to the 1.1 branch won't be even reported.

This gains us anything only for the "1.1.0 only" variant, though, which
doesn't sound possible.
--
A true bird-watcher waves his tail while doing so.
Marco d'Itri
2016-11-14 15:51:04 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
--
ciao,
Marco
Niels Thykier
2016-11-14 19:10:00 UTC
Permalink
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
At the moment, the maintainers of apache2 are picking the openssl 1.0
route. So at this rate, you would not get ChaCha20 for apache2 in
stretch anyway even if ssl1.1 says the "default"... :-/

The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).

Thanks,
~Niels

[1] https://github.com/cloudflare/sslconfig/tree/master/patches
Niels Thykier
2016-11-14 20:30:00 UTC
Permalink
Post by Niels Thykier
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
At the moment, the maintainers of apache2 are picking the openssl 1.0
route. So at this rate, you would not get ChaCha20 for apache2 in
stretch anyway even if ssl1.1 says the "default"... :-/
[...]
Thanks,
~Niels
For avoidance of doubt, this was not aimed at the apache2 maintainers.
I appreciate that "ssl1.0 vs. ssl1.1" is not an entirely easy decision
for maintainers - especially as it affects reverse dependencies as well.

The apache2 case was mentioned because I deemed it relevant to Marco's
argument.

~Niels
Adrian Bunk
2016-11-14 22:16:14 UTC
Permalink
Post by Niels Thykier
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
At the moment, the maintainers of apache2 are picking the openssl 1.0
route.
...
For libcurl3 the OpenSSL version is part of the ABI due to SSL_CTX.
If packages linked with libcurl3 use a different OpenSSL version than
libcurl3, that can break badly.

Apache seems to have similar problems.

Such packages do not even have a choice of going to 1.1 since that would
make it impossible for their rdeps to use 1.0.2
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
Trying to mix OpenSSL 1.0.2 and 1.1 is the expected mess.

And since 80% of all OpenSSL-using packages in unstable are still
using libssl1.0.2 (binNMUs have not yet happened), all runtime
issues observed so far are only the tip of the iceberg.
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free."
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.

For Apache, the choices available are:
1. no ChaCha20 in Apache in stretch
2. move the stretch release schedule by 6-12 months to have
only OpenSSL 1.1 in stretch
3. apply ChaCha20 patches to OpenSSL 1.0.2

You have the same choices for any other OpenSSL 1.1 features you
consider important.

Any explicit or implicit claims that you could just switch a package
like Apache to OpenSSL 1.1 within the current stretch release schedule
are just resulting in a lot of people wasting a lot of time.
Post by Niels Thykier
Thanks,
~Niels
...
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
Scott Leggett
2016-11-15 08:03:28 UTC
Permalink
Post by Adrian Bunk
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free."
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.
...
2. move the stretch release schedule by 6-12 months to have
only OpenSSL 1.1 in stretch
So with OpenSSL 1.1 in stretch, the release schedule is going to move by
6-12 months regardless?
--
Regards,
Scott.
Adrian Bunk
2016-11-15 14:51:26 UTC
Permalink
Post by Scott Leggett
Post by Adrian Bunk
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free."
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.
...
2. move the stretch release schedule by 6-12 months to have
only OpenSSL 1.1 in stretch
So with OpenSSL 1.1 in stretch, the release schedule is going to move by
6-12 months regardless?
Shipping OpenSSL 1.1 as security-supported technology preview in stretch,
and a few packages that both work with OpenSSL 1.1 and do not have
inter(r)dependencies with packages that don't work properly with OpenSSL
1.1 could use it - that would be possible without negative impact on the
release schedule.
Post by Scott Leggett
Regards,
Scott.
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
Jonas Smedegaard
2016-11-15 10:59:54 UTC
Permalink
Quoting Adrian Bunk (2016-11-14 23:16:14)
Post by Adrian Bunk
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide
libssl1.0-dev and have libssl1.1-dev around for anyone who can
really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a
very bad default for next year's release.
Bad enough that I would have to use a different distribution for
some web servers.
[...]
Post by Adrian Bunk
1. no ChaCha20 in Apache in stretch
2. move the stretch release schedule by 6-12 months to have
only OpenSSL 1.1 in stretch
3. apply ChaCha20 patches to OpenSSL 1.0.2
4. use libapache2-mod-gnutls?

- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Bernd Zeimetz
2016-11-15 11:59:24 UTC
Permalink
Post by Jonas Smedegaard
4. use libapache2-mod-gnutls?
that might work for you, but its nothing the common debian user will
do.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Sebastian Andrzej Siewior
2016-11-15 23:15:39 UTC
Permalink
Post by Adrian Bunk
And since 80% of all OpenSSL-using packages in unstable are still
using libssl1.0.2 (binNMUs have not yet happened), all runtime
issues observed so far are only the tip of the iceberg.
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free."
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.
Are you afraid of bugs or that nobody will look after them? Can't speak
for apache but #843988 got patched and so did #843532.

Sebastian
Adrian Bunk
2016-11-16 17:49:44 UTC
Permalink
Post by Sebastian Andrzej Siewior
Post by Adrian Bunk
And since 80% of all OpenSSL-using packages in unstable are still
using libssl1.0.2 (binNMUs have not yet happened), all runtime
issues observed so far are only the tip of the iceberg.
Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid free."
or #843988 will be a common sight on the list of RC bugs for several
months in any scenario with OpenSSL 1.1 as default.
Are you afraid of bugs or that nobody will look after them? Can't speak
for apache but #843988 got patched and so did #843532.
The problem are not specific bugs, the problem is the whole size of the
problem:

1. Sorting out what packages have to stay at 1.0.2
The majority of OpenSSL-using packages in stretch might end up
using 1.0.2 - sorting this out is part of the ongoing OpenSSL
transition.

2. OpenSSL 1.1 support is often only build-tested
We are currently at 650 packages in unstable depending on libssl1.0.2,
and when binNMUs will happen we might get a three-digit number of
new RC bugs like #843988 and #843532.

3. Another Debian OpenSSL security fiasco?
Bugs like #843988 are only about problems that show up immediately.
This is often code where mistakes can be CVEs, and bug #843988 or
the comment "With Kurt's patch, apache2 crashes on startup" don't
make me optimistic regarding silent new security holes.
Depending on how/if this was applied upstream, these might become
Debian-specific CVEs.
People will remember the last time Debian screwed up badly in the area
of OpenSSL, so this could really harm the reputation of Debian.

4. Schedule
The transition freeze was 11 days ago, and the soft freeze is only
1.5 months ahead.
If the work on points 1 and 2 above is not mostly finished
by December 5th (mandatory 10-day migrations will start, only
1 month until the soft freeze), either the OpenSSL transition
or the release schedule have to be scrapped.
Post by Sebastian Andrzej Siewior
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
Sebastian Andrzej Siewior
2016-11-16 21:53:18 UTC
Permalink
Post by Adrian Bunk
The problem are not specific bugs, the problem is the whole size of the
1. Sorting out what packages have to stay at 1.0.2
The majority of OpenSSL-using packages in stretch might end up
using 1.0.2 - sorting this out is part of the ongoing OpenSSL
transition.
You have two choices: either port it to 1.1.0 and stay with 1.0.2.
Post by Adrian Bunk
2. OpenSSL 1.1 support is often only build-tested
We are currently at 650 packages in unstable depending on libssl1.0.2,
and when binNMUs will happen we might get a three-digit number of
new RC bugs like #843988 and #843532.
stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
We would also face the same problem if openssl 1.0.2 decided to do a
realloc() at some point. Lucky it did not yet. Some package run a
testsuite so we find bugs there, too.
Post by Adrian Bunk
3. Another Debian OpenSSL security fiasco?
Bugs like #843988 are only about problems that show up immediately.
This is often code where mistakes can be CVEs, and bug #843988 or
the comment "With Kurt's patch, apache2 crashes on startup" don't
make me optimistic regarding silent new security holes.
Depending on how/if this was applied upstream, these might become
Debian-specific CVEs.
I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
upstream for the two perl patches I made and had hope that the debian
maintainer knows how to forwarded them.
Post by Adrian Bunk
People will remember the last time Debian screwed up badly in the area
of OpenSSL, so this could really harm the reputation of Debian.
4. Schedule
The transition freeze was 11 days ago, and the soft freeze is only
1.5 months ahead.
If the work on points 1 and 2 above is not mostly finished
by December 5th (mandatory 10-day migrations will start, only
1 month until the soft freeze), either the OpenSSL transition
or the release schedule have to be scrapped.
So people still can choose to go for 1.1.0 or 1.0.2. They may work on
1.1.0.
Post by Adrian Bunk
cu
Adrian
Sebastian
Adrian Bunk
2016-11-17 11:10:40 UTC
Permalink
Post by Sebastian Andrzej Siewior
Post by Adrian Bunk
The problem are not specific bugs, the problem is the whole size of the
1. Sorting out what packages have to stay at 1.0.2
The majority of OpenSSL-using packages in stretch might end up
using 1.0.2 - sorting this out is part of the ongoing OpenSSL
transition.
You have two choices: either port it to 1.1.0 and stay with 1.0.2.
60 packages got removed from testing since there was only a 10 day
window between openssl1.0 being available and autoremoval of these
packages.

And after submitting patches to switch packages to 1.0.2, it was you who
said "Adrian, seriously? This is not a patch."

This is your transition, and it should actually be you who is working on
getting all ~ 200 RC bugs in sid related to your transition resolved.

And this is only about the simple cases.
A huge problem is the unknown number of small and big clusters of
packages that have to use the same OpenSSL version.

Noone from you OpenSSL developers seems to be working on sorting these
clusters out.

Like I do not understand why Kurt is trying to switch Apache to 1.1
As far as I can see, Apache is part of the libcurl3 cluster where
all packages anyway have to stay at 1.0.2 for stretch.
Post by Sebastian Andrzej Siewior
Post by Adrian Bunk
2. OpenSSL 1.1 support is often only build-tested
We are currently at 650 packages in unstable depending on libssl1.0.2,
and when binNMUs will happen we might get a three-digit number of
new RC bugs like #843988 and #843532.
stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
We would also face the same problem if openssl 1.0.2 decided to do a
realloc() at some point. Lucky it did not yet.
...
Every non-trivial piece of software has bugs.

The relevant part here is "works with 1.0.2, but did not work with 1.1".
These are regressions when switching from 1.0.2 to 1.1, no matter where
the actual bug is.
Post by Sebastian Andrzej Siewior
Post by Adrian Bunk
3. Another Debian OpenSSL security fiasco?
Bugs like #843988 are only about problems that show up immediately.
This is often code where mistakes can be CVEs, and bug #843988 or
the comment "With Kurt's patch, apache2 crashes on startup" don't
make me optimistic regarding silent new security holes.
Depending on how/if this was applied upstream, these might become
Debian-specific CVEs.
I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
upstream for the two perl patches I made and had hope that the debian
maintainer knows how to forwarded them.
You are not the only one patching these, and surely not the least
knowledgable person making such patches.

And noone seems to be systematically tracking for all patches what
happens in the end - even cherry-picking an upstream patch might
miss critical later upstream fixes.

The problem here is the huge amount of packages that need changes due to
the OpenSSL API breakage.
Post by Sebastian Andrzej Siewior
Post by Adrian Bunk
People will remember the last time Debian screwed up badly in the area
of OpenSSL, so this could really harm the reputation of Debian.
4. Schedule
The transition freeze was 11 days ago, and the soft freeze is only
1.5 months ahead.
If the work on points 1 and 2 above is not mostly finished
by December 5th (mandatory 10-day migrations will start, only
1 month until the soft freeze), either the OpenSSL transition
or the release schedule have to be scrapped.
So people still can choose to go for 1.1.0 or 1.0.2. They may work on
1.1.0.
Is everyone aware that this choice is per-cluster and not per-package?

One single leaf package that chooses to stay at 1.0.2 and is part
of a cluster implies that you must force all other packages in the
cluster to also stay at 1.0.2
Post by Sebastian Andrzej Siewior
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
Tino Mettler
2016-11-21 10:11:09 UTC
Permalink
On Thu, Nov 17, 2016 at 13:10:40 +0200, Adrian Bunk wrote:

[...]
Post by Adrian Bunk
Is everyone aware that this choice is per-cluster and not per-package?
Hi,

one of my packages uses OpenSSL and Qt. I tried to inform upstream
regarding the plans for 1.1 in Stretch because the package FTBFS with
1.1 as it uses a lot of structures that got opaque (which requires some
non-trivial changes). It wasn't that easy to get the current state and
plans for the transition when digging in bug reports, changelogs,
mailing lists and helpful hints I got on IRC by accident.

At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.

I was somewhat puzzled that I did not read anything about the whole
subject at debian-devel-announce, as it is not one of the usual
transitions.

Regards,
Tino
Jan Niehusmann
2016-11-21 13:06:55 UTC
Permalink
Hi,
Post by Tino Mettler
At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.
I'm not so sure about this any more:

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.

Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?

If that's true, it would (IMHO) be a major step towards a timely release
of stretch with OpenSSL 1.1 as the default version.

Jan
Henrique de Moraes Holschuh
2016-11-21 13:30:13 UTC
Permalink
Post by Jan Niehusmann
Post by Tino Mettler
At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.
Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?
The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays. What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.

If, at any point, internal data structures from openssl are exposed, or
OpenSSL contextes are passed between two libraries, or a library and an
application, *they must all be from the same openssl*.

This is not something the linker or dlopen/dlsym can enforce. And you
need to manually inspect the code to be sure... usually.

So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
--
Henrique de Moraes Holschuh <***@debian.org>
Lisandro Damián Nicanor Pérez Meyer
2016-11-21 15:46:10 UTC
Permalink
On lunes, 21 de noviembre de 2016 11:30:13 ART Henrique de Moraes Holschuh
Post by Henrique de Moraes Holschuh
Post by Jan Niehusmann
Post by Tino Mettler
At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.
Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?
The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays. What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.
If, at any point, internal data structures from openssl are exposed, or
OpenSSL contextes are passed between two libraries, or a library and an
application, *they must all be from the same openssl*.
This is not something the linker or dlopen/dlsym can enforce. And you
need to manually inspect the code to be sure... usually.
So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
Qt uses ssl in QtNetwork, so at very least I would say that if you don't use
QtNetwork you should be fine.

But this is only theory.
--
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Antti Järvinen
2016-11-22 11:03:30 UTC
Permalink
Post by Henrique de Moraes Holschuh
The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays. What causes extremely nasty
Someone confirm following is true: both application using 1.1 and
library (qt in my example) using 1.0 both create encryption keys, both
first call function RAND_seed(..) then is the random pool properly
initialized for both versions of the library?? I haven't looked at
internals but his kind of random pool might be easily implemented as a
global shared object. Or a separate one. Initializing the correct one
could be tricky at run-time.

--
Antti
Kurt Roeckx
2016-11-23 23:37:01 UTC
Permalink
Post by Henrique de Moraes Holschuh
Post by Jan Niehusmann
Post by Tino Mettler
At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.
Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?
The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays. What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.
If, at any point, internal data structures from openssl are exposed, or
OpenSSL contextes are passed between two libraries, or a library and an
application, *they must all be from the same openssl*.
This is not something the linker or dlopen/dlsym can enforce. And you
need to manually inspect the code to be sure... usually.
I've always had the impression that there are or used to be
probems using using dlopen()/dlsym(). Maybe related to some things
like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
library. Do you know of any problems related to that?

Note that QT is one of those that uses dlopen()/dlsym() when
calling openssl functions (for license reasons).
Post by Henrique de Moraes Holschuh
So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.


Kurt
Henrique de Moraes Holschuh
2016-11-24 01:50:12 UTC
Permalink
Post by Kurt Roeckx
I've always had the impression that there are or used to be
probems using using dlopen()/dlsym(). Maybe related to some things
like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
library. Do you know of any problems related to that?
AFAIK, OpenSSL itself -- at least as packaged by Debian -- should not
get confused about where its *own* static globals are. And any globals
it might export would also be fully ELF-symbol-versioned from what I can
see (objdump -tT).

If RTDL_GLOBAL is borking ELF symbol versioning, all bets are off.

Note: I have no idea what happens if you throw libssl.a into the mix
with a different version of libssl.so. This kind of hell-born
braindamage can happen due to glibc nss modules, for example.
Post by Kurt Roeckx
Note that QT is one of those that uses dlopen()/dlsym() when
calling openssl functions (for license reasons).
No comment I could make about this would be acceptable in polite
company. Or in impolite company. Or even during a sailor-class-cursing
competition.
Post by Kurt Roeckx
Post by Henrique de Moraes Holschuh
So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.
If it does, all reverse *build* dependencies would need to be inspected,
then.

AFAIK, that means they must not link to anything that could link to a
different libssl than the one used by qt5. If they do, everything needs
to be inspected down to the details to ensure nothing will ever leak
openssl contextes and data structures across a library boundary
(including the application).
--
Henrique Holschuh
Adrian Bunk
2016-11-24 13:59:10 UTC
Permalink
Post by Henrique de Moraes Holschuh
...
Post by Kurt Roeckx
Post by Henrique de Moraes Holschuh
So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.
If it does, all reverse *build* dependencies would need to be inspected,
then.
AFAIK, that means they must not link to anything that could link to a
different libssl than the one used by qt5. If they do, everything needs
to be inspected down to the details to ensure nothing will ever leak
openssl contextes and data structures across a library boundary
(including the application).
If inspection is not easily possible, then adding a dependency on
libssl1.0-dev to qtbase5-private-dev should be sufficient to
ensure that this is not leaked to a different OpenSSL version.

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
Lisandro Damián Nicanor Pérez Meyer
2016-11-24 03:02:20 UTC
Permalink
On jueves, 24 de noviembre de 2016 00:37:01 ART Kurt Roeckx wrote:
[snip]
Post by Kurt Roeckx
Post by Henrique de Moraes Holschuh
So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe. If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.
It seems to be doing this in qtbase5-private-dev. Not sure if
there are actually any users of it.
Sadly there are users of qtbase5-private-dev, and that's why we need to do a
transition on each patch release. Ugly as hell, but nothying we maintainers
can do about it.

Now which of those use the SSL stuff is another thing which I would really not
try to dig into.
--
The POP3 server service depends on the SMTP server service, which
failed to start because of the following error:
The operation completed successfully.
-- Windows NT Server v3.51

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Kurt Roeckx
2016-11-16 23:40:42 UTC
Permalink
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.


Kurt
Lisandro Damián Nicanor Pérez Meyer
2016-11-17 01:04:00 UTC
Permalink
Post by Kurt Roeckx
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.
I am with Kurt here. I myself didn't want to apply an untested patch to qt4 to
add libssl1.1 support without enough time to test it (because after all qt4 is
dead upstream and we can only hope for the best, but not *right* now).

We need to find another option.
--
The generation of random numbers is too important to be left to chance.
http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Scott Kitterman
2016-11-17 05:27:43 UTC
Permalink
On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Kurt Roeckx
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.
I am with Kurt here. I myself didn't want to apply an untested patch to qt4
to add libssl1.1 support without enough time to test it (because after all
qt4 is dead upstream and we can only hope for the best, but not *right*
now).
We need to find another option.
We now have the particularly fun situation where neither openssl 1.1 (due to
#844366) nor openssl 1.0 (due to #736687) can get to unstable, so if your
package build-depends on openssl it's going to be some time before your
package gets to unstable no matter which one you pick.

Scott K
Adrian Bunk
2016-11-17 10:49:25 UTC
Permalink
Post by Scott Kitterman
On Wednesday, November 16, 2016 10:04:00 PM Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Kurt Roeckx
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.
I am with Kurt here. I myself didn't want to apply an untested patch to qt4
to add libssl1.1 support without enough time to test it (because after all
qt4 is dead upstream and we can only hope for the best, but not *right*
now).
We need to find another option.
We now have the particularly fun situation where neither openssl 1.1 (due to
#844366) nor openssl 1.0 (due to #736687) can get to unstable,
...
s/unstable/testing/

openssl 1.1 and openssl1.0 have to enter testing at the same time.

#736687 is a non-issue for the transition itself, and the release team
can force a package into testing ignoring such a bug.
Post by Scott Kitterman
Scott K
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
Bernd Zeimetz
2016-11-19 17:30:06 UTC
Permalink
Post by Kurt Roeckx
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.
Understandable. Did you talk to upstream about the issue? What do they say?
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Kurt Roeckx
2016-11-19 20:06:27 UTC
Permalink
Post by Bernd Zeimetz
Post by Kurt Roeckx
Post by Niels Thykier
The alternative for ChaCha20 would be to adopt Cloudflare's patches[1],
but that sort of assumes that you are only interested in openssl 1.1 for
ChaCha20 (and not the other changes).
I'm not willing to maintain such a patch.
Understandable. Did you talk to upstream about the issue? What do they say?
Chacha20 would be a new feature. Following the policy that can't
be added in a 1.0.2 version, only bugs get fixed in it.

We made a new release with new features, that version is 1.1.0.


Kurt
Ondrej Novy
2016-11-19 21:32:58 UTC
Permalink
Hi,
Post by Kurt Roeckx
Chacha20 would be a new feature. Following the policy that can't
be added in a 1.0.2 version, only bugs get fixed in it.
yep, they don't add new feature, but break API between 1.1.0b->c release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
https://github.com/openssl/openssl/issues/1903
https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e

Really nice.

Please revert this transition and try again with buster, thanks.
--
Best regards
Ondřej NovÃœ

Email: ***@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Kurt Roeckx
2016-11-19 23:49:13 UTC
Permalink
Post by Ondrej Novy
Hi,
Post by Kurt Roeckx
Chacha20 would be a new feature. Following the policy that can't
be added in a 1.0.2 version, only bugs get fixed in it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
https://github.com/openssl/openssl/issues/1903
This is being fixed.


Kurt
Scott Kitterman
2016-11-21 02:46:54 UTC
Permalink
Post by Kurt Roeckx
Post by Ondrej Novy
Hi,
Post by Kurt Roeckx
Chacha20 would be a new feature. Following the policy that can't
be added in a 1.0.2 version, only bugs get fixed in it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366
https://github.com/openssl/openssl/issues/1903
This is being fixed.
Great. Would it be possible to revert this change in Debian for now so that
1.1.0 can get to Testing and stop blocking other changes that have been built
against openssl 1.1? I have a package on the autoremoval list that can't get
to Testing until it does. I know I can periodically comment on the bug in
question, but it'd be nicer just to have the fix migrate.

Scott K
Lisandro Damián Nicanor Pérez Meyer
2016-11-15 12:37:01 UTC
Permalink
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
and have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
That's why I wrote:

And if we **really** need to switch to libssl1.1 then we **really** need to
delay the release by 6 months as a very minimum, maybe 1 year.

Yes, I also know that it sounds awful, but do we have another way out?
--
Ponga su mano en una estufa caliente por un minuto, y le parecerá como una
hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto.
¡Eso es relatividad!.
Albert Einstein (1879-1955)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Adrian Bunk
2016-11-15 14:34:53 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
and have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
And if we **really** need to switch to libssl1.1 then we **really** need to
delay the release by 6 months as a very minimum, maybe 1 year.
Yes, I also know that it sounds awful, but do we have another way out?
Yes, patching the OpenSSL 1.1 features that are really needed into the
Debian OpenSSL 1.0.2 package.

For ChaCha20 that's existing patches that are already being used
elsewhere.

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
Moritz Mühlenhoff
2016-11-17 21:43:53 UTC
Permalink
Post by Adrian Bunk
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
and have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
And if we **really** need to switch to libssl1.1 then we **really** need to
delay the release by 6 months as a very minimum, maybe 1 year.
Yes, I also know that it sounds awful, but do we have another way out?
Yes, patching the OpenSSL 1.1 features that are really needed into the
Debian OpenSSL 1.0.2 package.
For ChaCha20 that's existing patches that are already being used
elsewhere.
That's not an option, while there's an external patch for chacha20/poly
by cloudflare it hasn't been upstreamed and we cannot cover it with
security support in a meaningful manner. And other features are not
backportable at all.

Kurt has already asked who would do the backports and support them in
https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop
pretending that's a genuine option.
Adrian Bunk
2016-11-17 23:02:25 UTC
Permalink
Post by Moritz Mühlenhoff
Post by Adrian Bunk
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Marco d'Itri
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
and have libssl1.1-dev around for anyone who can really do the switch.
I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very
bad default for next year's release.
Bad enough that I would have to use a different distribution for some
web servers.
And if we **really** need to switch to libssl1.1 then we **really** need to
delay the release by 6 months as a very minimum, maybe 1 year.
Yes, I also know that it sounds awful, but do we have another way out?
Yes, patching the OpenSSL 1.1 features that are really needed into the
Debian OpenSSL 1.0.2 package.
For ChaCha20 that's existing patches that are already being used
elsewhere.
That's not an option, while there's an external patch for chacha20/poly
by cloudflare it hasn't been upstreamed and we cannot cover it with
security support in a meaningful manner.
1.1.0 will be out of upstream security support after August 2018,
1.0.2 after 2019.

Debian is able and willing to provide security support for two OpenSSL
releases in stretch, that will both be without upstream support in 2020.
Post by Moritz Mühlenhoff
And other features are not
backportable at all.
Kurt has already asked who would do the backports and support them in
https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop
pretending that's a genuine option.
Dual 1.0.2/1.1 is the expected mess, and people have to stop pretending
it would be a genuine option that most of the important packages in
stretch would use 1.1, unless the release schedule is moved by 6-12
months.

Trying to make all or a majority of OpenSSL-using packages in stretch
use 1.1 might not even be much faster in delivering 1.1 features to
stable users than making stretch 1.0.2-only[1], and release buster
1.1-only a year after stretch.

As a bonus, "stretch 1.0.2-only and early buster" would imply providing
security support for one OpenSSL version that will be upstream-supported
during the whole (non-LTS) lifetime of stretch, instead of providing
security support for two OpenSSL versions that will both get out of
upstream support during the lifetime of a stretch without early buster.

And/or get sponsorship from companies for supporting ChaCha20-patched
1.0.2 through Freexian - this would be an option that would not impact
the release schedule.[2]

OpenSSL upstream created this mess by only providing new features
together with a huge API breakage, and there are no nice solutions
for stretch.

cu
Adrian

[1] shipping 1.1 as security-supported technology preview is an option
[2] I am aware that this would be controversial
--
"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
Moritz Mühlenhoff
2016-11-18 21:22:59 UTC
Permalink
Post by Adrian Bunk
And/or get sponsorship from companies for supporting ChaCha20-patched
1.0.2
It's not a matter of whipping up some patch; anything less than an
official backport of chacha20 into a 1.0.2x release is not going
to be supportable.

Cheers,
Moritz
Adrian Bunk
2016-11-18 22:19:53 UTC
Permalink
Post by Moritz Mühlenhoff
Post by Adrian Bunk
And/or get sponsorship from companies for supporting ChaCha20-patched
1.0.2
It's not a matter of whipping up some patch; anything less than an
official backport of chacha20 into a 1.0.2x release is not going
to be supportable.
Supporting 1.1.0 in addition to 1.0.2, including 2 years of supporting
1.1.0 after upstream support for it ended - it is confirmed that Debian
is able and willing to support that.

Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not
obvious to me why this would be that much worse in comparison that
it would not be an option under any circumstances.

Whether it is the best available option is a separate question.

My current preference would be stretch 1.0.2-only[2], and an early
buster a year later[3] if Fedora manages to make a release with 1.1
in June.

With dual 1.0.2/1.1 not working in the current release schedule,
what is your preferred solution?
Post by Moritz Mühlenhoff
Cheers,
Moritz
cu
Adrian

[1] which should see a lot less code changes now that upstream
is focussing on 1.1 and later
[2] with or without ChaCha20 patched
[3] my preference, whether the release team would agree I do not know
--
"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
Moritz Mühlenhoff
2016-11-20 17:40:59 UTC
Permalink
Post by Adrian Bunk
Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not
obvious to me why this would be that much worse in comparison that
it would not be an option under any circumstances.
That patch has never been upstreamed and is not something we can
rely on, it's also questionable whether it will receive any support
from its author(s). I very much doubt cloudflare will use it much
longer.

Cheers,
Moritz
Stefan Fritsch
2016-11-19 10:18:54 UTC
Permalink
Post by Moritz Mühlenhoff
Post by Adrian Bunk
And/or get sponsorship from companies for supporting ChaCha20-patched
1.0.2
It's not a matter of whipping up some patch; anything less than an
official backport of chacha20 into a 1.0.2x release is not going
to be supportable.
I am sure Redhat will be interested in that as well. So release now with 1.0.2
without ChaCha20 and upgrade openssl in a point release when/if 1.0.2 supports
ChaCha20.

That or delay the release by a few months.

BTW, just because an openssl-using app/lib does not export an interface that
allows access of openssl-related internals does not mean that no other lib or
plugin messes with those internals. For example, for apache2 there is gridsite
which uses mod_ssl private interfaces and a private copy of a header from the
apache2 sources to get access to the SSL context. Finding all such issues in
all packages will take time.

Cheers,
Stefan
Marco d'Itri
2016-11-19 22:07:23 UTC
Permalink
Post by Stefan Fritsch
plugin messes with those internals. For example, for apache2 there is gridsite
which uses mod_ssl private interfaces and a private copy of a header from the
apache2 sources to get access to the SSL context. Finding all such issues in
all packages will take time.
We call this "broken by design" and a "FPOS program".
--
ciao,
Marco
Simon Richter
2016-11-19 22:59:59 UTC
Permalink
Hi,
Post by Marco d'Itri
Post by Stefan Fritsch
plugin messes with those internals. For example, for apache2 there is gridsite
which uses mod_ssl private interfaces and a private copy of a header from the
apache2 sources to get access to the SSL context. Finding all such issues in
all packages will take time.
We call this "broken by design" and a "FPOS program".
The problem with OpenSSL is that these things are often necessary.

In KiCad, we explicitly link against OpenSSL in order to initialize a
struct that contains lock/unlock functions, in case the libcurl we use
is linked against OpenSSL, so it doesn't keel over when asked to perform
two HTTPS requests at the same time.

The git history of OpenSSL doesn't exactly give me a lot of confidence
either, and stable branches are apparently not even compile tested after
backporting fixes (as evidenced by compile failures on KiCad's Jenkins
server).

My dream solution at this point would be to organize a week-long
hackfest somewhere where we move everything to GnuTLS if possible.

Simon
Bernd Zeimetz
2016-11-20 07:49:41 UTC
Permalink
Post by Simon Richter
My dream solution at this point would be to organize a week-long
hackfest somewhere where we move everything to GnuTLS if possible.
Are you sure that makes things better? I've seen too many weird issues
with GnuTLS. What about LibreSSL?
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Marco d'Itri
2016-11-20 12:57:52 UTC
Permalink
Post by Simon Richter
My dream solution at this point would be to organize a week-long
hackfest somewhere where we move everything to GnuTLS if possible.
I do not think that anybody has been considering GnuTLS as a credible
replacement for a very long time.
A few years ago Red Hat started porting some major packages to NSS, but
even this effort has been discontined:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation .
--
ciao,
Marco
Clint Adams
2016-11-21 02:35:08 UTC
Permalink
Post by Marco d'Itri
I do not think that anybody has been considering GnuTLS as a credible
replacement for a very long time.
That's very silly.
Bernd Zeimetz
2016-11-21 19:10:18 UTC
Permalink
Post by Clint Adams
Post by Marco d'Itri
I do not think that anybody has been considering GnuTLS as a credible
replacement for a very long time.
That's very silly.
No, its the truth unfortunately.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Russ Allbery
2016-11-21 19:17:43 UTC
Permalink
Post by Bernd Zeimetz
Post by Clint Adams
Post by Marco d'Itri
I do not think that anybody has been considering GnuTLS as a credible
replacement for a very long time.
That's very silly.
No, its the truth unfortunately.
It's a ton of work to maintain a high-quality SSL implementation. Even
apart from the multitude of security issues that constantly arise, you
have to deal with interoperability with a bunch of half-assed, semi-broken
SSL implementations in the wild. It needs resources, and the GnuTLS
development team doesn't seem to have those resources (and hasn't for a
while). This in turn makes it hard to persuade upstreams to even consider
it, since they're usually very worried about interopability (and GnuTLS
has a spotty track record there).

It also really hurts for GnuTLS to have a completely different API,
whatever the merits of that API over OpenSSL's. (The OpenSSL
compatibility layer is missing so much that it's not really usable. For
instance, it offers no way to set cipher suite preferences at all and
disables TLSv1.1 and newer, at least as far as I was able to determine
from looking at the code while trying to solve another reported bug.)
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Moritz Mühlenhoff
2016-11-20 17:34:22 UTC
Permalink
Post by Stefan Fritsch
Post by Moritz Mühlenhoff
Post by Adrian Bunk
And/or get sponsorship from companies for supporting ChaCha20-patched
1.0.2
It's not a matter of whipping up some patch; anything less than an
official backport of chacha20 into a 1.0.2x release is not going
to be supportable.
I am sure Redhat will be interested in that as well. So release now with 1.0.2
without ChaCha20 and upgrade openssl in a point release when/if 1.0.2 supports
ChaCha20.
Red Hat has no product with long term support based on 1.0.2 and RHEL 8 will
certainly use 1.1, so while that would certainly be great I'm afraid such a
patch is hypothetical.

Cheers,
Moritz
Jan Niehusmann
2016-11-14 21:16:25 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and
have libssl1.1-dev around for anyone who can really do the switch.
That's the only viable alternative I see.

It looks like an increasing number of packages, including apache2,
openssh, qt4 and qt5, picked to build-depend on libssl1.0-dev.

So OpenSSL 1.0 won't go away, and through packages indirectly depending
on both versions, we'll get very difficult to solve conflicts.

As removing all those packages clearly is not an option, the release
will be significantly delayed if we don't revert the default to be
OpenSSL 1.0.

(It's fine if packages which depend on libssl-dev get an RC-bug if they
can't be compiled with OpenSSL 1.1. Packages which can't be ported
should explicitly depend on libssl1.0-dev. That way we'll make progress
towards a point where we can start a smooth transition.)

I'd be glad to have a quick transition to OpenSSL 1.1 now, but I honestly
don't see a way how this may work.

Please revert the default back to 1.0 for now.

Jan
Lisandro Damián Nicanor Pérez Meyer
2016-11-15 13:43:07 UTC
Permalink
On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote:
[snip]
Post by Jan Niehusmann
(It's fine if packages which depend on libssl-dev get an RC-bug if they
can't be compiled with OpenSSL 1.1. Packages which can't be ported
should explicitly depend on libssl1.0-dev. That way we'll make progress
towards a point where we can start a smooth transition.)
I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev
means that some apps/libs will get automatically recompiled and some of them
might even not FTBFS (because for example, they are ready to use 1.1).

That means we left the door open to crashes due to mixed libssl versions.

By letting libssl-dev provide libssl1.0 we do not open this door, and we let
maintainers decide on a per-basis case.
--
You are the Doc, Doc!
Marty McFly To Dr. Emmett Brown, Back to the Future III

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Bernd Zeimetz
2016-11-15 13:52:15 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
I *really* disagree with that. Swtiching libssl-dev to provide
libssl1.1-dev
means that some apps/libs will get automatically recompiled and some of them
might even not FTBFS (because for example, they are ready to use 1.1).
If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug
that
should be fixed anyway. There is no real reason not to support both
versions.
Post by Lisandro Damián Nicanor Pérez Meyer
That means we left the door open to crashes due to mixed libssl versions.
By letting libssl-dev provide libssl1.0 we do not open this door, and we let
maintainers decide on a per-basis case.
And we have to maintain two openssl versions trough the release cycle.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Lisandro Damián Nicanor Pérez Meyer
2016-11-15 14:01:39 UTC
Permalink
Post by Bernd Zeimetz
Post by Lisandro Damián Nicanor Pérez Meyer
I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev
means that some apps/libs will get automatically recompiled and some of them
might even not FTBFS (because for example, they are ready to use 1.1).
If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug
that
should be fixed anyway. There is no real reason not to support both
versions.
A bug which, IMO, should not be RC right now, but switching libssl-dev to
provide libssl1.1 *now* will probably hide crashes in the case I described
above.

So yes, I agree with you, I just don't agree this is the right time. Doing it
as soon as the buster release cycle starts it's just fine.
Post by Bernd Zeimetz
Post by Lisandro Damián Nicanor Pérez Meyer
That means we left the door open to crashes due to mixed libssl versions.
By letting libssl-dev provide libssl1.0 we do not open this door, and we let
maintainers decide on a per-basis case.
And we have to maintain two openssl versions trough the release cycle.
For stretch we will already have, except we delay the release by ~1 year.
Which again, if it's deemed necessary, then we should consider it.
--
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Jan Niehusmann
2016-11-15 14:26:05 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
[snip]
Post by Jan Niehusmann
(It's fine if packages which depend on libssl-dev get an RC-bug if they
can't be compiled with OpenSSL 1.1. Packages which can't be ported
should explicitly depend on libssl1.0-dev. That way we'll make progress
towards a point where we can start a smooth transition.)
I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev
means that some apps/libs will get automatically recompiled and some of them
might even not FTBFS (because for example, they are ready to use 1.1).
That means we left the door open to crashes due to mixed libssl versions.
I probably didn't state that clear enough: I don't think libssl-dev
should provide libssl1.1-dev.

But building packages - purely for testing purposes - against
libssl1.1-dev and reporting any issues is a good thing, and I even think
such bugs could be marked RC, to make sure we make progress.

At the same time, I don't want to remove packages which can't be ported
quickly. Therefore, either these bugs can't be RC, or there must be an
easy way for maintainers to opt out. One way of such an opt-out would be
changing the dependency to libssl1.0-dev.

However, the quoted paragraph was meant as a side-note only. It's not
important, at the moment.


The one thing we should decide *quickly* is if we want to revert
libssl-dev back to 1.0, or if we want to delay the freeze by several
months.
Post by Lisandro Damián Nicanor Pérez Meyer
By letting libssl-dev provide libssl1.0 we do not open this door, and we let
maintainers decide on a per-basis case.
Yes, and we avoid cases like with libcurl3, where the recompile to
libssl1.1 broke ABI compatibility of libcurl3 without notice.

Jan
Russ Allbery
2016-11-14 16:39:18 UTC
Permalink
Post by Ondřej Surý
And this is happening all over places (apache2 vs php7.0) - I don't
think we can have a partial transition. It's now all or nothing.
xml-security-c has not yet been ported to OpenSSL 1.1 upstream (which is
non-trivial), and we're now at an impasse in the Shibboleth suite because
cURL is using 1.1, but xml-security-c and Apache both need 1.0.

I agree with Ondřej: the current transition state is not releasable. We
need to figure out something else.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Dimitri John Ledkov
2016-11-14 17:35:52 UTC
Permalink
There is a large number of packages currently build-depending on
openssl 1.0 explicitly.
Supporting dual-stack 1.0 & 1.1 openssl is a lot of work.
In Ubuntu, I have reverted the 1.1 migration, and forced 1.0 to be
used and provided by both libssl-dev & libssl1.0-dev packages.
This was done after a consensus consultation with some of the ubuntu
developers, archive admins, and security team.
If the transition in Debian goes really well, I see Ubuntu picking it
up for 17.10. Realistically, I see it for the 18.04 LTS cycle.
--
Regards,

Dimitri.
Ian Jackson
2016-11-15 15:54:00 UTC
Permalink
Lots of people have posted in this thread that they see problems with
our current approach to the openssl transition.

Do the openssl maintainers have an response ?

Thanks,
Ian.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Daniel Pocock
2016-11-15 16:42:59 UTC
Permalink
Post by Ian Jackson
Lots of people have posted in this thread that they see problems with
our current approach to the openssl transition.
Do the openssl maintainers have an response ?
I just started looking at this thread 2 minutes ago. I really don't
know where to start.

Would the OpenSSL maintainers and/or release managers consider making a
wiki page about the transition with the most common questions about it,
similar to the upstream wiki but with a Debian focus?

The questions which come to my mind (and may already be answered):

- will it definitely go ahead for stretch?

- will the stretch freeze and release dates be delayed to allow people
to catch up?

- is it expected that package maintainers spend time patching for this,
or we can wait for upstreams to support it?

- given the huge number of packages listed on the transition page, I
couldn't help feeling that it would be useful to be able to get some
reports about how many packages have now had a bug forwarded upstream,
how many upstreams have released a newer version with the fix, how many
upstreams have a fix that is not released, etc

Wearing my upstream hat, I do hope to ensure my own packages support it
sooner rather than later. Some of them will go into NEW though because
they have ABI or API version numbers in the binary package names, so
they won't be available immediately.

Regards,

Daniel
Sebastian Andrzej Siewior
2016-11-15 23:01:06 UTC
Permalink
Post by Daniel Pocock
Would the OpenSSL maintainers and/or release managers consider making a
wiki page about the transition with the most common questions about it,
similar to the upstream wiki but with a Debian focus?
I started one at
https://wiki.debian.org/OpenSSL-1.1
Post by Daniel Pocock
- will it definitely go ahead for stretch?
- will the stretch freeze and release dates be delayed to allow people
to catch up?
- is it expected that package maintainers spend time patching for this,
or we can wait for upstreams to support it?
I can't answer those. I just copied them into the Wiki hoping someone
will.
Post by Daniel Pocock
- given the huge number of packages listed on the transition page, I
couldn't help feeling that it would be useful to be able to get some
reports about how many packages have now had a bug forwarded upstream,
how many upstreams have released a newer version with the fix, how many
upstreams have a fix that is not released, etc
I added to the wiki a few links:
- my ben page. Similar to release team's page but it shows which package
moved to 1.0 and which more towards 1.1. (updated ~17.15 UTC).

- BTS user tags bugs. All bugs reported by Kurt and myself were user
tagged.
Post by Daniel Pocock
Regards,
Daniel
Sebastian
Jonas Smedegaard
2016-11-16 00:50:03 UTC
Permalink
Quoting Sebastian Andrzej Siewior (2016-11-16 00:01:06)
Post by Sebastian Andrzej Siewior
Post by Daniel Pocock
Would the OpenSSL maintainers and/or release managers consider
making a wiki page about the transition with the most common
questions about it, similar to the upstream wiki but with a Debian
focus?
I started one at
https://wiki.debian.org/OpenSSL-1.1
Great!
Post by Sebastian Andrzej Siewior
Post by Daniel Pocock
- will it definitely go ahead for stretch?
- will the stretch freeze and release dates be delayed to allow
people to catch up?
- is it expected that package maintainers spend time patching for
this, or we can wait for upstreams to support it?
[...]
Post by Sebastian Andrzej Siewior
- BTS user tags bugs. All bugs reported by Kurt and myself were user
tagged.
- will those user-tagged bugs properly track all related issues too?

As an example, Bug#828590 for uwsgi is currently being addressed. When
I can hopefully upload that package tomorrow, the package evidently no
longer fails to build from source and the FTBFS bug can therefore be
closed. But at the same time other bugs - less severe, but directly
caused by the conflicting libssl libraries - will emerge¹. I can try to
treat such collateral issues as related - e.g. by cloning and adapting,
and/or by keeping open the original bug and renaming it, and maybe by
user-tagging (if someone documents what tagging is suitable - I sure
don't want to make things worse by sloppy bug tagging). But it seems to
me that there is a real risk that some of the bugs tracked in above wiki
page may miss out on some similar collateral problems in other packages.

- Jonas

¹ uwsgi build-depends not only on libssl-dev, but also libapache-dev,
php-dev and libcurl4-openssl-dev now linking against conflicting
libssl*-dev packages.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Daniel Pocock
2016-11-16 07:13:21 UTC
Permalink
Post by Sebastian Andrzej Siewior
Post by Daniel Pocock
Would the OpenSSL maintainers and/or release managers consider making a
wiki page about the transition with the most common questions about it,
similar to the upstream wiki but with a Debian focus?
I started one at
https://wiki.debian.org/OpenSSL-1.1
Great, thanks for doing that, I dropped in a couple of additional
questions (testing upstream builds with travis-ci, testing on jessie)
Ian Jackson
2016-11-16 12:26:55 UTC
Permalink
Post by Ian Jackson
Lots of people have posted in this thread that they see problems with
our current approach to the openssl transition.
Do the openssl maintainers have an response ?
I count the following people who expressed concern[1] about this some
time before the 11th of November (last activity from an openssl
maintainer):

Lisandro Damin Nicanor Prez Meyer
Ian Jackson
Pau Garcia i Quiles
Colin Tuckley
Jan Niehusmann

On the 11th Kurt replied, but only to a specific technical aspect of
Jan Niehusmann's message. (On the 10th there was a second openssl
revision upload.) It seems to me that there has been no real answer
to most of those comments, and ample time to do so.

Since then I additionally count the following people who have
expressed concern[1]:

Jan Wagner
Ondřej Surý
Adam Borowski
Russ Allbery
Dimitri John Ledkov
Jan Niehusmann
Adrian Bunk
Scott Leggett

I appreciate that not everyone can be available all of the time, but
a maintainer has a choice of when to initiate a transition and should
arrange to do so at a time when they can be available in a timely
manner to help steward their transition.

A maintainer should be ready to explain, and if necessary change,
decisions they have taken. (Ideally wider consultation before taking
such a decision would be better.)

In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.

If we are going to wind back on this change we should do it ASAP. We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.

If we decide to wind back the transition and the openssl maintainers
continue not to be available (within the short timeframes required),
we have a lot of people who could competently prepare an NMU.

Thanks,
Ian.

[1] I have had to make some judgements about the implications in
people's mails. "Expresse concern" for me includes suggestions that
the current situation would need a substantial slip to the release.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Pau Garcia i Quiles
2016-11-16 12:58:12 UTC
Permalink
On Wed, Nov 16, 2016 at 1:26 PM, Ian Jackson
Post by Ian Jackson
A maintainer should be ready to explain, and if necessary change,
decisions they have taken. (Ideally wider consultation before taking
such a decision would be better.)
In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.
If we are going to wind back on this change we should do it ASAP. We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.
If we decide to wind back the transition and the openssl maintainers
continue not to be available (within the short timeframes required),
we have a lot of people who could competently prepare an NMU.
From a project management point of view, I can see three alternatives
OpenSSL 1.0 only
=============

* All packages work fine
* No release delays
* We will be using an LTS version of OpenSSL
* Some obscure feature (e. g. BlaBla20) may be missing or be difficult
to support on a limited number of packages (e. g. apache2)


OpenSSL 1.1 only
=============

* Many packages do not support OpenSSL in upstream, therefore they
need patching from Debian maintainer (security risk). Some packages do
not have a maintainer volunteer that can provide this patch.
* Release delay between 6-12 months seems certain
* We will be using version of OpenSSL with support end date before
Stretch's support end date
* We will be providing all new features that come with OpenSSL


OpenSSL 1.0 + 1.1
==============

* Every package will be buildable but we can expect surprises on
runtime due to dlopen'ed libraries, indirect use, etc
* Release delay seems certain but difficult to determine
* Even with a release delay, we cannot be 100% sure all the rutnime
surprises will be gone
* We need to support 2 versions of OpenSSL and be prepared for
third-party applications (not included with Debian) to fail due to
runtime surprises
* Different support cycles upstream (one LTSL, one not)
* We will be providing both versions of OpenSSL for the end-user to
choose (when he has the knowledge)


If I were in charge of taking this decision:

* OpenSSL 1.0 + 1.1 would be out. It's the worst possible scenario:
even with a delay, I can expect problems
* OpenSSL 1.1 will delay the release and/or leave a lot of packages out
* OpenSSL 1.0 makes possible to release as planned and provides an LTS
release. The minor inconveniences for missing ciphers, etc do not
justify the negative impact of the other choices, IMO.

So I would release Stretch with OpenSSL 1.0 only, and then make a plan:
1. OpenSSL 1.1 is gone from sid effective immediately and move to experimental
2. On April 1st 2017 we replace OpenSSL 1.0 with OpenSSL 1.1 in sid.
All packages are expected to support OpenSSL 1.1 only by this date.
3. Stabilize and aim for a quick Debian release 1 year after Stretch.
Yes, that means 2 Debian versions supported for some time.

Of course, that's just my suggestion. Feel free to disagree.
--
Pau Garcia i Quiles
http://www.elpauer.org
Pau Garcia i Quiles
2016-11-16 13:26:53 UTC
Permalink
On Wed, Nov 16, 2016 at 1:58 PM, Pau Garcia i Quiles
<***@elpauer.org> wrote:

[...]
Post by Pau Garcia i Quiles
OpenSSL 1.0 only
=============
[...]
Post by Pau Garcia i Quiles
* Some obscure feature (e. g. BlaBla20) may be missing or be difficult
to support on a limited number of packages (e. g. apache2)
[...]

Sorry, it's ChaCha20, not BlaBla20. My bad.
--
Pau Garcia i Quiles
http://www.elpauer.org
Marco d'Itri
2016-11-16 13:31:28 UTC
Permalink
Post by Pau Garcia i Quiles
* Some obscure feature (e. g. BlaBla20) may be missing or be difficult
to support on a limited number of packages (e. g. apache2)
ChaCha20 is hardly obscure: if it is to you then I fear that your
opinion on this issue is not informed enough to be useful.
--
ciao,
Marco
Stephan Seitz
2016-11-16 13:46:47 UTC
Permalink
Post by Marco d'Itri
ChaCha20 is hardly obscure: if it is to you then I fear that your
opinion on this issue is not informed enough to be useful.
It doesn’t matter in the end.

If no one wants to delay the next release until all applications support
OpenSSL 1.1.0 in a secure way even is upstream may not be interested in
patching the software for now then we can’t have version 1.1.0.

And there is still the problem that 1.1.0 is not supported as long as the
available LTS version.

Many greetings,

Stephan
--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Moritz Mühlenhoff
2016-11-16 15:05:25 UTC
Permalink
Post by Stephan Seitz
And there is still the problem that 1.1.0 is not supported as long as the
available LTS version.
That's not a decisive factor, Debian security support has been extended
over the upstream support time frame many times before.

Cheers,
Moritz
Bernd Zeimetz
2016-11-17 21:32:34 UTC
Permalink
Hi,
Post by Pau Garcia i Quiles
OpenSSL 1.0 + 1.1
==============
* Every package will be buildable but we can expect surprises on
runtime due to dlopen'ed libraries, indirect use, etc
* Release delay seems certain but difficult to determine
* Even with a release delay, we cannot be 100% sure all the rutnime
surprises will be gone
* We need to support 2 versions of OpenSSL and be prepared for
third-party applications (not included with Debian) to fail due to
runtime surprises
* Different support cycles upstream (one LTSL, one not)
* We will be providing both versions of OpenSSL for the end-user to
choose (when he has the knowledge)
I think releasing with 1.0+1.1 makes sense, but without forcing 1.1 to
be the default. Single packages which support 1.1 very well should be
able to use it, but maintainers should not be forced to even try to
migrate to a new version.

This would even make it possible to backport packages to support the new
OpenSSL version. Maybe even apache2. In the meantime people could use
haproxy in front of it, or whatever else they like.

Having ChaCha20 is nice, but delaying a release for it is not an option
(hint: people won't be able to use ChaCha20 while they are waiting for a
release... :))


best regards,

Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Ian Jackson
2016-11-16 15:49:32 UTC
Permalink
Post by Ian Jackson
Post by Ian Jackson
Lots of people have posted in this thread that they see problems with
our current approach to the openssl transition.
Do the openssl maintainers have an response ?
...
Post by Ian Jackson
In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.
I tried to find previous opinions of the release team by reading the
transition bug #827061.

I was not able to find the message where the release team gave
permission for the upload of openssl 1.1.x (in particular, the new
version of libssl-dev) to unstable, that started the transition. Can
someone point me to the formal instruction to upload to unstable ? Or
was permission granted by irc or something ?

The most recent message I can find from a release team member in that
bug report is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061#944
That does seem to suggest that in late October the release team had
more or less decided to go ahead.

Reading that bug I think it's a shame that we didn't manage to
effectively identify the issues we've now discussed here on -devel
earlier, despite Kurt's several messages to d-d-a.

Ian.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Carsten Leonhardt
2016-11-16 16:05:44 UTC
Permalink
Post by Ian Jackson
Reading that bug I think it's a shame that we didn't manage to
effectively identify the issues we've now discussed here on -devel
earlier, despite Kurt's several messages to d-d-a.
Concerns were already raised in June, in the subthread starting here:
https://lists.debian.org/debian-devel/2016/06/msg00501.html but they
were not responded to.

- Carsten
Niels Thykier
2016-11-16 17:50:00 UTC
Permalink
Post by Ian Jackson
[...]
I was not able to find the message where the release team gave
permission for the upload of openssl 1.1.x (in particular, the new
version of libssl-dev) to unstable, that started the transition. [...]
[...]
Ian.
Kurt received acknowledgement from the release team before uploading
ssl1.1 as the default.

~Niels
Jonathan Wiltshire
2016-11-16 16:03:04 UTC
Permalink
Post by Ian Jackson
In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.
If we are going to wind back on this change we should do it ASAP. We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.
Indeed it's been under discussion for the past week or so independent of
the thread on -devel. I hope you'll forgive me for not breaking
confidences just yet, but we expect to be able to resolve this very
soon.
--
Jonathan Wiltshire ***@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits
Ian Jackson
2016-11-16 17:14:11 UTC
Permalink
Post by Jonathan Wiltshire
Post by Ian Jackson
If we are going to wind back on this change we should do it ASAP. We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.
Indeed it's been under discussion for the past week or so independent of
the thread on -devel. I hope you'll forgive me for not breaking
confidences just yet, but we expect to be able to resolve this very
soon.
Excellent, I'm glad to hear that you're discussing it.

Ian.
--
Ian Jackson <***@chiark.greenend.org.uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Sebastian Andrzej Siewior
2016-11-16 21:57:55 UTC
Permalink
Post by Ian Jackson
If we decide to wind back the transition and the openssl maintainers
continue not to be available (within the short timeframes required),
we have a lot of people who could competently prepare an NMU.
NMU openssl back to 1.0.2 or its rdeps to libssl1.0?
Kurt and myself tried to help everyone who asked for help with porting.
Kurt reviewed several patches of people which tried to update 1.1.0.
Post by Ian Jackson
Thanks,
Ian.
Sebastian
Loading...