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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[sago]

*very nice* Russ. Congrats and thanks! Totally removes a wart I've
just got used to working around.

"bake" is a pretty universal verb for this, afaict. I wouldn't say it
was clever or new. "fry" however (in Jacob's post) was new to me and
required googling.

Ian.

-- 
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: High Level Discussion about the Future of Django

[sago]

Isn't that what forking is for?

A group of folks feel frustrated about not being able to commit, so
they make their own copy of the source code available. A few months
later they either implode when they realise just how much work it is
going to take to do anything remotely sensible, or they come up with
some bit of nuggety goodness that can be chopped around and
backported.

As long as the forking happens without falling out, that is...

On a completely unrelated note, any plans to move Django to git?

Ian.

Not that I count for jack, but its +1 on API stability and backwards
compatibility from me, btw!



On Apr 16, 5:23 pm, "Tom X. Tobin"  wrote:
> On Fri, Apr 16, 2010 at 10:32 AM, Jacob Kaplan-Moss  
> wrote:
> > I'm not arguing that "stability, maturity, and longevity" are
> > "correct" priorities, only that, well, those are the ones we've
> > chosen. I'm not saying it's "wrong" to want more rapid improvement,
> > only that it's lower on *my* list.
>
> My priorities overlap, but not completely.
>
> Stability is very important to me, and should be important to *anyone*
> whose livelihood depends on Django.  Stability is a large part of the
> reason we *can* run our own Django branch and run production sites
> based on it, yet not lose our minds in the process.
>
> Maturity is fairly important; I want solutions that have experience
> and judgement behind them.  Maturity can become rigidity, though; I
> enjoy exploring new ways to solve existing problems, and a new, but
> superior, solution isn't — strictly speaking — "mature".
>
> Longevity is where I part ways; I'd much rather have a clean break
> than keep working around a wart.  I think my overriding principle here
> is correctness; I'm perfectly happy to do the work to fix my code if
> it means adopting the *right* solution.
>
> None of this means that I think the core development process should
> change.  (Well, besides my fervent desire that they officially adopted
> git — and yes, I do believe it *would* make a difference, centralized
> "official" branch and all — but that's a discussion for another time
> and a few beers.)  Django has been very successful with the current
> process, and I'd be very wary of tinkering with the foundations of
> that success.
>
> But here's the great part: nothing is stoping anyone from hacking new
> paths through the jungle on their own branches.  What you *can't* get
> — and honestly *shouldn't* get — is automatic recognition that your
> branch is somehow officially supported, and all the notions of
> stability, maturity, and longevity that go with that recognition.  If
> you know enough to make significant changes to Django, you also
> probably know enough to fix the problems that can crop up due to your
> changes — and that's not something we should expect from the average
> developer who just wants to Get Work Done.
>
> So ... who has a GitHub account and some neat code to look at?  :-)
>
> --
> 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 
> athttp://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: What The Enterprise wants from Django

[sago]

> I would have guessed that a big issue with Django from an enterprise
> perspective is its use of 'singletons'.
>
> How much is this an issue in practice?  
Yes, that's been my experience. For complex deployments with tens or
hundreds of apps, it is often the case that it is absolutely essential
to have settings on a per-app basis. Unfortunately those settings very
often clash.

> It strikes me that this is just one example of a whole class of "best
> practice" stuff that we should document, but don't at present - like
> project layout, automated deployment, continuous integration,
> configuration management, etc.
It would help smaller companies I think, folks who need to deploy a
couple of SOA nodes or a site with ten or twenty apps across a handful
of servers. When it comes to huge deployments, it is so diverse. Best
practice for Google isn't best practice for wisconsinhairstylists.com

Case studies are helpful if folks can share them. But its a political
minefield (or unhelpful pontification, depending on the care you take)
to get into the business of canonizing deployment structures!
-- 
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: What The Enterprise wants from Django

[sago]

> I don't understand how avoiding the settings.py mechanism will produce
> *more* flexibility.

