Is there any way to correlate modular package versions in RHEL8.x with ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for https://access.redhat.com/errata/RHSA-2020:3714: - RedHat lists httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm - in CentOS this (probably?) matches httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL and Centos (not sure if there were exceptions, though).
Thanks, Antal
On Sun, Oct 4, 2020 at 5:54 PM Antal Nemeš Antal.Nemes@hycu.com wrote:
Is there any way to correlate modular package versions in RHEL8.x with ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL and Centos (not sure if there were exceptions, though).
Define "correlate". Everything up to the ".module" is consistent. I'll also admit that I've found modules to create real difficulty updating and that their use in RHEL 8 makes it far more difficulty to manage python module updates for various CentOS releases.
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build System) .. it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL and CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build System .. the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Here is some info on how MBS works .. this is for Fedora, but the principles are the same for the CentOS version:
https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/MBS
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with
ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for
https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches
httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL
and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build System) .. it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL and CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build System .. the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into git.centos.org represent state from internal RHEL repos that produced released RHEL packages? Does this import contain any kind of hash reference or any kind of identifier from RHEL repo, such that it could be used to link RHEL released modules with Centos?
Here is some info on how MBS works .. this is for Fedora, but the principles are the same for the CentOS version:
https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/MBS
On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš Antal.Nemes@hycu.com wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with
ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for
https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches
httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL
and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build System) .. it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL and CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build System .. the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into git.centos.org represent state from internal RHEL repos that produced released RHEL packages?
It represents the SRPMs that are in the released RHEL packages.
Does this import contain any kind of hash reference or any kind of identifier from RHEL repo, such that it could be used to link RHEL released modules with Centos?
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
josh
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Josh Boyer Sent: Tuesday, 6 October 2020 14:20 To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
CAUTION: Origin is external! The content might not be safe!
On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš Antal.Nemes@hycu.com wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with
ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for
https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists
httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches
httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between
RHEL
and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build
System) ..
it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL
and
CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for
commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build
System ..
the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into git.centos.org represent state from
internal RHEL repos that produced released RHEL packages?
It represents the SRPMs that are in the released RHEL packages.
Does this import contain any kind of hash reference or any kind of identifier
from RHEL repo, such that it could be used to link RHEL released modules with Centos?
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
Makes sense. But the names of src.rpm published by RHEL do contain index and commit hash, don't they? E.g. from the link I referenced earlier at https://access.redhat.com/errata/RHSA-2020:3714 , src.rpm is httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.src.rpm Are these original src.rpm names lost during the import process?
josh _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Oct 6, 2020, 6:14 PM Antal Nemeš Antal.Nemes@hycu.com wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Josh Boyer Sent: Tuesday, 6 October 2020 14:20 To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
CAUTION: Origin is external! The content might not be safe!
On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš Antal.Nemes@hycu.com wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with
ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for
https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists
httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches
httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between
RHEL
and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build
System) ..
it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL
and
CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never
match for
commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build
System ..
the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into git.centos.org represent state from
internal RHEL repos that produced released RHEL packages?
It represents the SRPMs that are in the released RHEL packages.
Does this import contain any kind of hash reference or any kind of
identifier
from RHEL repo, such that it could be used to link RHEL released modules with Centos?
It does not, because the source is pushed from SRPMs, not the internal
RHEL
git repositories.
Makes sense. But the names of src.rpm published by RHEL do contain index and commit hash, don't they?
They contain part of one, yes. The SRPM is exploded though, and the Release version does not contain the hash as it calculated by MBS at build time, as Johnny said. It's part of dist. The import records the full NVR as a tag, but that has no bearing on the CentOS git hash or build system.
E.g. from the link I referenced earlier at
https://access.redhat.com/errata/RHSA-2020:3714 , src.rpm is httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.src.rpm Are these original src.rpm names lost during the import process?
No, but it doesn't matter as explained above.
If you would like to ensure RHEL metadata is useful for the systems you maintain, I would suggest using RHEL. I realize that is not always feasible or desirable for some, but mapping that metadata to binaries built by another project is fairly outside the scope of what it is intended to cover. It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself.
Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that.
josh
From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Josh Boyer Sent: Wednesday, 7 October 2020 01:51 To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On Tue, Oct 6, 2020, 6:14 PM Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel On Behalf Of Josh Boyer Sent: Tuesday, 6 October 2020 14:20 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
CAUTION: Origin is external! The content might not be safe!
On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: mailto:centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On 10/4/20 4:54 PM, Antal Nemeš wrote:
Is there any way to correlate modular package versions in RHEL8.x with ones from Centos8.x in any way, no matter how difficult?
For example, looking at package list for https://access.redhat.com/errata/RHSA-2020:3714:
- RedHat lists
httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm
- in CentOS this (probably?) matches
httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64
AFAIK, the non-modular packages shared the same NEVRA between RHEL and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build System) .. it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL and CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since http://git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build System .. the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into http://git.centos.org represent state from internal RHEL repos that produced released RHEL packages?
It represents the SRPMs that are in the released RHEL packages.
Does this import contain any kind of hash reference or any kind of identifier from RHEL repo, such that it could be used to link RHEL released modules with Centos?
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
Makes sense. But the names of src.rpm published by RHEL do contain index and commit hash, don't they?
They contain part of one, yes. The SRPM is exploded though, and the Release version does not contain the hash as it calculated by MBS at build time, as Johnny said. It's part of dist. The import records the full NVR as a tag, but that has no bearing on the CentOS git hash or build system.
E.g. from the link I referenced earlier at https://access.redhat.com/errata/RHSA-2020:3714 , src.rpm is httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.src.rpm Are these original src.rpm names lost during the import process?
No, but it doesn't matter as explained above.
If you would like to ensure RHEL metadata is useful for the systems you maintain, I would suggest using RHEL. I realize that is not always feasible or desirable for some, but mapping that metadata to binaries built by another project is fairly outside the scope of what it is intended to cover.
Thanks, Josh. The context of my questions is that I am trying to determine if an installed package/module has any known security vulnerabilities and requires upgrading. CentOS does not provide metadata to make yum/dnf updateinfo work (https://bugs.centos.org/view.php?id=16560). CentOS project is not submitting CESA to centos-announce for Centos 8.x. CESA always referred to RHSA, so now I only have RHSA to rely on, and need to translate updated packages from RHSA to CentOS packages.
It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself.
Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that.
I agree, but CentOS project does not make such metadata (e.g. CESA, updateinfo) available.
josh
Thank you kindly for your responses, Antal
Am 07.10.20 um 10:32 schrieb Antal Nemeš:
From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Josh Boyer Sent: Wednesday, 7 October 2020 01:51 To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
On Tue, Oct 6, 2020, 6:14 PM Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel On Behalf Of Josh Boyer Sent: Tuesday, 6 October 2020 14:20 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
CAUTION: Origin is external! The content might not be safe!
On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel On Behalf Of Johnny Hughes Sent: Monday, 5 October 2020 16:53 To: mailto:centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8? >
On 10/4/20 4:54 PM, Antal Nemeš wrote: > Is there any way to correlate modular package versions in RHEL8.x > with ones from Centos8.x in any way, no matter how difficult? > > For example, looking at package list for https://access.redhat.com/errata/RHSA-2020:3714: > - RedHat lists > httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm > - in CentOS this (probably?) matches > httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64 > > AFAIK, the non-modular packages shared the same NEVRA between RHEL > and Centos (not sure if there were exceptions, though).
Modules are built by a new component called MBS (Module Build System) .. it works in conjunction with KOJI to do bulids.
Because of MBS, exact module names are not possible between RHEL and CentOS. This is because 2 things in MBS are generated at build time. One is an index number .. one is a commit hash from git.
Since http://git.centos.org is a closed system and it's hashes will be different than the internal RHEL git repo .. the hashes will never match for commits.
Also, since the CentOS MBS is a sperate system frmo the RHEL Build System .. the index number for build will also never be the same.
Therefore, modules will never patch with exact names.
Thanks, that explains a lot
Doesn't the import of sources into http://git.centos.org represent state from internal RHEL repos that produced released RHEL packages?
It represents the SRPMs that are in the released RHEL packages.
Does this import contain any kind of hash reference or any kind of identifier from RHEL repo, such that it could be used to link RHEL released modules with Centos?
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
Makes sense. But the names of src.rpm published by RHEL do contain index and commit hash, don't they?
They contain part of one, yes. The SRPM is exploded though, and the Release version does not contain the hash as it calculated by MBS at build time, as Johnny said. It's part of dist. The import records the full NVR as a tag, but that has no bearing on the CentOS git hash or build system.
E.g. from the link I referenced earlier at https://access.redhat.com/errata/RHSA-2020:3714 , src.rpm is httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.src.rpm Are these original src.rpm names lost during the import process?
No, but it doesn't matter as explained above.
If you would like to ensure RHEL metadata is useful for the systems you maintain, I would suggest using RHEL. I realize that is not always feasible or desirable for some, but mapping that metadata to binaries built by another project is fairly outside the scope of what it is intended to cover.
Thanks, Josh. The context of my questions is that I am trying to determine if an installed package/module has any known security vulnerabilities and requires upgrading. CentOS does not provide metadata to make yum/dnf updateinfo work (https://bugs.centos.org/view.php?id=16560). CentOS project is not submitting CESA to centos-announce for Centos 8.x. CESA always referred to RHSA, so now I only have RHSA to rely on, and need to translate updated packages from RHSA to CentOS packages.
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require such metadata.
It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself.
Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that.
I agree, but CentOS project does not make such metadata (e.g. CESA, updateinfo) available.
I think the CentOS project has no resources for that and this is what RHEL provides.
-- Leon
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 12:31 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
<snip>
Thanks, Josh. The context of my questions is that I am trying to determine if an installed package/module has any known security vulnerabilities and requires upgrading. CentOS does not provide metadata to make yum/dnf updateinfo work (https://bugs.centos.org/view.php?id=16560). CentOS project is not submitting CESA to centos-announce for Centos 8.x. CESA always referred to RHSA, so now I only have RHSA to rely on, and need to translate updated packages from RHSA to CentOS packages.
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require such metadata.
I have not observed such statements in RHSA, at least not for RHEL8. Do you have a reference I can look at? RHEL8 docs clearly make a provision for it: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself.
Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that.
I agree, but CentOS project does not make such metadata (e.g. CESA,
updateinfo) available.
I think the CentOS project has no resources for that and this is what RHEL provides.
I am not asking CentOS project to make this metadata available. I am just looking for ways to make use of what is already publically available by RedHat and endorsed by CentOS project. Right now, the only obstacle to getting a (decent) translation of OVAL definition from RHEL8 to Centos8 is the module version mapping.
-- Leon _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 10/7/20 9:46 AM, Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 12:31 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
<snip>
Thanks, Josh. The context of my questions is that I am trying to determine if an installed package/module has any known security vulnerabilities and requires upgrading. CentOS does not provide metadata to make yum/dnf updateinfo work (https://bugs.centos.org/view.php?id=16560). CentOS project is not submitting CESA to centos-announce for Centos 8.x. CESA always referred to RHSA, so now I only have RHSA to rely on, and need to translate updated packages from RHSA to CentOS packages.
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require such metadata.
I have not observed such statements in RHSA, at least not for RHEL8. Do you have a reference I can look at? RHEL8 docs clearly make a provision for it: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself.
Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that.
I agree, but CentOS project does not make such metadata (e.g. CESA,
updateinfo) available.
I think the CentOS project has no resources for that and this is what RHEL provides.
I am not asking CentOS project to make this metadata available. I am just looking for ways to make use of what is already publically available by RedHat and endorsed by CentOS project. Right now, the only obstacle to getting a (decent) translation of OVAL definition from RHEL8 to Centos8 is the module version mapping.
BUT .. as stated before .. these are 2 different closed systems.
And in reality, because of modules, it IS different. Our index number will not match the RHEL index number. Our git hash will not match the RHEL git hash.
Also .. CentOS has NEVER validated any security updates. We build source code as released .. nothing more. It is all we have ever done.
When it was possible, we also linked to the Red Hat Errata info. It is no longer possible .. at least easily (as you have seen). So we no longer do that.
The CentOS project does not map security updates any differently than any other update .. again, we never have. We build and release updated code when it is released. Any other verification of 'fit for use' has always been up to the end user.
Am 07.10.20 um 16:46 schrieb Antal Nemeš:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 12:31 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
<snip>
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require such metadata.
I have not observed such statements in RHSA, at least not for RHEL8. Do you have a reference I can look at? RHEL8 docs clearly make a provision for it: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
As I said (IIRC) - I remember that the mentioned sentence where everywhere placed: Like here
https://access.redhat.com/errata/RHBA-2020:3264
but it seems not to be on every errata anymore ...
-- Leon
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 23:41 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
Am 07.10.20 um 16:46 schrieb Antal Nemeš:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 12:31 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
<snip>
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require
such metadata.
I have not observed such statements in RHSA, at least not for RHEL8. Do
you have a reference I can look at?
RHEL8 docs clearly make a provision for it: https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux
/8/html/managing_and_monitoring_security_updates/installing-security-u pdates_managing-and-monitoring-security-updates
As I said (IIRC) - I remember that the mentioned sentence where everywhere placed: Like here
https://access.redhat.com/errata/RHBA-2020:3264
but it seems not to be on every errata anymore ...
Thanks for the reference. I see this note consistently on RHBA, but I have so far not seen it on any RHSA.
-- Leon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 10/7/20 5:30 PM, Antal Nemeš wrote:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 23:41 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
Am 07.10.20 um 16:46 schrieb Antal Nemeš:
-----Original Message----- From: CentOS-devel centos-devel-bounces@centos.org On Behalf Of Leon Fauster via CentOS-devel Sent: Wednesday, 7 October 2020 12:31 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Module version differences between RHEL8 and Centos8?
<snip>
Cherry picking only sec updates is not supported by this distribution. It results in a combination of installed packages that is not tested. IIRC every RHSA has a statement that all (latest) packages must be applied to be "secure". In this case it is not worth the effort to map hashes but other objectives like reportable compliance will require
such metadata.
I have not observed such statements in RHSA, at least not for RHEL8. Do
you have a reference I can look at?
RHEL8 docs clearly make a provision for it: https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux
/8/html/managing_and_monitoring_security_updates/installing-security-u pdates_managing-and-monitoring-security-updates
As I said (IIRC) - I remember that the mentioned sentence where everywhere placed: Like here
https://access.redhat.com/errata/RHBA-2020:3264
but it seems not to be on every errata anymore ...
Thanks for the reference. I see this note consistently on RHBA, but I have so far not seen it on any RHSA.
Regardless .. it is on the link listed in solutions:
https://access.redhat.com/articles/11258
Quote: Applying package updates on Red Hat Enterprise Linux 8
Before installing an update, make sure all previously released errata relevant to the system have been applied.
No one tests for mixed and skipped errata .. RHEL or CentOS.
From a security only perspective, the security updates are obviously most important. That does not make bugfix updates unimportant.
The only certified solution is the one on each active channel that includes all released updates. That is true regardless of the OS.
Red Hat does provide some updates in an extended tree for some releases, but those EAS/EUS trees still require all the rpms to be the latest released in that tree .. not a mixed and matched hodge podge where you have older rpms mixed with newer rpms.
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
Sure. but why don't push self-contained info at least? Especially while (I think) modulemd is stored internally somehow along with those SRPMs. I mean, for example:
https://git.centos.org/rpms/perl-DBD-Pg/commits/c8s-stream-3.7
pushed with 3 tags
imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+7d8e397c imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+907cf59b imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+c57d755d
Which are built with perl:5.24, perl:5.26 and perl:5.30? No chance to figure out. Those tags are almost useless info ATM.
Just import with something like:
imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+7d8e397c/perl:5.24
The same is for modulemd imports.
https://git.centos.org/modules/perl-DBD-Pg/commits/c8s-stream-3.7
Here tags are:
imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.56fce90f imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.98a3c9d0 imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.bde36347
Those 3 above are examples of TOTALLY USEFULL information without connected perl streams.
On Wed, Oct 7, 2020, at 08:00, plageat@tut.by wrote:
It does not, because the source is pushed from SRPMs, not the internal RHEL git repositories.
Sure. but why don't push self-contained info at least? Especially while (I think) modulemd is stored internally somehow along with those SRPMs. I mean, for example:
https://git.centos.org/rpms/perl-DBD-Pg/commits/c8s-stream-3.7
pushed with 3 tags
imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+7d8e397c imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+907cf59b imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+c57d755d
Which are built with perl:5.24, perl:5.26 and perl:5.30? No chance to figure out. Those tags are almost useless info ATM.
Just import with something like:
imports/c8s-stream-3.7/perl-DBD-Pg-3.7.4-4.module+el8.3.0+6565+7d8e397c/perl:5.24
The same is for modulemd imports.
https://git.centos.org/modules/perl-DBD-Pg/commits/c8s-stream-3.7
Here tags are:
imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.56fce90f imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.98a3c9d0 imports/c8s-stream-3.7/perl-DBD-Pg-3.7-8030020200313075823.bde36347
Those 3 above are examples of TOTALLY USEFULL information without connected perl streams.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
It would seem simple at first glance but it really isn't. The push tooling (which creates those tags) separates the module RPM pushes and the module metadata pushes, it doesn't know much directly about the relationship between them.
--Brian
-
Antal Nemeš -
Brian Stinson -
Johnny Hughes -
Josh Boyer -
Leon Fauster -
Nico Kadel-Garcia -
plageat＠tut.by