On Tue, 23 Mar 2010, Antoine Pitrou wrote:
Greg Ewing canterbury.ac.nz> writes:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's o
Greg Ewing canterbury.ac.nz> writes:
> > The main point of the __pycache__ proposal is to solve the needs of
> > Ubuntu/Debian packagers. If you are developing (rather than deploying or
> > building packages), you shouldn't have these needs AFAICT.
>
> Maybe it's one point, but I'm not sure it's
Greg Ewing canterbury.ac.nz> writes:
>
> Doesn't the existing .pyc mechanism have the same problem? Seems
> to me it's just as insecure to allow the Apache user to create
> .pyc files, since an attacker could overwrite them with arbitrary
> bytecode.
The problem is that you can't delete the __py
Barry Warsaw python.org> writes:
>
> When Python is being installed, either by a from-source 'make install' or by
> the distro packager, then you'd expect the umask not to be insane. In the
> latter case, it's a bug and in the former case you screwed up so you should be
> able to delete and rein
Barry Warsaw python.org> writes:
>
> I'm not sure what the right answer is. Some possible choices:
>
> * Tough luck
> * Force the umask so that the directory is writable, but then the question is,
> by whom? ugo+w or something less?
> * Copy the permissions from the parent directory and igno