Bad choice of words on my part, sorry. Of course code is always more
flexible than static data.

The two key bits of required 'flexibility' I didn't have out of the
box (and were difficult to hack and get working) are:
1. App level settings that are mutually exclusive (one app needs
settings different from another - this happens a lot).
2. Setting definitions that aren't tied in timing and scope terms to
Python's import process (I've seen this interact badly with start-up
code, for example).
And it would be cool to have a level of indirection so that settings
could be guaranteed to be dynamic (some are, some aren't, those that
are often need monkey-patch style hacks to change). And tools for
debugging where settings for a failed request are defined. And a
security layer around some settings. And fields and fields of other
ponies.

Seriously though, I don't think the settings.py approach is broken. It
makes sense, makes getting from nothing to runnable code a breeze, is
logical for small deployments, and has bags of flexibility for most
use-cases. I'm happy adjusting it in my projects. I've never deployed
or seen deployed a system that used settings.py in anything like its
default version, but the replacements aren't standard enough to be an
alternative default; every client has different technical, management
and internal politics constraints.

My comments were meant in the spirit of Jacob's. Just FYIs for a
particular niche of users.

I should also say that most of the developers I work with do love
working with Django. So their criticisms have to be taken against a
background of strong positivity.

-- 
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: What The Enterprise wants from Django

[sago]

I also work with several fortune 500 clients (though not specifically
as a Django consultant, Django is a preferred tool) and the issues
your client mentions, Jacob, are very similar to those I deal with.

Some other notes from the concerns of multinational clients:

I've had one very long and complex issue with a major client over
legacy databases with Composite Primary Keys (and other composite keys
more generally), an issue which has also come up in other contexts.
One of my smaller clients switched to a strange bastardization of
Django and SQLAlchemy because this was an issue. I understand the
history of #373 and why it is hard - just for disclosure.

A lack of any mechanism for developers to understand what third party
apps are reliable, what to avoid, known problems, and so on. This has
been a particular complaint since the Django ethos is (rightly) that
the core is the core, and other functionality should be packaged into
third party apps. App authors do a great job of being really generous
with their work, but it is very hard for stuff outside Django's core
to get any adoption. The processes involved in adopting a technology
can be complex and involve lots of stakeholders, legal and technical
due diligence. It is hard enough ticking those boxes to get Django
used, it simply isn't worth doing the same for all the other bits.
There's a lot of wheel reinventing going on, in my experience. A Django
+ project might be useful to give the rock-star third-party apps a
fighting chance at being used. Pinax is somewhat close, but has a very
different purpose and small, agile, company ethos.

Startup and Settings are the big killers though, head and shoulders
above the previous issues. I've nothing much to add to your comments
other than to say that some of the Django deployments I know of are
highly heterogeneous, with various servers running different SOA
elements, some Django some not. The configuration issues are
formidable and involve all kinds of dependencies beyond Django (or
even Python). I struggle to see a way that Django could solve those
issues, but allowing more flexibility and avoiding tying configuration
to an executable module (i.e. settings.py) would be useful. Like the
previous posters, I've also had to roll various custom solutions to
this problem. Is suspect at least some of the solution will always be
custom, though it might be worth making such solutions easier to
create.

It would also be useful for everyone to scream more loudly that monkey-
patching ANYTHING is a very bad idea. Its getting better now (as some
of the major things it was solving are solved properly), but it was a
woefully overused technique for a while that has meant a lot of
deployment pain! That's less about Django and more about evangelizing
bad development practice under the guise of Python-Fu.

Ian.
-- 
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: Suggestion: DictionaryField

[sago]

Mihail's initial version doesn't have any data in each model. So
presumably he's just tracking primary keys. In which case a
PositiveIntegerField would work.

And some of the use cases look awfully like 'choices=...' would be the
best bet. Others would be fine if you queried the current set of
values and put them in a drop down on the form:

options = set(MyModel.objects.values_list('opt', flat=True))

