Public bug reported: [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 the nodejs core element that can/could be used for much more than just the mailman3 stack.
For the mailman stack we'd pull in most binaries, being libnode64, nodejs and nodejs-doc [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. I know this is dragging in a lot of components, but mailman3 was re-implmented using common frameworks and that meands django, node, ... [Security] This is one of the components of overall mailman3 stack that is not looking so good. We know of 7 CVEs of which only one is known fixed. The rest would need analysis and triage to be sure => https://people.canonical.com/~ubuntu-security/cve/pkg/nodejs.html When checking on Mitre the list is longer, but mapping to actual src packages can be hard: => http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nodejs I found no extra CVEs other than those tracked by the security Team that are really on src:nodejs For CVE-2019-1559 and CVE-2019-1543 we are safe due to a new openssl. CVE-2019-5737 was fixed in a recent upload that is synced to Debian. Therefore no open known issues left right now. But in general that package clearly has a higher exposure and therefore effort for the security Team once promoted. Therefore their ack is needed even more than usual. [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. 28 bugs in Ubuntu for this - the majority is the usual crap, but there are quite some SIGABRTs which reflects the effort we will have to maintain it once promoted to main. Another issue becoming clear on these reports is that the users often mix&match NPM with Archive versions and that is unsupported, but hard to debug and quite some effort. Also the number is that high because currently no team owns them, it seems many could be cleared (I did some now). Debian has 9 bugs open, mostly odd architecture FTBFS and a segfault that waits for more info - nothing critical we have to wait on. Upstream OTOH seems very active, there are 596 open and 8989 closed bugs. The package seems to get regular updates by upstream and Debian. No exotic HW involved. The package utilizes a lot build time self tests. In addition it has some (trivial) autopkgtests that would e.g. detect breakage by a main node.js upgrade. No Lintian warning except a few newer Standards/Compat versions and watch GPG checks - nothing severe. In addition there are a bunch of warnings about the js objects like P: nodejs source: insane-line-length-in-source-file test/fixtures/throws_error5.js line length is 516 characters (>512) P: nodejs source: source-contains-prebuilt-javascript-object test/fixtures/throws_error5.js line length is 516 characters (>512) But that is exactly what nodejs is about, I don#t think this is a problem. It also has W: nodejs source: patch-file-present-but-not-mentioned-in-series 2012_kfreebsd.patch but that isn't important for non BSD builds. The package does not rely on demoted or obsolete packages. No new gt2k dependencies [UI standards] It uses internationalization via ICU, it even has an own "intl" issue category upstream. 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 mostly meets the FHS and Debian Policy standards. Not really a policy violation but a usual MIR red flag is that bundles a lot of things, see deps/* and I think this will be a reason to nack it, but unfortunately also a huge effort to make it split. Even if split then maintenance effort will most likely rise a lot. Fortunately the config seems to disable most of these - see in d/rules setting configure to use --shared-* I checked and it seems it uses almost all from shared libs, the only one it does use the embedded is the v8 source. libnode-dev conflicts with libv8-dev so I guess the one thing it duplciates is the v8 in this package vs src:libv8-3.14 While not perfect it seems that is done for a reason, and that would mean especially the security Team would have two v8 implmentations to check. The packaging itself is complex as well, with many special cases. Nothing totally insane fortuantely, but more potential bits to understand when providing service. [Maintenance] The Server team will subscribe for the package for maintenance [Background] The package description explains the general purpose and context of the package well. ** Affects: nodejs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1820208 Title: [MIR] nodejs as dependency of mailman3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1820208/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
