...cut...

All the security bugs including ImageTragick was closed automatically when F23 went EOL.
...cut...
See: https://bugzilla.redhat.com/show_bug.cgi?id=1299275#c153

Edited the original post to include comment # in Bugzilla & it is F23 (not F21).

<tag>meeting</tag>

I'm +1 for this suggestion, though we might need to put some rules in place to properly categorize CVE bugs if they are not already classified in some manner. Otherwise the script won't be able to key off of data in the bugs themselves.

@jwboyer: I think that in most cases, Red Hat Product Security does a very good job with attaching things to tracker CVE bugs, even if a package is only in Fedora or EPEL.
They also add a lot of very useful metadata we could use to script stuff, including CVE ID, and sometimes exact affected versions of Fedora/EPEL.

@jwboyer: I think that in most cases, Red Hat Product Security does a very good job with attaching things to tracker CVE bugs, even if a package is only in Fedora or EPEL.
They also add a lot of very useful metadata we could use to script stuff, including CVE ID, and sometimes exact affected versions of Fedora/EPEL.

I absolutely agree. They do an amazing job.

However, are 100% of the security bugs opened in Fedora done so by that team? I don't believe we can definitively say so. Also, are that team's bugzilla standards codified as Fedora process/policy as well? It would be nice to document the metadata and such and adopt them as official Fedora process for security bugs.

I fear without at least trying that, we're going to miss some bugs. At least with a documented process, we can point people to that if they complain we closed their security bug.

FESCo Meeting 2017-07-21

  * AGREED: wait another week, ask for input from program manager and
    what work needs to be done with EOL scripts (+1:5, +0:0, -1:0)
    (maxamillion, 16:46:27)

I can modify the EOL tooling to exclude all the bugs having Security keyword set. Just let me know :-)

Does it make sense to increase the version of such bugs to the latest supported Fedora release to avoid cumulation of open bugs on unsupported releases ?

I can modify the EOL tooling to exclude all the bugs having Security keyword set. Just let me know :-)
Does it make sense to increase the version of such bugs to the latest supported Fedora release to avoid cumulation of open bugs on unsupported releases ?

Yes I think it makes sense to increase the version of the bugs.

i.e. when F24 becomes EOL, it makes sense to also change it to F25.

In today's FESCo meeting, it was decided to enumerate various ideas in this ticket and on the devel mailing list, and revist next week (+1:5, +0:0, -1:0)

My suggestion would be for the security bugs to behave a needinfo set on it for the pkg-owner@fedoraproject.org alias. That way, at least the owners get nagged about it between the announcement of the impending mass-close and the actual event.

Setting needinfo flag for security bugs is not an issue for the tooling. So, I am fine with it. The only remaining issue for the tooling, I see, is identification of security issues. Will we start to use "Security" keyword for such bugs ? Currently this keyword is not used on Fedora project in Bugzilla (at least the keyword is not used reliably).

In Friday's FESCo meeting, it was decided that the EOL scripts will be adjusted to move keyword: security bugs to the next release and add a note that this was a security bug and should be checked to see if it's fixed in the next release.