I understand the sentiment, but unfortunately there's a complete mishmash of severities in that list. Some are actual issues, and some are rather theoretical issues that don't matter in normal circumstances.

I think we could treat CVE bugs the same as FTBFS bugs, i.e. subject those packages to the same notifications and staged removal described in the newly-approved policy in https://pagure.io/fesco/issue/1890. (One problem is that this policy hasn't been implemented so far, but I hope to fix.)

I understand the sentiment, but unfortunately there's a complete mishmash of severities in that list. Some are actual issues, and some are rather theoretical issues that don't matter in normal circumstances.

Quite possible, but those trackers should be closed by the maintainers with an explanation as to why these are not "real" issues. Keeping them open does not solve any problem imo :)

I think we could treat CVE bugs the same as FTBFS bugs, i.e. subject those packages to the same notifications and staged removal described in the newly-approved policy in https://pagure.io/fesco/issue/1890. (One problem is that this policy hasn't been implemented so far, but I hope to fix.)

Correct, i am seeking a policy change, technicalities can be easily figured out later i think!

those trackers should be closed by the maintainers with an explanation

You're correct obviously, but so far we have been rather lax about those bugs, and suddenly removing packages, some of them rather important, is not an option. This needs to be done in a way that gives the maintainers of the package, and of dependent packages, time to react and escalate the issue if necessary.

Correct, i am seeking a policy change, technicalities can be easily figured out later i think!

Hooking this up to the FTBFS process is effectively a policy decision — it sets the timeline and the warnings and the steps, and pretty much all technicalities, since the same procedure is to be followed for both types of bugs.

As noted, the proposal is presently too broad, and too narrow. Many of the issues are at best 'alerts' that some helper script is insufficiently cautious. It may be proper in some security models to remove such, but I think it is over-kill here

The rpm cpio path following exploit is not reachable with signed content, and really any fault for letting binaries with such through would belong elsewhere ... (and really is so general, that it is not 'solveable', while remaining cpio conformant)

With the new FESCO approach on issue closing, this one needs to be turned down, and if 'sharpened come back, rather than being a 'talklng draft policy'

I'll note about the proposed plan that we cannot completely remove packages from stable releases.
We can block packages from new builds and remove any updates from updates/updates-testing, but that still leaves the package as it was at release time for that release in the base repos. In some cases this might make things worse as we are still shipping the insecure version and don't have any way to update it if some fix came along. ;(

We can really only remove packages before release time.

I'll note about the proposed plan that we cannot completely remove packages from stable releases.

I am not proposing this. I am proposing we remove them from the next release, similar to the FTBS process. This should be easier then removing them from updates/updates-testing.

We can block packages from new builds and remove any updates from updates/updates-testing, but that still leaves the package as it was at release time for that release in the base repos. In some cases this might make things worse as we are still shipping the insecure version and don't have any way to update it if some fix came along. ;(
We can really only remove packages before release time.

This is what i am proposing!

As noted, the proposal is presently too broad, and too narrow. Many of the issues are at best 'alerts' that some helper script is insufficiently cautious. It may be proper in some security models to remove such, but I think it is over-kill here
The rpm cpio path following exploit is not reachable with signed content, and really any fault for letting binaries with such through would belong elsewhere ... (and really is so general, that it is not 'solveable', while remaining cpio conformant)

The above are really specific examples, if such security issues do exist, they should be closed with comments. I am not asking you to solve these at all. And these should not result in package removal from the distro.

Out of all the security issues filed against fedora, it is quite possible that ~20-40% arent really addressable ,and there is no reason why they should not be closed.

With the new FESCO approach on issue closing, this one needs to be turned down, and if 'sharpened come back, rather than being a 'talklng draft policy'

Lastly, we always have a list of critical path rpms, which cannot be removed from the distros, like rpm etc. so that we dont break the install, due to package removal.

Lastly, we always have a list of critical path rpms, which cannot be removed from the distros, like rpm etc. so that we dont break the install, due to package removal.

Your bugzilla query did not 'whitelist' any such, and I do not know of a durable location with such a list of 'critical path' RPMs

May I see a script to produce such a 'non-exempt' list? Without it, this is just arm-waving

Lastly, we always have a list of critical path rpms, which cannot be removed from the distros, like rpm etc. so that we dont break the install, due to package removal.

Your bugzilla query did not 'whitelist' any such, and I do not know of a durable location with such a list of 'critical path' RPMs
May I see a script to produce such a 'non-exempt' list? Without it, this is just arm-waving

