devel February 2021

devel@lists.centos.org

62 participants
47 discussions

Re: [CentOS-devel] re CVE errata in CentOS Stream
by redbaronbrowser 19 Feb '21

19 Feb '21

On Friday, February 19, 2021 2:26 PM, Josh Boyer <jwboyer(a)redhat.com> wrote: > On Fri, Feb 19, 2021 at 2:45 PM redbaronbrowser > redbaronbrowser(a)protonmail.com wrote: > > > > > On Wednesday, February 17, 2021 9:01 PM, Mike McGrath mmcgrath(a)redhat.com wrote: > > > > > > > > > There's a bit of nuance to this question in that policy states that CVEs should be fixed in RHEL before CentOS Stream. > I'm not sure what policies you're referring to. Can you point to > where they are documented? I suspect you mean the various blogs and > answers on the list, which are good discussions but I don't want to > assume that those are policies, nor do I want to assume that is what > you are referring to. I trimmed the coversation down to the policy I'm refering to. > Also, Stream and CI/CD are indeed important and related. However, > that doesn't mean there is a single universal approach to everything. I am not implying there is a single universal approach to everything. What I am asking is if exceptions to the policy Mike McGrath stated has already been established so the Stream community can get access to help quickly? Or would a RHEL user indicating a CVE fix cause a regression require seeking management approval before releasing the information to Stream? > > Will there be a way to expedite a CVE fix attempt into Stream after reports of a regression from RHEL users? > > Can you help me understand why an answer to that question matters > given that we are not providing an SLA on CVE fixes in Stream? I > understand that leaves things ambiguous, but even if the answer to > your question was "yes" it doesn't change anything in a manner that > matters from a Stream contributors perspective. I was not expecting an SLA on CVE fixes. If a CVE fix works as intended then I expect the policy MG stated to be the policy followed. I am not trying to object to that. A service-level agreement is between Red Hat and RHEL customers. There is no service agreement with Stream users so I never expected a SLA. Instead I was thinking more along the lines of an ULA (Upstream Level Agreement) that if a CVE "fix" is confirmed to be a CVE "breakage" similar to "Boot Hole," that management approval is already in place for the RHEL team to move access to that regression code to Stream users to be able to review. The SLA policy applying only to RHEL would continue to do so. But it sounds like as it stands now if a CVE "fix" causes unexpected problems, even after the problems are confirmed it may be weeks until management approves the Upstream getting access to help work on the issue. All I'm asking for a ULA which may only apply to 0.01% of updates so that management approval already pre-exists to release it to Upstream in a number of hours instead of weeks. > I am trying to be very clear here to avoid the mistake we made, > inadvertent or not, with the CentOS Linux lifecycle change. There is > no SLA on CVE fixes in Stream. Ok > > Will there be a repo for known problematic security updates such as a CR-broken? > > Not to my knowledge. > > > What would be the roll of Stream if "Boot Hole" could happen again? Why is Stef Walter bringing it up? Are we being asked to help prevent or reduce the impact of that should it occur? > > Stef can speak for himself as to why it was mentioned. It is perhaps > a confusing issue to raise in the context of Stream, because that > particular CVE was under embargo anyway. There is no call to action > nor opportunity for the Stream community to deal with embargoed CVEs > in Stream itself. That is the nature of embargoes. I think you mean the development of the "Boot Hole" patch took place during an embargo, right? Once "Boot Hole" was released and actually impacted RHEL customers, wasn't the embargo period already over? I'm not asking for anything ahead of RHEL customers getting it. All I am asking for is pre-approval from management to get access as an Upstream once a problem with RHEL is confirmed. > > Put another way, is Stream a true Upstream or a hybrid? Is it really the policy that Stream is strictly a downstream when it comes to CVEs? Or if something unexpect happens again, is the policy in place were we act as an Upstream for addressing it? > > With the nuance of CVEs in play, it's a hybrid. Mike already > explained that nuance above. In terms of closing the openness gap, that seems more than just a nuance. Of the CentOS 7 errata announced, 20% has been security updates. The existing information in the Stream FAQ and CentOS blog imply we are becoming the 100% Upstream. Instead the reality seems closer to being 80% Upstream and 20% Downstream.

1 0

No default stream configured for modules in powertools
by Peter Georg 19 Feb '21

19 Feb '21

Hi everyone, I just tried to install the new python39 stream on one of my systems. This includes the python39-Cython package. I realized that a simple "dnf install python39-Cython" does not work as the package is part of powertools (whereas python38-Cython is in appstream) [1]. Hence python39-Cython is not part of the "python39" module, but part of "python39-devel" - the corresponding module for python39 subpackages in powertools. Afaik this is required as a stream may only contain packages residing in one repository. Ultimately the install fails because the python39-devel module has not set a default stream. For the python39 module a default stream is set. I checked and can confirm that none of the modules in powertools has set a default stream. This is puzzling as all these modules have only one stream and the corresponding modules in appstream have a default stream set. Wouldn't it make more sense to use the same default for both the module in appstream and the corresponding module in powertools (or any other repository it may reside in)? Best Peter [1] Of course I could run a "dnf module enable python39-devel" before issuing the install command. However I use many scripts to setup systems that simply expect a list of packages to install, all these fail. Note that I do not even have to specify a stream to enable the correct one. While this makes sense as there is only one stream, it should not work according to the documentation (see man dnf): "In case stream is not specified, the enabled or the default stream is used, in this order." No stream is enabled and there is no default stream. This whole process just feels inconsistent.

