Re: When to close CVE's

2023-01-21 Thread Kevin Fenzi
On Fri, Jan 20, 2023 at 04:47:05PM +, Gary Buhrmaster wrote:
> On Fri, Jan 20, 2023 at 3:48 PM Richard Shaw  wrote:
> 
> > I think in practical terms that makes sense but our tools don't really help.
> 
> I agree, and that seems to be an artifact of
> the single Fedora component in RHBZ, which
> treats Fedora as one thing.
> 
> I supposed (in theory again) that there could
> be a master bugzilla for the CVE which depends
> on child bugzillas for each impacted Fedora
> release, and would get (auto) closed only when
> all the child bugzillas are resolved (either by
> updates or the Fedora release aging out).
> 
> Alternatively, an entirely different bugzilla for
> each Fedora release (but as Fedora is just
> a single component, unlike each RHEL
> which has different components for each
> version, I don't think that works).

I think that sort of thing indeed reflects reality better, but at the
cost of much more complexity. Maintainers already dislike the amount of
bugs to deal with, having tons more doesn't sound too appealing... at
least to me.

> > So I guess what I'm asking is if there is a specific policy around this? If 
> > not, should there be?
> 
> I think there should be at least an agreed
> upon best practice, which needs to be
> explicitly documented somewhere (maybe
> it is, but I don't recall seeing it, so I am
> not following it).

I'm not sure we can have any specific policy.

CVE's are all over the map. Sure we have priorities and 'scores' but
even then, they often are not quite right or don't apply the same way to
the way Fedora has packaged the software. 

I think we can perhaps have a 'rule of thumb'/SHOULD type of advice: 
* If it's high or critical, do consider updating stable releases if you
  can.
* If you decide not to update stable releases, please add a comment to
  the bug noting that and close it.

> So, as with much of Fedora, we fall back
> to depending on (usually volunteer)
> packagers to do the right thing (which works
> out well most of the time because packagers
> such as yourself are contentious about
> doing the right thing).

yeah, I think this is just too complex an area for us to have a detailed
policy.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Richard Shaw
On Fri, Jan 20, 2023 at 2:29 PM Demi Marie Obenour 
wrote:

>
> My general rule is that a security fix is worth backporting a SONAME change
> for, if there is no way to backport the patch.
>

In this case all the Fedora branches are recent enough but EL 7 and EL 8
are not and are impractical to fix at this point.

I've already been bitten in the past making major updates to EL branches. I
believe this was also with OpenImageIO. Someone was using it at work for
their project and had validated against the current version. Obviously in
this case there is NO way to determine out of repo dependencies.

The update was required to support a Review Request package so he
ultimately re-validated against the newer version, but lesson learned.

Since all of the severities are Medium and not High I think I will leave it
as is.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Demi Marie Obenour
On 1/20/23 10:48, Richard Shaw wrote:
> On Fri, Jan 20, 2023 at 9:22 AM Gary Buhrmaster 
> wrote:
> 
>> On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw  wrote:
>>>
>>> So is it when a build is complete in Rawhide? Or must *ALL* active
>> releases get the "fix"?
>>>
>>
>> I am not sure it is official policy/practice, but in
>> theory I would think that the CVE is technically
>> closed when all impacted Fedora releases get
>> the fix, but if you use various "Resolves rhbz#1234567"
>> syntax in the change log (and I generally try to
>> do so in addition to referencing the CVE by it's
>> identifier) I seem to recall that as soon as the
>> package hits rawhide the issue gets closed.  It
>> is therefore up to the packager to make sure they
>> have actually done the necessary builds/backports
>> to previous releases as appropriate (not all CVEs
>> may apply to previous Fedora releases as they
>> may have different package versions, of course).
>> I have mostly decided that in practice, as long as
>> I have done any appropriate builds/backports, and
>> one is just waiting for the usual distribution delays,
>> that it is good enough (although high severity
>> CVEs may need special handling).
>>
>> Or are you asking something different?
>>
> 
> I think in practical terms that makes sense but our tools don't really
> help.
> 
> Let's take the case of OpenImageIO[1][2], which is why I'm asking this
> question, I only update Rawhide when SONAME is bumped, so if a CVE is only
> fixed in the latest release, then only Rawhide, or Rawhide-1 (depending on
> when we branch) gets the fix.

My general rule is that a security fix is worth backporting a SONAME change
for, if there is no way to backport the patch.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Gary Buhrmaster
On Fri, Jan 20, 2023 at 4:47 PM Gary Buhrmaster
 wrote:

> such as yourself are contentious about
> doing the right thing).

Obviously that word should have been conscientious
(I hate autocorrect).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Gary Buhrmaster
On Fri, Jan 20, 2023 at 4:53 PM Kevin P. Fleming  wrote:

> Small clarification: where you wrote 'component' you meant 'product' :-)
> BZ has both Products and Components, forming two levels. RHEL 7/8/9 are
> Products, on the same level as Fedora.

