as indicated in the title the purpose of this proposal is to have a new restricted mailing-list dedicated to security announcements.
The main goal of this mailing list would be to immediately and automatically announce when a new advisory has been completed. We decided in Security Policy: Stop announcing advisories on the forum to stop using the forum for that, and it’s possible to receive notifications through xwiki.org but it still remains more complex to just subscribe to a mailing-list to get the information.
The mailing-list could also be used to manually send information regarding security whenever there is a need: e.g. announcement about some new important best practices in XWiki in terms of security or important security policy changes.
The idea is that this mailing-list would be read-only for subscribers and the access would be restricted like for the existing security ML, but it wouldn’t necessarily be the exact same people in both ML. The reason for having a separation between both MLs is that the security ML should still be able to receive reports without broadcasting those before committers could actually read them and act on them. Also the security ML would still be a channel to discuss, where the new ML would be a channel to announce only.
Regarding who could write on the new security ML, I think we could restrict it to the Core Committers.
+1 in principle. What I’m missing in this proposal is the process how to get on this list. Would the idea be that we restrict the main security list more and security access wouldn’t give you access to it anymore but just to this announcement list? Or is the idea that we make it possible to get access to this list without getting full security access?
I think our current policy almost answers it already. In the checklist to add a new security member, the security ML is the only optional item, so security access already means “all private channels except the reports list”. I’d simply add the new list as a mandatory item of that checklist, and leave the security ML as it is.
I don’t think we can give access to it without full security access: the notification is sent when the advisory is announced, i.e. before the public disclosure, so subscribers need to agree to the same rules as any security member.
A few other points to settle:
The main sender will be the Security Advisory App on xwiki.org, so its sender address must be allowed to post, on top of the Core Committers. Do we need a SPAPP issue to send the notification to the list?
The archives must be private, like for the security ML.
Do we keep the xwiki.org notification as well, or does the ML replace it?
So I would go first with what Vincent said, but I think one big advantage of the new list might be to allow organization to gets access to it, and not only individuals. So it’s something I would propose probably in an amendment of the policy.
Yes we will need that, I wanted first to ensure we agree on the principle.
yes
I think we can keep it: the notif are opt-in only, I don’t see a strong reason to remove the feature.
Subscribers will need to agree to the same rules, but it still provides less access than full access:
it only grants access to advisories for issues that have been fixed, not unfixed ones, so the access is later in the process.
even if we send the full advisory to the list, we agreed to not include any PoC in them so it provides less information.
For these reasons, I think it would be interesting to provide access to this list without providing full security access. An example would be that we could allow sponsoring companies to provide access to this list/forward these emails to some of their clients with whom they have a non-disclosure agreement without those clients needing to explicitly ask for security access.