[MIR] norm as dependency of mailman3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
norm (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:/
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.
[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 Ubuntu or Debian bugs.
The project seems not to use a classic code/issue tracker
=> https:/
The package seems to get regular updates by upstream and Debian.
No exotic HW involved.
It seems upstream does not ship tests, so there is nothing to run at build time.
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.
A warning on prebuilt jar objects is slightly interesting.
The package does not rely on demoted or obsolete packages.
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.
Changed in norm (Ubuntu): | |
assignee: | Ubuntu Security Team (ubuntu-security) → nobody |
[Duplication]
No duplication of that functionality in the Archive in general or main in particular.
[Embedded sources and static linking]
This package does not statically link to libraries.
It does create static .a libs for its -dev package, but that is fine
A few "-Wl,-Bstatic" made me nervous at first, but that is how waf does "configure" and is safe.
No Go package
This package has some embedded code, but it seems ok to me. cs.itd. nrl.navy. mil/... /codesearch. debian. net/search? q=ProtoQueue% 3A%3AContainer% 3A%3AContainer
There is "protolib" which is a platform abstraction helper (it seems).
And that is not norm itself but an embedded source.
Throughout the Archive there seem to be only two (norm and mgen) users of that and no packaging of the lib as reusable artifact.
That other (mgen) is a product of the same source being http://
=> https:/
I think this is no reason to nack, but will check with other MIR team members first.
[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 (but there are no tests by upstream to run)
[Packaging red flags]
- no current ubuntu Delta to evaluate
- symbol tracking present in libnorm1.symbols
- watch file is present
- Lintian warnings are present but ok
- no usage of Built-Using
- no golang package that would make things harder
- debian/rules is not perfectly clean due to waf beign used as buld sytsem, but as clean as possible given the case.
[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. /wiki.ubuntu. com/MIRTeam# Upstream_ red_flags
I have no good policy/tool to check if they are "incautious" as defined on https:/
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.