[CentOS] CentOS Security Advisories OVAL feed??

On 05/08/2020 16:49, Johnny Hughes wrote:
> On 8/5/20 1:05 AM, centos at niob.at wrote:
>> On 04/08/2020 23:50, Jon Pruente wrote:
>>> On Tue, Aug 4, 2020 at 11:34 AM <centos at niob.at> wrote:
>>>
>>>> Q5) If the answer to the last question is "no": shouldn't there be such
>>>> a resource?
>>>>
>>> CentOS doesn't publish security errata. If you need it then you should
>>> either buy RHEL, or deal with putting together your own set up with
>>> something like http://cefs.steve-meier.de/
>> I expected just this answer, and we do have a RHEL subscription (and
>> BTW: thanks for the link). But you missed the main point by omitting the
>> other questions (especially Q1, Q2 and Q3): There are upstream package
>> versions that were never rebuilt for CentOS.
>>
>> For instance: If, for whatever reason, I am required to stay with nginx
>> 1.14.1 then the missing rebuild of the packages mentioned in
>> RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would
>> leave me with a vulnerable system.
>>
>> The question for an OVAL feed is actually an add-on question: In the
>> same spirit that is the base for the CentOS project itself: wouldn't
>> such a feed be a good thing to have? Otherwise your answer could be the
>> catch-all answer to all questions CentOS: Go get a commercial
>> subscription. Personally, I think such an answer is not very helpful.
>>
>> So what do you think about the underlying issue? Under what
>> argumentation does it NOT constitute to be an issue?
>>
> Modules suck .. :)
>
> But that is built and in the repo ..
>
> dnf list 'nginx*'
>
> nginx.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-all-modules.noarch
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-filesystem.noarch
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-mod-http-image-filter.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-mod-http-perl.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-mod-http-xslt-filter.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-mod-mail.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
> nginx-mod-stream.x86_64
> 1:1.14.1-9.module_el8.0.0+184+e34fea82                  AppStream
>
> As I have said before .. mbbox (the item used to build modules) adds an
> index code (the 184) and a part of the git commit (e34fea82) .. so this
> will always be different between RHEL and CentOS .. because we use
> different builders and a different git repo.  Red Hat's RHEL index code
> is 4108 and the git commit is af250afe
>
Thanks a lot for pointing that out! That explains part of the problem. 
The corresponding source RPMs are indeed identical (I checked :-) ), so 
the packages were (indeed) rebuilt. That was not at all obvious to me.

OTOH: I probably would have guessed if there had been a corresponding 
e-mail to Centos-Announce. At this point, I would like to add that I am 
extremely impressed by the CentOS project and that I do not want to 
blame anybody for forgetting such an e-mail (or maybe it was just lost 
somewhere in SMTP-land) - I just want to state that fact. Thanks for 
putting in all that hard work!

With that new knowledge, I also checked my other issues wrt to the 
container-tools package: Same module issue. So there is a pattern. But 
there is also the pattern that I cannot find the corresponding 
CentOS-Announce e-mail. Strange, isn't it?

This still leaves me wondering if there should be an attempt at 
providing a CentOS OVAL file similar to the one by RH that is not 
generated by taking the upstream file and running some uninspired 
sed-script on it, like (for reference):

     sed -e 's,/etc/redhat-release,/etc/centos-release,g' -e 
's/199e2f91fd431d51/05b555b38483c65d/g'

However, the question could be asked if such an OVAL file would be of 
any use, in the light of possibly missing CESA announce e-Mails, because 
that advisory information must some be translated into the OCAL XML.

Having said all this: maybe there is some deeper problem here, because 
of that pattern of missing announce e-mails that correspond with 
packages that differ in the final version number with respect to the 
upstream package. Or is this just a coincidence?


peter