Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support security errata for rpm repos #57

Open
dylan-bartos-tanium opened this issue May 12, 2023 · 2 comments
Open

Support security errata for rpm repos #57

dylan-bartos-tanium opened this issue May 12, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@dylan-bartos-tanium
Copy link

The repodata stored on packages.microsoft.com does not currently conform to industry established best practices for software versioning and errata content. Red Hat has for many years been leading in the space, with many other maintainers like Oracle, Rocky, and Alma following the same practices to allow customers and partners to interact with the repository in a meaningful way.

I'll be referencing the omi package to use as an example. https://github.com/microsoft/omi

Security Errata

The updateinfo.xml component of the repodata stores advisory details for the packages in the primary.xml and allows security plugins/parameters to be used by tools like yum/dnf when updating. OMI's most recent published CVE at the time of this posting is CVE-2022-33640. Providing security errata would allow administrators to effectively update their packages when using 'security only' update methodologies. At present moment, all updates are classified as bugfixes, "hiding" the security fixes from admins using the relatively common "security only" methodology. This is concerning and is likely causing CVEs to go un-patched in the wild.

Software Versioning

Packages released typically have multiple version attributes (Epoch, Version, Release). The omi package provides a major/minor version tag in the Version attribute (1.7.0 at the time of this posting). It additionally provides a Release attribute which is commonly noted as either 0 or 1 in the release notes. In the repodata, this is maintained across all OSes.

The industry best practice is to provide some form of additional identifying information on a per-OS basis. For instance, RHEL7 and derivatives use an "{int}.el7" or "{int}.el7_9" format to denote the major/minor release of the OS. RHEL8 and derivatives use a formatting like "{int}.el8". This helps clearly identify which OS a particular RPM was built for.

If we look at the curl package, you find attributes:
Epoch: (none)
Name: curl
Version: 7.61.1
Release: 22.el8
Architecture: x86_64

The omi package has attributes:
Epoch: (none)
Name: omi
Version: 1.7.0
Release: 0
Architecture: x86_64

@daviddavis
Copy link
Member

Hi @dylan-bartos-tanium thanks for the issue.

Publishing security errata for rpm repos is a feature we're aware of and are hoping to support. I hope to have more details to share in the future.

For packaging versioning, we (the Linux Repo team) don't control that. That is set by the package builders/maintainers. Would you mind filing an issue at https://github.com/microsoft/omi/issues?

@daviddavis daviddavis changed the title Repodata does not conform to industry best practices Support security errata for rpm repos May 15, 2023
@daviddavis daviddavis added the enhancement New feature or request label May 15, 2023
@dylan-bartos-tanium
Copy link
Author

Filed as issue 741 microsoft/omi#741. Thanks @daviddavis , great to hear!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants