[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10280 [Firefox Patch Issues]: Torbrowser shouldn't load flash into the process space by default
#10280: Torbrowser shouldn't load flash into the process space by default
-------------------------------------+-------------------------------------
Reporter: mikeperry | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Firefox Patch | Version:
Issues | Keywords: tbb-testcase,
Resolution: | MikePerry201402R
Actual Points: | Parent ID:
Points: |
-------------------------------------+-------------------------------------
Changes (by cypherpunks):
* type: enhancement => defect
Comment:
Replying to [comment:27 mikeperry]:
> Replying to [comment:25 cypherpunks]:
> In all seriousness though, I actually don't believe your claims to be
the case at all. If these documents were separate (really they already
nearly are - the requirements and implementation already are in separate
sections), we *still* would not have had a requirement that plugins not
have been loaded into the address space, ...
Yes, this is correct. A discussion would have happened still. But the
discussion at then point is more clear: should we add this requirement,
and how shall we word it? Once that is done, then this automatically
becomes a functional defect--no further discussion necessary.
And then you can tract these things. You can track that you had either:
1. A defect in the requirements.
2. A defect in the design.
3. A defect in the code.
Lower number means harder to fix. Higher number, easier.
This is a defect in the requirements, because you did not have a
requirement that restricted this class of vulnerabilities, yet these are
realistic vulnerabilities.
>So no, having two pieces of paper instead of just one would not have
saved us from this argument.
Buy putting them in the same document, you make tracking changes in that
document more complicated. The documents should be revisioned and
versioned--and in source control. It should be clear who made what
change. This gets complicated if you obviously have diagrams and so on,
and formatting, in the documents. People use special software just for
this--you could get by with a text file, or simply multiple versions on
the file name, with text annotations of changes in the documents and in
the commit summaries.
Once that is done, a lot of things get easier. You can read a slew of
papers on this stuff. For the most part, you will benifit in your
projects with this approach because it is possible to completely spec
everything out before hand--you are not like a startup needing "Agile"
crap, because you have 10 clients that are all marketing people that don't
know what they want, and keep calling you each day with requirements
changes. We know exactly what we want Tor Browser to do. How it does it,
is design. Requirements changes should only be necessary in cases like
this, where someone finds need for a new requirement based on an increased
understanding of vulnerability surface, or because some new plugin or
change to firefox comes out, or html5 comes out, or stuff like that. Then
you know where these requirements are coming from, and can document that.
You then get the benifit of determining which designs cover which
requirements, which code covers which requirements, and eventually can
track bugs easier.
It was calculated in the 1970's and 80's that every hour spent on
requirements equals 100 hours less coding, and every hour on design, 10
hours less coding. (or something like that).
So in one sentance (or so) please explain what this new requirement is,
and add it to the requirements document (once you fix that up). Thanks.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10280#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs