[issue23748] platform._uname_cache is writeable

2015-03-23 Thread STINNER Victor
STINNER Victor added the comment: > Hmmm... dear sir - what prevents you from adding an __all__ to the module > with these cache variables excluded ? You didn't understand the general philosophy, we are not hidding internals. For the specific case of platform._uname_cache, it uses the "_" pre

[issue23748] platform._uname_cache is writeable

2015-03-23 Thread Anand B Pillai
Anand B Pillai added the comment: Closing is an easy fix, bet on my word this would appear as a different bug, thanks for your quickie fix! -- ___ Python tracker ___ ___

[issue23748] platform._uname_cache is writeable

2015-03-23 Thread Anand B Pillai
Anand B Pillai added the comment: Hmmm... dear sir - what prevents you from adding an __all__ to the module with these cache variables excluded ? -- ___ Python tracker ___

[issue23748] platform._uname_cache is writeable

2015-03-23 Thread STINNER Victor
STINNER Victor added the comment: we are all consenting adults here. Why do you modify a private attribute? > I am changing the type to security as I dont think this is a behaviour issue. I don't understand why do you consider that it is a security vulnerability? >>> import hack_uname # Someon

[issue23748] platform._uname_cache is writeable

2015-03-23 Thread Anand B Pillai
Anand B Pillai added the comment: I am changing the type to security as I dont think this is a behaviour issue. -- type: behavior -> security ___ Python tracker ___ _

[issue23748] platform._uname_cache is writeable

2015-03-23 Thread Anand B Pillai
New submission from Anand B Pillai: >> import platform >>> print 'Actual =>',platform.uname() Actual => ('Linux', 'toshiba-laptop', '3.13.0-24-generic', '#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014', 'x86_64', 'x86_64') >>> import hack_uname # Someone imports my module unaware of the hack (see at