[CentOS-devel] Module version differences between RHEL8 and Centos8?

Leon Fauster

leonfauster at googlemail.com
Wed Oct 7 10:30:38 UTC 2020


Am 07.10.20 um 10:32 schrieb Antal Nemeš:
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Josh Boyer
>> Sent: Wednesday, 7 October 2020 01:51
>> To: The CentOS developers mailing list. <centos-devel at 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 at 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



More information about the CentOS-devel mailing list