... | ... | @@ -15,7 +15,7 @@ question several years ago: what is the process for rating a bug? The team set d |
|
|
|
|
|
categorize bug by severity (low means public work, medium means private work, high is private work and released asap; high vs. critical (difference is in case of the latter there is a shout-out to people and urging them to upgrade/update)
|
|
|
|
|
|
TROVE (Tor Registry Of Vulnerabilities and Exposures): private ticket with work and public ticket just as a placeholder with minimal info
|
|
|
TROVE (Tor Registry Of Vulnerabilities and Exposures) is used; private ticket with work and public ticket just as a placeholder with minimal info
|
|
|
|
|
|
"exposure" = maybe data leak in a wide sense
|
|
|
|
... | ... | @@ -23,69 +23,63 @@ gitlab confidential tickets are tricky (who is allowed to look at confidential t |
|
|
|
|
|
dev patches on individual private forks, CI does not work currently so there is none yet
|
|
|
|
|
|
works well as
|
|
|
security policy/TROVE system works well as
|
|
|
- no discussion of how severe a bug is while dealing with the incident
|
|
|
- no need to reinvent the process while dealing with the issue
|
|
|
- we don't lose security issues
|
|
|
|
|
|
nick's suggestions:
|
|
|
- look over netteam sec policy and think about what you like to change
|
|
|
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. TROVE has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
- 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
|
|
|
|
|
|
types of severity might not make sense for browser
|
|
|
GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
|
|
|
- high etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
- no embargo for upstream issues (can't get told about secret openssl bug but not to tell the openssl devs)
|
|
|
level high etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
|
|
|
- how to track upstream sec bugs
|
|
|
- for tor it does not make sense to file separate tickets for upstream sec
|
|
|
bugs
|
|
|
no embargo for upstream issues (can't get told about secret openssl bug but not to tell the openssl devs)
|
|
|
|
|
|
- severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
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
|
|
|
|
|
|
- GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
|
|
|
Should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
- severe enough bugs get a CVE
|
|
|
- nick recommends against using gitlab labels for that (no "trove" or "security" label)
|
|
|
|
|
|
Who is the intented consumer of that TROVE list?
|
|
|
- teams should keep a look at that and if a report comes in we need to make sure
|
|
|
- teams should keep a look at that and if a report comes in we need to make sure the issues are correctly tracked
|
|
|
- security bug retrospective if wanted
|
|
|
- transparency for external consumers (how many sec bugs we know about, when did we fix them etc.)
|
|
|
- could be helpful for packagers whether they should backport patches
|
|
|
|
|
|
The wiki is fine for now but maybe we want to have a real database at some point
|
|
|
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 TROVE yet but it might be a good idea to have a propor process here, although there is some disclosure process 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 propor process here, although there is some disclosure process right now
|
|
|
|
|
|
trying to be non-committal about commitments
|
|
|
trying to be non-committal about commitments in the security policy
|
|
|
|
|
|
no tooling around TROVE yet but nick would love to have some if we know as an org what we want
|
|
|
no tooling around TROVE/security policy yet, but nick would love to have some if we know as an org what we want
|
|
|
|
|
|
maybe next steps could be different teams suggest TROVE changes taking other teams' ideas into account; having one document and different TROVE documents per team seems to be a smart idea
|
|
|
maybe next steps could be different teams suggest security policy changes so we can take other teams' ideas into account; having one document instead of different security policy documents per team seems to be a smart idea
|
|
|
|
|
|
MR workflow would be good in general, maybe sticking everything in to a separate repo to make that one easier might be good
|
|
|
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; sometimes Incidents and confidential Incidents for sec related things
|
|
|
TPA has incidence response flow; Incidents and confidential Incidents for sec related things are used
|
|
|
|
|
|
Maybe teams that don't ship software might need something else (e.g. what does a sec bug look like in network-health land)?
|
|
|
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)
|
|
|
- nick thinks we might want to use gitlab confidential issues more and make that flow nice
|
|
|
- there is a gitlab plugin for schleuder (BUT then we'd get the spam problem in gitlab )
|
|
|
- there is a gitlab plugin for schleuder (BUT then we'd get the spam problem in gitlab)
|
|
|
|
|
|
could we require email submitted to schleuder list to be encrypted: no (although technical possible to enforce)
|
|
|
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 their own issues they report
|
|
|
many folks have a hard time to evaluate the severity of the issues they report
|
|
|
|
|
|
sympathy for sunsetting schleuder list
|
|
|
there is sympathy for sunsetting schleuder list
|
|
|
|
|
|
no way right now to submit anonymously sec issues to gitlab and then being in the conversation (no maintainer for anonymous sec reporting tool)
|
|
|
gitlab account creation tool and approval process is not really maintained (not run on TPA servers), juga might look at it for maintenance purposes
|
|
|
|
|
|
TODO: add links to anon-ticket and lobby projects
|
|
|
no way right now to submit anonymously sec issues to gitlab and then being in the conversation (no maintainer for [anonymous sec reporting tool](https://gitlab.torproject.org/tpo/tpa/anon_ticket))
|
|
|
[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
|
|
|
|
|
|
maybe HackerOne as a solution to sec bug reporting and getting a convo going with the reporter
|
|
|
- problem of external provider selling bug reports
|
... | ... | |