My proposal is in line with:
https://fedoraproject.org/wiki/Critical_path_package?rd=Critical_path_packages
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal

Such a list is not difficult to compile/edit etc and should not be a blocker to this proposal.

@huzaifas, can you bring this matter to the devel mailing list? We discussed it at the meeting today and we would like to gather some more input from the general developer audience before discussing it again next week.

@huzaifas, can you bring this matter to the devel mailing list? We discussed it at the meeting today and we would like to gather some more input from the general developer audience before discussing it again next week.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZCM54WM3WYZAJ3MXAOXJHLZCUGZONN3F/

Also i plan to talk about this during FLOCK this year.

Note that we identified a very similar issue in the crypto fedora packages. We ship many packages with no upstream release for 5 or even 10 years (libtomcrypt, beecrypt), and CVEs not only accumulate, but worse they are not being reported at all (no-one expects these components to be used by real software). A compromise could be to use the approach Huzaifas proposes for packages considered to be the "security perimeter" of Fedora (crypto, networking, and packages which relate to security), and in these we can also be stricter by requiring a live upstream (releases in cadence < 5 years).

I'm +1 to this. Leaving packages in the distribution with known dead upstreams and known CVEs is setting our users up for a terrible experience. We are supposed to be the curators of this content and removing insecure software should be part of that curation.

proposal: If a CRITICAL or IMPORTANT security issue is currently open against a package, or a security issue of lower severity has been open for at least 6 months, at the branch point a procedure similar to long-standing FTBFS will be triggered immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This applies to all packages, not just leaf.

I'm +1 to that general idea, but I'm concerned that doing it at branch point could put the release date at risk. Could we make the action date earlier than the branch date to alleviate that risk?

We certainly could. Do you have a proposal for the date?

On 08/20/2018 01:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

Do you have a proposal for the date?

How about 4 weeks prior to branching, and they have until Bodhi
activation to respond? I think that's 6 weeks.

This was discussed in yesterday's meeting (2018-08-20):
AGREED: - Postpone decision until next week, awaiting zbyszek's proposal in ticket (+5, -0, +0)

The proposal: https://pagure.io/fesco/issue/1935#comment-527041

This was discussed in yesterday's meeting (2018-08-20):
AGREED: - Postpone decision until next week, awaiting zbyszek's proposal in ticket (+5, -0, +0)
The proposal: https://pagure.io/fesco/issue/1935#comment-527041

I like and agree to the above proposal!

From the FESCo meeting today:

  * AGREED: If a CRITICAL or IMPORTANT security issue is currently open
    against a package, or a security issue of lower severity has been
    open for at least 6 months, four weeks before the branch point a
    procedure similar to long-standing FTBFS will be triggered
    immediately, with 8 weeks of weekly notifications to maintainers and
    subsequent orphaning and then subsequent removal from distribution.
    This applies to all packages, not just leaf. (+6, 0, -0)
    (contyk, 16:00:25)

What should be the next action here?

From the FESCo meeting today:
* AGREED: If a CRITICAL or IMPORTANT security issue is currently open
against a package, or a security issue of lower severity has been
open for at least 6 months, four weeks before the branch point a
procedure similar to long-standing FTBFS will be triggered
immediately, with 8 weeks of weekly notifications to maintainers and
subsequent orphaning and then subsequent removal from distribution.
This applies to all packages, not just leaf. (+6, 0, -0)
(contyk, 16:00:25)

What should be the next action here?

IMO two things we need to do:
1. Document/Announce this change (Not sure if fesco does that or i should, but pls let me know)
2. Engage RCM and make changes to the branching script (or what ever it is called, to ensure that the above policy is adhered to) - i can do this

I sent out the announcement: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/A5AOCRX75X4ULTWRJVF7JYT7V2LL6RXR/

1. Engage RCM and make changes to the branching script (or what ever it is called, to ensure that the above policy is adhered to)

Actually I don't think this can/should be tied to branching. The whole process needs to start 4 weeks before branching, and will continue long after branching. So I think a separate script will be needed. But it would be great if you could start working on the scripting to do this. I think getting a list of bugs that meet the agreed criteria would be the first step, useful on it's own even without the parts that do any actions.

Hmm, my mail to announce@ got rejected. Can somebody with the right privs resend it?

Pfff, it should be devel-announce@. I resent it myself now.

A followup to move this forward: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN5GRXPY6AP5C4WNOV7GNDQ3Z5NRMTSJ/