[MIR] Promote ruby-json to main as a pcs dependency
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ruby-json (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
[Availability]
The package ruby-json is already in Ubuntu universe.
The package ruby-json build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x.
Link to package [[https:/
[Rationale]
ruby-json promotion to main is needed because of the
[[https:/
Ideally, we expect that ruby-json (and pcs) will be promoted in the "L" development cycle. The idea is to promote only the ruby-json binary.
[Security]
Required links:
https:/
I looked for "json gem" which brings some unrelated CVEs but also two that are associated to this package, they are: CVE-2020-10663 and CVE-2013-0269.
https:/
In the OSS security mailing list I found only an email thread about
CVE-2013-0269 already mentioned above.
https:/
And in the Ubuntu security tracker only 2 CVEs, both of medium priority, and they seem to not be affecting the package in Ubuntu.
This is a ruby library which does not provide any executable, nor systemd files.
[Quality assurance - function/usage]
The package works well right after install.
[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and has not too many and long
term critical bugs open:
- Ubuntu: https:/
- Debian: https:/
The package does not deal with exotic hardware we cannot support.
[Quality assurance - testing]
The package runs a test suite on build time, if it fails
it makes the build fail, link to build log:
The package runs an autopkgtest, and is currently passing on this list of
architectures: amd64, arm64, armhf, i386, ppc64el, s390x.
Link to test logs: https:/
The package does have not failing autopkgtests right now.
[Quality assurance - packaging]
debian/watch is present and works.
debian/control defines a correct Maintainer field.
Lintian overrides are not present. Here is the output of `lintian --pedantic` against Kinetic version:
P: ruby-json source: update-
P: ruby-json source: very-long-
This package does not rely on obsolete or about to be demoted packages.
The package will not be installed by default.
Packaging and build is easy, link to d/rules:
https:/
[UI standards]
Application is not end-user facing (does not need translation).
[Dependencies]
No further depends or recommends dependencies that are not yet in main. This is for the ruby-json binary.
[Standards compliance]
This package correctly follows FHS and Debian Policy.
[Maintenance/Owner]
The Server team is not yet, but will subscribe to the package before promotion.
This does not use static builds.
This does not use vendored code.
This package is not rust based.
The package successfully built during the most recent test rebuild.
[Background information]
The Package description explains the package well.
Upstream Name is: json
Link to upstream project: https:/
Related branches
- Christian Ehrhardt : Approve
- Athos Ribeiro: Approve
- Canonical Server Reporter: Pending requested
-
Diff: 61 lines (+17/-0)1 file modifiedsubscriptions.yaml (+17/-0)
CVE References
description: | updated |
Changed in ruby-json (Ubuntu): | |
assignee: | nobody → Christian Ehrhardt (paelzer) |
tags: | added: sec-1401 |
Changed in ruby-json (Ubuntu): | |
assignee: | Lucas Kanashiro (lucaskanashiro) → nobody |
status: | Incomplete → Invalid |
Review for Package: ruby-json
[Summary]
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, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: ruby-json
Specific binary packages built, but NOT to be promoted to main: <none>
Note:
This was already in main in Trusty and before. So I expect no major
showtoppers now since it was not unmaintained since then.
Required TODOs:
- Update to 2.6.2 as the package wasn't updated in a while
[Duplication] /github. com/intridea/ multi_json to exist.
OK:
There is no other package in main providing the same functionality.
There seems to be enough developer debate which json lib to pick for
something like https:/
But even they state that the one we review here is "The default JSON gem"
and that it is the one shipping with later ruby versions.
So I guess we are ok to promote this one over alternatives.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- 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
- 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 system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)
Problems:
- does not parse data formats (files [images, video, audio,
xml, json, asn.1], network packets, structures, ...) from
an untrusted source.
- While not concerning there have been CVEs (just what you expect with parsers
of any content). Of them CVE-2013-0269 was fixed long agoi, but CVE-2020-10663
isn't mentioned anywhere - I checked the fix for ruby 2.5 and that change is
present, so it isn't an open case. But still things can happen, so it seems
worth to do a security evaluation as well.
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- no special HW needed for testing
- no new python2 dependency
Problems:
- does not have a non-trivial test suite that runs as autopkgtest
While it would be nice, for the purpose of this SW I do not consider
this critical
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far
...