Re: Design and code review requested for Django string signing / signed cookies

[Russell Keith-Magee]

On Mon, Jan 4, 2010 at 8:47 PM, Simon Willison  wrote:
> I'm pursing expert feedback on the crypto used in Django signing /
> signed cookies. Here's the e-mail I'm sending out to various mailing
> lists. I'll also link to this post from a number of places and see if
> I can get some smart eyes on it that way.
>
> 
>
> Hello,
>
> We've been working to add string signing and signed cookies to the
> core of the Django web framework . We
> have a design and an implementation but we've decided we should get
> some feedback from security experts before adding it to the project.
>
> I'd really appreciate any feedback people can give us on the approach
> we are using. We're planning on adding two APIs to Django - a low-
> level API for signing and checking signatures on strings, and a high-
> level API for setting and reading signed cookies.
>
> The low-level API can be seen here:
>
> http://github.com/simonw/django/blob/signed/django/utils/signed.py
>
> The core signing logic lives in the Signer class on line 89:
>
> http://github.com/simonw/django/blob/signed/django/utils/signed.py#L89
>
> Here are the corresponding unit tests:
>
> http://github.com/simonw/django/blob/signed/tests/regressiontests/utils/signed.py
>
> To summarise, the low-level API is used like this:
>
 signer = Signer('my-top-secret-key')
 value = u'Hello world'
 signed_value = signer.sign(value)
 signed_value
> 'Hello world:DeYFglqKoK8DLYD0nQijugnZaTc'
 unsigned_value = signer.unsign(signed_value)
 unsigned_value
> u'Hello world'
>
> A few notes on how the code works:
>
> Signing strings
> ---
>
> Actual signatures are generated using hmac/sha1. We encode the
> resulting signature with base64 (rather than the more common
> hexdigest). We do this because the signatures are expected to be used
> in both URLs and cookies, where every character counts. The relevant
> functions are:
>
> def b64_encode(s):
>    return base64.urlsafe_b64encode(s).strip('=')
>
> def base64_hmac(value, key):
>    return b64_encode(
>        (hmac.new(key, value, sha_constructor).digest())
>    )
>
> Picking a key to use for the signature
> --
>
> We've been (I think) pretty paranoid about picking the key used for
> each signature. Every Django installation has a SECRET_KEY setting
> which is designed to be used for this kind of purpose. Rather than use
> the SECRET_KEY directly as the key for signatures, we derive a key for
> each signature based on the SECRET_KEY plus a salt.
>
> We do this because we're worried about attackers abusing a component
> of a Django application that allows them to control what is being
> signed and hence increase their information about the key. I don't
> know if hmac/sha1 can be attacked in this way, but I'm pretty sure
> this is a good idea. If you have any tips as to how I can explain the
> benefits of this in the documentation for the feature they would be
> greatly appreciated!
>
> By default, the key we actually use for the signature (and hence pass
> to the base64_hmac function above) is sha1('signer' + SECRET_KEY +
> salt). 'salt' defaults to the empty string but users will be
> encouraged to provide a salt every time they use the low-level signing
> API - Django functionality that calls it (such as the signed cookie
> implementation) will always use a salt.
>
> Here's the signature method from the Signer class in full:
>
> def signature(self, value, salt=''):
>    # Derive a new key from the SECRET_KEY, using the optional salt
>    key = sha_constructor('signer' + self.key + salt).hexdigest()
>    return base64_hmac(value, key)
>
> Appending the signature to a string
> ---
>
> API users are not expected to call that signature() method directly
> though. Instead, we provide two methods - sign() and unsign() - which
> handle appending the signature to the string.
>
> Here they are in full:
>
> def sign(self, value, salt='', sep=':'):
>    value = smart_str(value)
>    return '%s%s%s' % (
>        value, sep, self.signature(value, salt=salt)
>    )
>
> def unsign(self, signed_value, salt='', sep=':'):
>    signed_value = smart_str(signed_value)
>    if not sep in signed_value:
>        raise BadSignature, "No '%s' found in value" % sep
>    value, sig = signed_value.rsplit(sep, 1)
>    expected = self.signature(value, salt=salt)
>    if sig != expected:
>        # Important: do NOT include the expected sig in the exception
>        # message, since it might leak up to an attacker!
>        raise BadSignature, 'Signature "%s" does not match' % sig
>    else:
>        return force_unicode(value)
>
> The smart_str method simply ensures that any Python unicode strings
> are converted to UTF8 bytestrings before being signed. force_unicode
> converts utf8 bytestrings back to Python unicode strings.
>
> As you can see, the separator between the 

Re: Design and code review requested for Django string signing / signed cookies

[h...@richardkiss.com]

In this code:

def signature(self, value, salt=''):
# Derive a new key from the SECRET_KEY, using the optional salt
key = sha_constructor('signer' + self.key + salt).hexdigest()
return base64_hmac(value, key)

may I suggest putting the salt before the constant string "signer",
like this:

def signature(self, value, salt=''):
# Derive a new key from the SECRET_KEY, using the optional salt
key = sha_constructor(salt + 'signer' + self.key).hexdigest
()## THIS LINE IS DIFFERENT
return base64_hmac(value, key)

If a constant string comes first, an attacker can calculate the
partial sha hash of 'signer' and cache the state, making this prefix
pretty much useless. By putting the salt first, they'd have to do a
lot more calculation.

There are obviously other corresponding changes when you check the
signature.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Jacob Kaplan-Moss]

On Mon, Jan 4, 2010 at 5:00 PM, Alex Gaynor  wrote:
> So, thinking out loud here, I know the DSF has a policy of hands of in
> the development of Django, but I was thinking (out loud) that perhaps
> it would be sensible for the DSF to hire someone to do a security
> audit of some of this stuff.  I have 0 clue about the particulars of
> how anything like that works, but it was just a thought that occurred
> to me.

