Flock idea: Provide help to package maintainer when people file CVE (dedicated repo) #9
Labels
No labels
meeting
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
security/tickets#9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An idea that came up at Flock, and that formally just implements what actually is already written in the Packager Guidelines: provide a repository for tickets for packagers to reach out to when people file CVEs and the affected packagers ain't sure what to do about it. Sometimes it might be only little confirmation or direction they need, and today, people might also have a deterring "what to do when CVEs are filed?" in their minds when considering if they want to become packager (whereas we need more packagers...).
Having a separated repo ("CVE" or so) might be easier to discover for packagers, and it can be directly linked in guidelines etc.
Also, in case we want to support at some point private tickets for stuff that might be not yet ready for the public, we can have separate permissions to this repo.
CC @decathorpe
Yeah this was partly my suggestion. I think it might be a nice "service" that the Security SIG can provide for Fedora packagers who have never (or rarely) had to deal with security issues.
PS: I don't think using "CVE" in the name specifically is a good idea. Not all security issues get a CVE number assigned to them, and CVE is not the only numbering authority for security issues (for example, there is also the RUSTSEC advisory database specific to Rust crates).
I think I'm +1 on the general idea, but I think it'd work better as a form & tag on the tickets repo rather than a dedicated repo.
There are also a few docs and CI checks that say something along the lines of "Ask Security's permission" so would let them submit to the same place.
I would leave the decisions of the name of the repo, and if this is done in a separate repo at all, to you folks. I am currently no packager, so you might have a better perspective on how/where packagers in situations like the current one might look first and what they will look for. So I remain 0 about this.
But adding how I think it could become if we put everything in the ticket repo: if many would use this at some point, it could become confusing if all is in one repo (maybe not just for the packagers?). And not sure if the name of a repo makes a difference when people search for something ("ticket" in "security" is maybe not expressive and reassuring enough to have a strong incentive to open a ticket?), and the value of "review what had happened about this in the past" might decrease given that it is mixed with many other types of issues). In any case, we will not be able to have separate permissions in this repo (that might be of minor relevance for now anyway). Just thoughts to consider :)
Actually, not just partly :P But I tried to keep your points generic. After all the ai talking about ai plus the ai with the ai I was no longer sure if I remember all points correctly (not sure if you also said something about ai in this process?) :D
Approach has been agreed in the Security SIG Meeting on 18.6.2026:
4*+1
0*0
1*-1
Ticket template draft to be implemented by @decathorpe :)