The MIR text in comment #0 has been updated. ** Description changed:
- Hello, the Ubuntu Security Team would like the libopenscap8 binary - package from openscap promoted to main. libopenscap8 is incorporated - into the CVEscan snap: https://github.com/canonical/sec- - cvescan/blob/master/snapcraft.yaml + Hello, the Ubuntu Security Team would like to propose the libopenscap8 binary + package from openscap be promoted to main. - One wrinkle is that we'd like libopenscap8 from an existing release - moved into main, so that it can be used by the snapcraft build process. - I don't know the snap ecosystem well enough to know if CVEscan can be - ported to the core20 world or if it must remain in core18 world. So we - may like openscap from 18.04 LTS or openscap from 20.04 LTS - retroactively 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. No later version exists at + this time. This release is currently present in Debian Testing. [Availability] openscap is in universe. [Rationale] - The Ubuntu Security Team would like the libopenscap8 binary package from openscap promoted to main. libopenscap8 is incorporated into the CVEscan snap: https://github.com/canonical/sec-cvescan/blob/master/snapcraft.yaml + 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 may make sense to require a security review. However, the package has no executables, no setuid or setgid files, does not daemonize or otherwise itself run a persistent service, and does not open listening ports. + 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 adminstrator (on content they trust) after using existing permission + escallation 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 escallation paths (such as suid, sgid, &c). - [Quality assurance] - - No configuration is necessary to use the library, though applications that use this library will need to be configured. + [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. - - The Debian package appears to be in an unfortunate state: - - Still provides a python2 package, no python3 package: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937211 - - A segfault with upstream fix has been ignored: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932120 - - The upstream fix for the segfault was intermingled with an unrelated new feature: - - https://github.com/OpenSCAP/openscap/pull/1387/commits - - 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 the segfault that has been ignored in Debian. The SRU appears stalled: - - https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1851682 + - 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-resources/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 + E: openscap source: source-is-missing xsl/xccdf-resources/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: + 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. + 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 + Thanks! + + Original author: Seth Arnold + Updated by: Alex Scheel + Revisited: 2021-06-02 ** Description changed: 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. + - 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. No later version exists at - this time. This release is currently present in Debian Testing. + 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. + 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 adminstrator (on content they trust) after using existing permission - escallation 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 escallation paths (such as suid, sgid, &c). + 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. + - 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. + - 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-resources/bootstrap.min.js - E: openscap source: source-is-missing xsl/xccdf-resources/openscap.js + 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 + 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. + 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1877696 Title: [MIR] openscap To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1877696/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
