[MIR] libpgm as dependency of mailman3

Bug #1820203 reported by Christian Ehrhardt 
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libpgm (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

[Availability]
The package is already universe for quite a while and build/works fine so far.
It is for example already used for https://lists.canonical.com/mailman3/postorius/lists/
OTOH it is a library that can/could be used for much more than just the mailman3 stack.

It builds on all architectures (arch:any)

[Security]

No known CVEs found.
The protocol had some issues a few years ago and related issues in Cisco/Microsoft products, but I found no open issues in the package.
=> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pgm

[Quality assurance]

As part of the mailman3 stacks as of now (Disco) this installs fine and works fine.
On itself it is useful to (many) other dependencies and does not need a post install configuration on its own.

The package does not ask debconf questions.

One known bug in each of Ubuntu and Debian.
- The Ubunut bug is outdated and should be ok with 5.2 which we have.
- The Debian bug is only important for solaris builds
Upstream has 16 open and 27 closed issues - nothing very severe for our intentions.

The package seems get updates by Debian as needed.
But upstream seems to have stopped releasing after 2012.
=> https://github.com/steve-o/openpgm/releases
After talking with one of the uploaders it became clear that they still work on master and fixes can be pulled from there as needed.
https://github.com/steve-o/openpgm/commits/master

No exotic HW involved.

There are some tests in ./openpgm/pgm/test/ and ./openpgm/pgm/*_unittest.c but dh_auto_test isn't catching them.
OTOH I can't even guarantee they would be usable, but TL;DR no build time tests run.

d/watch is set up and ok.

gNo Lintian warning except newer Standards/Compat versions and no HTTPS links uses or GPG checks - nothing severe.

The package does not rely on demoted or obsolete packages.
The Scons build system is a pain, but it seems to work as packaged by Debian so no complains.
No new gt2k dependencies
As mentioned the package itself might be abandoned/orphaned by upstream

[UI standards]

It uses i18n from gi18n-lib to provide the infrastructure, but I found no translations so far.
But that is ok as this is a low level library without (a lot) of user visible strings - no translations (needed).
No End-user applications that needs a standard conformant desktop file.

[Dependencies]

Some dependencies are not in main, but we drive MIR for all related packages
that are not in main at the same time.
Please check the list of bugs from the main Mailman3 MIR in bug 1775427 to get an overview.

[Standards compliance]
The package meets the FHS and Debian Policy standards.
The packaging itself is very straight forward and uses dh_* as much as possible - the d/rules fits on one screen.

[Maintenance]

The Server team will subscribe for the package for maintenance, but in
general it seems low on updates and currently is a sync from Debian.

[Background]
The package description explains the general purpose and context of the package well.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

[Duplication]
No duplication of that functionality in the Archive in general or main in particular.

[Embedded sources and static linking]
This package does not contain embedded library sources.
This package does not statically link to libraries.
It does create static .a libs for its -dev package, but that is fine
No Go package

[Security]
I can confirm that there seems to be no CVE/Security history for this package.
It Does not:
- run a daemon as root
- uses old webkit
- uses lib*v8 directly
- open a port
- integrates arbitrary javascript into the desktop
- deals with system authentication
- uses centralized online accounts
- processes arbitrary web content

But it does
- parse data formats

Being a multicast protocol implementation in general it has to parse data that could have been remotely crafted.
A security review is therefore recommended.

[Common blockers]
- builds fine at the moment
- server Team committed to subscribe once this gets promoted (enough for now)
- code is not user visible, no translation needed

Not perfect but ok
- does not run build time tests (upstream source would have tests).

[Packaging red flags]
- no current ubuntu Delta to evaluate
- symbol tracking present in libpgm-5.2-0.symbols
- watch file is present
- Lintian warnings are present but ok
- debian/rules is rather clean
- no usage of Built-Using
- no golang package that would make things harder

[Upstream red flags]
- no suspicious errors during build
- no use of sudo, gksu
- no use of pkexec
- no use of LD_LIBRARY_PATH
- no important open bugs
- no Dependency on webkit, qtwebkit, libgoa-*
- no embedded copies in upstream either

Being written in C it obviously uses malloc and also non length limited (n) sprintf and such.
I have no good policy/tool to check if they are "incautious" as defined on https://wiki.ubuntu.com/MIRTeam#Upstream_red_flags
But I know that the security Team has such tools, so for that (as above for network related tasks) I'd recommend a security review on this package to be sure.

[Summary]
Ack from the MIR-Teams POV, but as outlined above a security review is recommended.
Assigning the security Team.

Changed in libpgm (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Revision history for this message
Seth Arnold (seth-arnold) wrote :
Changed in libpgm (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

After evaluating dependencies, required further changes and mostly maintainability for security and packaging it was decided there are too many concerns - not about any single package in particular, but the overall Mailman3 stack - about the ability to maintain and monitor it as well as we need it for support in main.

We have closed the primary LP bug already, the MIRs that are already approved will stay that way, but we will make no seed change to pull things in for now. Yet if other needs come up for those they have a prepared MIR already.
Other bugs - like this one - which are not yet completed in terms of review will be closed as Won't Fix.

Even thou it ended being aborted, I think that is a valid outcome of the MIR evaluations. Never the less I want to thank everybody involved for all the work spent in what was nearly a year working through these MIRs.

Changed in libpgm (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.