RE:pybuild sphinxdoc and extensions
> Yes. Which wiki page? URL? this one [1] > Ahum... "maintaining a patch" is probably an overstatement here. > Here's an example "diff" (not a valid diff for computers, but enough for > understanding by humans): > extensions = ['sphinx.ext.autodoc', > 'sphinx.ext.todo', > 'sphinx.ext.coverage', >- 'sphinx.ext.intersphinx', yes this is a one liner patch. > So, you'd be just removing 'sphinx.ext.intersphinx' from the extensions > list, that's a really minimalistic one liner patch. And that's much much > much cleaner than forcing sphinx to fail accessing the network. I just follow the LibraryStyleGuide... cheers Frederic [1] https://wiki.debian.org/Python/LibraryStyleGuide -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e58...@sun-dag3.synchrotron-soleil.fr
Re: pybuild sphinxdoc and extensions
On 04/07/2014 03:39 PM, picca wrote: >> As for http_proxy='localhost', it's much better to write >> http_proxy='127.0.0.1:9', as there really could be a web proxy running >> on localhost, and you don't really want to use it, do you? > > I just used the snipset of the wiki page explaining the library > packaging. Maybe the wiki should be changed. Yes. Which wiki page? URL? >> Also, are you >> doing like this to avoid intersphinx? In this case, why don't you just >> remove the intersphinx extension from conf.py? That's IMO much cleaner >> than just blocking the connection. > > It is easier for me to deal with this from the debian/rules files instead of > maintaining a patch. Ahum... "maintaining a patch" is probably an overstatement here. Here's an example "diff" (not a valid diff for computers, but enough for understanding by humans): extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.coverage', - 'sphinx.ext.intersphinx', So, you'd be just removing 'sphinx.ext.intersphinx' from the extensions list, that's a really minimalistic one liner patch. And that's much much much cleaner than forcing sphinx to fail accessing the network. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53457de4.1000...@debian.org
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
Hi.
Jakub Wilk writes:
> * Jakub Wilk , 2014-02-13, 00:27:
>>>The CGI's code is supposed to be safeguarding against abuse,
>>The protection is not very good. (I'll disclose the details later.)
>
> The exploit I had in mind was:
>
> import re
> from re import sys
> imp = re.sys.modules['imp']
> posix = imp.load_dynamic('', 'posix')
>
> which gives you access to the goodies of the posix module. There's a
> resource limit that prevents you from opening any file, but you can do
> chmod(), chown(), remove(), rename(), kill(), …
>
> Apparently this is now fixed:
> https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a
>
> I wouldn't be surprised if there were other clever ways to bypass OPT's
> security restrictions, and upstream doesn't seem to confident about this
> code either.
Thanks for sharing this. I'll have to read about re.sys (WTF ?)...
FWIW, I've put a hold to my tests of packaging OPT, while I was
investigating the use of Docker for sandboxing Web apps in its
containers.
For instance, I've been playing with FusionForge's mediawiki (including
its PostgreSQL and Apache dependencies) in such an environment, and it
seems one possible way...
I'm not sure whether others have similar plans using Docker for
something that could be done "the debian way". Probably deserves another
post.
Best regards,
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738hmveul@inf-8660.int-evry.fr
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
* Jakub Wilk , 2014-02-13, 00:27:
The CGI's code is supposed to be safeguarding against abuse,
The protection is not very good. (I'll disclose the details later.)
The exploit I had in mind was:
import re
from re import sys
imp = re.sys.modules['imp']
posix = imp.load_dynamic('', 'posix')
which gives you access to the goodies of the posix module. There's a
resource limit that prevents you from opening any file, but you can do
chmod(), chown(), remove(), rename(), kill(), …
Apparently this is now fixed:
https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a
I wouldn't be surprised if there were other clever ways to bypass OPT's
security restrictions, and upstream doesn't seem to confident about this
code either.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409121133.ga2...@jwilk.net