The policy isn't exactly "hands off;" it's just that the DSF has no
interest in driving the development of Django. But the DSF certain can
(and in my opinion should) pay for services like this *if* the
development team and community thinks it's necessary.

That said, I think the idea's probably a non-starter. First, like
Tobias (see below) I tend to highly believe in the mantra of many
eyeballs, so I'd argue that an expert review in no way absolves of the
need for open peer review. However, it would tend to discourage
community review -- paid work almost always discourages volunteers --
and would thus be a net loss. Second, from a more pragmatic point of
view, my impression is that anyone who's actually worth paying would
cost well beyond what the DSF could actually afford.

Don't mean to shoot you down, though, and I *really* like the
precedent you're setting by bringing this up. The main reason I wanted
to have a DSF in the first place was so that we could have options
like this. Even if we don't use the option this time (and I think we
shouldn't) it's good for the community to know that it's available.

Jacob

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Tobias McNulty]

On Mon, Jan 4, 2010 at 6:00 PM, Alex Gaynor  wrote:

> So, thinking out loud here, I know the DSF has a policy of hands of in
> the development of Django, but I was thinking (out loud) that perhaps
> it would be sensible for the DSF to hire someone to do a security
> audit of some of this stuff.  I have 0 clue about the particulars of
> how anything like that works, but it was just a thought that occurred
> to me.
>

To be honest I prefer the distributed approach ("the more eyes the better")
of sending the code out to be reviewed by volunteers on various
security-related lists.  I suppose the two could be combined, but I'd hate
to see a paid person in any way decrease the efforts of volunteers (or our
motivation to find such volunteers).  Just my two cents.

Cheers
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: idea for using RequestContext by default

[buttman]

> > I much prefer the @render_to() syntax. This way, I can think of my
> > view functions as "context variable creators", instead of "response
> > returners". I think of view functions as a sort of context processor
> > thats only meant for one specific template.
>
> I'm in complete agreement with Simon on this point. I fail to see the
> benefit of decorators in this context. However, it's easy to find
> several negative points:
>
>  * The "accept a request, return a response"  view contract makes
> sense, and is consistent with other layers in the Django stack.
>  * Special handling is required in the decorator when a view needs to
> return HttpResponseRedirect (or any other non-template-rendered
> response). This says nothing for the case where you need to return a
> non-200 response *and* templated content.

I actually just checked one of my views, and the version of @render_to
that comes with django-annoying does indeed let you return
ResponseRedirect objects. For an example, look at this code:

http://github.com/nbv4/flightloggin/blob/master/logbook/views.py

which is currently in production and it works fine. If request.POST
exists, it will save a form and then issue a ResponseRedirect,
otherwise, it'll create some variables and then return locals(), which
the decorator will then handle.

>  * The return value for views becomes a tuple with a convention,
> rather than an explicit single (response) object.

I don't understand this part. tuples? With the decorator views return
dictionaries.

> So - I'm fairly confident in saying that this isn't going to happen in
> Django trunk.

Fine with me. Either I import it from annoying.decorators or
django.shortcuts, it don't make no difference to me...

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: r11964 and PendingDeprecationWarning

[Luke Plant]

On Tuesday 05 January 2010 00:40:42 Jannis Leidel wrote:

> Maby just an odd idea but what happens if someone monkey patched
>  them as lists (e.g. because the input formats weren't configurable
>  until now)? Would lazy() handle this automatically given list and
>  tuples are both iterables or should we pass an additional
>  resultclass, like
> 
> DEFAULT_DATE_INPUT_FORMATS = lazy(lambda:
>  en_format('DATE_INPUT_FORMATS'), tuple, list)()
>  DEFAULT_TIME_INPUT_FORMATS = lazy(lambda:
>  en_format('TIME_INPUT_FORMATS'), tuple, list)()
>  DEFAULT_DATETIME_INPUT_FORMATS = lazy(lambda:
>  en_format('DATETIME_INPUT_FORMATS'), tuple, list)()

Personally I wouldn't worry about people who are monkey patching - 
they ought to expect things to break. But I don't think this addition 
will harm either.

Luke

-- 
"Love is like an hourglass, with the heart filling up as the brain 
empties."

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: r11964 and PendingDeprecationWarning

[Jannis Leidel]

Hi Luke,

> pinging Jannis - did you see this?  Can you have a look at my 
> suggestion?

Mea culpa, this is indeed an issue and I like your solution of using lazy(), 
since the *_INPUT_FORMATS tuples are only used for iteration.

