Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bite of Python

access.redhat.com

Post reply on HN
Print view View original

41–50 of 168 posts

Re: A bite of Python

#41

Post by masklinn »

viraptor wrote: post #38
masklinn wrote: post #36

Earlier quoted context omitted.

Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...

My bad, wrote rounding not accuracy. (corrected now) But my point was that it's not related to weak typing as the parent seems to suggest.

> But my point was that it's not related to weak typing as the parent seems to suggest.

And you're completely right there. Any language using floating-point numbers will have the same issue regardless of its typing discipline e.g. Rust: https://is.gd/4BNoWa

Re: A bite of Python

#42

Post by guyzmo »

masklinn wrote: post #39
marklgr wrote: post #31

Earlier quoted context omitted.

> The feature is just some syntactic sugar. I would not call it "syntactic sugar", but rather a leak of implementation details. It could be deliberate, like Perl did for its OO (showing the entrails of all its objects), but it's not particularly sugary-sweet-yummy.

It's not an implementation detail, it is a deliberate, specified and documented feature of the language dedicated to namespace conflict resolutions in the context of inheritance. ref: https://docs.python.org/2/reference/expressions.html#atom-id... ref: https://docs.python.org/2/faq/programming.html#i-try-to-use-...

Yes! Exactly! I added the py3 links of those in my big lengthy parent comment, so people get twice the chance to RTFM !

Re: A bite of Python

#43

Post by catnaroek »

JonnieCache wrote: post #34
catnaroek wrote: post #24

Earlier quoted context omitted.

> An asserts checks DESIRED constraints. Then imagined it is. Your desires are totally a part of your imagination, unless you make them become real. > Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do. Point taken. Unfortunately, logging errors or aborting the program won't make a…

If you have the process quit it definitely stops them from being false though. I thought that was the point of assert()?

> If you have the process quit it definitely stops them from being false though.

The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.

Re: A bite of Python

#44

Post by guyzmo »

SEJeff wrote: post #25
blowski wrote: post #9

Earlier quoted context omitted.

Relying on developers to read and remember every bit of documentation for every bit of code is more likely to end up with insecure code compared to introducing sane defaults with an explicit, expressive API.

And the TL;DNR being: developers can't be expected to do a good job. Some of them in fact will do a terrible job. This can be said for every industry involving people.

The sad truth is: s/Some/Most/

Re: A bite of Python

#45

Post by tehwalrus »

viraptor wrote: post #33
tehwalrus wrote: post #32

Having written code in Python for a few years, I've come across most of these (some of the ways to hack builtins/modify the code on a function reference were new to me). However, it had also never occurred to me to make anything I cared about the security of in python. Perhaps this article is aimed at people who are writing system utilities for linux distributions, and are considering Python? Presumably some such uti…

> A valid conclusion for some types of software, given the list of "bugs" in the post, would be don't write it in Python. Do you have some specific types in mind? I know some types of protection are not reachable from python directly and require native modules, but I'm not sure what would cause you to drop Python altogether. I'd be interested to hear some examples.

Well, for example, you might want to write a package manager for a Linux distribution[1]. An attacker could change the behaviour of someone's package manager by some non-privileged means (messing with the user's python path and placing an evil self-hiding module that changes the behaviour of the engine e.g. by always listing a malicious package as a dependency of whatever you're currently installing).

The problematic code here is Python's `import` mechanism and mutable global references to standard library functions. You can cut out the "buggy" code by writing in another language.

[1] https://wiki.gentoo.org/wiki/Python

Re: A bite of Python

#46

Post by mrswag »

viraptor wrote: post #29
mrswag wrote: post #7

Some points are valid, but come on, if an attacker has write access to your code, you can't recover from that, ever.

> but come on, if an attacker has write access to your code Why is this relevant for this article? The article doesn't say anything about attackers having write access to the source.

It's in their threat model under 'Module injection':

> The mitigation is to maintain secure access permissions on all directories and package files in search path to ensure unprivileged users do not have write access to them.

Re: A bite of Python

#47

Post by riskable »

viraptor wrote: post #29
mrswag wrote: post #7

Some points are valid, but come on, if an attacker has write access to your code, you can't recover from that, ever.

> but come on, if an attacker has write access to your code Why is this relevant for this article? The article doesn't say anything about attackers having write access to the source.

Yes it does... One of the examples is monkey patching using bytecode. How are you going to do that without write access to the filesystem running your code?

The same is true for module imports... If you have write access to the same directory as the code itself there's all sorts of havoc one can cause beyond merely substituting your own os.py.

Re: A bite of Python

#48

Post by dschiptsov »

"Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100.

Assert is a statement, not an expression, so do not use it as an expression.

One should never compare floats. This is taught in any freshman CS course. The limitation is due to the standard encoding of floats - IEEE 754 - not Python's fault.

Everything else are features of a truly dynamic language, designed for a really quick prototyping. Python3.x got rid of many inconsistencies and caveats of 2.x

Shall we re-read the classic now?

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Re: A bite of Python

#49

Post by blowski »

coldtea wrote: post #18
blowski wrote: post #11

Earlier quoted context omitted.

It's not an anomaly, but it can be a surprise for people who don't understand what it does. For example, they use asserts for validation and then the validation doesn't work in production. It's absolutely right the way it works, but it's still a gotcha for the audience this blog post is aimed at.

> It's not an anomaly, but it can be a surprise for people who don't understand what it does. That's almost a tautology though.

The point is that they think they understand it, because most of Python behaves the same in development and production. You see this function called 'assert', it gives the right error at the right time, and all is good. Then you push it to production and it stops throwing errors. Eventually, you read the manual and it tells you that this specific function is ignored in production. This is a surprise because, say, print doesn't behave like that.

Re: A bite of Python

#50

Post by viraptor »

tehwalrus wrote: post #45
viraptor wrote: post #33

Earlier quoted context omitted.

> A valid conclusion for some types of software, given the list of "bugs" in the post, would be don't write it in Python. Do you have some specific types in mind? I know some types of protection are not reachable from python directly and require native modules, but I'm not sure what would cause you to drop Python altogether. I'd be interested to hear some examples.

Well, for example, you might want to write a package manager for a Linux distribution[1]. An attacker could change the behaviour of someone's package manager by some non-privileged means (messing with the user's python path and placing an evil self-hiding module that changes the behaviour of the engine e.g. by always listing a malicious package as a dependency of whatever you're currently installing). The problematic…

That's possible, but I don't think it's relevant. If you have access to the user's profile, it doesn't really matter what language the package manager uses. You still have rights to create aliases, create local wrapper scripts, use LD_PRELOAD, set LD_LIBRARY_PATH, and many other ways to execute your own code. You can stop the user accessing the original package manager in the first place.

dnf for example is widely used (Fedora's default package manager) and it's written in Python: https://github.com/rpm-software-management/dnf

Post reply on HN