we currently have a Github Security Team in both Github Organizations xwiki and xwiki-contrib. Those teams have been primarily created to allow people belonging to those teams to have access to the draft advisories: this is done right now by manually adding the team as collaborator of each new draft security advisory created.
In practice right now only the administrators of the repositories have the capabilities to create them: right now it means it’s the committers (or admins of contrib repositories).
My proposal is to extend that, to allow all members of the Security teams to be able to open draft advisories, by giving to the team the Security Manager role.
In practice, it still mean a committer will have to take ownership of security issues, to actually push the fixes, but a security contributor might be able to do the actual work, create the draft advisory, open a fork and propose the fix inside the fork.
The Security Manager role also gives a more rights to the people (taken from Github’s official doc):
Read access on all repositories in the organization, in addition to any existing repository access
Write access on all security alerts in the organization
The ability to configure settings for security features at the organization level, including the ability to enable or disable GitHub Advanced Security features
The ability to configure settings for security features at the repository level, including the ability to enable or disable GitHub Advanced Security features
One interesting side effect that I’m seeing, is that this role also gives people belonging to the group immediate access to all draft advisories, without needing anymore to add the group as a collaborator. So it simplifies a bit the creation of advisories.
Also I consider that people in this group are already people we trust, so giving them a bit more power should be ok IMO.
This means that a non-committer (ie a contributor with security access) would be able to create an advisory without creating a confidential jira issue. That doesn’t look great to me. It’s not an issue for committers since they know the workflow and that we need a jira issue.
So they’d be able to work in the advisory branch but without posting a PR for the jira issue?
I’m failing to see what is the reason for this proposal and what it fixes. Right now, anyone can create a confidential jira issue and open a PR for it. The only problem (and maybe this is what you wan to fix) is that if they’re not careful in the wording in the PR, they’ll disclose the issue publicly before we’re reading to disclose the CVE. But if that’s the issue you’re trying to fix, they’d still be able to provide a PR so not sure it would fix that issue.
Not sure what this does and what are the UCs where we’d want security contributors to send “security alerts”. I need to research what they are.
Why would we want to allow contributors to do that? That seems like a bad idea.
Right now I’m close to -1. Let’s say I’m -0 strongly. Especially because being able to change our security settings is a no go for me (without being a committer).
That’s probably because I don’t understand the need and what triggered this proposal.
Hi, it’s a +0 for me. I definitely see the appeal to ease the process of creating advisories, but there’s a clear concern on the other rights this would grant and I don’t see the full scope yet.
Technically yes. It’s something we could clarify when people are requesting security access: to ensure they read the policy and commit to respect it. Now honestly I don’t think it’s a real issue: people requesting access to the security in majority wants read access only. The few other ones are devs who already contribute and for those we are explaining the process.
It’s not the main goal (see below), but yes it’s actually one advantage.
This is actually forbidden: we don’t want people to do that at all. As it would disclose immediately the issue basically. We want people to use private security forks for that, which is the process documented in the security policy.
No the main issue I’m trying to fix is that we have contributors who are not committers who are trying to contribute fixing security issues on xwiki-contrib. And right now, they don’t have any rights on the contrib repositories so they’re not able to open draft security advisories: basically right now they have to ask a committer to do the job for them, which is time consuming and doesn’t bring any advantage.
Now as I indicated the fact they are then able to do everything until publication is really good for us: committers don’t need to be involved until review so it’s saving us time.
Security alerts are security advisories.
Strictly speaking we don’t. It’s just that the role also gives that. Now personally I don’t think it’s a strong issue compared to the benefits.
I do see several drawbacks (see my post above).