Maby just an odd idea but what happens if someone monkey patched them as lists 
(e.g. because the input formats weren't configurable until now)? Would lazy() 
handle this automatically given list and tuples are both iterables or should we 
pass an additional resultclass, like

DEFAULT_DATE_INPUT_FORMATS = lazy(lambda: en_format('DATE_INPUT_FORMATS'), 
tuple, list)()
DEFAULT_TIME_INPUT_FORMATS = lazy(lambda: en_format('TIME_INPUT_FORMATS'), 
tuple, list)()
DEFAULT_DATETIME_INPUT_FORMATS = lazy(lambda: 
en_format('DATETIME_INPUT_FORMATS'), tuple, list)()

Best,
Jannis

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: r11964 and PendingDeprecationWarning

[Luke Plant]

pinging Jannis - did you see this?  Can you have a look at my 
suggestion?

Cheers,

Luke

-- 
"Love is like an hourglass, with the heart filling up as the brain 
empties."

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 1:57 AM, buttman  wrote:
> On Jan 2, 5:52 pm, Simon Willison  wrote:
>> On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
>>
>> > In the discussions on CSRF there have been several proposals to
>> > include RequestContext by default in render_to_response or in a
>> > similar function. As a side note to my previous post, I'd like to
>> > mention my favorite way to do this: render_to , see:
>>
>> >http://www.djangosnippets.org/snippets/821/
>>
>> So here's how that's supposed to work:
>>
>> @render_to('my/template.html')
>> def my_view(request, param):
>>     return {'data': 'some_data'}
>>
>> I have to admit I don't understand the appeal of this syntax at all.
>> How is it any better than this? :
>>
>> def my_view(request, param):
>>     return render('my/template.html', {'data': 'some_data'})
>>
>> The decorator implementation is more complicated, makes debugging
>> trickier (since decorators confuse stack traces and other debugging
>> tools) and doesn't save any typing. What are the advantages?
>>
>> I'm a big fan of decorators for things like caching/memoization, but I
>> don't understand why they provide any advantage for the above. I'm not
>> a fan of the current @permalink decorator in Django for the same
>> reason - if a decorator simply changes the syntax for how arguments
>> are passed to a function, what's the point of using them?
>>
>> Cheers,
>>
>> Simon
>
> I much prefer the @render_to() syntax. This way, I can think of my
> view functions as "context variable creators", instead of "response
> returners". I think of view functions as a sort of context processor
> thats only meant for one specific template.

I'm in complete agreement with Simon on this point. I fail to see the
benefit of decorators in this context. However, it's easy to find
several negative points:

 * The "accept a request, return a response"  view contract makes
sense, and is consistent with other layers in the Django stack.
 * Special handling is required in the decorator when a view needs to
return HttpResponseRedirect (or any other non-template-rendered
response). This says nothing for the case where you need to return a
non-200 response *and* templated content.
 * The return value for views becomes a tuple with a convention,
rather than an explicit single (response) object.

So - I'm fairly confident in saying that this isn't going to happen in
Django trunk.

However, this position doesn't prevent you from using this approach in
your own code, so if you're a fan of using decorators in this way,
feel free to do so.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGI support in Django

[Russell Keith-Magee]

On Mon, Jan 4, 2010 at 11:46 PM, Gustavo Narea
 wrote:
> Hi,
>
> One more update about the WSGI related improvements for Django:
>
> I have created a Mercurial branch to keep track of these changes and
> keep them synchronized with trunk:
> http://bitbucket.org/Gustavo/django-wsgi/
>
> Even though I know it's late for 1.2 at this point, please keep in mind
> that part of these enhancements were supposed to be a high priority for
> the 1.2 release [1] (GSoC-2). This branch implements more features than
> the official http-wsgi-improvements branch and is complete/working. And
> again, I am willing to help you with anything you need to get it merged,
> such as writing docs and discussing the implementation further.

There's a very important reason why the feature list is called 'High
Priority" and not "Must Have". We're all volunteers, so it's
impossible for us to know exactly how much time we will have to
dedicate to Django. Therefore, our goals need to be (and are)
expressed in terms of relative priorities, rather than in terms of
absolutes.

Malcolm was the champion behind GSOC-2; unfortunately, Malcolm has
been buried under real-life and work stuff, so he hasn't been able to
shepherd the GSOC-2 changes into trunk. This is unfortunate, but there
isn't much we can do about this.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Alex Gaynor]

On Mon, Jan 4, 2010 at 4:53 PM, Luke Plant  wrote:
> On Monday 04 January 2010 21:45:41 jcampbell1 wrote:
>
>> I am not that familiar with your framework, but I think a signed
>> cookie should use http only cookies by default.  There is no valid
>> reason for a script to read a cookie that it can't verify.  http
>>  only cookies significantly decrease the surface area of XSS
>>  attacks.
>
> I can think of various circumstances where it might be useful and
> harmless.  For example, if the signed cookie stored the user's login
> name, and some client side javascript used the login name for some
> convenience feature, like highlighting the login name wherever it
> appeared on the page.
>
> To generalise, the issue of using HttpOnly cookies is orthogonal to
> whether they are signed or not, because the value of the cookie can be
> used in multiple ways, not all of which will depend on the value being
> verified.
>
> Luke
>
> --
> "Love is like an hourglass, with the heart filling up as the brain
> empties."
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

So, thinking out loud here, I know the DSF has a policy of hands of in
the development of Django, but I was thinking (out loud) that perhaps
it would be sensible for the DSF to hire someone to do a security
audit of some of this stuff.  I have 0 clue about the particulars of
how anything like that works, but it was just a thought that occurred
to me.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Luke Plant]

On Monday 04 January 2010 21:45:41 jcampbell1 wrote:

> I am not that familiar with your framework, but I think a signed
> cookie should use http only cookies by default.  There is no valid
> reason for a script to read a cookie that it can't verify.  http
>  only cookies significantly decrease the surface area of XSS
>  attacks.

I can think of various circumstances where it might be useful and 
harmless.  For example, if the signed cookie stored the user's login 
name, and some client side javascript used the login name for some 
convenience feature, like highlighting the login name wherever it 
appeared on the page.

To generalise, the issue of using HttpOnly cookies is orthogonal to 
whether they are signed or not, because the value of the cookie can be 
used in multiple ways, not all of which will depend on the value being 
verified.

Luke

-- 
"Love is like an hourglass, with the heart filling up as the brain 
empties."

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[jcampbell1]

On Jan 4, 7:47 am, Simon Willison  wrote:
> And set_signed_cookie() is here:
>
> http://github.com/simonw/django/blob/signed/django/http/__init__.py#L388
>