Thanks.  I suppose I should have actually checked
the terms before posting.  But posting before
checking is a time honored tradition which I
am too often guilty of :-).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Kevin P. Fleming

On 1/20/23 11:47, Gary Buhrmaster wrote:

I agree, and that seems to be an artifact of
the single Fedora component in RHBZ, which
treats Fedora as one thing.

I supposed (in theory again) that there could
be a master bugzilla for the CVE which depends
on child bugzillas for each impacted Fedora
release, and would get (auto) closed only when
all the child bugzillas are resolved (either by
updates or the Fedora release aging out).

Alternatively, an entirely different bugzilla for
each Fedora release (but as Fedora is just
a single component, unlike each RHEL
which has different components for each
version, I don't think that works).
Small clarification: where you wrote 'component' you meant 'product' :-) 
BZ has both Products and Components, forming two levels. RHEL 7/8/9 are 
Products, on the same level as Fedora.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Gary Buhrmaster
On Fri, Jan 20, 2023 at 3:48 PM Richard Shaw  wrote:

> I think in practical terms that makes sense but our tools don't really help.

I agree, and that seems to be an artifact of
the single Fedora component in RHBZ, which
treats Fedora as one thing.

I supposed (in theory again) that there could
be a master bugzilla for the CVE which depends
on child bugzillas for each impacted Fedora
release, and would get (auto) closed only when
all the child bugzillas are resolved (either by
updates or the Fedora release aging out).

Alternatively, an entirely different bugzilla for
each Fedora release (but as Fedora is just
a single component, unlike each RHEL
which has different components for each
version, I don't think that works).

> So I guess what I'm asking is if there is a specific policy around this? If 
> not, should there be?

I think there should be at least an agreed
upon best practice, which needs to be
explicitly documented somewhere (maybe
it is, but I don't recall seeing it, so I am
not following it).

So, as with much of Fedora, we fall back
to depending on (usually volunteer)
packagers to do the right thing (which works
out well most of the time because packagers
such as yourself are contentious about
doing the right thing).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Richard Shaw
On Fri, Jan 20, 2023 at 9:22 AM Gary Buhrmaster 
wrote:

> On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw  wrote:
> >
> > So is it when a build is complete in Rawhide? Or must *ALL* active
> releases get the "fix"?
> >
>
> I am not sure it is official policy/practice, but in
> theory I would think that the CVE is technically
> closed when all impacted Fedora releases get
> the fix, but if you use various "Resolves rhbz#1234567"
> syntax in the change log (and I generally try to
> do so in addition to referencing the CVE by it's
> identifier) I seem to recall that as soon as the
> package hits rawhide the issue gets closed.  It
> is therefore up to the packager to make sure they
> have actually done the necessary builds/backports
> to previous releases as appropriate (not all CVEs
> may apply to previous Fedora releases as they
> may have different package versions, of course).
> I have mostly decided that in practice, as long as
> I have done any appropriate builds/backports, and
> one is just waiting for the usual distribution delays,
> that it is good enough (although high severity
> CVEs may need special handling).
>
> Or are you asking something different?
>

I think in practical terms that makes sense but our tools don't really
help.

Let's take the case of OpenImageIO[1][2], which is why I'm asking this
question, I only update Rawhide when SONAME is bumped, so if a CVE is only
fixed in the latest release, then only Rawhide, or Rawhide-1 (depending on
when we branch) gets the fix.

Typically in Bodhi you would mark the BZ as being fixed by the release
which by default closes the bug.

So I guess what I'm asking is if there is a specific policy around this? If
not, should there be?

Thanks,
Richard

[1] Actually not the best example, but the most immediate one. Upstream
(Larry) is actually quite good at backporting changes when needed.
[2]
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=OpenImageIO=Fedora=Fedora%20EPEL
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Gary Buhrmaster
On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw  wrote:
>
> So is it when a build is complete in Rawhide? Or must *ALL* active releases 
> get the "fix"?
>

I am not sure it is official policy/practice, but in
theory I would think that the CVE is technically
closed when all impacted Fedora releases get
the fix, but if you use various "Resolves rhbz#1234567"
syntax in the change log (and I generally try to
do so in addition to referencing the CVE by it's
identifier) I seem to recall that as soon as the
package hits rawhide the issue gets closed.  It
is therefore up to the packager to make sure they
have actually done the necessary builds/backports
to previous releases as appropriate (not all CVEs
may apply to previous Fedora releases as they
may have different package versions, of course).
I have mostly decided that in practice, as long as
I have done any appropriate builds/backports, and
one is just waiting for the usual distribution delays,
that it is good enough (although high severity
CVEs may need special handling).

Or are you asking something different?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: When to close CVE's

2023-01-20 Thread Siddhesh Poyarekar
On Fri, Jan 20, 2023 at 8:54 AM Richard Shaw  wrote:
>
> So is it when a build is complete in Rawhide? Or must *ALL* active releases 
> get the "fix"?
>

It depends on the severity of the CVE.  For High severity ones it
makes sense to fix in all active releases, less so for Medium/Low
CVEs.

hth

Sid
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue