[tor-dev] Extending deadline for small features in 0.2.3.x by one week (to the 13th)

[Jacob Appelbaum]

On 01/09/2012 04:33 PM, Nick Mathewson wrote:
> On Thu, Jan 5, 2012 at 5:05 PM, Nick Mathewson <nickm at torproject.org> wrote:
>> Hi, all!
>>
>> Previously, I had set the deadline for merging small features into
>> 0.2.3.x as Jan 6.  Due to work that had piled up or suddenly appeared
>> in the new year, I wasn't able to get patches reviewed this week as
>> much as I wanted, so I'm going to push the small-feature merge window
>> back to Jan 13.
>>
>> This is the deadline for me to merge stuff, not for stuff to get
>> submitted: I probably will not consider any patches where the first
>> version is submitted after Monday, unless they are surprisingly tiny
>> and obviously correct.
> 
> I just did an initial triage over all Tor tickets that are in state
> "needs_review" in the bugtracker.  If your ticket is not tagged with
> "small-feature," or it is not in state "needs_review", then it is not
> on my list of small features to review and merge (or not) by Friday.
> If I missed something, please let me know!
> 
> This was not a triage over bug reports; only feature patches... so
> don't worry if there's a pending bugfix (or pending bug) that I didn't
> tag.  For my next round of triage, I'll take all remaining tickets
> that look like a feature request to me, and remove them from the
> 0.2.3.x milestone.
> 


Hey Nick,

My old prop 179 branch has largely been merged but I realize now that
one key change hasn't - it's the two line change at the top of crypto.h
- basically it sets the TLS public key modulus to be 2048:

+/** Length of our TLS keys. */
+#define TLS_PK_BYTES 2048

And later:

+  if (crypto_pk_generate_key_with_bits(rsa,TLS_PK_BYTES)<0)

I made this change and it worked fine - the major objection is that the
DH parameter isn't 2048 bits.

I rather think that we should make the 2048bit rsa key change and also
the DH change. I propose that I hack up
crypto_generate_dynamic_dh_modulus to use a 2048bit modulus. That way,
we'll have by default, a 2048bit key for TLS and a 1024bit DH right away
and if you flip the random DH option, you'll also get a 2048bit DH. And
in the future, I propose that we flip the random DH option by default.

Should I make such a branch and request it for review?

All the best,
Jake