[Bug 1822069] Shibboleth package maintenance in Ubuntu [Was: SRU: Shibboleth SPv3 for bionic]

Tue Apr 16 12:06:39 UTC 2019

[moving this thread over to ubuntu-motu@ from
https://launchpad.net/bugs/1822069]

On Tue, Apr 16, 2019 at 11:28:58AM -0000, Etienne Dysli Metref wrote:
> 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.

That sounds great, and fits a common pattern used by other Ubuntu
development teams too.

When an Ubuntu delta exists, you can adjust Vcs-* in debian/control to
point to the correct place on Salsa to help other Ubuntu developers find
the correct VCS.

Note that Ubuntu developers may upload (to Ubuntu) without updating the
VCS first. This is rather like an NMU in Debian, but more common. For
example, in Ubuntu uploads needed for library transitions are generally
driven from the library provider end, rather than the library consumer
end, and so uploads relating to a transition may just "appear" in the
archive. If this happens, you'll need to pull in those uploads to your
VCS, as the archive remains the single source of truth.

However, if you're available and developers know to talk to you, they'll
try to avoid stepping on your toes as much as possible by communicating
first.

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

Right. There's no ownership claim as such; just an understanding that
your team is volunteering to generally look after the packages, and
others will try to work with you on that.

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

I suggest you announce your intentions to ubuntu-devel@ and
ubuntu-motu@, together with details on how to contact your team (perhaps
nominate ubuntu-motu@ for now, and subscribe).

In fact, we're quite far off topic on this bug now. I suggest we switch
to talking on ubuntu-motu@ instead. I'll Cc: that list now, and switch
the bug to Bcc:, to move this conversation over there.

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