Ticket #268 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Use of PYTHONPATH env var in an insecure way

Reported by: sylvestre Owned by: somebody
Priority: blocker Milestone: 0.5.0
Component: guake Version:
Keywords: Cc:

Description

A security issue have been reported on the Debian bt:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605164

As attachement, a fix

Attachments

PYTHONPATH.diff Download (0.8 KB) - added by sylvestre 2 years ago.
0001-fixing-python-layout-part-1.patch Download (5.2 KB) - added by ulidtko 2 years ago.
python distribution layout patch, part 1
0002-fix-python-layout-part-2.patch Download (6.0 KB) - added by ulidtko 2 years ago.
python distribution layout patch, part 2
0003-fix-python-layout-lapping.patch Download (1.9 KB) - added by ulidtko 2 years ago.
python distribution layout patch, part 3
0004-fix-python-layout-guake-prefs-script.patch Download (2.0 KB) - added by ulidtko 2 years ago.
python distribution layout patch, part 4

Change History

Changed 2 years ago by sylvestre

  Changed 2 years ago by ulidtko

Moreover, I would say that Guake violates Filesystem Hierarchy Standard by placing .py files under /usr/lib. They should go to /usr/share/pyshared/guake/*.py, and the compiled binary C module should go to /usr/lib/python2.6/dist-packages.

So, the wrong distribution layout causes the need of using PYTHONPATH. This should be fixed, rather then workarounded with alternative substitution.

And furthermore, I have a patch for this; see attachments.

Changed 2 years ago by ulidtko

python distribution layout patch, part 1

Changed 2 years ago by ulidtko

python distribution layout patch, part 2

Changed 2 years ago by ulidtko

python distribution layout patch, part 3

Changed 2 years ago by ulidtko

python distribution layout patch, part 4

  Changed 2 years ago by lincoln

  • status changed from new to closed
  • resolution set to fixed

Hello there,

I agree with ulidtko about the FHS violation and I'm happy to say that I've applied the patches to fix this :)

Thank you!

follow-up: ↓ 4   Changed 2 years ago by sylvestre

OK, great. Do you have an ETA for a new release with this change ?

If I may comment the change (I am not the author of these commits), it is usually preferred to set the actual author of the patch (the option --author in git allows that).

in reply to: ↑ 3   Changed 2 years ago by lincoln

Replying to sylvestre:

OK, great. Do you have an ETA for a new release with this change ?

Humm, not yet. I'll start this discussion in the mailing list. I guess it's about the time to happen.

If I may comment the change (I am not the author of these commits), it is usually preferred to set the actual author of the patch (the option --author in git allows that).

I usually apply patches using git-am, this uses all present fields, like Date, Author. Is there any patch that was applied without this info?

  Changed 2 years ago by sylvestre

Sorry, my bad. ;) Trac is wrong on this page: http://guake.org/log/src/globals.py.in?rev=1f7c06378019150870e58554fdb6f2a44d687b81 It says "Author" which it should say "commiter" Sorry for the useless noise!

  Changed 2 years ago by pingou

At the detail of the commit, it differs author from git-author: http://guake.org/changeset/61d67c4d61882188b93f17d901298454dd243ca7/src/globals.py.in

Note: See TracTickets for help on using tickets.