I am not that familiar with your framework, but I think a signed
cookie should use http only cookies by default.  There is no valid
reason for a script to read a cookie that it can't verify.  http only
cookies significantly decrease the surface area of XSS attacks.

Regards,
John Campbell

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Jacob Kaplan-Moss]

On Mon, Jan 4, 2010 at 12:34 PM, Simon Willison  wrote:
> We do however need to consider the places in Django that are already
> using hmac / md5 / sha1 (contrib.formtools and middleware.csrf for
> example). Even if we don't add the signed cookies feature to 1.2,
> fixing any problems with our existing use of crypto should not be
> affected by the feature freeze. There's not much point in implementing
> this logic in several different places, so I think we should keep
> targeting the django.utils.signed module for 1.2.

Agreed - I see no issues with targeted it for the beta (but using it
for signed cookies probably has to slip to 1.3). It's certainly an
improvement to have a single place where this sensitive code lives.
>From a worst-case-scenario standpoint, it'd make a security fix much
easier to only have a single place to fix it.

Jacob

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

On Jan 4, 6:18 pm, James Bennett  wrote:
> Simon, the amount of pushback this is getting, and the changes which
> need to be made to start bringing it up to snuff, make me feel far too
> nervous about this being ready in time to make 1.2 at all. I know
> you've put in the effort to shepherd this along, but I'm starting to
> think it's time to push this to the 1.3 release cycle (especially
> since 1.2 alpha freeze is tomorrow, and I don't think there's any way
> it'll be even alpha-ready by then).

I certainly don't think we should check this in for the alpha freeze.

We do however need to consider the places in Django that are already
using hmac / md5 / sha1 (contrib.formtools and middleware.csrf for
example). Even if we don't add the signed cookies feature to 1.2,
fixing any problems with our existing use of crypto should not be
affected by the feature freeze. There's not much point in implementing
this logic in several different places, so I think we should keep
targeting the django.utils.signed module for 1.2.

Cheers,

Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: idea for using RequestContext by default

[buttman]

On Jan 2, 5:52 pm, Simon Willison  wrote:
> On Dec 30 2009, 10:28 pm, Wim Feijen  wrote:
>
> > In the discussions on CSRF there have been several proposals to
> > include RequestContext by default in render_to_response or in a
> > similar function. As a side note to my previous post, I'd like to
> > mention my favorite way to do this: render_to , see:
>
> >http://www.djangosnippets.org/snippets/821/
>
> So here's how that's supposed to work:
>
> @render_to('my/template.html')
> def my_view(request, param):
>     return {'data': 'some_data'}
>
> I have to admit I don't understand the appeal of this syntax at all.
> How is it any better than this? :
>
> def my_view(request, param):
>     return render('my/template.html', {'data': 'some_data'})
>
> The decorator implementation is more complicated, makes debugging
> trickier (since decorators confuse stack traces and other debugging
> tools) and doesn't save any typing. What are the advantages?
>
> I'm a big fan of decorators for things like caching/memoization, but I
> don't understand why they provide any advantage for the above. I'm not
> a fan of the current @permalink decorator in Django for the same
> reason - if a decorator simply changes the syntax for how arguments
> are passed to a function, what's the point of using them?
>
> Cheers,
>
> Simon

I much prefer the @render_to() syntax. This way, I can think of my
view functions as "context variable creators", instead of "response
returners". I think of view functions as a sort of context processor
thats only meant for one specific template.

Almost every single view I have ever written (more or less) follows
this pattern:

process stuff into variables -> add said variables to a ContextRequest
-> send said ContextRequest to a template for rendering.

With @render_to, it allows me to delegate all the rendering crap to
the decorator, while the view function gets to focus on what is really
there for; creating extra variables to be passed on to the template.
It makes things simpler for me and adds readability.

Also, I've never had a problem with the decorator messing up
tracebacks.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[James Bennett]

Simon, the amount of pushback this is getting, and the changes which
need to be made to start bringing it up to snuff, make me feel far too
nervous about this being ready in time to make 1.2 at all. I know
you've put in the effort to shepherd this along, but I'm starting to
think it's time to push this to the 1.3 release cycle (especially
since 1.2 alpha freeze is tomorrow, and I don't think there's any way
it'll be even alpha-ready by then).


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[marknca]

I think this is a great addition to Django. I wanted to comment on
some of the issues being discussed and hopefully provide a little
insight into the _why_ of it all.

SHA-1 is perfectly fine for HMAC (as verified by Bruce Schneier, NIST,
and several others). Here's why:

SHA-1
==
plaintext -> SHA-1 = hash

HMAC-SHA-1

plaintext + key -> SHA-1 = hash

The key is --excuse the pun-- the key. The receiver of the message
will use the key in the decryption process and will then be able to
verify the authenticity and _integrity_ of the message.

Assuming that the key exchange is safe (a completely different
discussion), a collision in the hash space will not affect security in
HMAC.

A collision (in a simple hash) results when random plaintext creates
the same hash as the "real" plaintext. An attacker can exploit this to
open an avenue into your application.

Because each party has the key, this avenue extremely unlikely to be
open. If the attack is tried the validation of the hash fails because
the receiver already has the key for the message.

That being said, I would still use SHA-256...why use a weaker
algorithm when a stronger one is available at almost no cost?

I don't have the mathematical proof that a truncated hash is still
valid (someone jump in if they do) but the logic holds if a smaller
hash is required.

Because the SHA algorithm diffuses changes in the plaintext throughout
the resulting hash, truncating the SHA-256 hash simply reduces the
possible hash space, thus increasing the possibility of a collision.

