[elrepo] Updateinfo for ELRepo 8?

[Phil Perry]

On 09/07/2019 22:05, Pat Riehecky wrote:
> 
> 
> On 7/9/19 3:19 PM, Akemi Yagi wrote:
>> On Tue, Jul 9, 2019 at 8:54 AM Pat Riehecky<riehecky at fnal.gov>  wrote:
>>> Would the ELRepo project be open to providing a limited updateinfo for
>>> ELRepo 8?
>>>
>>> There is a fairly viable python library[1] for building and managing the
>>> XML file.  In theory this would permit folks using ELRepo to easily
>>> install security errata (and get notifications from PackageKit about
>>> missing ones).
>>>
>>> I'd be happy to assist getting this off the ground.
>>>
>>> Pat
>>>
>>> [1]https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_python-2DUpdateinfo&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=LBLCgToPbzzUo9ulP_-bul1Qh7dhe35Nipnrb64Yf50&s=umHJ3s6jcJgesSF_jq1NZW4g9yDOmxwvn84ZsWgKXLs&e=  
>>>
>>> --
>>> Pat Riehecky
>> Hi Pat,
>>
>> Thanks for your suggestion and offer to help. Due to my lack of
>> complete knowledge of the subject, I need to ask a question.
>>
>> We don't differentiate between security/bug fix updates - we support
>> the latest package release only, so users of elrepo should generally
>> update to the latest version of which ever package(s) they may be
>> using. In this situation how would the updateinfo benefit elrepo?
>>
>> Again pardon my ignorance.  :(  :)
>>
>> Akemi
>> _______________________________________________
>> elrepo mailing list
>> elrepo at lists.elrepo.org
>>
> 
> No worries :)
> 
> There are a few ways updateinfo could assist with things.
> 
> Part of the XML requires a publication date.  This could help with 
> tracking down when a package was built for possible ABI breakage.  I 
> also use it to track how often a given package is updated.[2]
> 
> There is a section where you can list related tickets for a given 
> update.  This could be handy for tracking a package back to the original 
> request.
> 
> One of the biggest uses is the distinction between security and 
> non-security packages.  Admittedly I'm looking back a bit, but the 
> nvidia kmod 295.40-1.el6.elrepo (CVE-2012-0946) was a bit scary.  Folks 
> following the announcements knew what to do, and folks that installed 
> the latest packages were fine.  But folks that were not subscribed to 
> the list may not have been aware of the need to update.
> 
> I'm a firm believer in install all the updates, but alas not all folks 
> do.  Generally folks break down into two camps : Users and Business.
> 
> With the metadata for an RPM tagged as a security update in EL8, 
> PackageKit and GnomeSoftware nag a normal user about the missing 
> security fix - I find this nag eventually forces the issue. From a "big 
> business" process perspective, it can be easier to justify a change 
> ticket for packages that are tagged as being security fixes.[3]
> 
> I'm not clear that ELRepo has (or needs) any commitment to do security 
> tracking of packages.  And I'm not sure how much of a problem it would 
> be if things were tagged by default as "not security"[4] (unless you are 
> releasing it because it is security) and changed to 'security' if it is 
> discovered to be a security fix. This would be a really nice feature for 
> folks using Katello/Sat6.
> 
> So I guess my follow up question is: would these possible benefits be 
> worth reviewing for the ELRepo workflow?
> 
> Or put another way, would there be a benefit to the project with some of 
> the enhanced data visibility this would present?
> 
> Pat
> 
> 
> [2]
> For example, with the XSL I've got click on the update id for an update in
>   : WARNING 25MB XML PAGE LOAD :
> http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/repodata/updateinfo.xml
> 
> I'd estimate ELRepo 7 right now would be in the 18k size range.
> 
> [3] Katello/Sat6 has a specific workflow in place to promote security 
> errata or really any errata that is listed in an updateinfo.  And 
> another that lists outstanding updateinfo errata. Packages not listed in 
> an updateinfo.xml are not listed as "errata" and not subject to this 
> workflow.
> 
> If you are curious about this :
> https://www.theforeman.org/plugins/katello/3.12/user_guide/errata/index.html
> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/managing_hosts/chap-red_hat_satellite-managing_hosts-configuring_host_collections#sect-Red_Hat_Satellite-Managing_Hosts-Adding_Errata_to_a_Host_Collection
> 
> [4] There are a bunch of types recognized by PackageKit beyond what RH uses
> https://pagure.io/python-Updateinfo/blob/master/f/docs/updateinfo.xsd#_148
> 
> Perhaps ELRepo could use newpackage, errata, and security ?
> 

Hi Pat,

I'm minded to say no as I'm not seeing the cost-benefit, either for 
elrepo or our users.

Firstly, we have no security data available to us for the vast majority 
of packages we release. Upstream kernel.org do not release security 
advisories so we have no way of classifying kernel-ml or kernel-lt 
releases as security-related or not. In reality, I'm guessing that the 
majority of kernel releases do contain some kind of security-related 
patches, but it's kind of irrelevant as our advice is (1) these packages 
are provided on an as-is basis and not intended for production use, and 
(2) we only support the latest release.

Likewise, we have no data on the security status of kmod packages which 
are based on code backported from upstream kernels.

Similarly, we often have no security data for OEM driver releases (your 
NVIDIA example is an exception rather than the rule).

So this leads to the question would we tag everything as a security 
update without an accompanying advisory notice providing details, or tag 
everything as not a security update thus opening ourselves up to 
criticism of misleading people if a package release was later discovered 
to contain a security fix. The latter would be particularly concerning 
to me as trust is everything when asking users to install kmod packages 
into the heart of their kernel.

 From my perspective, everything we release is inherently of high risk. 
We are asking users to trust and install either a full kernel or a 
package that inserts a driver into their kernel. We recommend anyone who 
accepts that risk to install/update to the latest version (and we worked 
closely with Red Hat in the early days of elrepo to ensure kmod packages 
were updatable rather than multi-install). Anyone who accepts that risk 
and chooses not to install the latest version against our explicit 
advice, or sticks with an old trusted stable version for whatever reason 
knows what they are doing.

Ironically, one of our most popular packages (Nvidia) is somewhat of an 
anomaly as we provide this largely as a convenience to users in RPM 
packaged format. We do this largely because we firmly believe the kmod 
format is the best delivery method for kernel modules on end user machines.

If we were rebuilding content that comes with an existing security 
rating / advisory that we could easily access and assign to our packages 
then I could see more value, but from my perspective any assignment 
would be largely arbitrary and not based on any underlying knowledge or 
data.

Do others have an opinion?

Phil