Re: Purpose of constant_time_compare?

This is quickly becoming off topic, but I'll bite ;D. On Wed, Dec 8, 2010 at 10:52 PM, Gabriel Hurley wrote: > 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 a

Re: Feedback required: #14799 -- Problem with setting up test databases

Sorry I haven't kept up with this discussion; althugh the issue has now been closed, I'd like to say, On Sunday 05 December 2010 23:08:28 Nick Phillips wrote: > On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote: > > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES -- >

Re: Feedback required: #14799 -- Problem with setting up test databases

On Thu, Dec 9, 2010 at 6:37 PM, Shai Berger wrote: > Sorry I haven't kept up with this discussion; althugh the issue has now been > closed, I'd like to say, > > On Sunday 05 December 2010 23:08:28 Nick Phillips wrote: >> On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote: >> > Option 4:

Re: Feedback required: #14799 -- Problem with setting up test databases

On Thu, Dec 9, 2010 at 11:45 AM, Russell Keith-Magee wrote: > > During the original multi-db design process, we considered allowing > for the definition of dependencies, but abandoned the idea because of > the complexity required to get automated synchronization correct in > every case. For exampl

Re: Purpose of constant_time_compare?

On Thu, 2010-12-09 at 00:54 -0800, Mike Malone wrote: > If you can show me a viable timing attack, over the Internet, under > reasonable real-world circumstances, and caused by something as > negligible as a single string comparison I will give you my paycheck. > And I will eat my laptop. We don'

Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

Hello, I just found what I think is a couple of bugs in Generic Views: First: in the class MultipleObjectMixin, in the file django/views/generic/list.py there is a couple of methods that i think have a possible bug or missbehavior: lines 65/101 def get_context_object_name(self, object_lis

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

Hi, First, in answer to your question in the title - yes, normally you should report bugs like this to Trac, once you are sure you've found a bug. > The problem here is: > > > If i don't set a context_object_name in my app, the method > get_context_object_name puts a name based in the verbose_

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

BTW: what happens when your verbose_name_plural contains a quote (single or double)? -- Gert Mobile: +32 498725202 Twitter: @gvangool Web: http://gert.selentic.net On Thu, Dec 9, 2010 at 18:42, Luke Plant wrote: > Hi, > > First, in answer to your question in the

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

On Thu, Dec 9, 2010 at 12:42, Luke Plant wrote: > Hi, > > First, in answer to your question in the title - yes, normally you > should report bugs like this to Trac, once you are sure you've found a > bug. > > Then is better, we disscuss if this is really a bug. > > The problem here is: > > >

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

On 9 December 2010 19:40, Gert Van Gool wrote: > BTW: what happens when your verbose_name_plural contains a quote (single or > double)? > -- Gert Or whitespace :) Plus, most people put a ugettext_lazy there, so it's translated in admin model list. I don't think context variable names shouldn't de

Ticket 14567 bump/update (ModelMultipleChoiceField: self.queryset.none() vs. [])

http://code.djangoproject.com/ticket/14567 I recently updated my django trunk and noticed some changes to the test file structure that made my previous patch for this issue invalid, so I went back and made the necessary adjustments. I realize this isn't one of the more controversial or interesting

Re: Purpose of constant_time_compare?

Depending on the implementation, yes timing attacks can be exploited in the field, not just in theory. Again much depends on a lot of variables involved. Nate Lawson and Taylor Nelson had a great talk at BlackHat that covered piles of background and theory of timing attacks and successful exploita

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

the ticket http://code.djangoproject.com/ticket/14878 -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital about:me http://www.google.com/profiles/diegueus9 cel 3015290609 2010/12/9 Łukasz Rekucki > On 9 December 2010 19:40, Gert Va

question concerning the ModelChoiceIterator

Hey, why is the __len__ funtion in ModelChoiceIterator implemented as len(self.queryset) and not self.queryset.count. I thought the secound case would be a lot faster. Probably i'm thinking in the wrong way here. thx Sebastian -- You received this message because you are subscribed to the Google

Re: question concerning the ModelChoiceIterator

Because the assumption is that the QuerySet is going to be evaluated anyway (it's sort of in the class's name), so performing 2 queries would be wasteful. Alex On Thu, Dec 9, 2010 at 3:50 PM, bastir wrote: > Hey, > why is the __len__ funtion in ModelChoiceIterator implemented as > len(self.quer

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

+1 on fixing the the verbose_name_plural usage, as __every__ user with an activated language (that is: aside from english) will run into it. Regarding the double entry in the context: I am +1 on leaving object_list in there. This way middlewares (or other generic view mixins) could act on object_li

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

On Thu, Dec 9, 2010 at 17:10, Florian Apolloner wrote: > +1 on fixing the the verbose_name_plural usage, as __every__ user with an > activated language (that is: aside from english) will run into it. Regarding > the double entry in the context: I am +1 on leaving object_list in there. > This way m