1 0

re CVE errata in CentOS Stream
by Naoto Kobayashi 19 Feb '21

19 Feb '21

Dear community, I would like to ask a following question: - How are CVEs handled in CentOS Stream? The answer in faq page (https://centos.org/distro-faq <https://centos.org/distro-faq>) states that security issues will be updated in CentOS Stream after they are solved in the current RHEL release. However, CentOS Steam 8 solved CVE-2020-15437 (kernel) while RHEL 8 has not (as of February 17,2021). Does the order of security updates between RHEL and CentOS Stream depend on the situation? Best regards, --- Naoto Kobayashi

4 4

Cloud SiG Membership Cleanup - Completed
by Amy Marrich 19 Feb '21

19 Feb '21

Over the last few weeks I have reached out to everyone on the SiG's pending and current membership lists in preparation for the upcoming access merger. Everyone was asked if they wanted to remain a member and where their interests were to help drive the group. Based on replies or lack of a reply the lists have now been cleaned up. If anyone was removed and would still like to be a member please re-apply as we'd love to have you. If you never knew there was a Cloud SiG please apply as we welcome new members! Any questions please reach out! Thanks, Amy (spotz) *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/>

3 5

Cleaning up modulefailsafe/ stuff correctly - libuv saga from EPEL to AppStream
by Anthony Alba 19 Feb '21

19 Feb '21

Background : needing libuv-devel when AppStream/Devel versions were not in sync I installed modular libuv 1.36 from epel-modular. Subsequently when AppStream/Devel synced at 1.38 I had difficulty removing evidence of 1.36 due to /var/lib/dnf/modulefailsafe. dnf clean all didn't help there. What is the correct way to clean up modulefailsafe/ so that it unblocks non-modular packages? I had even removed all reference to EPEL repos but didn't realise the existence of the /var/lib/dnf/modulefailsafe/ lock files. Cheers Anthony

1 0

Non-modular libuv 1.38 is filtered out by modules
by Anthony Alba 19 Feb '21

19 Feb '21

Hi centos-devel, I can't figure out what is blocking libuv 1.38 from AppStream from being installed. * I have disabled EPEL Modular 8 as there is a modular libuv 1.36 inside there. * up to date CentOS 8 machine * using default CentOS-Linux*.repo files, and not using a local mirror dnf config-manager --disable epel-modular dnf module provides libuv Last metadata expiration check: 0:00:48 ago on Fri 19 Feb 2021 09:10:38 AM. # dnf install libuv Last metadata expiration check: 0:01:40 ago on Fri 19 Feb 2021 09:10:38 AM. All matches were filtered out by modular filtering for argument: libuv Error: Unable to find a match: libuv dnf repository-packages appstream list | grep libuv # shows nothing dnf install cmake Last metadata expiration check: 0:03:25 ago on Fri 19 Feb 2021 09:10:38 AM. Error: Problem: package cmake-3.11.4-7.el8.x86_64 requires libuv.so.1()(64bit), but none of the providers can be installed - conflicting requests - package libuv-1:1.38.0-2.el8.x86_64 is filtered out by modular filtering (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Any ideas? Anthony

1 1

CentOS AWS cloud images
by duke586 18 Feb '21

18 Feb '21

Hello! Thank you very much for the up-to-date AWS images for CentOS 7 on https://centos.org/download/aws-images/ . They contain all the necessary drivers for fast networking, but unfortunately the images lack a simple flag ("SRIOV") on the image to activate some of the drivers. The bug has been open since 2015: https://bugs.centos.org/view.php?id=8541 Reading related bugs, it sounds like the flag may have been added in the meantime, however right now it is missing (tested on ami-0686851c4e7b1a8e1). How can I help resolve this? Best regards, Viktor.

1 0

Hyperscale SIG meeting announcement
by Davide Cavalca 17 Feb '21

17 Feb '21

Hey folks, I wanted to announce that the Hyperscale SIG will be holding biweekly formal meetings at 6pm UTC on #centos-meeting-2 beginning Feb 17. You can find the series in the CentOS Calendar at https://www.centos.org/community/calendar/ We also normally hang out in #centos-hyperscale during daytime and you're welcome to drop in there anytime. If you'd like to learn more about the SIG, what we're working on and what's planned, you may find my CentOS Dojo talk interesting: https://www.youtube.com/watch?v=Kg7FqVGaZxs Cheers Davide

1 1

Re: [CentOS-devel] CentOS Stream Container images available on quay.io
by Sean Ho 17 Feb '21

17 Feb '21

> ## Next Steps > - We are still in discussions on how to push these properly to Dockerhub. > Since CentOS is an Official Image, there are some extra requirements here that we're working through. Does it means generating smaller former container image by kickstart- like tools instaed of additional scripts based on Red Hat UBI 8? Cheers, Sean

2 1

to which Bugzilla go to?
by lejeczek 17 Feb '21

17 Feb '21

Hi devel I've noticed a while ago that Redhat's Bugzilla has had, in "Red Hat Enterprise Linux 8" as one of the options "CentOS Stream" - which is where I've been recently reporting to. But I wonder about bugs relating to CentOS infra/repos - where to submit those, would you know? many thanks, L.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel February 2021