You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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
changed the title
Repodata does not conform to industry best practices
Support security errata for rpm repos
May 15, 2023
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
The text was updated successfully, but these errors were encountered: