Hello, the Ubuntu Security Team would like to propose the libopenscap8 binary
package from openscap be promoted to main.
libopenscap8 is useful in main for two reasons:
- The Security team publishes OVAL CVE data, which libopenscap8 is the only package in Ubuntu capable of evaluating this content. This allows users to check whether their system has all available security updates.
- The Certifications team publishes XCCDF+OVAL content for evaluating various benchmarks (such as CIS and STIG), which again libopenscap8 is the only such package satisfying this usecase in Ubuntu.
We'd like to first rebase to OpenSCAP 1.3.x, as this release will see upstream support longer into the future than the existing OpenSCAP 1.2.x release will. As OpenSCAP is a Red Hat upstream community, and OpenSCAP 1.2.x is shipped in RHEL 7 which is nearing EoL, they have stopped doing feature development work on OpenSCAP 1.2.x and focused on OpenSCAP 1.3.x (which is shipped in RHEL 8 and current Fedora versions). No later version exists at this time. This release is currently present in Debian Testing.
[Availability]
openscap is in universe.
[Rationale]
The Ubuntu Security & Compliance Team would like the libopenscap8 binary package from openscap promoted to main. libopenscap8 is referenced in our product documentation and several supported scenarios. Since some customers may not have ESM Apps (and thus LTS universe package support), shipping openscap in universe limits some customers from consuming Canonical-sponsored content, though they may pay for other content and reasonable expect the entire use-case be supported.
[Security]
As the intention is to use libopenscap8 in security software, it makes sense to require a security review. However, the package is intended to be executed by a local administrator (on content they trust) after using existing permission escalation procedures. libopenscap8 does not ship a daemon (or otherwise persist between runs), does not open any open ports, and does not add any other permission escalation paths (such as suid, sgid, &c).
[Quality Assurance]
- No configuration is necessary to use the library, though applications that use the library will provide content meant to be consumed via this library.
- grep -ri debconf returns no results.
- Upstream bug tracker has many open issues, some security relevant issues open for years.
- The Ubuntu bug tracker has very few open issues; the most important one is a segfault that has been ignored in Debian. The SRU appears stalled:
- https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1851682
However, this is addressed in the proposed OpenSCAP 1.3.x rebase.
- tests are not run (see debian/rules)
- debian/watch exists
- lintian messages:
E: openscap source: source-is-missing xsl/xccdf-resource/bootstrap.min.js
E: openscap source: source-is-missing xsl/xccdf-resources/openscap.js
line length is 263 characters (>256)
W: openscap source: python-foo-but-no-python3-foo python-openscap
(Note: lintian has not been re-run on the proposed OpenSCAP 1.3.x rebase)
[Dependencies]
All dependencies of the libopenscap8 library are in main. The source
package is less happy:
Build-Depends:
- dh-python
- python-defaults
- swig
[Standards compliance]
- I didn't spot FHS problems in the libopenscap8 binary package.
- Unknown Debian policy compliance.
- Quilt package
[Maintenance]
Security team is subscribed to bugs.
[Background information]
SCAP is an assertions language that is popular in the security communities for standardizing data streams. It can be used both for encoding information about vulnerable packages (as our OVAL data currently describes) as well as providing rules to measure compliance with published security standards.
Thanks!
Original author: Seth Arnold
Updated by: Alex Scheel
Revisited: 2021-06-02
FYI, snapcraft can build from universe just fine. I suspect what you are seeking is official support so openscap can get security support, therefore USNs, therefore cvescan can get snap USN notifications. In terms of an existing stable release, IIRC it is not possible to adjust the override for something in the release pocket, but that is ok: if this is approved then with the first upload to -security we can adjust the override for that source and binary (we could do the same for an SRU to -updates). In terms of the snap USN service, it doesn't care where the package resides; it just cares that there is a USN.
As for which release, cvescan could certainly be ported to 'base: core20', but as of today, core20 is not released yet (there are snaps, but UC20 (and therefore the core20 snap) hasn't been declared officially released yet, so it probably makes sense to hold off on porting. That said, since it doesn't seem like there are any open CVEs yet so I suggest proceeding with this MIR with groovy and focal in mind and porting later. If you still need core18, I then suggest also going back to bionic.