Request to upgrade DJango
 

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-incompatible-changes-in-1-3
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?


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

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-incompatible-changes-in-1-3
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.

--
Matthias Runge <mrunge@matthias-runge.de>
<mrunge@fedoraproject.org>

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

On 04/17/2012 02:10 PM, Matthias Runge wrote:

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-incompatible-changes-in-1-3


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.


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

On 17/04/12 21:29, Adam Young wrote:

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.


I just pushed an update to django-1.3.1 to epel6-testing. I'll look into
packaging

django-1.4 probably tomorrow.

Matthias
--
Matthias Runge <mrunge@matthias-runge.de>
<mrunge@fedoraproject.org>

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

On 17/04/12 21:29, Adam Young wrote:
> 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.
Ok, could you please try this one here:

http://www.matthias-runge.de/fedora/Django-1.4-2.el6.noarch.rpm

-docs:
http://www.matthias-runge.de/fedora/Django-doc-1.4-2.el6.noarch.rpm

and (for anyone interested:)

http://www.matthias-runge.de/fedora/Django-1.4-2.el6.src.rpm

(all of them taken from f17).

Matthias
--
Matthias Runge <mrunge@matthias-runge.de>
<mrunge@fedoraproject.org>

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

thanks.i will try.

On Wednesday, April 18, 2012, Matthias Runge <mrunge@matthias-runge.de> wrote:
> On 17/04/12 21:29, Adam Young wrote:
>> 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.
> Ok, could you please try this one here:
>
> http://www.matthias-runge.de/fedora/Django-1.4-2.el6.noarch.rpm

>
> -docs:
> http://www.matthias-runge.de/fedora/Django-doc-1.4-2.el6.noarch.rpm
>
> and (for anyone interested:)

>
> http://www.matthias-runge.de/fedora/Django-1.4-2.el6.src.rpm
>
> (all of them taken from f17).
>
> Matthias

> --
> Matthias Runge <mrunge@matthias-runge.de>
> * * * * * * * <mrunge@fedoraproject.org>
>

> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list

>

--
Sent from Gmail Mobile

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

On Tue, 2012-04-17 at 20:10 +0200, Matthias Runge wrote:
> 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-incompatible-changes-in-1-3
> > 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.


Yes, ReviewBoard currently cannot work with Django 1.4. This is a known
issue and last I heard probably won't be fixed until ReviewBoard 1.7.0
(not yet in beta release).

However, now that your 1.3.1 packages are in updates-testing, I have
been able to package up ReviewBoard 1.6.5 which requires Django 1.3, so
thanks for that. :) There are a lot of improvements in the 1.6.x series
that I think people will like.

https://admin.fedoraproject.org/updates/django-evolution-0.6.7-1.el6,python-djblets-0.6.16-1.el6,RBTools-0.4.1-1.el6,ReviewBoard-1.6.5-2.el6
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

On 04/19/2012 09:56 PM, Stephen Gallagher wrote:

On Tue, 2012-04-17 at 20:10 +0200, Matthias Runge wrote:


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-incompatible-changes-in-1-3
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.




Yes, ReviewBoard currently cannot work with Django 1.4. This is a known
issue and last I heard probably won't be fixed until ReviewBoard 1.7.0
(not yet in beta release).

However, now that your 1.3.1 packages are in updates-testing, I have
been able to package up ReviewBoard 1.6.5 which requires Django 1.3, so
thanks for that. :) There are a lot of improvements in the 1.6.x series
that I think people will like.

https://admin.fedoraproject.org/updates/django-evolution-0.6.7-1.el6,python-djblets-0.6.16-1.el6,RBTools-0.4.1-1.el6,ReviewBoard-1.6.5-2.el6






_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list


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





By not allowing this action, the UUID generation code becomes
inactive, but DJango continues to function normally.* For
ReviewBoard,* and most apps,* this is acceptable.





_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

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?

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

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.
* Because python is interpreted, selinux has no transition to tell it that
this is a specific program that needs to be able to write and execute
specific files
* Because the python interpreter is being embedded inside of apache, selinux
has no way of differentiating it from any other piece of apache.

The way out that I suggested in 2010 was to have a search path. Python
would loop through the search path to find which directory it could use to
write its temporary files for ffi. We'd need a way to set this path when
applications start up (maybe in their httpd.conf) as mod_wsgi allows
applications to run as different users than apache (which means that each
wsgi application might need a different ffi directory). The sysadmin or wsgi
application package would be responsible for creating the ffi directory and
setting the appropriate selinux context on it.

dmalcolm might not have liked that idea because of all the visible changes
it would have to do (configuring the directories to search). Or it might
just have been too much time to expend. I'm not sure.

btw, the workaround is to set httpd_tmp_exec --> on

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to upgrade DJango
 

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.





* Because python is interpreted, selinux has no transition to tell it that
this is a specific program that needs to be able to write and execute
specific files
* Because the python interpreter is being embedded inside of apache, selinux
has no way of differentiating it from any other piece of apache.

The way out that I suggested in 2010 was to have a search path. Python
would loop through the search path to find which directory it could use to
write its temporary files for ffi. We'd need a way to set this path when
applications start up (maybe in their httpd.conf) as mod_wsgi allows
applications to run as different users than apache (which means that each
wsgi application might need a different ffi directory). The sysadmin or wsgi
application package would be responsible for creating the ffi directory and
setting the appropriate selinux context on it.

dmalcolm might not have liked that idea because of all the visible changes
it would have to do (configuring the directories to search). Or it might
just have been too much time to expend. I'm not sure.

btw, the workaround is to set httpd_tmp_exec --> on

-Toshio






_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list






_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list