On 17/04/12 19:43, Adam Young wrote: > While looking into EPEL support for Openstack, we came across the issue > that EPEL ships with 1.2.7 and Openstack expects 1.3. Upon looking at > https://docs.djangoproject.com/en/1.3/releases/1.3/#backwards-incompatibl... > > I see that one of the major differences is protection against XSRF. This > alone is sufficient reason to upgrade. > > Installing an RPM from the Sourceforge site worked well with Openstack, > so it seems to fit our needs as well. > > Are there any objections to upgrading EPEL's version of Django To the > latest? Umh, my fault. I'm planning to upgrade django for epel6 to version 1.3.x since two weeks now; sadly, real life kept me really busy. There have been some requests to upgrade to version 1.4 (to skip 1.3.x). I'm aware of at least one application, which would break, if we upgrade to django-1,4: reviewboard. So, I'd do an update to django-1.3.1 in the next few days. An additional reason to upgrade is, that django developers only support the two latest versions, so 1.2.7 is not actively maintained any more.

If you can provide a 1.4 RPM, I am willing to test Openstack against it. I suspect we can move to that more slowly, but we'll be ahead of the curve.

On 17/04/12 19:43, Adam Young wrote: > While looking into EPEL support for Openstack, we came across the issue > that EPEL ships with 1.2.7 and Openstack expects 1.3. Upon looking at > https://docs.djangoproject.com/en/1.3/releases/1.3/#backwards-incompatibl... > I see that one of the major differences is protection against XSRF. This > alone is sufficient reason to upgrade. > > Installing an RPM from the Sourceforge site worked well with Openstack, > so it seems to fit our needs as well. > > Are there any objections to upgrading EPEL's version of Django To the > latest? Umh, my fault. I'm planning to upgrade django for epel6 to version 1.3.x since two weeks now; sadly, real life kept me really busy. There have been some requests to upgrade to version 1.4 (to skip 1.3.x). I'm aware of at least one application, which would break, if we upgrade to django-1,4: reviewboard. So, I'd do an update to django-1.3.1 in the next few days. An additional reason to upgrade is, that django developers only support the two latest versions, so 1.2.7 is not actively maintained any more.

One caveat. Any DJango app (Probably most Python wsgi apps, actually) is going to give an AVC Denial warning upon startup.

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

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.

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.

However, for libraries shipped with Fedora, there should be no need to use ctypes.

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(a)redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list