[Bug 1822069] Re: SRU: Shibboleth SPv3 for bionic
Etienne Dysli Metref
1822069 at bugs.launchpad.net
Tue Apr 16 11:28:58 UTC 2019
On 16/04/2019 11.31, Robie Basak wrote:
>> Can you explain how the new soname is a problem? I think it
>> clearly separates the new and old libraries.
>
> We can't delete the old library from Bionic, so the new and old must
> exist concurrently. Therefore you can't just upload a replacement
> source package, because that would make a security fix or regular
> update for the old library impossible[1]. We call this situation
> "NBS", or "not built from any source". You'll need to create a new
> parallel source package with a different name (for example with a
> version number in it), so that's another whole bunch of renaming.
Ah I see now, thanks. Short of forcing every Bionic user to upgrade to
the new libraries and removing the old ones from the archive, that's an
untenable position.
> The effort really needed to have been spent while Bionic was in
> development. That would have been at least an order of magnitude
> less effort.
Yes, removing Shibboleth packages from Bionic would have been better.
Absent packages don't block backports. ;)
> I honestly think that it would be more beneficial to spend that
> effort on future development (both upstream and in distributions)
> and maintain an out-of-archive backport for Bionic users, than spend
> this disproportionate amount of effort on updating Bionic now.
Agreed. I'm already maintaining the out-of-archive backports, but I'd
like to streamline it more so it feels like using [LTS]-backports (no
special versions like ...-1switchaai1~bionic1, for example).
In the Shibboleth case, I know that upstream is contemplating packaging
for Debian and Ubuntu, but their support policy of "only the latest
version is supported" is really at odds with the current policy of both
Linux distributions.
> For example, you could add dep8 tests which would automatically block
> package updates in Ubuntu unless they pass, preventing the release of
> broken Shibboleth packages from happening again.
Thanks for the idea! I'll look into that.
> Packages are team maintained. Like Debian, use (and choice) of a VCS
> is a team decision, and the archive itself is the single source of
> truth. The default is none. As there isn't a Shibboleth team in
> Ubuntu at the moment, you are welcome to form one, create a VCS
> somewhere (though not using Launchpad or Salsa would be swimming
> against the tide for Ubuntu developers), and ask that others use it.
> In the absence of a specific team, these packages currently fall
> under the remit of the MOTU team, but I'm not aware that anyone from
> MOTU has ever worked on them, so I don't think there would be any
> conflict there.
IMHO, ideally, the Shibboleth packaging repositories over on salsa.d.o
[1] should be the reference also for Ubuntu packaging. I can create an
ubuntu/ branch namespace there for this purpose, as per DEP-14. If I
understand you correctly, creating a team on LP would be enough to
"claim" ownership of these packages, though not enough to force others
to use salsa before uploading to Ubuntu.
I'll go ahead and create a team on LP as that seems to be a step in the
right direction. Then I'll try to reflect the current state of Ubuntu
packages in the Git repositories on salsa under ubuntu/ (changelog,
patches, etc.) so that all of this can be unified. I'd still need
sponsorship to upload though, but that can be sorted later.
Cheers,
Etienne
[1] https://salsa.debian.org/shib-team
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1822069
Title:
SRU: Shibboleth SPv3 for bionic
Status in log4shib package in Ubuntu:
New
Status in opensaml package in Ubuntu:
New
Status in opensaml2 package in Ubuntu:
New
Status in shibboleth-resolver package in Ubuntu:
New
Status in shibboleth-sp package in Ubuntu:
New
Status in shibboleth-sp2 package in Ubuntu:
New
Status in xml-security-c package in Ubuntu:
New
Status in xmltooling package in Ubuntu:
New
Status in log4shib source package in Bionic:
New
Status in opensaml source package in Bionic:
New
Status in opensaml2 source package in Bionic:
New
Status in shibboleth-resolver source package in Bionic:
New
Status in shibboleth-sp source package in Bionic:
New
Status in shibboleth-sp2 source package in Bionic:
New
Status in xml-security-c source package in Bionic:
New
Status in xmltooling source package in Bionic:
New
Status in log4shib source package in Cosmic:
New
Status in opensaml source package in Cosmic:
New
Status in opensaml2 source package in Cosmic:
New
Status in shibboleth-resolver source package in Cosmic:
New
Status in shibboleth-sp source package in Cosmic:
New
Status in shibboleth-sp2 source package in Cosmic:
New
Status in xml-security-c source package in Cosmic:
New
Status in xmltooling source package in Cosmic:
New
Bug description:
[Impact]
Bionic released with version 2 of the Shibboleth Service Provider (and
its accompanying dependencies) and with OpenSSL 1.1. However, the SPv2
isn't compatible with OpenSSL 1.1, only 1.0 (and earlier), and was
therefore shipped compiled against 1.0. This created a mix of OpenSSL
and libcurl versions between the Apache module that the Shibboleth SP
provides (mod_shib) and other modules, thus rendering mod_shib
uninstallable alongside other modules (that depend on libcurl4)
because of that conflict. Not being able to use mod_shib and mod_php
with php-curl -- for example -- together greatly reduces the
usefulness of the Shibboleth SPv2 in bionic, see LP#1776489. Version 3
of the Shibboleth SP is compatible with OpenSSL 1.1 and having it
available for bionic would allow users to install it together with
other Apache modules.
Moreover, the SPv2 suffers from a few security issues (LP#1636590)
which have since been fixed upstream and v2 is no longer supported
upstream (EOL, LP#1812401).
I propose to update the following source packages in bionic:
- shibboleth-sp [not in Bionic] to 3.0.4 (sync request for disco LP#1822055)
- opensaml [not in Bionic] to 3.0.1 (sync request for disco LP#1823325)
- xmltooling from 1.6.4-1ubuntu2.1 [Cosmic 3.0.2-1ubuntu1.1] to 3.0.4
- xml-security-c from 1.7.3-4ubuntu0.1 [Cosmic 2.0.1-1] to 2.0.2
- log4shib from 1.0.9-3 to 2.0.0
- shibboleth-resolver from 1.0.0-1build4 to 3.0.0
[Test Case]
# apt install apache2 libapache2-mod-shib2
[...]
# apt install libapache2-mod-php php-curl
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
php-curl : Depends: php7.2-curl but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
# apt install php7.2-curl
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
php7.2-curl : Depends: libcurl4 (>= 7.44.0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
# apt install libcurl4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
libcurl3-gnutls libfcgi-bin libfcgi0ldbl liblog4shib1v5 libltdl7 libmemcached11 libodbc1 libssl1.0.0 libxerces-c3.2 libxml-security-c17v5 opensaml2-schemas shibboleth-sp2-common xmltooling-schemas
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
libapache2-mod-shib2 libcurl3 libsaml9 libshibsp-plugins libshibsp7 libxmltooling7 shibboleth-sp2-utils
The following NEW packages will be installed:
libcurl4
0 upgraded, 1 newly installed, 7 to remove and 0 not upgraded.
Need to get 214 kB of archives.
After this operation, 18.7 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
[Regression Potential]
A new version can, of course, bring new bugs and security vulnerabilities. Catching up to SPv3 would at least give us an upstream-supported version. Shibboleth SP 3.0.4 and its dependencies are, as of this writing, all in Debian testing without any major bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/log4shib/+bug/1822069/+subscriptions
More information about the Ubuntu-sponsors
mailing list