A bite of Python
access.redhat.com
A bite of Python
1–10 of 168 posts
Re: A bite of Python
#2I wouldn't call it 'traps'. I would call it 'read and understand documentation before writing code' like: what is 'is' operator, or how floats behave in EVERY programming language, or why you should sanitize EVERY user input.
So, basically, I can write such a list for every language I know.
Re: A bite of Python
#3If you're interested in reviewing Python code for potential security issues, here's a related project: https://github.com/openstack/bandit (I'm one of the devs)
It will actually pick up a number of security issues listed in the post. It's useful in real world too - led to a number of CVEs being reported.
Re: A bite of Python
#4I wouldn't call it 'traps'. I would call it 'read and understand documentation before writing code' like: what is 'is' operator, or how floats behave in EVERY programming language, or why you should sanitize EVERY user input. So, basically, I can write such a list for every language I know.
which is great and you totally should. not everyone knows about those things.
Re: A bite of Python
#5If you're interested in reviewing Python code for potential security issues, here's a related project: https://github.com/openstack/bandit (I'm one of the devs) It will actually pick up a number of security issues listed in the post. It's useful in real world too - led to a number of CVEs being reported.
I looked at Bandit earlier this year, but had to put it down when I discovered it didn't have a way to fill in default config -- the instant I specified anything in the config file, I had to supply a complete config, including literally every single check it's capable of doing, because Bandit would discard all its defaults on encountering that single line of custom config.
Don't suppose you know if that's gotten better?
Re: A bite of Python
#6The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development.
"Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract checks are disabled to maximize performance." - https://en.wikipedia.org/wiki/Design_by_contract
Re: A bite of Python
#7Some points are valid, but come on, if an attacker has write access to your code, you can't recover from that, ever.
Re: A bite of Python
#8I wouldn't call it 'traps'. I would call it 'read and understand documentation before writing code' like: what is 'is' operator, or how floats behave in EVERY programming language, or why you should sanitize EVERY user input. So, basically, I can write such a list for every language I know.
I'd argue that a good programming language should rarely force you to go back to the docs. Anyway, for a list of weird language properties, check out this tag:
https://stackoverflow.com/questions/tagged/hidden-features?s...
Re: A bite of Python
#9I wouldn't call it 'traps'. I would call it 'read and understand documentation before writing code' like: what is 'is' operator, or how floats behave in EVERY programming language, or why you should sanitize EVERY user input. So, basically, I can write such a list for every language I know.
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.
Re: A bite of Python
#10If you're interested in reviewing Python code for potential security issues, here's a related project: https://github.com/openstack/bandit (I'm one of the devs) It will actually pick up a number of security issues listed in the post. It's useful in real world too - led to a number of CVEs being reported.
I looked at Bandit earlier this year, but had to put it down when I discovered it didn't have a way to fill in default config -- the instant I specified anything in the config file, I had to supply a complete config, including literally every single check it's capable of doing, because Bandit would discard all its defaults on encountering that single line of custom config. Don't suppose you know if that's gotten bett…
It's not ideal - the config file is still a complete list, but there are a few things you can do.
- `bandit-config-generator` will give you a file filled with the current/default configuration, so it's a simple way to start with the defaults and modify just what you need
- if you just need to enable/disable tests rather than reconfigure, you can do that in command line options
- if you want to get rid of specific warning, you can mark the line with "# nosec" in the source
Merging various configs is possible, but rather complex to implement considering we aim for the config to be a complete description that won't ever need to change between versions.
If none of the above workarounds solve your use case, feel free to report an issue. (https://bugs.launchpad.net/bandit) I can't guarantee how/whether we'll fix this, but we'd definitely like to know what the problem is and how you're trying to use Bandit.