But I have had the odd occassion where I've wanted a set of options (a
la choices) but that were editable from the admin. Because of the need
to edit them, however, they have to be top level manually created
models, otherwise I can't specify their admin interface and edit them.

Ian.

On Jan 18, 3:35 am, Yuri Baburov  wrote:
> Hi Łukasz, Mikhail,
>
> You can go further and create DictionaryField.
>
> But I see the problems you will get with it:
> 1) You won't be able to refer to the model afterwards, since it's not
> defined in models.py as global.
> 2) I prefer to make DictionaryModel key the primary_key when
> appropriate, you'll need that option.
> 3) Additional fields or methods can appear at any time later, making
> such "economy" almost useless.
>
> So, my only wish is better builtin autocomplete widget for admin and
> regular usage.
> Current default one (for raw_id_fields) looks overcomplicated.
> Unfortunately, The Right autocomplete widget for django admin doesn't exist 
> yet.
>
> 2010/1/18 Łukasz Rekucki :
>
>
>
> > 2010/1/17 Simon Meers :
> >> I had considered designing something like this last week. It does seem to 
> >> be
> >> a common requirement -- any situation where a simple field would be almost
> >> suitable but for the fact you'd like to avoid duplicates and allow fast
> >> selection of existing values. A Field shortcut could be commonly used to
> >> avoid the creation of separate models. Another example:
>
> >>     class Suburb(models.Model):
> >>     name = models.CharField(max_length=64, unique=True)
>
> >>     class Meta:
> >>     ordering = ['name']
>
> >>     def __unicode__(self):
> >>     return u'%s' % self.name
>
> >>     class School(models.Model):
> >>     name = models.CharField(max_length=64, unique=True)
>
> >>     class Meta:
> >>     ordering = ['name']
>
> >>     def __unicode__(self):
> >>     return u'%s' % self.name
>
> >>     class Student(models.Model):
> >>     school = models.ForeignKey(School)
> >>     suburb = models.ForeignKey(Suburb)
> >>     # ...
>
> >> could be replaced with simply:
>
> >>     class Student(models.Model):
> >>     school = models.DictionaryField(max_length=64)
> >>     suburb = models.DictionaryField(max_length=64)
> >>     # ...
>
> >> I'm not 100% sold on the name, but I think it is on the right track. I'm
> >> also wondering whether it could be worth catering for types other than
> >> CharField as well. For example:
>
> >>     team_number = models.DictionaryField(type=models.IntegerField)
>
> >> This makes me wonder whether perhaps this could be generically applied to
> >> all fields via a Field.__init__ kwarg instead:
>
> >>     class Student(models.Model):
> >>         school = models.CharField(max_length=64, lookup=True)
> >>         suburb = models.CharField(max_length=64, lookup=True)
> >>         team_number = models.IntegerField(lookup=True)
>
> >> Either way, these fields could then be stored in separate tables
> >> appname_modelname_fieldname, with a single field of the appropriate type
> >> (named 'value' or similar). It would be nice to also provide external 
> >> access
> >> to these auto-generated models via something like Student.school.objects.
> >> Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
> >> and objects can be accessed via
> >> Student.school.field.related.parent_model.objects.all(), but a shortcut
> >> would be nice.
>
> >> The auto-generated models could provide ordering by value, a unique
> >> constraint on the field, and a simple __unicode__ method like the examples
> >> above.
>
> > This seems like a lot of work and tweeks, just so you can save that 2
> > lines to define a class.
>
> > class DictModel(models.Model):
> >    class Meta:
> >        abstract = True
> >        ordering = ['value']
> >        unique_together = ('value',)
>
> >    def __unicode__(self):
> >        return unicode(self.value)
>
> > # just 2 lines per dictionary and you have all the flexibility you'll ever 
> > need
> > class School(DictModel):
> >    value = models.CharField(max_length=64)
>
> > class Suburb(DictModel):
> >    value = models.IntegerField()
>
> > Also, by giving your dictionaries an explicit name, they can be easily
> > reused. I would probably also make the "value" field a primary_key, so
> > that you won't have to make all those joins just to print out
> > student's info.
>
> >> Simon
>
> >> 2010/1/17 Михаил Лукин 
>
> >>> 