There may be other ramifications but it's definitely worth exploring.
(I'm checking out the other threads right now).

Is the short URL requirement really required by the large community?
(honest question, not trying to be an @$$) Don't most email clients
(including mobile) handle multi line URL's properly now?

Also if you're planning on expanding the API in the future, please
setup version-ing now. It's a lot easier to handle when it's built in
from the start.

Keep up the great work!

Mark
@marknca

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Finalizing model-validation: ComplexValidator

[mrts]

Malcolm had some good comments when all of this was discussed
previously:

http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad

He also seemed to have further ideas and code, perhaps he can be
pinged for sharing them.

Best,
MS

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGI support in Django

[Gustavo Narea]

Hi,

One more update about the WSGI related improvements for Django:

I have created a Mercurial branch to keep track of these changes and
keep them synchronized with trunk:
http://bitbucket.org/Gustavo/django-wsgi/

Even though I know it's late for 1.2 at this point, please keep in mind
that part of these enhancements were supposed to be a high priority for
the 1.2 release [1] (GSoC-2). This branch implements more features than
the official http-wsgi-improvements branch and is complete/working. And
again, I am willing to help you with anything you need to get it merged,
such as writing docs and discussing the implementation further.

I hope to see these improvements in v1.3 then, even if it's not my
implementation.

Cheers,

 - Gustavo.

[1] http://code.djangoproject.com/wiki/Version1.2Features#Highpriority


On Wed, 2009-10-28 at 08:24 +0800, Russell Keith-Magee wrote:
> On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
>  wrote:
> >
> > Hi there.
> >
> > Over the last week I've been working to improve WSGI support in Django
> > and I have sent a few patches which have not received the feedback I
> > expected to have, so I wanted to ping you. ;-)
> 
> In the interests of good community relations, I want to clarify the
> feedback you should be expecting.
> 
> Just because you've uploaded a patch doesn't mean you're going to get
> immediate feedback. We're all volunteers, so our time is limited -
> sometimes, this means that patches don't get triaged for a while.
> Patience is required.
> 
> On top of that, we've just finished our feature discussion phase, and
> we have nominated the features that are a high priority for the
> project [1]. These are the features that will be receiving development
> priority over the next few months. Features that aren't on this list
> aren't going to get the immediate attention of the core team.
> 
> The feature list isn't completely locked off, though. Any feature with
> a complete patch is potentially on the list for inclusion. However,
> any feature that isn't on the list will require:
> 
> 1) A champion in the core team to commit the code
> 2) A design and implementation that has been approved by the community
> (as evidenced by discussion on django-dev)
> 
> That means you're going to need a member of the core team who is
> excited about this possible feature. I can't speak for the other
> members of the core team, but personally, this isn't a big itch. I can
> certainly see how it could be useful, but I've already committed to
> some big-ticket items that are much higher priorities for me
> personally.
> 
> So - you need to have some patience. If you can't get a core developer
> engaged as a result of this thread, you may need to wait until the
> v1.3 feature discussion phase, which will open as soon as v1.2 is
> finalized. Alternatively, you could help out with the features that we
> have already agreed upon for v1.2, and maybe try to leverage the karma
> you gain from doing that work into support for your WSGI patch.
> 
> [1] http://code.djangoproject.com/wiki/Version1.2Features
> 
> Yours,
> Russ Magee %-)
> 
> --~--~-~--~~~---~--~~
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en
> -~--~~~~--~~--~--~---
> 


-- 
Gustavo Narea.
Software Developer.

2degrees - the collaboration service for sustainable business.
http://www.2degreesnetwork.com/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

[Alex Gaynor]

Yes, multiple database support was merged into trunk on December 22:
http://www.djangoproject.com/multidb-changeset/

Alex

On Mon, Jan 4, 2010 at 9:40 AM, Joe  wrote:
> Has this code been merged to a 1.2 alpha build somewhere or is the
> multi-db branch still the current release?  Only asking because the
> first message in the thread indicated a schedule which meant the code
> would be merged in before EOY and I just want to make sure I'm on the
> right codebase moving forward :)
>
> Thanks,
> Joe
>
> On Dec 23 2009, 4:04 am, Russell Keith-Magee 
> wrote:
>> On Wed, Dec 23, 2009 at 1:32 PM, Michael Manfre  wrote:
>> > With multiple database defined, what is the expected behavior for
>> > syncdb and the otherdbrelated commands?
>>
>> The management commands all work the same way under multidb - they
>> only ever work on a single database at a time. If you don't specify a
>> database, the 'default' databse is used.
>>
>> > The documentation shows that
>> > it is relatively easy to associate an admin form with a given
>> > database, but is there a way of associated a model or app to a given
>> > database?
>>
>> Yes - ish. If you're working with your own application and models,
>> just define a custom manager for that model. The manager just needs to
>> override get_query_set() and applies a using() modifier:
>>
>> class PersonManager(models.Manager):
>>     def get_query_set(self):
>>         return super(PersonManager, self).get_query_set().using('other')
>>
>> class Person(models.Model):
>>     objects = PersonManager()
>>     name = models.CharField(max_length=50)
>>     ...
>>
>> Unfortunately, this approach doesn't work for a model in a reusable
>> app - for example, you can't easily push contrib.auth.User to a
>> different database. However, you can just call
>> User.objects.using('other') whenever you want to use the User
>> model.
>>
>> I know this is less than ideal, but the goal for 1.2 was to complete
>> the plumbing and get the important porcelain in place (e.g., using()).
>> The goal for 1.3 is to identify the common end-user use cases for
>> multidb and make some easily exploitable hooks for end-users.
>>
>> Yours,
>> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>



-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

[Joe]

Has this code been merged to a 1.2 alpha build somewhere or is the
multi-db branch still the current release?  Only asking because the
first message in the thread indicated a schedule which meant the code
would be merged in before EOY and I just want to make sure I'm on the
right codebase moving forward :)

