© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
Review for Package: duktape
[Summary]
My answer was first a NACK:
"""
An alternative is in main (more details in the section [Duplication]. Instead just add a delta to continue to use mozjs please. If you want to challenge that decision, then please make a clear argument why, as long as we have to maintain mozjs anyway for other things, staying on mozjs isn't sufficient.
"""
But on discussion and later comments it became clear that this isn't a blocker despite that.
So instead the verdict is now:
MIR team ACK under the constraint to resolve the below listed required TODOs and as much as
possible having a look at the recommended TODOs.
This does need a security review, but since - for now - this is a NACK anyway
I'll not yet assign ubuntu-security.
List of specific binary packages to be promoted to main: duktape, libduktape207, duktape-dev
Required TODOs:
- Until upstream resolved 2523 auto-generating the matching test sources and
add it to the package - might be in d/t/* or in the original place out of
a multi-tarball upload. Either way then please - it is ok if build time tests
might still be impossible, but for something as complex as a JS engine they
need to be added as autopkgtest. Otherwise I'm afraid we might too often
break them without noticing it for quite some time.
Recommended TODOs:
- could you please have a retry if adding back the creation of building
debug symbols might work nowadays? It will help supporting the package.
If it does still not work, fine, but at least leave comment on the bug what
the remaining issue is so it can be revisited in the future.
- Could we have a timeline and maybe a bug/ML reference for "duktape is a much
smaller JavaScript implementation and simpler code-base to maintain than
mozjs, and Debian is going to use it." ?
[Duplication]
Duktape is explicitly picked for smaller size and better maintainability.
There are various others, depending on the language of choice like
libjavascriptco
golang-
And more like quickjs and elk which are meant to be small (like duktape),
but are not packaged. So ok, of all the alternatives duktape is fine.
But then - as outlined in the report - there is mozjs. I can follow the argument
of "simpler code-base to maintain", but unless we get rid of mozjs it means
we end up with a big and a small codebase. So this makes the overall effort
worse right?
And mozjs is already in main since a long time (search for spidermonkey,
that works better). AFAICS [1] polikit still works with both and [2] many other
things hold mozjs in main. So for Ubuntu it would be better to fully support
one (=mozjs) and carry a delta to use that instead of duktape.
[1]: https:/
[2]: https:/
=> There is annother package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this (just depends on libc)
- no -dev/-debug/-doc packages that need exclusion
duktape-dev has no concerning dependencies
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
Problems: None
[Security]
OK:
- history of CVEs does not look concerning
There was one case, but it was resolved and is in all new versions
since jammy. Yet the triage of the CVE is still open.
https:/
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)
Problems:
- does deal with system authentication (eg, pam), etc)
- does parse data formats
It does parse code. While the intended use case right now (policykit) can be
considered trusted data I still think this needs a security review. On one
hand dak might be used in other less trusted situations, and on the other
hand attacking policykit (which will use dak) is a high value target.
[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- Go package, but using dh-golang
Problems:
- does not have a test suite that runs at build time
- does have a non-trivial test suite that runs as autopkgtest
=> This was already brought up in when filing the case and Amin (thanks!)
already worked out a rough test plan using that.
Looking forward having the tests run at build time when issue 2523
is completed is fine, but I wonder if we should not feel blocked on that.
This is code from the same repository, same license, ...
Until Upstream (and they might very well say they never will) release
tarballs with it we can still solve it on our side.
How about adding a step to d/rules to generate a matching test-tarball
which could then either be used as multi-tarball source or just unpacked and
updated each version into debian/tests/...
These tests should pass, which also means they have to be updated to work
with python3 I guess. I know it is a lot of work but for something as
complex as a javascript engine, I'd really think we can not promote it
without tests. So I'm asking to do the work to make it run as autopkgtest.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package (usually is a sync so far)
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list
Problems:
- Upstream update history is a bit slow, two release in 3.5 years. But
in my check for alternatives I've found many others, but none that would
be an obvious better choice to suggest
- The disabling of ddebs is rather critical for support to have a chance
at debugging. This is thre since 2017, we should have a look at
re-enabling this. Could you please try to have a look as part of this
MIR process?
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
tests)
- no use of user nobody
- no use of setuid
- use of setuid, but ok because TBD (prefer systemd to set those
for services)
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (either embedded
or experienced user usage)
Problems: None