[launching-pad] Find a home for the Security Response WG #141
Comments
jamesmunns
added
the
A-teams
|
I don't think we work particularly closely with any team, we end up collaborating with libs and crates.io a bunch due to the nature of most vulnerabilities, but those aren't governance relations. To me this is a true horizontal, and it adds to the pile of other "horizontal" teams that the Rust project has that its governance structure is not well suited for. It likely should be a direct working group under the council. It could be under infra, but the sensitive nature of the team means that it should not be beholden to other teams with potentially less strict membership requirements. |
|
@Manishearth do you happen to have a list handy of teams you think would qualify as "horizontal" teams? There has been some discussion of "project serving" teams, WG-Security-Response and WG-Triage come to mind. I have a snapshot of the project structure, if that is useful to skim. I'm definitely interested in pushing for a better structure (over "just make easy fixes quickly"), and agree that there is not a good approach today for either of "cross cutting" or "does things that don't produce specific artifacts". Your opinions are very welcome here, or feel free to reach out to me privately to discuss. |
|
Infra, Security, Triage, Website, Moderation. Launching Pad itself. From defunct teams: Governance, Internationalization. When the new governance structure was being formed I did provide feedback that the requirement that all teams have a direct representative and the cap on council size would underserve horizontals and smaller teams like Community, but it got lost in the mix. For a more radical proposal: I don't actually think that compiler/devtools need to be separate toplevel teams, or language/library: you could instead have a pair of Product and Design teams, and that would free up space at the top level for teams like Community, which really should still exist if we can rebootstrap it. |
|
Given the structure we have, it seems most appropriate for this to become a subteam of T-infra. Some security reports are of course directly about things that concern T-infra. Others are not, but the horizontal coordination there seems most analogous in kind and character to that done by T-release. If we ever adopt a more radical reorganization, or create a top-level security team as was mentioned in #140, then we could of course adjust at that time. With respect to:
I've always gathered that our T-infra membership requirements are strict, but in any case, I feel sure that T-infra and the security response team could work out some mutually acceptable arrangement. |
|
@jamesmunns and I had a good talk. As a bit of necessary context here, I should mention that the above is just a friendly suggestion of what seems most appropriate to me. That is, I'm just speaking personally, and I'm in particular curious to hear what @jamesmunns, those on T-infra, and those on the Security Response WG think of the suggestion. On the council side, @jamesmunns is of course the one coordinating this, and is of course in my view doing a great job in that. Thanks to James for opening this tracking issue, for bringing the various parties together, and for updating the council on all the various progress on this endeavor. |
|
I don't have an issue with putting security response under t-infra. It's a better fit than "launching pad" at least, and if we feel that there's a problem with this later we can always revisit it. |
|
I want to push back a bit on the idea that Security Response, but also the Secure Code WG, should be sub-teams of T-Infra. Not that there's anything wrong with that, but I think it makes more sense to evaluate what the needs of the project are in terms of security and unify those efforts in a top-level team. For one, in my personal opinion, security is too important of a topic to be a sub-team. From a technical, an organizational, and a "marketing" perspective, it should be something that is considered at the top-level of the project. I don't think it would look good if we bury our security efforts somewhere deep in the organizational chart. Instead, I'd argue that there is a clear need for a proper home for security-related work. We already have the Security Response WG and the Secure Code WG. Personally, I also think that we should set up a signing team or working group this year that'll own the TUF implementation for releases and crates. Those are already three groups of people working on security in some capacity (and I'm certainly missing more), which in my opinion warrants setting up a |
IMHO there is something wrong with that. these WGs also target areas that are not strictly infrastructure, and putting them under the infra team, to me, implies that these WGs are scoped to our infrastructure. my understanding of the Secure Code WG however is that they work on crates that improve secure coding practices for all Rust developers, and they maintain the RustSec database, which targets third-party crates, not our own infrastructure. it just doesn't seem like the right fit. |
|
There's also T-devtools. I considered suggesting that for the team that updates the RustSec database (the rebranded Secure Code WG), and maybe that would be a better fit for that one in the current structure. That of course wouldn't seem to make as much sense for the Security Response WG. |
The problem is not that members of the infra team are not trustworthy. The security response wg tries as much as possible to keep information about vulnerabilities on a need-to-know basis. For some vulnerabilities we don't even loop in the whole team responsible for the affected area, but just subsets of it! The problem we have is not trust, but that the more people we loop in, as trustworthy as they are, increases the chances of accidental leaks. Also, the fact that membership of t-infra is quite strict is not actually true, as the privileges you get by just being in the infra team are not that higher than being let's say on the compiler team. Being in infra-admins (root access) is exceedingly strict, but the team is also working on reducing the amount of things that need infra-admin privileges. |
|
In general, my concern about putting the Security Response WG under any other team in the organizational chart is that it would be effectively useless. By design the team is mostly dormant during the year except when we receive incoming vulnerability reports, and all of those are handled privately. We don't even have a public Zulip stream 1! Trying to find a place to park the team just because of the rule requiring every top-level team to have council representation doesn't make much sense to me. Moving under a top-level team makes sense if we think that there will be useful interactions between it and its parent. Doing that just to work around council representation rules is making our organizational structure even harder to understand and getting basically no advantages in return over the status quo. I think the effort of @jamesmunns and the launching pad in general to find a better home for teams is great, and there are teams/wgs where restructuring or moving under a top-level team makes sense! But I'm thinking more and more that we shouldn't try to do that with all of the teams. The ideal end state I'd like is that we try to find a home for the teams where it makes sense to have a parent team, we promote the rest of them (including wg-security-response) into top-level teams, and the launching pad representative morphs into the representative of all of them. Footnotes
|
|
One of the guiding questions I ask myself in how to arrange things is:
It sounds like you're saying that's not T-infra here. But I'm not sure it's really the council either, and in particular, what we want to avoid is the council having that direct responsibility for a lot of teams on which we may not have great context. It's a hard problem. |
|
Honestly the way I would like to see things is that security response (and other launching pad teams that don't have a good parent team, website and this-week-in-rust comes to mind) becomes a top-level team without direct council representation, and the council rep for launching pad morphs into the council rep for teams that don't have a direct rep. Adding teams for example under infra just for the sake of finding a home for them practically achieves the same thing (they operate independently of their parent team and they have indirect representation), with the downside of adding more workload to the infra rep and making our organization even more confusing. |
|
Yes, what you say is perhaps a plausible outcome. It's worth considering. That is, those teams would be subteams of some top-level umbrella team with no members itself, as with the launching pad today. It'd essentially be a kind of rebranding and repurposing of the launching-pad "team". (The downside is that it might leave the council with a relatively large number of "direct reports", and to the degree that the teams under this umbrella lack shared interests, it would make the job of the council member representing them more challenging.) |
Honestly, I don't think that's a bug. As I understood the governance RFC, the council should own important topics like security or public relations, and then delegate the implementation of those topics to top-level teams. And conversely, I also think that the voice of people working in these fields should be represented on the council to help set the direction of the project. The website is a bit off-topic, but a good example. Any broader changes to the public facing properties of the project (website, blogs, social media, ...) will require approval by the council anyways. Having direct representation in the council will make it much easier to have discussions about what the future of the project's branding should be, and give the team working on it the necessary mandate to implement those changes. Which they'll need, because design is famously subjective... Similarly, I also think that it would be beneficial to consider security at the top-level of the project and have it represented on the council. Given the amount of supply chain attacks and the high profile that the Rust project has, we shouldn't make this a second thought and add layers of indirection between the council and the teams working on it. Eventually, we will probably have to react as a project to outside threats, and then it will be better if communication lines are short and flow from the top. What are the issue with council representation that prevent us from adding another top-level team? |
|
It just gets a bit unwieldy to operate and make decisions as a council with too many members, so we do want to keep the number of nominally top-level teams with council seats below some finite limit. There's also an aspect of balance. We want the membership of the council to be representative of project membership and the active work of the project. If we have many top-level teams with council seats that each represent only a small handful of people and possibly intermittent work, that creates imbalance with teams like lang and compiler where (inclusive of their subteams) the representatives each represent a large number of project members and generally more continuous work. |
No, it' very much a bug, per intent of the governance design. This was a topic I explicitly discussed with some of the people involved in forming the Council governance structure when it was ongoing. I pointed out that there were two incompatible goals:
I pointed out that we'd have to budge on one of these to effectively support the long tail of horizontals and other "important" teams Rust has. These goals were ultimately given equal footing, and the "launching pad" was a temporary solution for papering over the incompatability. "launching pad" is not a permanent solution: the goals of the team are primarily around finding homes for unparented teams, the goals of the team are not the smooth working of said teams. So the current situation we are in is by design, adding new toplevel teams was explicitly discussed and rejected as a solution. If the council wishes to revisit that decision, that's fine, but it's worth acknowledging that this discussion has happened before and the solutions being brought up here now are not new. I think the problems here stem from a couple issues in the governance design. Guiding principle behind team organizationFirstly, it's worth acknowledging that the current list of toplevel teams is largely inherited. It has not changed much from the original set of toplevel teams, which seem to be designed with the general principle of "one team per large work area", large work areas somewhat defined by the existence of a major contributor working on them ~ full time. As such, they're more about the amount of work; lang, libs, and compiler are each a large amount of work, and thus they have separate toplevel teams. Cargo used to be a toplevel team when it involved a fair amount of full time work, and over time it was subsumed into Devtools. However, when we talk about organizing new teams, we do not organize by amount of work, but rather the type of work, the artifacts owned, and the responsibilities. Some of the discussion above notes that T-security-response and a hypothetical T-security are not the type of work that T-infra does, for example. Nor are their responsibilities cleanly under the responsibilities of T-infra. But they're definitely (currently) a much smaller amount of work! Organizing by type of work / artifacts owned, there is very little reason for T-compiler to be separated from the rest of T-devtools: their work is producing a binary artifact that does things needed by Rust programmers, no different from T-clippy or T-cargo. They just have a much, much larger amount of work. Similarly, when organizing in such a way, one can argue that T-libs-api and T-lang do not need separate toplevel representation either (libs-impl is an interesting case; and there are different ways that could be handled). This might feel a bit extreme: but I think it highlights the crux of the matter here: do we allocate direct representation to large teams, or to teams of equal "toplevel importance"? If it's the former, then making some loosely-tied umbrella teams seems acceptable. If it's the latter, we may need to largely rethink how the teams are organized. Why must subteams have a representative?I think "subteams must have a representative" comes from a point of view of primarily thinking about large subteams. The problems leading to that rule were because large subteams had no representative (direct or indirect); which definitely is a problem. However, I don't particularly think that smaller teams (working groups?) like the security WG really need direct representation: we are capable of communicating with the necessary teams as needed, and the presence of one of our members on the council would not lead to much additional insight flowing in to either team. I think we should potentially recognize that this is okay and formalize better systems around it. Perhaps by having a primary point of contact, or a regular check in, or something, but having a well designed way to have small teams without "shared member" representation seems superior to the current state where everything is just in limbo. |
jamesmunns
added
the
I-council-nominated
|
Just noting that I appreciate all of the discussion here so far, and I've nominated this issue to be discussed in the next council meeting. I had expected somewhat to have this discussion a little later in the process, after resolving more of the "easy to move" teams, and seeing the structure of teams that were remaining to find a home. I agree with Manish that there's somewhat of an impedence mismatch between a few of the teams (and really "horizontal aspects" in general) remaining in the Launching Pad and "how we structure teams today". I don't think we need to pause the discussion, but I do want to note that there isn't a particular deadline for this - we're not asking these teams to move immediately, and I think it's worth enumerating the points raised here so far, and the context behind them, before we jump to any solutions. |
|
Yes, I don't mind this taking a long time to figure out! In its current state, T-security-response is able to get its work done and interface with the teams it needs, so there's no immediate fire to put out. |
FWIW, I remember this a bit differently -- it was rejected as an option for initial governance reform, not as a long-term rejection. We've already reformed top-level teams a little since then (e.g., infra / release, and crates.io, IIRC); I expect we should continue to do so, including potentially larger changes (as you suggest). I at least am broadly in favor of finding ways to alter the top-level structure if we think that helps, which may (or may not) include the "other" org that you might be suggesting implicitly. |
|
Sorry, let me correct myself: Increasing the number of top-level teams (and thus the council) was rejected, and I think that was a long term rejection: it was a key part of the design that each top-level team have its own representation, and the council size is capped. Reshuffling what these teams are was definitely put on the table for later, yes. |
|
Thanks for the thoughtful discussion and additional context, folks.
My personal view on this is that, for the health of the project, only the latter makes sense. Security will never get as many contributors as the compiler, for example, but I'd argue that for the long-term success of Rust it is equally as important. I'd want the council to consciously set priorities for the project and then organize the project in such a way that it can deliver those. Otherwise we might miss important work that is not interesting enough or well suited to gather a large group of maintainers to advocate for it.
Specifically for security, I believe it should be represented on the council outright. Given how sophisticated supply chain attacks have become and how much of a target Rust is/will become, I'd be strongly in favor of someone with the security hat being part of the project's leadership so that they are always in the loop. That is a broader mandate than that of the Security Response WG, though, which is why I believe it would make sense to form a I was contemplating an alternative were we establish "horizontal" teams (like infrastructure, security, PR, and moderation) that support the project, like @Manishearth suggested. A representative of each team could sit in on council meetings and offer their expertise, without being formally part of the council and its decision making processes. But those teams would need some form of representation on the council as well, and at that point I'm wondering what the benefit would be over making them a part of the normal org chart. |
|
We need to start with agreement on a basic premise. Given the focus on security in software around the entire world, it makes total sense that a primary team(s) focused on Rust security are front and center in the Rust Project's organization tree. Assuming we agree on that premise, then we need to figure out a way to make that happen. Obviously,
But let me throw this idea out there - I was talking with @walterhpearce and the idea was floated to create a new umbrella team called |
|
Yes, an ops team makes sense! |
This is a tracking issue for finding a long-term home for the WG-Security Response team.
Lead:
Hey there all, as part of #118, I'm starting the triage process of trying to find permanent homes for teams currently under the launching pad. As WG-Security Response is also a working group, #91 is also relevant.
In this first pass, I'm making tracking issues for each of the teams, starting the discussion on whether y'all think there is a reasonable team you think would make sense to move under, and in general checking whether the members of these teams are still actively working on things related to these teams.
I am aware that the Security Response team is still active, so no need to confirm that. Has the team had any other discussions of teams that they may have affinity with, or that might serve as a good place to make Security Response a subteam of? (Infra comes to mind, but that might not be a reasonable guess).
Thanks!
The text was updated successfully, but these errors were encountered: