Investigate Membership of linux-distros Mailing List #13
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?
Right now Fedora doesn't have a representative on the linux-distros mailing list and things would be easier if we did. This is a private mailing list where vulnerabilities are pre-disclosed so distributions can prepare their updates and release them as soon as the embargo lifts.
Messages on this mailing list are sensitive and we'd get in a lot of trouble if they leaked, so let's make sure they don't.
Some questions that I have based on the discussions we've had:
Just to make sure everyone knows, Fedora has no embargo process. Once a maintainer commits something to src.fedoraproject.org it's public. :)
I'd also worry about the load of people reading the list and filing private bugs, but I have no idea what the volume is, so perhaps it's fine...
Agreed today:
General tendency: 1+ proven packager might be nice, but not a requirement, other things are relevant too (our AI bot ain't bad:). Having 2 people added seems to be the preference. The policy draft will precede a decision of who that should be. There is a consensus that @jforbes should be one of them.
First topic of today's meeting:
https://meetbot.fedoraproject.org/meeting-3_matrix_fedoraproject-org/2026-07-09/security-sig.2026-07-09-15.04.log.html
https://meetbot.fedoraproject.org/meeting-3_matrix_fedoraproject-org/2026-07-09/security-sig.2026-07-09-15.04.html
Related to linux-distros discussion regarding incentives for policies etc:
https://almalinux.org/security/
https://almalinux.org/p/vulnerability-disclosure-policy/
@jforbes off the cuff I would say we need a new component (e.g.,
linux-distrosor whatsoever) in our bugzilla, right?That way we can add the intended participants automatically to the very tickets, but no one else (at least not automatically). Everything else feels error prone. I still ask because the last time I worked with a private bugzilla ticket was an SELinux case ~1 year ago, so I might miss some possibilities (?)
That would be a good way to make sure that the full set of package maintainers can not see the information, only the individual who is read in. The bugzilla tickets need to be created by the persons who are representing Fedora on the list. The tickets are created against the package being read in as private tickets. I believe there are a couple of bits we need to consider before creating those tickets though.
I think we should call it
distribution-private, so it's not specific to the list.Some initial thoughts of what could be contained in a potential policy:
distribution-private(name to be adjusted)linux-distroscan be added to the component without FESCo approvallinux-distros(and acting as any of these distributions' representatives inlinux-distros) can be added at the discretion of the Security SIG, without FESCo approval-1).-> FPDA (name to be adjusted) must be drafted -> might involve legal team?
There is much to criticize about this, but it might be something to start a discussion with and bring up some questions...
Supplement 1: For contacting others, before they are added to a ticket, Matrix PM (end to end encryption) might be useful?
Supplement 2: "all information of the component shall be used only for purposes relevant for the security of the mentioned Linux distributions and/or the
Linux-distrosmailing list."This incorporates thoughts of the meeting logs, but I am not sure if it is appropriate to allow any (Security SIG) members who ain't members of the linux-distros list to be auto-involved in the component?
From talking to the Samba folks, I think the ticket approach described here would work. Users in the appropriate FAS group can see the ticket pre-disclosure and we can just move the ticket out of that component once the embargo lifts. IIRC, Red Hat's bugzilla is maintained by @agk who we'd probably need help from to implement this.
In bugzilla, security is controlled by groups, bug-by-bug. For example, we might create a new "secure" group for embargoed Fedora security bugs and limit the access to the small team. You would then put embargoed bugs into that group. Bugzilla's emails then just say "something changed on bug number N" unless you provide a GPG key so it can encrypt your email. You could have a "secure" security-embargoed component which would mean its bugs have to be private when they are created, or you could handle it within the existing components controlling the assignees yourself when creating the bugs.
Alternatively you could set up a separate "Fedora Security" product, separate from "Fedora" and lock that down more tightly. (One like that already exists from the past.)
We also have available the bugzilla "rules engine" which can provide automation (and after-the-fact validation, enforcing rules).
As discussed, I will provide a draft in a PR for #13 (comment)
-> I will keep Neal's suggested component name
distribution-privatefor now, but we can change that later tofedora-security(which was brought up in the meeting today). Personally I find both ok.-> I implement the publishing at the end in a transparent way that allows the discussed case-by-case flexibility: allowing to re-assign the private ticket to the real component or opening a new ticket at the real component with a link to the private one. Deriving from the feedback in the meeting: I will formulate it for now to prefer a new ticket at the real component (with a link) in case of a doubt, unless it is ensured no harm can rise if the private ticket is re-assigned to the public component.
-> I will keep it neutral to the used service, only assuming a private ticket service. May it be bugzilla, forge, or whatever. With easy-to-update links to the very service. Yet, using "component" is already something specific: I keep it in a way that can be easily updated to "repos" or so, without the need for a major reformulation/revision if the concepts are not equal.
-> I will assume the
sec-bugzappersFAS group for the component.-> I assume a component, not a separated product in bugzilla for now.
I try to provide the PR before the next meeting. At least something that can be discussed. The branch will be open for changes by other team members (I keep it in the SIG repo).
Not yet clear:
-> can we sign up the component to the mailing list with a service?
-> should or must the FAS group
sec-bugzappersbe unconditionally equal to the mailing list members?PR: security/docs#17
See text of PR -> Security SIG members can edit the PR -> feel free :)
Supplement: this PR is CLOSED -> see next post!
Supplement, I had to create a new PR, as fast-forward in the test window to verify if it solves the test seems to lead to an auto-merge... I already reverted the mess. The new PR is here: security/docs#18
#17 is closed and the commits removed again from the target branch.
See text of PR -> Security SIG members can edit the PR -> feel free :)
Regarding security/docs#18 (comment) : In the meeting of 6.8.2026, we agreed that the next step is to ask Legal if we will need a "Fedora Pre-Disclosure-Agreement" (FPDA) or if the PR with the policies in combination with the contributor agreement are sufficient to comply and to protect the Linux-Distros mailing list from our PoW.
Everyone is free to take over this task. People can in parallel review and improve the document, which presumes the FPDA only in a few paragraphs: so most parts of the policies are not affected by any Legal suggestion anyway.
Until then, I remove this from the meeting in #13 . Everyone is free to add it again when something specific is to be discussed or if there is any progress.