Because attaching a debugger to the Linux Kernel is so convenient and easy :P
But yeah, I was just being lazy and dumb. I solved it within ten minutes of someone saying "why don't you just go through the binfmt_elf code?" A debugger would've probably been more tedious than reading the relevant code directly, but would've been just as effective.
It's not and actually I do find it kind of amusing that Linux is possibly the hardest of the three main OSes to get a debugging set up for, but yeah I've had to do it enough that I don't mind doing and I can probably get it set up in a few minutes. Plus if the bug isn't in some architecture specific or hardware dependent thing there's this Linux compatibility userspace layer I help out on sometimes that is much easier to work with. And if it's that easy, I will generally choose to that instead of having to actually think about what I am doing ;)
Almost like those existing env vars made it clear that they were mistakes that make behavior inconsistent (especially libcurl) and they want to avoid repeating it with additional env vars. Having almost contributed to Curl before, they repeatedly note for contributors that just because old code does something questionable doesn't mean your new code is allowed to do it—if anything, you're just highlighting the questionable piece of old code as being important for them to rewrite soon (of course they can't remove the current env vars for compatibility reasons).
And the article specifically notes that the current solution doesn't work, but it requires discussion on what the best solution is instead of just taking the literal first solution suggested by someone.
I recommend reading the Telecommunications Act of 1996, which required all incumbent telephone companies to allow any other company to install equipment in their central offices and buy rights to already laid phone lines at a fixed rate, where all the expense of actually building and laying everything laid entirely with the owner of the central office.
Turns out that (fairly applied) antitrust doesn't care how much it money it costs an incumbent company to begin allowing competitors
This is a goofy argument. Telephone lines are a natural monopoly, cell phones are not. I have no interest in a poorly secured grab bag of bullshit blue-tooth add-ons, and there's no government interest in enabling that.
It's FOSS and is actually included with GCC, but the toolchain is still a PITA to install just because no one (other than Debian and Arch Linux) bothers packaging it. I think Alire is supposed to make it easy to install but I haven't used it much: https://alire.ada.dev/
SPARK 2014 itself is the same too AFAIK, the problem is there's a lot of auxiliary static analysis tools and plugins that are gated behind AdaCore's sales wall (and of course they'd never deign to sell licenses affordable to individuals)
The situation was pretty bad a few years ago, and the licensing was confusing but it's pretty straightforward now with Alire. (AdaCore also got rid of their "Community Edition which had the weird license restrictions).
I'm doing a presentation at FOSDEM next year called "Get started with Ada in 2 minutes or less!"[1]; because (on MacOS and Linux) I can go from not having no toolchain a all to compiling hello world in under 2 minutes (I've timed it).
Your step 1 violated my very hard rule against piping curl into a shell.
…and is ironic advice for a safety-critical system, no?
——-
(Yes, I’ve read arp242.net/curl-to-sh.html - but my point being that as I’d be new to Ada then I don’t know who to trust; I’ve never heard of getada.dev therefore I don’t trust it)
It's an understandable rule, and you can definitely just download the binary from alire.ada.dev and add it to $PATH but with such a harsh stigma around how difficult it is to get the toolchain set up, GetAda follows the precedent of Rust, where you can grab the toolchain via "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" (thanks to Rustup).
Is it really so bad to run it twice, with cat/bat replaced with sh on the second pass? If you're really paranoid about it you could save the first run to a file, so you know for certain that the server didn't do a switcheroo for the second one, but if you think about it, that's a low-payout move for Bad Guy #N compared to just sending the pwnage the first time around.
This is beside the fact that we're talking about downloading and running a user-owned binary, which, unlike the shell script, is impractical to inspect in any detail, and has the same privileges as the shell script we're supposed to worry about.
I view "don't curl to shell" as about 90% theatrics basically. Sure, read it first, I do in fact do that. But it's a silly 'very hard rule'.
I routinely save to a file before execution, but it's not really about being attacked. It's about the fact that those scripts, in order to be "fire and forget", make many assumptions, often very large ones, about where I want things or under what user, etc.
Many of them are actually quite well-written under the hood and can be easily moved to other directories, have comments about what it is doing, etc.
Not really much other than tangential mentions. I did write an addendum to the OP going over the secondary stack as well as where you still use normal dynamic allocation in Ada: https://nytpu.com/gemlog/2024-12-27-2
Except they were originally "Apple Computers" until they slowly gained enough recognition to rebrand to "Apple," plus that was in 1984, there wasn't an oversatuated market of other computer brands also called "Apple," unlike "Element" which has tons of existing tech-related and non–tech-related overlap and is generic on top of it.
But yeah, I was just being lazy and dumb. I solved it within ten minutes of someone saying "why don't you just go through the binfmt_elf code?" A debugger would've probably been more tedious than reading the relevant code directly, but would've been just as effective.