Re: Purpose of constant_time_compare?

[Gabriel Hurley]

You wanna hand over your paycheck now, or later? :-)


I know someone with a functional white-hat timing attack script sitting
on their laptop. They've been honing the statistical analysis to get
the number of data points needed down to a less noticeable size, but
the technique can already be successfully applied.


To your latter point, you can run a timing attack as slowly as you
like, and a lot of sites have very poor monitoring for things like
404s. A month or more of patient low-level attacking to gain access to
a prime target is well worth it.


The point being that we all ought to take timing attacks seriously.
They're not nearly as unrealistic as people think.


All the best,


- Gabriel

-- 
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: django.contrib.admin and null=True

[schinckel]

On Dec 9, 1:57 pm, schinckel  wrote:
> On Dec 8, 2:02 pm, nasp  wrote:
>
> > You might consider 
> > readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.
>
> Thanks: that was the link I needed.
>
> However, I do take exception with the comment:
>
>     If a string-based field has null=True, that means it has two
> possible values for “no data”: NULL, and the empty string.
>
> An empty string means something different in the context of a
> relational database than a NULL value (as -RAX- and Andrew hint at
> below).  It goes a bit deeper than just unique constraints (although I
> have hit this several times), but also impacts upon relational
> algebra. (NULL and TRUE => NULL, for instance). Even just as a string,
> an empty string is different to NULL. An empty string means "I know
> what the value is, and it is a string of no length", compared to one
> use of a NULL, as "I don't know what the value is (yet)."
>
> In addition, NULL behaves vastly differently to an empty string when
> using COALESCE() or BOOL().
>
>     SELECT COALESCE(NULL, '', 'FOO'); => ''
>     SELECT BOOL(''); => ERROR
>
> Now, if you stay in django-land, this is probably not going to bite
> you too much (unless you want an optional IPAddress field in a
> Postgres db), but if you sometimes have to hand-tune queries (or
> *gasp* create stored procedures in your database), then you lose the
> ability to use COALESCE, for instance.

Having said all of that, I've just implemented a solution (using
pre_save), but there is an issue: it is not possible to know from the
admin interface returned value if the user meant to have a None value,
or an empty string.

Matt.

-- 
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: django.contrib.admin and null=True

[schinckel]

On Dec 8, 9:24 pm, -RAX-  wrote:
> By default Admin saves an empty string in those TextFields and
> CharFields defined as null = True.
>
> Whatever the semantic reasons are, this default behavior creates
> problems in those fields which are both unique = True and null = True
> because by saving an empty string they do not respect that null !=
> null.

Exactly!

> A work around of would be to override the form used by the admin
> interface replacing the empty strings with None.

Yeah, that's what I was doing. I do like Andrew's solution more
though: a global pre_save hook.

Matt.

-- 
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: django.contrib.admin and null=True

[schinckel]

On Dec 8, 2:02 pm, nasp  wrote:
> You might consider 
> readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.

Thanks: that was the link I needed.

However, I do take exception with the comment:

If a string-based field has null=True, that means it has two
possible values for “no data”: NULL, and the empty string.

An empty string means something different in the context of a
relational database than a NULL value (as -RAX- and Andrew hint at
below).  It goes a bit deeper than just unique constraints (although I
have hit this several times), but also impacts upon relational
algebra. (NULL and TRUE => NULL, for instance). Even just as a string,
an empty string is different to NULL. An empty string means "I know
what the value is, and it is a string of no length", compared to one
use of a NULL, as "I don't know what the value is (yet)."

In addition, NULL behaves vastly differently to an empty string when
using COALESCE() or BOOL().

SELECT COALESCE(NULL, '', 'FOO'); => ''
SELECT BOOL(''); => ERROR

Now, if you stay in django-land, this is probably not going to bite
you too much (unless you want an optional IPAddress field in a
Postgres db), but if you sometimes have to hand-tune queries (or
*gasp* create stored procedures in your database), then you lose the
ability to use COALESCE, for instance.

-- 
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: django.contrib.admin and null=True

[schinckel]

On Dec 8, 9:28 pm, Andrew Godwin  wrote:
> On 07/12/10 23:26, schinckel wrote:
>
>
>
>
>
> > I haven't been able to find any documentation about this, but would be
> > happy to be pointed in the right direction.
>
> > When you use null=True in a field, and then use that model in the
> > admin, it will not save NULL to the database, but will instead save an
> > empty string (or attempt to).
>
> > I think this is broken behaviour: NULL values are semantically
> > different to empty strings, and in certain cases (I think it was
> > IPAddressField, but I will have another look later), it would fail to
> > write to the database.
>
> > Is there a reason that the admin interface saves what should be a NULL
> > value as an empty string? Do I report this as a bug?
>
> > Matt.
>
> Further to the other two replies, this is a known issue, and affects
> things like unique constraints too. The relevant bug 
> -http://code.djangoproject.com/ticket/9590- was closed as WONTFIX a
> while ago.

Yes, but don't we have new world order now? (GRIN).