Thanks,
Joe

On Dec 23 2009, 4:04 am, Russell Keith-Magee 
wrote:
> On Wed, Dec 23, 2009 at 1:32 PM, Michael Manfre  wrote:
> > With multiple database defined, what is the expected behavior for
> > syncdb and the otherdbrelated commands?
>
> The management commands all work the same way under multidb - they
> only ever work on a single database at a time. If you don't specify a
> database, the 'default' databse is used.
>
> > The documentation shows that
> > it is relatively easy to associate an admin form with a given
> > database, but is there a way of associated a model or app to a given
> > database?
>
> Yes - ish. If you're working with your own application and models,
> just define a custom manager for that model. The manager just needs to
> override get_query_set() and applies a using() modifier:
>
> class PersonManager(models.Manager):
>     def get_query_set(self):
>         return super(PersonManager, self).get_query_set().using('other')
>
> class Person(models.Model):
>     objects = PersonManager()
>     name = models.CharField(max_length=50)
>     ...
>
> Unfortunately, this approach doesn't work for a model in a reusable
> app - for example, you can't easily push contrib.auth.User to a
> different database. However, you can just call
> User.objects.using('other') whenever you want to use the User
> model.
>
> I know this is less than ideal, but the goal for 1.2 was to complete
> the plumbing and get the important porcelain in place (e.g., using()).
> The goal for 1.3 is to identify the common end-user use cases for
> multidb and make some easily exploitable hooks for end-users.
>
> Yours,
> Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

On Jan 4, 2:45 pm, Jordan Christensen  wrote:
> Is there a good way to make it forward upgradeable? Allow the
> developer to decide on the shorter SHA-1 hash or the (theoretically)
> more secure SHA-256?

There is - we can expand the BACKEND setting which is already in place
for signed cookies (but not for other clients of the Signer class). I
think we should do this. For one thing, it would mean we could provide
a backend which uses the Google keyczar Python library instead of the
code that we write. keyczar is properly audited, but depends on
PyCrypto so isn't appropriate as a required dependency of Django.

Another thing we can do is use SHA-256 but truncate the HMAC to 128
characters. Apparently it's perfectly fine to do this - it's being
discussed in the programming.reddit thread at the moment.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Daniel Pope]

The timestamp is necessary to limit replay attacks, and so it should
probably be more than optional - always issued, and checked by
default. The danger is that users might think "signing" is a
bulletproof guarantee that the cookie as received is exactly the
latest cookie issued to that unique user and use them where a replay
attack would be unacceptable for security. There is still a max_age
window for replay attacks, which I don't know of any way to close.

Encrypting the cookies as well would make replay attacks a little
trickier, forcing the attacker to use trial-and-error rather than
identifying targets by inspection. Security through obscurity only,
though cookies being opaque to the user can be useful in its own
right.

The API could accept a user-supplied "check" string so that if the
user can supply some other details - maybe an IP - and have the API
verify this for them (thus preventing replay attacks for different
IPs).

> unsigned_value = signer.unsign(signed_value)

On an API level, 'unsign' isn't an obvious choice. The operation you
are doing is verifying and stripping a signature, so I'd expect
'verify' in the name. You also might want access to the signature
data.

So for example, something like this:

>>> s = SignedString(signed_value)
>>> s
'Hello world'
>>> s.timestamp
1262612904
>>> s.is_key_current()
True
>>> s = SignedString(old_signed_value, max_age=3600)
...
SignatureExpired: signature older than max_age

Dan

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Jordan Christensen]

NIST seems to agree that SHA-1 is ok for HMAC as well:

http://csrc.nist.gov/groups/ST/hash/statement.html

"There are many applications of hash functions, and many do not
require strong collision resistance; for example, keyed hash
applications, such as the Hash-based Message Authentication Code
(HMAC) or key derivation applications of hash functions do not seem to
be affected."

Their plan in the same article doesn't mention transitioning off of
SHA-1 for HMAC related applications.

They also mention that SHA-1 is allowable for HMAC related use after
the 2010 switch over:

http://csrc.nist.gov/groups/ST/hash/policy.html

"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs)."

However it does say:

"Regardless of use, NIST encourages application and protocol designers
to use the SHA-2 family of hash functions for all new applications and
protocols."

Is there a good way to make it forward upgradeable? Allow the
developer to decide on the shorter SHA-1 hash or the (theoretically)
more secure SHA-256?

Jordan

