[ANNOUNCE] Django 1.2.7 -- corrects issue with 1.2.6 release package

[James Bennett]

Due to an issue with yesterday's 1.2.6 release package, today we are
issuing Django 1.2.7. All users of 1.2.X Django should upgrade to
1.2.7, rather than to 1.2.6.

Details here:

https://www.djangoproject.com/weblog/2011/sep/10/127/


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

Re: Improved password hashing for 1.4

[Paul McMillan]

> Having recently written a Python implementation of PBKDF2 myself, I'd
> just like to quietly point out that it is not a hashing algorithm. It
> is a Key Derivation Function. That is, it's a way of generating key
> material for crypto functions, from a password source.

Yes, you're absolutely right. My choice of words was incorrect. Is
your python implementation licensed in such a way that we could
consider including it in Django? We've looked at a couple
implementations now, having another option would be helpful.

-Paul

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

Re: plea for re-opening ticket 13125 marked as won't fix

[Florian Apolloner]

Stupid question, but why do you let inactive users login at all? I mean is 
this really a problem of the decorator and not of the login system you use?!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vLiHd62iAJ0J.
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.

Re: Proposal for a new templatetag definition syntax

[Alex Gaynor]

On Fri, Sep 9, 2011 at 6:16 PM, Wim Feijen  wrote:

> Hi Alex,
>
> Probably I am thinking way too simple, but if you gave me a free
> choice of how to write templatetags in my code, I would prefer:
>
> def mytag(foo, bar):
> # some code
> return output
>
> or:
>
> class MyTag(Tag):
>def __init__(self, foo, bar):
>self.foo = foo
>self.bar = bar
>
> and
>
> def mytag(src, limit=1, offset=10, ??)
>
> or:
>
> class MyTag(Tag):
>def __init__(self, limit=1, offset=10, ??):
>self.limit = limit
>self.offset = offset
>
>   def render(self):
>   """do some nasty stuff to limit and offset and return something."""
>
> Just kick me if I am talking non-sense, that's ok.
>
> Wim
>
> On 10 sep, 02:29, Alex Gaynor  wrote:
> > Hello all,
> >
> > For many years, writing templatetags has been among the most hilariously
> > complicated things we Django developers did. Anyone who has written
> parsing
> > for
> > templatetags, over and over, shares this pain. Further, the current
> syntax
> > present a tremendous problem for Armin Ronacher's GSOC towards template
> > compilation: template tags define a ``render()`` method, which takes the
> > current context (a stack of dictionaries) and perform some behavior which
> is
> > opaque to the caller. This is a problem because one of the core
> objectives
> > of
> > the template compilation infrastructure is to store the template context
> in
> > Python local variables, rather than in dictionaries. For all these
> reasons,
> > several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas
> Obrist,
> > Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> > out a
> > proposal that solves these problems, taking inspiration from the plethora
> of
> > libraries that exist today.
> >
> > We ultimately created two possible solutions, one inspired primarily by
> > django-classy-tags and django-templatetag-sugar, the other mostly
> inspired
> > by
> > django-ttags. We came to a fragile agreement on the first. We primarily
> > evaluated two cases for these, one very simple, the other more complex,
> and
> > compared the resulting implementations.
> >
> > The first case we considered was a templatetag which takes two, required,
> > arguments. Invocation looks like ``{% mytag foo bar %}``.  The two
> > definitions
> > look like:
> >
> > class MyTag(Tag):
> > args = [
> > Argument("foo"),
> > Argument("bar"),
> > ]
> >
> > class MyTag(Tag):
> > foo = Argument()
> > bar = Argument()
> >
> > the second case we considered was a tag which has one required,
> positional,
> > argument, and two optional, keyword arguments, which can occur in any
> order,
> > followed by a final, optional keyword argument, meaning any of the
> following
> > invocations are valid:
> >
> > {% mytag src limit 1 offset 10 %}
> > {% mytag src limit 1 offset 10 with foo %}
> > {% mytag src limit 1 %}
> > {% mytag src offset 10 limit 1 %}
> > {% mytag src %}
> >
> > and the two implementations were:
> >
> > class MyTag(Tag):
> > args = [
> > Argument("source"),
> > Unordered(
> > NamedArgument("limit", required=False),
> > NamedArgument("offset", required=False),
> > ),
> > NamedArgument("as", required=False, resolve=False)
> > ]
> >
> > class MyTag(Tag):
> > source = Argument()
> > limit = NamedArgument(required=False)
> > offset = NamedArgument(required=False)
> > as_ = BasicArgument(required=False)
> >
> > class Meta:
> > ordering = (
> > ('source',),
> > Unordered('limit', 'offset'),
> > ('as_',)
> > )
> >
> > The general consensus was that the second implementation was *very*
> slightly
> > preferable in the simple case, however it was significantly more
> complicated
> > in
> > the second case, and thus the first implementation was preferable
> overall.
> >
> > We notable did *not* discuss what the syntax for defining the output was,
> at
> > this stage we were only concerned with the syntax definition. This is
> > because
> > the actual ``render()`` equivalent will be orthogonal to the parsing
> stage
> > equivalent.
> >
> > For your consideration,
> > 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
>
> --
> 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
> 

