[MIR] python-django-gravatar2 as dependency of mailman3

[Christian Ehrhardt ]

[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 amd64 only (arch:all)

This package builds python2 and python3 binaries, but the transition to mailman3 will only pull in the python3 binaries.

[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at bug 1775427:

Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.

The code in the src package seems not directly derived from mailman2 so it won't easen the review due to that.

[Security]

No known CVEs found.
Django in general has quite some hits, but this component seems not to be part of it.
=> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=django
Old now fixed CVE on this:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3995

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

Zero known bugs in Ubuntu and Debian for this component.
Upstream is less active with 2 open and 7 closed issues - nothing critical.

The package seems to get semi-regular updates by upstream and Debian.

No exotic HW involved.

The package utilizes no build time self tests, but at least it has a autopkgtest for some coverage.

d/watch is set up and ok.

No 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.
py2 packages in this src, but as mentioned we won't pull them into main.
No new gt2k dependencies

[UI standards]

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.

[Christian Ehrhardt  (paelzer)]

[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.
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
- uses centralized online accounts
- integrates arbitrary javascript into the desktop
- parse data formats

But it does:
- deals with system authentication
- processes arbitrary web content

This is the gravatar integration for django.
While it isn't the component that does the authnetication it is still tied into identity management in general.
Django after all is a web framework, and since this part deals with security sensitive details I think a security review should be done for this package.

[Common blockers]
- builds fine at the moment
- server Team committed to subscribe once this gets promoted (enough for now)
- code is not directly user visible (gravatar urls not the UI), no translation needed
- dh_python is used
- package produces python2 bits, but they are not pulled into main by mailman3
- utilizes (rather trivial) smoke test as autopkgtest.

Not perfect but ok
- utilizes no build time self tests

[Packaging red flags]
- no current ubuntu Delta to evaluate
- no library with classic symbol tracking
- 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 (a few warnings, but nothing concerning)
- it is pure python, so no incautious use of malloc/sprintf
- 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

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

[Mike Salvatore (mikesalvatore)]

I reviewed python-django-gravatar2 version 1.4.2-3 as checked into
disco. This should not be considered a full security audit, but rather a
quick gauge of maintainability.

- There are no prior CVEs against the package
- Build depends:
           debhelper (>= 11),
           dh-python,
           python-all,
           python-setuptools,
           python3-all,
           python3-setuptools

- does not daemonize
- no initscripts
- no dbus services
- no setuid files
- no sudo fragments
- no udev rules
- does not fork
- Test suite performs thorough testing. Some tests rely on internet
  access. These tests are NOT run during build.
- no cronjobs
- no logging (not applicable)
- This project has had no activity in the past 1.5 years.
- does not use WebKit
- does not use PolicyKit
- does not use Javascript
- no memory management concerns

The URL returned by gravatar_url() is escaped, whereas the URL returned
in gravatar_profile_url() is not. A pull request has been submitted
upstream to rectify this.
https://github.com/twaddington/django-gravatar/pull/29

Some functions are capable of raising exceptions but provide no
documentation or indication to the user that exceptions may be raised.
Exceptions should be caught by django and transformed into HTTP 500
errors, so no there is theoretically no harm.

ACK from the security team for promoting to main

[Christian Ehrhardt  (paelzer)]

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.