... | ... | @@ -19,9 +19,11 @@ |
|
|
|
|
|
- "exposure" = maybe data leak in a wide sense
|
|
|
|
|
|
- Gitlab confidential tickets are tricky (who is allowed to look at confidential tickets); it's a good enough way for network team right now, though
|
|
|
- Gitlab confidential tickets are tricky (who is allowed to look at confidential tickets, many roles have access); it's a good enough way for network team right now, though
|
|
|
|
|
|
- dev patches on individual private forks, CI does not work currently so there is none yet
|
|
|
- sometimes working over two tickets, one public, one private
|
|
|
|
|
|
- dev patches on individual private forks, CI does not work currently so there is none yet, unclear if that is possible with private branches at all
|
|
|
|
|
|
- security policy/TROVE system works well as
|
|
|
- no discussion of how severe a bug is while dealing with the incident
|
... | ... | @@ -30,20 +32,32 @@ |
|
|
|
|
|
- nick's suggestions for other potential teams/the org:
|
|
|
- look over netteam security policy and think about what you like to change
|
|
|
- maybe we get to a single inter-team policy
|
|
|
- maybe different definitions for what security levels are (e.g. the netteam security policy has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
- types of severity might even not make sense for browser
|
|
|
- maybe it could be a good organisation-wide policy
|
|
|
- but we may have different definitions for what security levels are (e.g. the netteam security policy has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
- types of severity might even not make sense for browser or other teams
|
|
|
|
|
|
- GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
|
|
|
- security level "high" etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
|
|
|
- some things are *not* security issues, like ignoring security warnings
|
|
|
|
|
|
- the netteam actually went through historical vulnerabilities to classify them and determine how to answer future issues
|
|
|
|
|
|
- no embargo for upstream issues (can't get told about secret openssl bug but not to tell the openssl devs)
|
|
|
|
|
|
- how to track upstream sec bugs: for core tor it does not make sense to file separate tickets for upstream sec bugs, maybe for other areas it does
|
|
|
- how to track upstream sec bugs:
|
|
|
- for core tor it does not make sense to file separate tickets for upstream sec bug
|
|
|
- for tor browser, sometimes tickets are filed for upstream issues, other times just released
|
|
|
- for TPA, some problems are tracked in incidents (special gitlab issues!), most are not and just automatically deployed, those type of problems treated as the wider problem of "incident response"
|
|
|
|
|
|
- severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
|
|
|
- questions over whether the policy specifies response time frames or specific workflows:
|
|
|
- netteam has a policy of answering incoming requests systematically
|
|
|
- can do coordinated releases with (e.g.) researchers
|
|
|
- 60 days release limit?
|
|
|
|
|
|
- should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
|
|
|
- who is the intended consumer of that TROVE list?
|
... | ... | @@ -54,7 +68,7 @@ |
|
|
|
|
|
- the wiki is fine for now for tracking purposes but maybe we want to have a real TROVE database at some point
|
|
|
|
|
|
- how to deal with bug reporters and interact with them: there is nothing like that in the security policy yet but it might be a good idea to have a propor process here, although there is some disclosure process mentioned right now
|
|
|
- how to deal with bug reporters and interact with them: there is nothing like that in the security policy yet but it might be a good idea to have a proper process here, although there is some disclosure process mentioned right now
|
|
|
|
|
|
- trying to be non-committal about commitments in the security policy
|
|
|
|
... | ... | @@ -64,8 +78,6 @@ |
|
|
|
|
|
- MR workflow would be good in general, maybe sticking everything into a separate repo to make that flow easier might be good
|
|
|
|
|
|
- TPA has incidence response flow; Incidents and confidential Incidents for sec related things are used
|
|
|
|
|
|
- maybe teams that don't ship software need something other than the type of security policy used by the network team (e.g. what does a sec bug look like in network-health land)?
|
|
|
|
|
|
- nick explains the pain with the schleuder list bug intake (e.g. mostly encrypted spam)
|
... | ... | @@ -74,7 +86,7 @@ |
|
|
|
|
|
- could we require email submitted to schleuder list to be encrypted: no (although technically possible to enforce)
|
|
|
|
|
|
- many folks have a hard time to evaluate the severity of the issues they report
|
|
|
- many folks have a hard time to self-evaluate the severity of the issues they report
|
|
|
|
|
|
- there is sympathy for sunsetting schleuder list
|
|
|
|
... | ... | @@ -82,14 +94,18 @@ |
|
|
|
|
|
- [gitlab account creation tool](https://gitlab.torproject.org/tpo/tpa/gitlab-lobby) and approval process is not really maintained (not run on TPA servers), juga might look at it for maintenance purposes
|
|
|
|
|
|
- nick's priority for those two tools:
|
|
|
- ability to delete spammy users (not reported, will report)
|
|
|
- ability to immediately reject submissions if they haven't modified the template
|
|
|
|
|
|
- maybe HackerOne as a solution to sec bug reporting and getting a convo going with the reporter
|
|
|
- problem of external provider selling bug reports
|
|
|
- attracting the wrong folks (some just scanning your website for some supposed sec bugs)
|
|
|
|
|
|
- security policy could be seen as part of a disaster recovery policy
|
|
|
- broader security policy question (https://gitlab.torproject.org/tpo/team/-/issues/41) could be seen as part of a disaster recovery policy (https://gitlab.torproject.org/tpo/core/team/-/issues/17)
|
|
|
|
|
|
- overall summary:
|
|
|
- decommision schleuder for sec bug reporting
|
|
|
- consensus for looking at TROVE process for other teams/whole project, getting specific gitlab project going for that for tickets to coordinate that discussion (maybe rhatto can help with that) (repository opening first week after the meeting week, having this finalized at least by the end of 2022)
|
|
|
- retire schleuder security list for sec bug reporting
|
|
|
- consensus for looking at TROVE process for other teams/whole project, getting specific gitlab project going for that for tickets to coordinate that discussion (maybe @rhatto can help with that) (repository opening first week after the meeting week, having this finalized at least by the end of 2022)
|
|
|
- getting anon-reporting/lobby tools maintained
|
|
|
- for further ideas, discussions around this problem, see the [security issue intake process ticket](https://gitlab.torproject.org/tpo/team/-/issues/73) as well |