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