Link: Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms
Adrian Colyer's Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms (via) is a very readable and very interesting summary of an ultimately depressing academic paper on the security vulnerabilities that get induced in C code simply by migrating from 32-bit platforms to 64-bit platforms.
In theory I sort of knew about all of this, but it's one thing to vaguely have heard about it and another thing to see handy comparison charts and examples and so on of how relatively innocent C code introduces real vulnerabilities simply when you rebuild it on 64-bit machines and then expose it to attackers.
Here's a depressing quote from the academic paper to finish up with and motivate reading at least Colyer's summary of the whole thing:
Finally, we make use of this systematization and the experience thus gained to uncover 6 previously unknown vulnerabilities in popular software projects, such as the Linux kernel, Chromium, the Boost C++ Libraries and the compression libraries libarchive and zlib—all of which have emerged from the migration from 32-bit to 64-bit platforms.
That's, well, unfortunate. But not unexpected, I suppose. Maybe all future languages should not have any limited-range numeric types that can have different sizes on different platforms, even if it's theoretically an attractive idea for 'optimization'.
(I don't know what Rust does here, but Go does have
which are either 32 or 64 bits depending on the platform.)
The somewhat odd subject of Django versus Python
I was recently talking on Twitter with someone who was considering doing their website in Django as a learning project, because they really like Python. I had some tangled reactions to this and today I want to write them down in a better format than Twitter.
Simplified, I feel that basic use of Django is fairly detached from any particularly deep immersion into Python as a programming language in its own right. You certainly will write some Python as part of creating a basic Django web app, but you'll also write a bunch of Django specific things (including Django templates and other things that are not really connected to Python code). And some of Django's magic things cut directly against how Python normally works. The more basic the web app you have, the more easily it can probably be implemented using Django's standard basic features and thus the less Python you'll write.
Or in short, basic use of Django is more about Django than about Python. Only once you get beyond basic CRUD features and into complex application logic and so on do I think you're going to wind up immersed in Python itself, with Django simply acting as the scaffolding to connect it to the web.
It follows that the more you use Django features like the admin interface, the less Python immersion you're getting. If all goes well the admin interface can save you a lot of work writing update and modification forms and processing of them, but at least some of that would be actual Python code that the admin interface is 'saving' you from having to write.
I don't think this is specific to Django. Instead I expect it to be the same for any complex framework, because the purpose of a framework is to do the standard necessary work for you. This is a feature if you want a web app (especially with polished underlying code), but a drawback if you want to write Python. If your real desire is to write Python and wind up with a website, perhaps the right thing is a more minimal framework (although I don't know which one of them you want these days and all of my references are several years old by now).
PS: If you're doing anything really security sensitive, please do not roll your own code no matter how much you like writing Python. Use well-tested, well-audited, well-maintained framework code that gets a lot of exposure so that people will find (and fix) the remaining security bugs. It's really easy to have clever security ideas that aren't, or to miss some subtle issue.