| 2020-05-09 01:46:04 |
Seth Arnold |
bug |
|
|
added bug |
| 2020-05-09 01:46:16 |
Seth Arnold |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2020-05-13 22:51:09 |
Seth Arnold |
description |
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
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.
[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
[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.
[Quality assurance]
- No configuration is necessary to use the library, though applications that use this library will need to be configured.
- 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
- 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
[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 will subscribe 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 |
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
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.
[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
[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.
[Quality assurance]
- No configuration is necessary to use the library, though applications that use this library will need to be configured.
- 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
- 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
[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 |
|
| 2020-05-21 00:21:11 |
Seth Arnold |
bug |
|
|
added subscriber MIR approval team |
| 2020-05-21 14:17:48 |
Matthias Klose |
openscap (Ubuntu): status |
New |
Incomplete |
|
| 2020-05-26 23:07:14 |
Seth Arnold |
openscap (Ubuntu): status |
Incomplete |
New |
|
| 2020-06-02 14:36:28 |
Christian Ehrhardt |
openscap (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2020-06-03 13:23:25 |
Christian Ehrhardt |
openscap (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
Ubuntu Security Team (ubuntu-security) |
|
| 2020-06-11 06:22:37 |
Evgeny Kolesnikov |
bug |
|
|
added subscriber Evgeny Kolesnikov |
| 2021-06-03 13:07:53 |
Alexander Scheel |
description |
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
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.
[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
[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.
[Quality assurance]
- No configuration is necessary to use the library, though applications that use this library will need to be configured.
- 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
- 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
[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 |
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. 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 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 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-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:
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 |
|
| 2021-06-03 13:10:03 |
Alexander Scheel |
description |
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. 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 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 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-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:
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 |
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 |
|
| 2023-02-04 00:06:15 |
Mark Esler |
tags |
|
sec-1651 |
|
| 2023-10-10 15:27:44 |
Mark Esler |
openscap (Ubuntu): status |
New |
Incomplete |
|