Re: Possible contrib.humanize addition

[sago]

> Hmm, can it handle the following?
>
>  an honest man
>  a history book
>  an historical book (debatable)

It can't, the rules for the indefinite article around 'h' are complex
and depend on the etymology of the word used. To add complexity the
lexicographic rules are often different to the rules for speech, and
UK rules differ from US rules (and possibly Oz too, but I don't
know).

> If you present some research to
> demonstrate how this tag could/would work for non-English languages,
> it would be a lot more compelling.

That's not going to work, in any meaningful sense. That peculiarity of
the article is highly English-specific. The generalization would
surely be something like

{% if /some-regex/.matches(word) %}{{ form1 }} {{ word }}{% else %}
{{ form2 }} {{ word }}{% endif %}

where the regex is language and context dependent. There are various
regex replacement filters/tags out in the djangosphere. Could you use
one of them?

> (That's NT Koine Greek, it might be different/simpler/more complicated
> in modern Greek).
What is it about Django and NT scholars - have you come across James
Tauber (of Pinax fame?)

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

FilePathField pathnames

[sago]

When forms.FilePathField compiles the list of choices in its
constructor, it uses the full path name as the machine values for each
option, and just the final component for the human readable component.

This means that when rendered using the default widget, the output
includes the absolute path of the file on the server in the HTML
output. It seems clear to me that passing details of the directory
structure of the server out to the client is not a good thing to do
(not to mention an unnecessary waste of bandwidth).

I can, of course, get around this by using a custom widget to add and
remove the path component and just leave the last bit of the path (the
bit that the underlying form actually searches in, so the only bit
that is needed to differentiate different possible choices).

Seems like it should be standard behavior though. Should I raise a bug/
feature request and patch on this, or is there some good reason for
having the machine path passed out to the client?

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

[commercial] Django Training

[sago]

I just wanted to announce the first open commercial Django Training
program.

As well as being a great program, I hope it will be another
reinforcement in the message that Django is a deployable commercial
system for corporate web application development. I hope that having a
solid and skills-based program available will encourage more companies
to adopt Django and thereby raise the value of all our skills.

You can see details at

http://www.lamptraining.com/course/introduction-django/

And download the syllabus* at

http://www.lamptraining.com/syllabus/introduction-django.letter.pdf/
http://www.lamptraining.com/syllabus/introduction-django.a4.pdf/

I'm running two public open courses in the next couple of months, you
can see them at the info page above or on the schedule at:

http://www.lamptraining.com/schedule/

I'm also running a similar program with a Introduction to Python
program combined (see

http://www.lamptraining.com/course/django-and-python/

) on-site in a couple of weeks. If there's interest I could run that
publically too.

I'm adding new stuff over the next week or so, including some more
detail on some of the non-Django programs. If you need any more detail,
let me know.

Background
--

I've been developing web applications since 1996. I've been using
Django for over a year now to deliver projects for my clients (I
consult in software R). Recently, as companies have been considering
moving infrastructure to Django I've been asked to provide training,
both technical and in the form of management evangelism. As that has
increased in my workload, I decided to bring all the various training
that I can provide under the banner of this new training organisation:
LAMP Training (www.lamptraining.com).

Simply because there is nobody else doing it, and because there is a
lot of interest, most of the stuff I'm doing over the next couple of
months is Django related.

If you'd like to join a program, or have one delivered to your team get
in touch:

http://www.lamptraining.com/contact/


Best regards

Ian.


* Incidentally the site is a django project, including the on-demand
production of syllabus pdf's in a range of paper sizes. Nothing too
complex, the whole project is just a few hundred lines of code and was
three day's work, including design. But further evidence, if any is
required, as to the productivity Django can provide.


--~--~-~--~~~---~--~~
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---