On Jan 4, 8:49 am, Simon Willison  wrote:
> From Jordan Christensen on 
> Twitter:http://twitter.com/thebigjc/status/7366243197
>
> "@simonw why sha-1 instead of sha-256? NIST has recommended not using
> SHA-1 in new systems:http://bit.ly/6bIf5h;
>
> I chose sha-1 over sha-256 for reasons of signature length. A base64
> encoded signature generated with hmac/sha1 is 27 characters long. The
> same thing using hmac/sha256 is 43 characters long. If you're planning
> on using signatures in cookies and URLs that's quite a big difference
> (43 characters is more than half of the maximum 80 characters needed
> to safely transmit URLs in plain text e-mails, e.g. for account
> recovery links).
>
> My understanding is that the collision weaknesses discovered in SHA-1
> are countered by the use of HMAC. Here's Bruce Schneier on the matter:
>
> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
>
> "It pretty much puts a bullet into SHA-1 as a hash function for
> digital signatures (although it doesn't affect applications such as
> HMAC where collisions aren't important)."
>
> Despite the confusing API name, we're doing HMAC here, not digital
> signatures - so I think we're OK. If I'm wrong I'm sure a crypto geek
> will set me straight pretty quickly.
>
> Cheers,
>
> Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

Had some good feedback on news.ycombinator and programming.reddit -
you can follow the threads here:

http://news.ycombinator.com/item?id=1030290
http://www.reddit.com/r/programming/comments/ald1m/calling_crypto_security_experts_help_review_the/

tptacek on news.ycombinator pointed out a timing attack based on our
use of an insecure string comparison (an attack which affected Rails a
while ago). We can fix that using a constant time string comparison
such as this one:

http://code.google.com/p/keyczar/source/diff?spec=svn414=411=414=unidiff=/trunk/python/src/keyczar/keys.py

ascii on programming.reddit has convinced me to ditch the sep=":"
argument and hard code the separator. Customising that doesn't feel
like a feature anyone will ever need. They also repeated the advice to
use SHA-256 - I think I'll almost certainly have to give up my quest
for shorter signatures :(

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

>From Jordan Christensen on Twitter: 
>http://twitter.com/thebigjc/status/7366243197

"@simonw why sha-1 instead of sha-256? NIST has recommended not using
SHA-1 in new systems: http://bit.ly/6bIf5h;

I chose sha-1 over sha-256 for reasons of signature length. A base64
encoded signature generated with hmac/sha1 is 27 characters long. The
same thing using hmac/sha256 is 43 characters long. If you're planning
on using signatures in cookies and URLs that's quite a big difference
(43 characters is more than half of the maximum 80 characters needed
to safely transmit URLs in plain text e-mails, e.g. for account
recovery links).

My understanding is that the collision weaknesses discovered in SHA-1
are countered by the use of HMAC. Here's Bruce Schneier on the matter:

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

"It pretty much puts a bullet into SHA-1 as a hash function for
digital signatures (although it doesn't affect applications such as
HMAC where collisions aren't important)."

Despite the confusing API name, we're doing HMAC here, not digital
signatures - so I think we're OK. If I'm wrong I'm sure a crypto geek
will set me straight pretty quickly.

Cheers,

Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feedback: Syndication feed views

[Ben Firshman]

Is there any more documentation that I should write before the feature  
freeze tomorrow?

Thanks,

Ben

On 22 Dec 2009, at 00:39, Ben Firshman wrote:

>
> On 21 Dec 2009, at 20:06, Luke Plant wrote:
>>> I've documented it in some detail in the release notes. Is this
>>> painstaking enough?
>>
>> Unless I'm missing something, it's not nearly there (but some of this
>> may be the 'formal stuff' that Jacob doesn't mind being missing for
>> now).
>>
>> First, views.Feed.get_object() takes different arguments to
>> feeds.Feed.get_object().  This is pretty confusing, and really needs
>> to be *much* clearer in the documentation (not just the release
>> notes). The same goes for the get_feed() method.
>
> You're right. I've now given it a little versionchanged directive in  
> the main documentation, but perhaps this needs to be clearer. Note  
> that get_feed() isn't documented at all, but all the same, I've made  
> it clear it has changed in the release notes.
>
>>
>> The release notes imply that I can just switch from subclassing
>> feeds.Feed to view.Feed and change get_object(), and it will all  
>> work.
>> I can't see how that is possible:
>>
>> - I might have code that calls the constructor of feeds.Feed (or a
>> subclass) directly.  But views.Feed has a different signature
>> altogether, and feeds.Feed.__init__() does a bit of work that my own
>> code is going to have to do once feeds.Feed disappears.  Obviously
>> that code is doing something that will have to be done differently
>> with views.Feed.  But how exactly?
>>
>> - I might have code that calls the get_feed() method of feeds.Feed
>> (or a subclass) directly.  That method does extra work compared to
>> views.Feed.get_feed().  When feeds.Feed goes away, what does my code
>> need to be changed to?
>>
>> What I'm looking for is *step by step* instructions on how to update
>> my code, and a list of *all* the differences between views.Feed and
>> feeds.Feed, since the former is supposed to be the replacement for  
>> the
>> latter.  I shouldn't have to look at *any* of the code or previous
>> documentation to work out what has changed.  *All* the hard work
>> should have been done for me.  This is about maintenance programmers,
>> who have been given a promise of backwards compatibility, who just
>> want their application to carry on working.
>
> I understand. I've added additional details in the release notes,  
> but do we need step by step instructions on how to upgrade  
> undocumented APIs? As far as the documented API is concerned, very  
> little has changed. Under the hood though, Feed classes have changed  
> significantly. It would require reams of documentation to take into  
> account all the different ways people might be hacking with Feed  
> classes.
>
>>
>> I'm insisting on this, because until we see it, it's very difficult  
>> to
>> work out how "backwards compatible" this really is, and whether we
>> should deprecate feeds.Feed at all.  Jacob was happy for this to go  
>> in
>> without the formal stuff of documenting all this, so I guess we can
>> punt the decision about whether to deprecate feeds.Feed or not, but  
>> we
>> do need those docs at some point so we can see the implications of
>> deprecating feeds.Feed.
>
> I've gone through my changes and documented exactly what has changed  
> as far as the user is concerned. The old API should be completely  
> backwards compatible; the new Feed view certainly isn't.
>
>>
>> So for now, maybe just update the release notes so they don't say  
>> that
>> the new LatestEntries class is identical to before, or a caveat like
>> "if you are only using the high level feed framework (the feed()
>> view)" or something.
>>
>
> I've gone a little further than that in the patch I've just put on  
> the ticket (1), but this probably needs documenting in more detail.
>
> Thanks,
>
> Ben
>
> (1) 
> http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff
>  
>  (Why aren't my diffs showing? Are they too large for trac?)
>
> --
>
> You received this message because you are subscribed to the Google  
> Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com 
> .
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> .
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en 
> .
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Design and code review requested for Django string signing / signed cookies

[Simon Willison]

I'm pursing expert feedback on the crypto used in Django signing /
signed cookies. Here's the e-mail I'm sending out to various mailing
lists. I'll also link to this post from a number of places and see if
I can get some smart eyes on it that way.



Hello,

We've been working to add string signing and signed cookies to the
core of the Django web framework . We
have a design and an implementation but we've decided we should get
some feedback from security experts before adding it to the project.

I'd really appreciate any feedback people can give us on the approach
we are using. We're planning on adding two APIs to Django - a low-
level API for signing and checking signatures on strings, and a high-
level API for setting and reading signed cookies.

The low-level API can be seen here:

http://github.com/simonw/django/blob/signed/django/utils/signed.py

The core signing logic lives in the Signer class on line 89:

http://github.com/simonw/django/blob/signed/django/utils/signed.py#L89

Here are the corresponding unit tests:

http://github.com/simonw/django/blob/signed/tests/regressiontests/utils/signed.py

To summarise, the low-level API is used like this:

>>> signer = Signer('my-top-secret-key')
>>> value = u'Hello world'
>>> signed_value = signer.sign(value)
>>> signed_value
'Hello world:DeYFglqKoK8DLYD0nQijugnZaTc'
>>> unsigned_value = signer.unsign(signed_value)
>>> unsigned_value
u'Hello world'

A few notes on how the code works:

Signing strings
---

Actual signatures are generated using hmac/sha1. We encode the
resulting signature with base64 (rather than the more common
hexdigest). We do this because the signatures are expected to be used
in both URLs and cookies, where every character counts. The relevant
functions are:

def b64_encode(s):
return base64.urlsafe_b64encode(s).strip('=')

def base64_hmac(value, key):
return b64_encode(
(hmac.new(key, value, sha_constructor).digest())
)

Picking a key to use for the signature
--

We've been (I think) pretty paranoid about picking the key used for
each signature. Every Django installation has a SECRET_KEY setting
which is designed to be used for this kind of purpose. Rather than use
the SECRET_KEY directly as the key for signatures, we derive a key for
each signature based on the SECRET_KEY plus a salt.

We do this because we're worried about attackers abusing a component
of a Django application that allows them to control what is being
signed and hence increase their information about the key. I don't
know if hmac/sha1 can be attacked in this way, but I'm pretty sure
this is a good idea. If you have any tips as to how I can explain the
benefits of this in the documentation for the feature they would be
greatly appreciated!

By default, the key we actually use for the signature (and hence pass
to the base64_hmac function above) is sha1('signer' + SECRET_KEY +
salt). 'salt' defaults to the empty string but users will be
encouraged to provide a salt every time they use the low-level signing
API - Django functionality that calls it (such as the signed cookie
implementation) will always use a salt.

Here's the signature method from the Signer class in full:

def signature(self, value, salt=''):
# Derive a new key from the SECRET_KEY, using the optional salt
key = sha_constructor('signer' + self.key + salt).hexdigest()
return base64_hmac(value, key)

Appending the signature to a string
---

API users are not expected to call that signature() method directly
though. Instead, we provide two methods - sign() and unsign() - which
handle appending the signature to the string.

Here they are in full:

def sign(self, value, salt='', sep=':'):
value = smart_str(value)
return '%s%s%s' % (
value, sep, self.signature(value, salt=salt)
)

def unsign(self, signed_value, salt='', sep=':'):
signed_value = smart_str(signed_value)
if not sep in signed_value:
raise BadSignature, "No '%s' found in value" % sep
value, sig = signed_value.rsplit(sep, 1)
expected = self.signature(value, salt=salt)
if sig != expected:
# Important: do NOT include the expected sig in the exception
# message, since it might leak up to an attacker!
raise BadSignature, 'Signature "%s" does not match' % sig
else:
return force_unicode(value)

The smart_str method simply ensures that any Python unicode strings
are converted to UTF8 bytestrings before being signed. force_unicode
converts utf8 bytestrings back to Python unicode strings.

As you can see, the separator between the signature and the value
defaults to being a ':'. I plan to move it from being an argument on
the sign and unsign methods to being an argument to the Signer class
constructor.

Including a timestamp with the signature


The second class 

Backwards incompatible change to Email Backends in Django Trunk

[Russell Keith-Magee]

Hi all,

If you have been using the new email backend feature in trunk, you
should be aware that SVN revision 12084 introduces a small, but
backwards-incompatible change.

If you are using Django 1.1 (i.e., Django stable), or you haven't
manually specified EMAIL_BACKEND in your settings file, you will not
be affected by this change. This change only affects users who are
using a recent Django Trunk checkout, AND have manually specified
EMAIL_BACKEND in their settings file. These users will need to make a
small configuration change.

When the email backend feature was committed in revision 11709, the
EMAIL_BACKEND setting was specified at the level of a module. That is,
if you were using the file-based backend, you would have specified:

EMAIL_BACKEND = 'django.core.mail.backends.filebased'

As of revision 12084, this has been modified to be a class-level
specification. You must now specify:

EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend'

Rather than specifying the module that contains the email backend
class, you need to specify the full name of the backend class. This
means you need to append ".EmailBackend" to any existing EMAIL_BACKEND
setting.

This has been done to normalize the way that pluggable backends are
defined in Django. At the time that the email backend was committed,
no formal policy had been set regarding conventions for specifying
backends. A policy emerged as a result of the introduction of
session-based messages. Since email backends have not yet been part of
a formal Django release, we have decided to make this change to
maintain consistency between the backends that will be introduced in
v1.2.

Apologies for any inconvenience this causes to those of you on the
bleeding edge.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.