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

On 10/7/20 9:46 AM, Antal Nemeš wrote:
> 
> 
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of
>> Leon Fauster via CentOS-devel
>> Sent: Wednesday, 7 October 2020 12:31
>> To: centos-devel at 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/html/managing_and_monitoring_security_updates/installing-security-updates_managing-and-monitoring-security-updates
> 
>>>> 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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201007/23c3b66b/attachment-0002.sig>