Re: Improved password hashing for 1.4

[Russell Keith-Magee]

On Sat, Sep 10, 2011 at 11:54 AM, Paul McMillan  wrote:
> In conjunction with Justine Tunney, Isaac Kelly and Russell KM, I'd
> like to introduce our plan of attack for including significantly
> better password hashing in Django 1.4. One of the key goals with this
> push is to include just enough functionality that we can improve this
> particular aspect of Django. There's a lot of other great work that
> could happen as part of a more general contrib.auth overhaul, but we
> want to change as little as possible so we can get a patch out quickly
> (in time for the 1.4 feature freeze).
>
> The default password hashing algorithm will be changed to PBKDF2.
> We'll include a pure python implementation, but preferably load faster
> versions if available at the system level.

Preferentially, not preferably - but otherwise +1 :-)

> Password hashing will happen via pluggable backends that implement the
> set_password() and check_password() methods on the current User model.
> We're considering trying the generic backend module from armstrong for
> this, with the idea that we can move our other adhoc backend
> implementations to a unified generic module in the future.

It's worth pointing out that this can -- and probably should -- be
handled as a two-step process.

Step one is to get PBKDF2 support into trunk.

Step two is a cleanup of the way backends are handled in general. This
is a larger code cleanup exercise, and a worthwhile one; but the
decision to refactor Django's backend loading code is orthogonal to
the need to add PBKDF2 support.

It's also worth noting that we already have a pluggable backend to use
here -- auth is already a backend-based system. It requires some
refactoring to get the password checking code into the backend rather
than being user-based, but that's a relatively small modification of
the existing codebase.

> We will include backends that implement all the existing hashing
> schemes as well as an optional module for bcrypt that uses a system
> library if available. We will work to provide a clean upgrade path for
> users of django-bcrypt.
>
> We will be extending the current system that allows users to upgrade
> their password algorithms in place. We recognize that sysadmins may
> change their mind about which algorithm they prefer (for example, if
> PBKDF2 becomes more overhead than they like, or they decide to upgrade
> from SHA1). We want people to be confident in trying the new hashing
> algorithms, so we will provide a mechanism for choosing a preferred
> hashing backend and converting passwords to that backend as they are
> used.
>
> We're looking at ways to mitigate the effects of DoS attacks against
> the auth module due to the higher CPU usage for these new backends.
> Suggestions on this topic are welcome, but will probably be
> implemented as part of a separate commit.
>
> I'm really excited that we finally have the momentum to bring this
> important change to Django!

Likewise; +1 to the general thrust, and for getting this into 1.4

Russ %-)

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

Re: Fixture loading using bulk_create

[Alex Gaynor]

On Sat, Sep 10, 2011 at 8:19 AM, Anssi Kääriäinen
wrote:

