Request to upgrade DJango

[Adam Bishop]

Hello,

I noticed that Django-1.3 has spent 14 days in the testing branch as of yesterday - do you plan to release it now, or does additional testing need to be done on it?

Thanks,

Adam Bishop
Access & Identity Management 
Janet
Direct line: +44 (0)1235 822 245
Janet, the UK’s education and research network

On 20 Apr 2012, at 19:25, David Malcolm wrote:

> On Fri, 2012-04-20 at 09:37 -0700, Toshio Kuratomi wrote:
>> On Fri, Apr 20, 2012 at 12:16:34PM -0400, Adam Young wrote:
>>> On 04/20/2012 10:47 AM, Toshio Kuratomi wrote:
>>> 
>>>    On Fri, Apr 20, 2012 at 09:42:26AM -0400, Adam Young wrote:
>>> 
>>>        One caveat.   Any DJango app (Probably most Python wsgi apps, actually) is
>>>        going to give an AVC Denial warning upon startup.
>>> 
>>>    Only a denial?  ;-)  Do you have selinux in permissive?
>>> 
>>> In enforcing it still gives a denial....
>>>        DJango imports Python's UUID
>>>        module which in turn imports ctypes.  Ctypes does dynamic code generation,
>>>        specifically by writing a file andd then trying to execute it, which, as you
>>>        can imagine,  is a pretty big security hole.  Let the wsgi community know that,
>>>        until we have that fixed,  we should not attempt to get rid of the AVC denial
>>>        warning message, but instead should push on the Python upstread to get a fix
>>>        in.  Yes, David Malcolm is aware of it.
>>> 
>>>        https://bugzilla.redhat.com/show_bug.cgi?id=814391
>>> 
>>> 
>>>    That's sorta a duplicate of this bug;
>>>    https://bugzilla.redhat.com/show_bug.cgi?id=582009
>>> 
>>>    (AFAICS, they're the same, but yours is against RHEL and mine is against
>>>    Fedora).
>>> 
>>> 
>>> Yes,  they are the same,  but mine has to do with the fact that it is part of
>>> the core library calling into ctypes.  They can be addressed and fixed
>>> separately.
>>> 
>> Upstream python doesn't like ctypes because it allows python code to more
>> easily create obscure bugs but it likes it more than the alternatives.  The
>> reason is that upstream python is very friendly to the alternate language
>> vms/interpreters.  Those alternatives often can't work with the python
>> C-API/ABI.  But they can work with ctypes.
>> 
>>> 
>>>    I discussed it with dmalcolm when I opened it in 2010 -- it's not easily
>>>    solvable.
>>> 
>>>    * By its nature, libffi needs to generate code that it then executes.
>>> 
>>> I think this is the crux of the matter.  I do not think that libffi needs to
>>> write this code out to disk to read it back in.  It would be better if it held
>>> it in memory, but even that would probably be disallowed by SELinux.  I suspect
>>> that there are better ways to do this form of dynamic binding that does not
>>> require code generation. 
>>> 
>> The previous python maintainer actually wrote the patch to have it write out
>> to disk because we have SELinux set to prevent execmem by default.  Writing
>> to disk is "better" in that it allows noexecmem by default on Fedora.
>> 
>>> However,  for libraries shipped with Fedora,  there should be no need to use
>>> ctypes.
>>> 
>> If you're talking about changing uuid into an extension module, then see
>> above as to why that isn't an upstreamable change.
> 
> It may be possible to fix the issue with uuid with a one-line change to
> ctypes which makes it avoid the SELinux-unfriendly codepaths unless
> absolutely necessary (uuid doesn't use them): see
> https://bugzilla.redhat.com/show_bug.cgi?id=814391#c2
> 
> 
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list


Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG