Re: Untrusted search path vulnerabilities
On Thu, Nov 18, 2010 at 07:04:07PM +0800, Paul Wise wrote: > > On Wed, Nov 17, 2010 at 22:58, Jakub Wilk wrote: > >> A number of packages in the archive sets the PYTHONPATH environment > >> variable > >> in an insecure way. They do something like: > >> > >> PYTHONPATH=/spam/eggs:$PYTHONPATH > >> > >> This is wrong, because if PYTHONPATH were originally unset or empty, > >> current > >> working directory would be added to sys.path. > > I wonder if this class of vulnerabilities (inc the LD_LIBRARY_PATH > ones) could be automatically warned about by lintian. I wonder if this wouldn't be our duty to remove the possibility of these vulnerabilities at all. Who relies on these PATH variables features to include the current directory instead of adding "." ? Why don't we fix python, ld.so and other stuff doing the same such that empty entries are skipped ? Mike -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118111750.ga31...@glandium.org
Re: Check license and copyright of files in entire tree (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
On Mon, Apr 21, 2008 at 11:27:18PM +1000, Ben Finney wrote: > Emilio, and everyone: a reminder to please continue following > http://www.debian.org/MailingLists#codeofconduct>. In particular, > please don't send individual copies of messages also sent to the list, > since I haven't asked for that. > > > Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > > > Ben Finney wrote: > > > Good catch. I'll have to gather the copyright notices properly > > > from the whole tree. > > > > Have a look at `licensecheck -R *` (in case you haven't yet), very > > useful script for these purposes. > > Indeed, I wasn't aware of that. In this case, it's even more useful > for me to run: > > $ licensecheck --recursive --copyright . Just don't forget that it will skip a lot of file types by default. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
On Fri, Oct 05, 2007 at 08:04:27PM +0200, Josselin Mouette wrote: > Please note that they can all be binNMUed after python2.5 has become the > default, but all of them will have to migrate to testing at once. We > must make this list shorter unless we want this transition to recall bad > memories to the release team. Well, then, that's not going to happen before the toolchain gets fixed on mips, because of > Here is the list: (...) > xulrunner Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
current python-only packages and new policy
Hi, I'm writing because the New Policy is not very verbose on building a package for only the current version of python. First, why would i need to build-dep on python-all-dev when python-dev is enough ? Second, why would i need to use python-central or python-support when there's only one supported version of python ? Mike PS: Please Cc me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Sun, Jul 02, 2006 at 12:55:27PM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > FWIW, here is what i got for python-libxslt1: the files are the same size, > but are different. I was wondering how different they could be and it's > quite stunning, actually: > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C > python2.3/libxsltmod.so > /tmp/2.3 > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C > python2.4/libxsltmod.so > /tmp/2.4 > [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.* > 1808c1808 > < 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 39 > |..E...$..v.9| > --- > > 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 3b > > |..E...$..v.;| > > > Yep, there's only one *bit* of difference. It's even worse. There's *no* real difference. [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ objdump -d python2.3/libxsltmod.so > /tmp/2.3 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ objdump -d python2.4/libxsltmod.so > /tmp/2.4 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.3 /tmp/2.4 2c2 < python2.3/libxsltmod.so: ファイル形式 elf32-i386 --- > python2.4/libxsltmod.so: ファイル形式 elf32-i386 3596c3596 < 714f: 39 7d f0cmp%edi,0xfff0(%ebp) --- > 714f: 3b 7d f0cmp0xfff0(%ebp),%edi Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
FWIW, here is what i got for python-libxslt1: the files are the same size, but are different. I was wondering how different they could be and it's quite stunning, actually: [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C python2.3/libxsltmod.so > /tmp/2.3 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ hexdump -C python2.4/libxsltmod.so > /tmp/2.4 [EMAIL PROTECTED]:/usr/lib/python-support/python-libxslt1$ diff /tmp/2.* 1808c1808 < 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 39 |..E...$..v.9| --- > 7140 08 8b 45 ec 89 04 24 e8 e8 d9 ff ff 8b 76 18 3b |..E...$..v.;| Yep, there's only one *bit* of difference. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Fri, Jun 30, 2006 at 06:43:22PM +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 30 juin 2006 à 17:38 +0200, Mike Hommey a écrit : > > On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette <[EMAIL > > PROTECTED]> wrote: > > > Python-support already checks the md5sums of the files to install, but > > > it excludes the .so because files are moved to /usr/share and it would > > > violate the FHS. I also thought this would never happen. > > > > > > I can add the handling of this case by putting them e.g. > > > in /usr/lib/python-support/python-foo/all/. > > > > What if, let's say, python 2.3 and 2.4 versions are identical, but 2.5 > > is different ? > > > > Also, don't forget the files are different until they are stripped. So > > the basis for differenciation shouldn't be an md5sum... > > It's kind of chicken-and-egg problem. If dh_pysupport is run before > dh_strip, it won't detect this similarity. If it is run after dh_strip, > it won't be possible to use dh_strip --dbg-package as gdb wouldn't be > able to find the symbols at their final location. > > If the case is sporadic enough, I guess we should just let go or handle > the case by hand. If it is not, I can try to modify python-support so > that it moves files in /usr/lib/debug as well, but it's kind of ugly. Or you could compare all ELF sections except .debug.* or something along these lines. Or strip in a temporary directory, but that'd mean the stripping work would be done twice... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Fri, Jun 30, 2006 at 04:16:40PM +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Python-support already checks the md5sums of the files to install, but > it excludes the .so because files are moved to /usr/share and it would > violate the FHS. I also thought this would never happen. > > I can add the handling of this case by putting them e.g. > in /usr/lib/python-support/python-foo/all/. What if, let's say, python 2.3 and 2.4 versions are identical, but 2.5 is different ? Also, don't forget the files are different until they are stripped. So the basis for differenciation shouldn't be an md5sum... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python independant binary extensions
On Thu, Jun 29, 2006 at 10:09:20PM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm currently working on getting libxml2 (and later libxslt) to the new > policy, and actually noticed something interesting: > -rw-r--r-- root/root273888 2006-06-29 22:02 > ./usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so > -rw-r--r-- root/root273888 2006-06-29 22:02 > ./usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so > > Same size AND same content. A bit more information on that: Before dh_strip: -rwxr-xr-x 1 root root 770117 Jun 29 20:31 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rwxr-xr-x 1 root root 770117 Jun 29 20:31 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so md5sums: 7a59735cc2928d873051ec02ec918fa9 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so a23dffbdd649938b80b4cad250dd71cc debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so After dh_strip: -rwxr-xr-x 1 root root 273888 Jun 29 21:05 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rwxr-xr-x 1 root root 273888 Jun 29 21:05 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so md5sum: 417dad3c9d4def4e10cf57470d5d0296 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so 417dad3c9d4def4e10cf57470d5d0296 debian/python-libxml2/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so So, if python-support/python-central would deal with that it would need to be done after dh_strip... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Python independant binary extensions
Hi all, I'm currently working on getting libxml2 (and later libxslt) to the new policy, and actually noticed something interesting: -rw-r--r-- root/root273888 2006-06-29 22:02 ./usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so -rw-r--r-- root/root273888 2006-06-29 22:02 ./usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so Same size AND same content. After some discussions on #debian-python, I added stuff in debian/rules so that if the binary extensions are identical, I'd replace the dup with a symbolic link. I'm still building for all versions as suggested on #d-p in case the python includes change in some ways. Don't you think it'd be nice to add support to python-support and python-central for that case ? Cheers, Mike PS: Please Cc me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, 13 Jun 2006 at 16:10:48 -0500, Joe Wreschnig wrote: > On Tue, 2006-06-13 at 22:05 +0200, Mike Hommey wrote: > > What about people who want to use pyxpcom with modules that aren't > > available with the current python ? > > But a user couldn't install more than one such module at a time, since > the packages are mutually exclusive. It seems far better to me to just > force everyone to use one version and avoid the issue. > > Or, fix pyxpcom, which sounds horribly broken. It's not broken, actually. There are 2 different things in pyxpcom: - a python binding to load and use xpcom components - an xpcom component to load and use python written components (pyloader). The problem is that if you launch the python binding, it will also load the pyloader component. If this component doesn't use the same python version as the binding you're using, you're pretty much fscked. Maybe there would be a way not to load the pyloader component if loaded from an incompatible python version... Mike PS: Please CC me, I'm not subscribed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > When you install some python extensions (.so), it is common that they come > with > associated .py files (modules). Those .py files usually are the same in > /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will > keep only one copy of them in /usr/share/pycentral and symlink them back into > /usr/lib/python2.[34]/ ... > > However if the .py installed in /usr/lib/python2.3 is different from the > one installed in /usr/lib/python2.4, then you can't share it between both > versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I > meant. Feel free to fix the wording in the wiki if you have a better way > to express it. Okay, it sounds clearer said like that. Stupid question: why doesn't pycentral autodetect if files are different or not ? I don't actually see a reason why DH_PYCENTRAL need to be set... > > PS: Anyways, there's one package you didn't list because it's in NEW, > > which WON'T be merged as required by the new policy: python2.x-xpcom, > > provided by xulrunner. > > The reason is simple: different installations for different python > > versions CAN'T coexist without breaking each other. > > OK, then indicate "current" in XS-Python-Version and support only the > current version in python-xpcom (make sure to generate the provides > field). What about people who want to use pyxpcom with modules that aren't available with the current python ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 08:38:57PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > Hello, > > the Python team has agreed on a new policy [1]. As we want to do the > python 2.4 transition now, we need to make sure the packages match the > policy. This will limit the amount of broken packages when python2.4 will > become the default and will smooth this transition. > > So please check in the list at the end of this mail if you're concerned, > and if yes, please update your packages following these instructions: > http://wiki.debian.org/DebianPython/NewPolicy > http://people.debian.org/~piman/python-policy/ Maybe I'm dumb or something, but I don't get what "If the public modules installed differ between python versions and if they can't be shared, you should set the following environment variable when invoking dh_pycentral." is supposed to mean. Please Cc: me, I'm not subscribed. Mike PS: Anyways, there's one package you didn't list because it's in NEW, which WON'T be merged as required by the new policy: python2.x-xpcom, provided by xulrunner. The reason is simple: different installations for different python versions CAN'T coexist without breaking each other. PPS: I'll take care of libxml2 and libxslt as soon as I understand what I'm supposed to change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 26, 2006 at 04:12:35PM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 21 janvier 2006 à 21:52 +0100, Mike Hommey a écrit : > > On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> > > wrote: > > > Python is the "official" language of Ubuntu. If we want to merge work > > > they're doing (Anthony Towns mentioned their work on boot speed, for > > > example) it's a good idea to structure our Python like theirs is. This > > > (...) > > > > Boot speed and python does not really sound a match... > > Surprisingly, python is often faster than perl for the same task. Boot speed and perl does not really sound a match either. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> wrote: > Python is the "official" language of Ubuntu. If we want to merge work > they're doing (Anthony Towns mentioned their work on boot speed, for > example) it's a good idea to structure our Python like theirs is. This > (...) Boot speed and python does not really sound a match... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