>
>
> On Sep 10, 1:55 pm, "Jonas H."  wrote:
> > I started hacking the loaddata command to make use of the shiny new
> > `bulk_create` code -- however, it seems that fixture loading (at least
> > in its current incarnation) is incompatible to bulk inserts, for this
> > reasons:
> >
> > 1. It's possible to have model objects overridden by fixtures.
> > e.g. in modeltests/fixtures/fixtures/fixture1.json, there's a
> > `fixtures.article` with pk=3, and in fixture2.json there's another
> > pk=3 article which overrides that from fixture1.
> >
> > Of course this is not compatible with forced inserts.
> >
> > 2. pre_save/post_save signals are not sent.
> > It seems like it's not documented anywhere that signals are sent
> > during fixture loading but I think that for backwards compatibility
> > reasons this behaviour should not be changed.
> >
> > Any ideas on these issues?
>
> Why the signals aren't sent in bulk_insert, is it because PK is not
> necessarily  available for post_save signal? Otherwise one could send
> all pre_save signals in one batch before insert and for post_save just
> after. Cascading deletes do something like that IIRC. If this is
> impossible to do in bulk_insert, the signal sending could still be
> done manually in fixture loading. PK should be available there
> directly from the fixtures, right?
>
> For the overridden pk problem you could do batches of say 100 inserts
> at a time, first do "select pk from tbl where pk in (list of pks in
> batch)", then use update for the returned pks and insert the rest.
>
>  - Anssi
>
> --
> 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.
>
>
I looked into using bulk_create for fixtures back at DjangoCon.eu, basically
it's a mess because fixtures are not necessarily creating data, they can
also be overwriting existing ones.

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

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

Re: Fixture loading using bulk_create

[Anssi Kääriäinen]

On Sep 10, 1:55 pm, "Jonas H."  wrote:
> I started hacking the loaddata command to make use of the shiny new
> `bulk_create` code -- however, it seems that fixture loading (at least
> in its current incarnation) is incompatible to bulk inserts, for this
> reasons:
>
> 1. It's possible to have model objects overridden by fixtures.
>     e.g. in modeltests/fixtures/fixtures/fixture1.json, there's a
>     `fixtures.article` with pk=3, and in fixture2.json there's another
>     pk=3 article which overrides that from fixture1.
>
>     Of course this is not compatible with forced inserts.
>
> 2. pre_save/post_save signals are not sent.
>     It seems like it's not documented anywhere that signals are sent
>     during fixture loading but I think that for backwards compatibility
>     reasons this behaviour should not be changed.
>
> Any ideas on these issues?

Why the signals aren't sent in bulk_insert, is it because PK is not
necessarily  available for post_save signal? Otherwise one could send
all pre_save signals in one batch before insert and for post_save just
after. Cascading deletes do something like that IIRC. If this is
impossible to do in bulk_insert, the signal sending could still be
done manually in fixture loading. PK should be available there
directly from the fixtures, right?

For the overridden pk problem you could do batches of say 100 inserts
at a time, first do "select pk from tbl where pk in (list of pks in
batch)", then use update for the returned pks and insert the rest.

 - Anssi

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

Fixture loading using bulk_create

[Jonas H.]

I started hacking the loaddata command to make use of the shiny new 
`bulk_create` code -- however, it seems that fixture loading (at least 
in its current incarnation) is incompatible to bulk inserts, for this 
reasons:


1. It's possible to have model objects overridden by fixtures.
   e.g. in modeltests/fixtures/fixtures/fixture1.json, there's a
   `fixtures.article` with pk=3, and in fixture2.json there's another
   pk=3 article which overrides that from fixture1.

   Of course this is not compatible with forced inserts.

2. pre_save/post_save signals are not sent.
   It seems like it's not documented anywhere that signals are sent
   during fixture loading but I think that for backwards compatibility
   reasons this behaviour should not be changed.

Any ideas on these issues?

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

Re: Improved password hashing for 1.4

[Daniel Swarbrick]

On Sep 10, 5:54 am, Paul McMillan  wrote:
>
> The default password hashing algorithm will be changed to PBKDF2.
> We'll include a pure python implementation, but preferably load faster
> versions if available at the system level.
>

Having recently written a Python implementation of PBKDF2 myself, I'd
just like to quietly point out that it is not a hashing algorithm. It
is a Key Derivation Function. That is, it's a way of generating key
material for crypto functions, from a password source.

PBKDF2 makes use of a hashing algorithm (SHA1 by default), and
repeatedly hashes a password plus salt to effectively "stretch" the
number of bits in a password, and generate longer keys for crypto
algorithms such as AES. The greater the number of rounds of hashing,
the more the original password is "stretched", costing an attacker
more computing time in the process.

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