Re: Draft schedule for Tor 0.2.1.x.

["Kyle Williams" <kyle.kwilliams@xxxxxxxxx>]

Nick,

I have a suggestion.  Automatic updates.  
Here is my reason as to why I feel this is probably the most important feature you need to implement.
"
Mar 31 2008 08:27:52.240 [notice] Tor 0.1.2.9-rc opening new log file.

....
"
That wasn't my tor log, but someone else.  There are still clients out there that are still affected from the POC last year, EVEN after they updated to the new version. Check your torrc files folks.

Looking back on Defcon last year, wouldn't it have been nice to be able to issue an update and know that most of the users would have been updated within 24-48 hours?  Look at the OpenSSL screwup from last week, wouldn't that have been nice to be able to issue an update then too (even though it wasn't your fault)?

I know that you and Roger don't like the in your face approach, but I still feel that security vulnerabilities/updates need to be brought to the users attention by displaying big, obvious, in your face alerts about problems.  E-mail sometimes isn't fast enough.  And simply making a notice or warning of it in the log file doesn't cut it.   You wouldn't want to scare the user by telling them there is a problem with no solution, so having a big "Upgrade Now" button in the security alert window would be nice.

You never know what tomorrow brings, and how the face of security could change in the blink of an eye.  ;-)

Best regards,
Kyle

On Mon, May 19, 2008 at 12:56 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

Hi, folks!

It's time to start talking more about what goes into the next release
of Tor, the 0.2.1.x series.  I think this release's development will
go much more smoothly if we have rough time windows in mind for when
parts of its development need to be done.

These are all rough targets.  We can bend them if we have a big reason
to do so, such as fixing a big security problem or interoperating
right with an important external project.  On the other hand, we
shouldn't bend them unless we're willing to risk delaying the release
by doing so.  I've tried to include rationales inline.

Here are the rough dates for the next release:

==============================
June 30: PROPOSAL CUTOFF.

All feature proposals for consideration should be in and discussed
before this date.  In the meantime, we should already be implementing
accepted proposals.  Note also the "and discussed": complex proposals
received on June 29 are unlikely to be adequately discussed by June
30.

Trivial proposals might be accepted after this date, if they are
indeed trivial.

July 15: ARCHITECTURE FREEZE.

No major architectural changes should get made to Tor after this date.
[I'm leaving "major architectural change" deliberately underdefined.
It would definitely include switching how we use libevent buffers, or
making big changes to our threading model.]

August 15: FEATURE FREEZE.

No new features should be added after this date.  This is when we
should move to pure testing and bugfixing.

September 15: FIRST RELEASE CANDIDATE

If we've not pushed the other deadlines too hard, we should be ready
for release by now.
==============================

Note that the important thing to do now is to improve and discuss
feature proposals, and write new ones.

yrs,
--
Nick Mathewson