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
On 8/5/20 10:45 AM, centos at niob.at wrote:> 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? >We understand that there are no announcements for CentOS 8 .. this (the modules differences) is precisely the reason why (the names do not match up and our scripts require that). We do not have the capability to announce these at the present time. This is something that needs an engineering solution. Submissions welcome. -------------- 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/attachments/20200805/caab1789/attachment.sig>
On 05/08/2020 17:55, Johnny Hughes wrote:> >> 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? >> > We understand that there are no announcements for CentOS 8 .. this (the > modules differences) is precisely the reason why (the names do not match > up and our scripts require that). > > We do not have the capability to announce these at the present time. > > This is something that needs an engineering solution. Submissions welcome. > >Thanks for the clarification. This explains exactly what I have seen. Are those scripts available somewhere? A quick search didn't turn up anything obvious... peter
Am 05.08.20 um 17:55 schrieb Johnny Hughes:> On 8/5/20 10:45 AM, centos at niob.at wrote: >> 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? >> > > We understand that there are no announcements for CentOS 8 .. this (the > modules differences) is precisely the reason why (the names do not match > up and our scripts require that). > > We do not have the capability to announce these at the present time. > > This is something that needs an engineering solution. Submissions welcome. >I the mean time : https://feeds.centos.org/ -- Leon