> General opinion last time I asked about this (it bites me occasionally)
> is that there's a divide between people who use NULL, and between people
> who think there should be one empty value, but even if fixed it'd
> probably break backwards compatibility in so many subtle ways, it's
> unlikely to occur.

> My suggested workaround is to add a pre_save hook that manually fixes
> the fields up. Someone I know has one that runs against all saves on all
> models, and auto-corrects any "" values in nullable fields to None
> before saving them.

This looks like a good solution. I was just cleaning up the data in
the clean() method on a form,
but this is nicer. And global.

-- 
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: Purpose of constant_time_compare?

[sago]

Your paycheck is safe.

It is a hypothetical attack, yes. Only observed under very specific
conditions (with a comparator deliberately and parametrically slowed
down - see the actual TR for details). Best reported resolution for
this attack across a WAN has been microsecond resolution (still bloody
impressive, imho), LAN at hundreds of nanoseconds. Typical time for
individual character comparisons on commodity hardware is in the tens
of picosecond range.

But having said that, even hypothetical attacks are often a code-stink
of a badly reviewed implementation.

But it won't be fairly obvious you're getting attacked in that way,
unless you've specifically put in code or other tech to detect it.
Most web-frameworks (Django included) just let that sail right by
(rightly) assuming it isn't their job to worry.

Ian.

On Dec 9, 2:02 am, Mike Malone  wrote:
> Yea... in reality I'd bet my paycheck that the answer is no. Despite Coda's
> blog post, you can't use the jitter in HTTP requests to gain any insight
> into where a string match fails.
>
> Even if you could do so with hundreds of requests, it's fairly obvious that
> an attack is taking place when you get that many bad requests for one
> account.
>
> Mike
>
>
>
>
>
>
>
> On Wed, Dec 8, 2010 at 12:10 PM, Alex Gaynor  wrote:
>
> > On Wed, Dec 8, 2010 at 3:08 PM, Jonas H.  wrote:
>
> >> Hello out there,
>
> >> what is the point of `django.utils.crypto.constant_time_compare`? I
> >> understand it takes O(n) time no matter what input it is feeded with, but 
> >> of
> >> what avail is it?
>
> >> Can the time spent in *one single string comparison* really make such a
> >> huge difference?
>
> >> Confused,
> >> Jonas
>
> >> --
> >> 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 >>  i...@googlegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/django-developers?hl=en.
>
> > In theory, yes.  These are a class of attacks known as timing attacks:
> >http://en.wikipedia.org/wiki/Timing_attack.  That said I don't know of any
> > actual real world attacks using these, but better safe than sorry.
>
> > Alex
>
> > --
> > "I disapprove of what you say, but I will defend to the death your right to
> > say it." -- Evelyn Beatrice Hall (summarizing 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 > i...@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.

Re: Purpose of constant_time_compare?

[Mike Malone]

Yea... in reality I'd bet my paycheck that the answer is no. Despite Coda's
blog post, you can't use the jitter in HTTP requests to gain any insight
into where a string match fails.

Even if you could do so with hundreds of requests, it's fairly obvious that
an attack is taking place when you get that many bad requests for one
account.

Mike

On Wed, Dec 8, 2010 at 12:10 PM, Alex Gaynor  wrote:

>
>
> On Wed, Dec 8, 2010 at 3:08 PM, Jonas H.  wrote:
>
>> Hello out there,
>>
>> what is the point of `django.utils.crypto.constant_time_compare`? I
>> understand it takes O(n) time no matter what input it is feeded with, but of
>> what avail is it?
>>
>> Can the time spent in *one single string comparison* really make such a
>> huge difference?
>>
>> Confused,
>> Jonas
>>
>> --
>> 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.
>>
>>
> In theory, yes.  These are a class of attacks known as timing attacks:
> http://en.wikipedia.org/wiki/Timing_attack.  That said I don't know of any
> actual real world attacks using these, but better safe than sorry.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing 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.
>

-- 
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: How to concatenate strings in django templates?

[Russell Keith-Magee]

On Wed, Dec 8, 2010 at 8:27 PM, Javier Guerra Giraldez
 wrote:
> On Wed, Dec 8, 2010 at 5:39 AM, Muhammad Ahsan
>  wrote:
>> {% extend shop/shop_name/base.html %}
>
> shop/{{shop_name}}/base.html
>
>
> ... and this is the wrong list

If you're going to respond like this, it's only polite to point out
*why* this is the wrong list, and direct the author to the more
appropriate venue.

In this case, django-users would be a better place to post --
django-developers is for discussing the development of Django itself,
not for general how-to queries.

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: Purpose of constant_time_compare?

[Alex Gaynor]

On Wed, Dec 8, 2010 at 3:08 PM, Jonas H.  wrote:

> Hello out there,
>
> what is the point of `django.utils.crypto.constant_time_compare`? I
> understand it takes O(n) time no matter what input it is feeded with, but of
> what avail is it?
>
> Can the time spent in *one single string comparison* really make such a
> huge difference?
>
> Confused,
> Jonas
>
> --
> 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.
>
>
In theory, yes.  These are a class of attacks known as timing attacks:
http://en.wikipedia.org/wiki/Timing_attack.  That said I don't know of any
actual real world attacks using these, but better safe than sorry.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing 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: Purpose of constant_time_compare?

