Issue 16248: Security bug in tkinter allows for untrusted, arbitrary code execution. (original) (raw)
Created on 2012-10-16 15:29 by Ramchandra Apte, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (64)
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-16 15:29
Because tkinter.py uses exec to execute code from a file, it has a security bug. It searches for the file in the home dir. Apparently, on my system (don't know if its the same on others), the $HOME variable is the same as the non-root one when running Python with root priveleges Steps to reproduce: create a file called .Tk.py in your home folder Whatever code is in that file will be executed.
run these three lines of code in Python:
import tkinter w = tkinter.Tk() w.mainloop()
I will add more details in later comments.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-16 15:31
s/tkinter.py/tkinter.init
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-16 15:32
In Lib/tkinter/init.py:1801 , the readprofile function executes untrusted code.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-16 15:34
specifically, when running Python using sudo (not in a root shell), the $HOME variable is preserved.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-17 02:24
I made many mistakes in the original bug report. Here is a fixed one:
Because Lib/tkinter/init.py:1801 uses exec to execute code from a file, it has a security bug. It searches for the file in the home dir. Apparently, on my system, the $HOME variable is the same as the non-root one when running Python with root privileges using sudo.
Steps to reproduce: create a file called .Tk.py in your home folder Whatever code is in that file will be executed.
run these three lines of code in Python using sudo:
import tkinter w = tkinter.Tk()
And the code in the .Tk.py will be executed (unless if you change the baseName for the Tk object) There may be similar ways of running Python with root privileges preserving the environment variables in other OS'es Using Kubuntu Linux (variant of Ubuntu Linux) 12.04
Author: Guilherme Polo (gpolo) * 
Date: 2012-10-17 18:16
It is a well known fact that the readprofile function uses exec, and it has been like that for more than 18 years. The parameters baseName and className defines the execution of the files HOME/.className.tcl,HOME/.{className}.tcl, HOME/.className.tcl,HOME/.{className}.py, HOME/.baseName.tcl,andHOME/.{baseName}.tcl, and HOME/.baseName.tcl,andHOME/.{baseName}.py. The function's docstring actually say that.
Said that, I never needed to load custom code during the creation of a Tk instance. To me the existence of readprofile is unneeded.
But what is your proposal to the issue ?
Author: want to delete this account (Want to Delete This Account)
Date: 2012-10-18 04:55
On 17 October 2012 23:46, Guilherme Polo <report@bugs.python.org> wrote:
Guilherme Polo added the comment:
It is a well known fact that the readprofile function uses exec, and it has been like that for more than 18 years. The parameters baseName and className defines the execution of the files $HOME/.{className}.tcl, HOME/.className.py,HOME/.{className}.py, HOME/.className.py,HOME/.{baseName}.tcl, and $HOME/.{baseName}.py. The function's docstring actually say that.
Said that, I never needed to load custom code during the creation of a Tk instance. To me the existence of readprofile is unneeded.
But what is your proposal to the issue ?
Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16248>
Simply remove the readprofile code (it is not documented and I never had to use it)
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-18 05:02
Apparently when replying by email my old account name is shown ("mani and ram") Just so you know that "mani and ram" is me.
Author: Guilherme Polo (gpolo) *
Date: 2012-10-18 15:24
For something that has been around for so long, I would be a little more careful.
My suggestion is: no longer declare readprofile as an internal function; remove the direct call to readprofile from Tk.init; tell users about the new behavior, and the need to call readprofile themselves if they wish to.
In some years we might be able to estimate if readprofile is used at all, and then decide about removing it. Since I haven't been active as a Python committer, I will let the final decision to someone else.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-31 15:55
It is possible with this bug to make a sudo IDLE edit a root-file.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-31 15:56
oops ignore last msg
Author: Guilherme Polo (gpolo) *
Date: 2012-10-31 16:19
I can ignore it, but let us be honest. If you got sudo privilege already, why are you bothering to break (or whatever else) the system using IDLE ? The issue here did not give you the sudo privilege. If it did, then we have an actual security bug.
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-10-31 16:30
I think this is a legitimate security bug. the malicious program needs to create a file with a certain name in the home dir. If a user runs say IDLE (or another tk app) with root priveleges using sudo, the file will be run with root priveleges.
Author: Mark Dickinson (mark.dickinson) *
Date: 2012-11-01 10:22
Ramchandra: can you give an example of a realistic situation where the existence of this code in tkinter allows users to execute code that they wouldn't be able to execute otherwise?
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-11-01 14:09
@Mark Dickinson Run the attached file, exploit.py, with normal priveleges and then run IDLE with sudo (something I did to actually uncover this bug!). Then the file "/root/exploited" should contain "Exploit succeeded!"
Author: Mark Dickinson (mark.dickinson) *
Date: 2012-11-01 16:29
Okay, but if a user can run IDLE with sudo, they presumably already have many other ways to use sudo to create files in /root, without using IDLE or tkinter. That's why I said: "that they wouldn't be able to execute otherwise". I don't see the security issue here.
Author: Zachary Ware (zach.ware) *
Date: 2012-11-01 19:32
If I understand correctly, I think what Ramchandra is getting at is that if an attacker could manage to get a .Tk.py file into a user's home directory somehow, then the next time that user happens to do 'sudo idle', the attacker's code is executed with root privileges.
That said, I don't know that it would be any easier for an attacker to get such a file into such a place than to just do their maliciousness some other way.
I think Guilherme's suggestion of just making those who need it call it themselves, instead of at every tkinter startup, sounds good.
Author: Antoine Pitrou (pitrou) *
Date: 2012-11-01 19:55
As Zachary and Ramchandra explained, the security issue is obvious: a non-sudoer user A can make a sudoer user B execute arbitrary code, simply by placing a file where IDLE will be run from.
This is the same reason Python has -s and -E options. The least we could do would be to disable readprofile() when sys.flags.ignore_environment is true.
Author: Mark Dickinson (mark.dickinson) *
Date: 2012-11-01 19:58
And then user A is relying on user B executing IDLE via sudo? Is that a normal thing to do?
Author: Antoine Pitrou (pitrou) *
Date: 2012-11-01 19:59
And then user A is relying on user B executing IDLE via sudo? Is that a normal thing to do?
Well, I suppose that could be any Tk app, not just IDLE. And I also suppose you could use IDLE to edit some file that is only root-writable.
Author: Mark Dickinson (mark.dickinson) *
Date: 2012-11-01 20:01
So if this is a security issue, should Python 2.6 also be fixed?
Author: Antoine Pitrou (pitrou) *
Date: 2012-11-01 20:02
So if this is a security issue, should Python 2.6 also be fixed?
Probably, if it's deemed important enough by our security RMs.
Author: Stefan Krah (skrah) *
Date: 2012-11-01 20:18
Isn't IDLE supposed to be a Python shell? As I understand this issue, you'd have the same "exploit" by adding this to your .bashrc:
echo "EXPLOIT" > /root/exploit
Then, as a normal user, run:
sudo bash
It would be nice to get rid of the exec, but why is this an exploit?
Author: Antoine Pitrou (pitrou) *
Date: 2012-11-01 20:26
As I understand it, this is not specifically about IDLE. Any Tk app would be vulnerable.
Author: Guilherme Polo (gpolo) *
Date: 2012-11-01 20:49
It is not IDLE specific. But I still fail to see how this actually is a security bug. It doesn't give more power to the user than the user already gave to it. If you are recklessly installing untrusted libraries or anything for the matter, then you already have a lot of other problems.
Anyways, I would still go with my earlier option because I never used this piece of code.
2012/11/1 Antoine Pitrou <report@bugs.python.org>
Antoine Pitrou added the comment:
As I understand it, this is not specifically about IDLE. Any Tk app would be vulnerable.
Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16248>
Author: Stefan Krah (skrah) *
Date: 2012-11-01 21:37
I also don't find the scenario where an attacker has write privileges to a user's home directory so disturbing -- there are juicier targets (like .bashrc).
This constructed example using /tmp is a little more troubling:
$ cd /tmp $ echo 'print("exploit")' > .Tk.py $ export XAUTHORITY=$HOME/.Xauthority $ unset HOME $ python3.3
import tkinter w = tkinter.Tk() /usr/local/lib/python3.3/tkinter/init.py:1817: ResourceWarning: unclosed file <_io.TextIOWrapper name='./.Tk.py' mode='r' encoding='ANSI_X3.4-1968'> exec(open(class_py).read(), dir) exploit
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2012-11-02 04:41
On 2 November 2012 01:48, Stefan Krah <report@bugs.python.org> wrote:
Stefan Krah added the comment:
Isn't IDLE supposed to be a Python shell? As I understand this issue, you'd have the same "exploit" by adding this to your .bashrc:
echo "EXPLOIT" > /root/exploit
Then, as a normal user, run:
sudo bash
It would be nice to get rid of the exec, but why is this an exploit?
nosy: +skrah
Python tracker <report@bugs.python.org> <http://bugs.python.org/issue16248>
Almost nobody knows that when using tkinter, code in .Tk.py is executed. (readprofile is not even documented!) While in your example, it is quite easy to see that it will run .bashrc
Author: Stefan Krah (skrah) *
Date: 2012-11-02 12:50
Ramchandra Apte <report@bugs.python.org> wrote:
Almost nobody knows that when using tkinter, code in .Tk.py is executed. (readprofile is not even documented!) While in your example, it is quite easy to see that it will run .bashrc
The point of the example is that it's "game over" anyway once an attacker has write privileges to a user's home directory.
"sudo bash" is certainly a more common operation than "sudo tkapp.py", and users are not in the habit of auditing .bashrc each time they launch a shell.
In fact, I'd probably be more likely to notice a new file ".Tk.py" than a small modification to my .bashrc.
That said, I absolutely agree that ideally tkinter apps should not execute code from a startup file, especially if the startup file is not in the user's home directory.
Author: Antoine Pitrou (pitrou) *
Date: 2012-11-02 18:29
I'm gonna point people to the discussion about the "-s" flag of the Python interpreter (added as part of PEP 370), since the issue is conceptually identical: http://mail.python.org/pipermail/python-dev/2008-January/076130.html
Adding Christian to the discussion since he was the author and implementor of that PEP.
Author: Christian Heimes (christian.heimes) *
Date: 2012-11-02 18:37
It's gonna take a while to read this ticket ...
Some comments: The code in site.py already does some checks, for example getuid() == geteuid(). System code and code that is run with administrator privileges shall be run with -Es to prevent code injection. See https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/938869 comment #24 for an issue.
Author: Christian Heimes (christian.heimes) *
Date: 2012-11-04 15:16
I'm all with Antoine's suggestion. readprofile() should not be executed when sys.flags.ignore_environment is set.
Author: Zachary Ware (zach.ware) *
Date: 2012-11-09 21:48
Here are a pair of trivial patches that implement Antoine's suggestion of not executing readprofile() if the -E flag is set. Current tests seem to pass, but there are no new tests included because frankly I'm not sure of either how to test it or where. Also, I can't seem to find any tests of the -E flag at all; does this change need a test? No doc change either since the function isn't documented.
The patches apply equally well on 2.6 or 2.7, or 3.1 or 3.2, depending on whether this is determined to be security issue enough to mess with 2.6 and 3.1.
Thanks,
Zach
Author: Roundup Robot (python-dev) 
Date: 2012-12-09 13:48
New changeset d8300842a0e9 by Antoine Pitrou in branch '3.2': Issue #16248: Disable code execution from the user's home directory by tkinter when the -E flag is passed to Python. http://hg.python.org/cpython/rev/d8300842a0e9
New changeset 10d04bdb05ab by Antoine Pitrou in branch '3.3': Issue #16248: Disable code execution from the user's home directory by tkinter when the -E flag is passed to Python. http://hg.python.org/cpython/rev/10d04bdb05ab
New changeset a4fc52da295b by Antoine Pitrou in branch 'default': Issue #16248: Disable code execution from the user's home directory by tkinter when the -E flag is passed to Python. http://hg.python.org/cpython/rev/a4fc52da295b
Author: Roundup Robot (python-dev)
Date: 2012-12-09 13:51
New changeset 822b472eff13 by Antoine Pitrou in branch '2.7': Issue #16248: Disable code execution from the user's home directory by tkinter when the -E flag is passed to Python. http://hg.python.org/cpython/rev/822b472eff13
Author: Antoine Pitrou (pitrou) *
Date: 2012-12-09 14:03
Fixed. I will let Benjamin and Barry decide whether this deserves backporting to security branches. Benjamin, Barry, please do your job :)
Author: Roundup Robot (python-dev)
Date: 2012-12-09 15:17
New changeset 03b3124e9ea3 by Antoine Pitrou in branch '3.1': Issue #16248: Disable code execution from the user's home directory by tkinter when the -E flag is passed to Python. http://hg.python.org/cpython/rev/03b3124e9ea3
Author: Ramchandra Apte (Ramchandra Apte) *
Date: 2013-02-20 14:23
I suppose this should be closed.
Author: Christian Heimes (christian.heimes) *
Date: 2013-02-20 14:40
The bug hasn't been closed deliberately. We need to announce the security fix and possibly acquire a CVE, too.
Author: Zachary Ware (zach.ware) *
Date: 2013-02-20 15:54
I believe we're also waiting on input from Barry about whether to apply the patch to 2.6.
Author: Barry A. Warsaw (barry) *
Date: 2013-02-20 15:57
Does the 2.x patch apply cleanly to 2.6? If so, then I think it should be applied (though I'd like to review it first). 2.6 is still under security maintenance until October 2013. I'm thinking we'll probably do one last security release around that time.
Author: Zachary Ware (zach.ware) *
Date: 2013-02-20 16:02
Does the 2.x patch apply cleanly to 2.6?
It should, if I remember correctly, though I haven't checked since uploading it. I believe there were actually very few or no changes to the file the patch is for between 2.6 and 2.7.
Author: Barry A. Warsaw (barry) *
Date: 2013-02-20 16:11
Release blocking for 2.6.9 (oh how I wish we could release block for specific Python versions).
Author: Antoine Pitrou (pitrou) *
Date: 2013-02-20 17:42
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6?
Perhaps it's your job as a release manager to check that ;-P
Author: Barry A. Warsaw (barry) *
Date: 2013-02-20 23:09
I'm working on applying the 2.x patch to 2.6, but one thing interesting of note: sudo, at least on Debian and derivatives going back at least to Squeeze, generally reset the environment by default (i.e. env_reset). So you'd have to either have disabled env_reset in sudoers or use sudo -E the exploit.py.
Author: Antoine Pitrou (pitrou) *
Date: 2013-02-20 23:17
I'm working on applying the 2.x patch to 2.6, but one thing interesting of note: sudo, at least on Debian and derivatives going back at least to Squeeze, generally reset the environment by default (i.e. env_reset). So you'd have to either have disabled env_reset in sudoers or use
sudo -Ethe exploit.py.
Or you just have to use something else than Debian.
Author: Roundup Robot (python-dev)
Date: 2013-02-20 23:26
New changeset 936621d33c38 by Barry Warsaw in branch '2.6':
- Issue #16248: Disable code execution from the user's home directory by http://hg.python.org/cpython/rev/936621d33c38
Author: Barry A. Warsaw (barry) *
Date: 2013-02-20 23:29
I think this has now been applied to all of 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4. So, closing.
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *
Date: 2013-08-01 17:31
The fix in 2.6, 2.7, 3.1 and 3.2 branches introduced UnboundLocalError occurring when a non-None baseName parameter is passed. At least a part of fa82071bb7e1 should be backported to 2.6, 2.7, 3.1 and 3.2 branches.
$ python2.7 -c 'import Tkinter; print(repr(Tkinter.Tk(baseName="some_name")))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1748, in init if not sys.flags.ignore_environment: UnboundLocalError: local variable 'sys' referenced before assignment $ python3.2 -c 'import tkinter; print(repr(tkinter.Tk(baseName="some_name")))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.2/tkinter/init.py", line 1734, in init if not sys.flags.ignore_environment: UnboundLocalError: local variable 'sys' referenced before assignment
Author: Larry Hastings (larry) *
Date: 2013-08-01 18:03
You're talking about a new bug. Please open a new issue.
I'm closing this issue right now because I want to cut a Python 3.4 alpha release tomorrow, and this bug is marked Python 3.4 and "release blocker".
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *
Date: 2013-08-01 18:08
UnboundLocalError is effect of partially incorrect fix for this bug. It is better to update Versions field.
Author: Roundup Robot (python-dev)
Date: 2013-08-01 20:25
New changeset 0f17aed78168 by Antoine Pitrou in branch '2.7': Fix tkinter regression introduced by the security fix in #16248. http://hg.python.org/cpython/rev/0f17aed78168
Author: Antoine Pitrou (pitrou) *
Date: 2013-08-01 20:27
I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how to test it). I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2. As for 3.1, it's pretty much dead.
Author: Zachary Ware (zach.ware) *
Date: 2013-08-08 02:46
Antoine Pitrou wrote:
I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how to test it). I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2. As for 3.1, it's pretty much dead.
That fix does work, but it should probably get a NEWS entry since it fixes a regression from 2.7.3 to 2.7.5.
Also, I think the same fix should be backported to all three of 2.6, 3.1, and 3.2. The same regression as in 2.7.5 exists in 3.2.5, and would be introduced by the next (last?) releases of 2.6 and 3.1.
Sorry to have broken every possible version of Python :S
Author: Roundup Robot (python-dev)
Date: 2013-08-13 18:24
New changeset 00bcf202cc3f by Antoine Pitrou in branch '2.7': Add NEWS entry for 0f17aed78168 (issue #16248) http://hg.python.org/cpython/rev/00bcf202cc3f
Author: Antoine Pitrou (pitrou) *
Date: 2013-08-13 18:24
That fix does work, but it should probably get a NEWS entry since it fixes a regression from 2.7.3 to 2.7.5.
Done, thank you?
Also, I think the same fix should be backported to all three of 2.6, 3.1, and 3.2.
Benjamin and Barry will have to decide what to do for 2.6 and 3.2.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2013-08-19 04:33
3.2 is owned by Georg.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2013-08-19 04:34
As for 3.1, feel free to apply. There will likely be a source release of it at some point.
Author: Roundup Robot (python-dev)
Date: 2013-08-21 00:55
New changeset 84f40562669f by Barry Warsaw in branch '2.6': Fix UnboundLocalError regression due to previous incorrect fix for http://hg.python.org/cpython/rev/84f40562669f
Author: Barry A. Warsaw (barry) *
Date: 2013-08-21 00:57
Applied the fix to 2.6 and null merged into 2.7. This didn't need a NEWS entry because the regression hadn't been released yet. I'll remove 2.6 from the Versions now.
Author: Georg Brandl (georg.brandl) *
Date: 2013-09-14 07:11
Should be fixed now in 3.2 too.
Author: Roundup Robot (python-dev)
Date: 2013-09-14 07:12
New changeset c18c18774e24 by Georg Brandl in branch '3.2': Fix tkinter regression introduced by the security fix in #16248. http://hg.python.org/cpython/rev/c18c18774e24
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *
Date: 2013-09-14 09:14
Fix still needs to be applied on 3.1 branch.
Author: Roundup Robot (python-dev)
Date: 2013-09-15 19:58
New changeset c39f42f46a05 by Georg Brandl in branch '3.1': Fix tkinter regression introduced by the security fix in #16248. http://hg.python.org/cpython/rev/c39f42f46a05
Author: Antoine Pitrou (pitrou) *
Date: 2013-09-15 19:59
Fix backported to 3.1, closing.
History
Date
User
Action
Args
2022-04-11 14:57:37
admin
set
github: 60452
2013-09-15 19:59:57
pitrou
set
status: open -> closed
resolution: fixed
messages: +
2013-09-15 19:58:58
python-dev
set
messages: +
2013-09-14 09:14:32
Arfrever
set
priority: deferred blocker -> release blocker
status: closed -> open
messages: +
versions: + Python 3.1, - Python 3.2
2013-09-14 07:12:15
python-dev
set
messages: +
2013-09-14 07:11:01
georg.brandl
set
status: open -> closed
messages: +
2013-09-13 12:30:46
Arfrever
link
2013-08-22 15:34:25
serhiy.storchaka
link
2013-08-21 00:57:20
barry
set
versions: - Python 2.6
2013-08-21 00:57:03
barry
set
messages: +
2013-08-21 00:55:30
python-dev
set
messages: +
2013-08-19 04:34:17
benjamin.peterson
set
messages: +
2013-08-19 04:33:08
benjamin.peterson
set
messages: +
2013-08-13 18:24:57
pitrou
set
messages: +
2013-08-13 18:24:06
python-dev
set
messages: +
2013-08-08 02:46:24
zach.ware
set
messages: +
2013-08-01 20:27:07
pitrou
set
priority: release blocker -> deferred blocker
stage: resolved
messages: +
versions: - Python 3.1, Python 2.7
2013-08-01 20:25:42
python-dev
set
messages: +
2013-08-01 18:08:18
Arfrever
set
status: closed -> open
resolution: fixed -> (no value)
messages: +
versions: + Python 3.1, - Python 3.3, Python 3.4
2013-08-01 18:03:55
larry
set
status: open -> closed
resolution: fixed
messages: +
2013-08-01 17:31:28
Arfrever
set
status: closed -> open
resolution: fixed -> (no value)
messages: +
stage: resolved -> (no value)
2013-02-20 23:29:48
barry
set
messages: +
2013-02-20 23:29:04
pitrou
set
status: open -> closed
2013-02-20 23:26:03
python-dev
set
messages: +
2013-02-20 23:17:28
pitrou
set
messages: +
2013-02-20 23:09:26
barry
set
messages: +
2013-02-20 17:42:31
pitrou
set
messages: +
2013-02-20 16:11:29
barry
set
versions: + Python 2.6
2013-02-20 16:11:11
barry
set
priority: normal -> release blocker
nosy: + georg.brandl, larry
messages: +
2013-02-20 16:02:57
zach.ware
set
messages: +
2013-02-20 15:57:35
barry
set
messages: +
2013-02-20 15:54:23
zach.ware
set
messages: +
2013-02-20 14:40:01
christian.heimes
set
status: closed -> open
messages: +
2013-02-20 14:23:08
Ramchandra Apte
set
status: open -> closed
messages: +
2012-12-09 15:17:50
python-dev
set
status: pending -> open
messages: +
2012-12-09 14:03:48
pitrou
set
status: open -> pending
nosy: + barry, benjamin.peterson
messages: +
resolution: fixed
stage: resolved
2012-12-09 13:51:25
python-dev
set
messages: +
2012-12-09 13:48:57
python-dev
set
nosy: + python-dev
messages: +
2012-11-09 21:48:32
zach.ware
set
files: + issue16248-3.x.patch
2012-11-09 21:48:17
zach.ware
set
files: + issue16248-2.x.patch
keywords: + patch
messages: +
2012-11-04 15:16:49
christian.heimes
set
messages: +
2012-11-02 18:37:26
christian.heimes
set
messages: +
2012-11-02 18:29:20
pitrou
set
nosy: + christian.heimes
messages: +
2012-11-02 12:50:55
skrah
set
messages: +
2012-11-02 04:41:32
Ramchandra Apte
set
messages: +
2012-11-01 21:37:45
skrah
set
messages: +
2012-11-01 20:49:42
gpolo
set
messages: +
2012-11-01 20:26:37
pitrou
set
messages: +
2012-11-01 20🔞00
skrah
set
nosy: + skrah
messages: +
2012-11-01 20:02:24
pitrou
set
messages: +
2012-11-01 20:01:14
mark.dickinson
set
messages: +
2012-11-01 19:59:57
pitrou
set
messages: +
2012-11-01 19:58:23
mark.dickinson
set
messages: +
2012-11-01 19:55:34
pitrou
set
nosy: + pitrou
messages: +
versions: + Python 2.7, Python 3.2, Python 3.3, Python 3.4
2012-11-01 19:32:41
zach.ware
set
nosy: + zach.ware
messages: +
2012-11-01 16:29:57
mark.dickinson
set
messages: +
2012-11-01 14:09:21
Ramchandra Apte
set
files: + exploit.py
messages: +
2012-11-01 11:36:19
asvetlov
set
nosy: + asvetlov
2012-11-01 10:22:41
mark.dickinson
set
nosy: + mark.dickinson
messages: +
2012-10-31 16:30:14
Ramchandra Apte
set
messages: +
2012-10-31 16:19:43
gpolo
set
messages: +
2012-10-31 15:56:30
Ramchandra Apte
set
messages: +
2012-10-31 15:55:37
Ramchandra Apte
set
messages: +
2012-10-19 18:51:22
terry.reedy
set
nosy: + terry.reedy, - Want to Delete This Account
2012-10-18 15:24:27
gpolo
set
messages: +
2012-10-18 05:02:58
Ramchandra Apte
set
messages: +
2012-10-18 04:55:11
Want to Delete This Account
set
nosy: + Want to Delete This Account
messages: +
2012-10-17 18:16:05
gpolo
set
messages: +
2012-10-17 17:07:42
Arfrever
set
2012-10-17 07:43:19
Ramchandra Apte
set
title: Security bug in tkinter allows for untrusted code execution. -> Security bug in tkinter allows for untrusted, arbitrary code execution.
2012-10-17 02:24:05
Ramchandra Apte
set
messages: +
2012-10-16 15:34:06
Ramchandra Apte
set
messages: +
2012-10-16 15:32:48
Ramchandra Apte
set
messages: +
2012-10-16 15:31:35
Ramchandra Apte
set
messages: +
2012-10-16 15:29:27
Ramchandra Apte
set
type: security
2012-10-16 15:29:21
Ramchandra Apte
create