[Christophe Pettus]

On Dec 8, 2010, at 12:08 PM, Jonas H. wrote:
> Can the time spent in *one single string comparison* really make such a huge 
> difference?

Yes.

http://codahale.com/a-lesson-in-timing-attacks/

--
-- Christophe Pettus
   x...@thebuild.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.

Purpose of constant_time_compare?

[Jonas H.]

Hello out there,

what is the point of `django.utils.crypto.constant_time_compare`? I 
understand it takes O(n) time no matter what input it is feeded with, 
but of what avail is it?


Can the time spent in *one single string comparison* really make such a 
huge difference?


Confused,
Jonas

--
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: How to concatenate strings in django templates?

[Иван Маркеев]

You can put variable with needed path from view or url to your template.

08.12.2010 17:23 пользователь "Muhammad Ahsan" 
написал:


I want to concatenate string in django template tag like

{% extend shop/shop_name/base.html %}

here shop_name is my variable and i want to concatenate this with rest
of path. suppese i have shop_name=example.com

and i want result to extend shop/example.com/base.html

plz help. thanx in advance :)

--
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.

-- 
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: How to concatenate strings in django templates?

[Javier Guerra Giraldez]

On Wed, Dec 8, 2010 at 5:39 AM, Muhammad Ahsan
 wrote:
> {% extend shop/shop_name/base.html %}

shop/{{shop_name}}/base.html


... and this is the wrong list

-- 
Javier

-- 
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: call_command retval

[Harro]

If it does not exist; create a ticket.

+1 on both points

On Dec 7, 4:13 pm, Marco Paolini  wrote:
> I think call_command should return something significant
> to let the caller know if the command was successful or not.
>
> Another issue ralated to this is: having an error retcode when calling
> management commands from
> commandline
>
> The problem now is that for instance loaddata swallows all exceptions
> and only spits them out to stderr
> without exiting sys.exit(1)
>
> that's not good if you use loaadata command from a script.
>
> Do you agree?
>
> should I submit a ticket (I could not find any on django trac)?
>
> Marco

-- 
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: django.contrib.admin and null=True

[-RAX-]

By default Admin saves an empty string in those TextFields and
CharFields defined as null = True.

Whatever the semantic reasons are, this default behavior creates
problems in those fields which are both unique = True and null = True
because by saving an empty string they do not respect that null !=
null.
For instance suppose you want to create a TextField containing an
alphanumeric code which if exists is unique. The default behavior of
the Admin forms will save "" in all the empty fields violating the
unicity.

A work around of would be to override the form used by the admin
interface replacing the empty strings with None.

On Dec 8, 12:26 am, schinckel  wrote:
> I haven't been able to find any documentation about this, but would be
> happy to be pointed in the right direction.
>
> When you use null=True in a field, and then use that model in the
> admin, it will not save NULL to the database, but will instead save an
> empty string (or attempt to).
>
> I think this is broken behaviour: NULL values are semantically
> different to empty strings, and in certain cases (I think it was
> IPAddressField, but I will have another look later), it would fail to
> write to the database.
>
> Is there a reason that the admin interface saves what should be a NULL
> value as an empty string? Do I report this as a bug?
>
> Matt.

-- 
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.

How to concatenate strings in django templates?

[Muhammad Ahsan]

I want to concatenate string in django template tag like

{% extend shop/shop_name/base.html %}

here shop_name is my variable and i want to concatenate this with rest
of path. suppese i have shop_name=example.com

and i want result to extend shop/example.com/base.html

plz help. thanx in advance :)

-- 
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: django.contrib.admin and null=True

[Andrew Godwin]

On 07/12/10 23:26, schinckel wrote:

I haven't been able to find any documentation about this, but would be
happy to be pointed in the right direction.

When you use null=True in a field, and then use that model in the
admin, it will not save NULL to the database, but will instead save an
empty string (or attempt to).

I think this is broken behaviour: NULL values are semantically
different to empty strings, and in certain cases (I think it was
IPAddressField, but I will have another look later), it would fail to
write to the database.

Is there a reason that the admin interface saves what should be a NULL
value as an empty string? Do I report this as a bug?

Matt.

   


Further to the other two replies, this is a known issue, and affects 
things like unique constraints too. The relevant bug - 
http://code.djangoproject.com/ticket/9590 - was closed as WONTFIX a 
while ago.


General opinion last time I asked about this (it bites me occasionally) 
is that there's a divide between people who use NULL, and between people 
who think there should be one empty value, but even if fixed it'd 
probably break backwards compatibility in so many subtle ways, it's 
unlikely to occur.


My suggested workaround is to add a pre_save hook that manually fixes 
the fields up. Someone I know has one that runs against all saves on all 
models, and auto-corrects any "" values in nullable fields to None 
before saving them.


Andrew

--
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.