← Back to context

Comment by eqvinox

9 days ago

Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?

3 comments

eqvinox

Reply
xg15  9 days ago

I don't know much about glibc's specifics, but in general: Security comes before a lot of things but not before accidental breakage. If you say "our compat guarantees are so strong you shouldn't keep track of versions at all", I expect this to mean that APIs and ABIs will never change, or at least not without a massive awareness campaign and transition plan being announced before - because such a breakage would take out my project or might even introduce new vulnerabilities.

A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.

  • eqvinox  9 days ago

    > Security comes before a lot of things but not before accidental breakage.

    It didn't really sound accidental, though the bugzilla report sounds like they underestimated the impact. But I'm quite sure they were aware this would break at least some old software, it's not like it's hard to understand what exactly is happening here. Old software (or rather, builds) used executable stacks by default, and some edge cases used them for some time after that. I'll say they probably should've done a warning period.

    > If you say "our compat guarantees are so strong you shouldn't keep track of versions at all",

    What I said was you should never pin a glibc version, not to not keep track of versions at all :). I will admit this is hazy if you build binaries to distribute; in that case you probably want to intentionally use an old glibc. But that's not exactly a "pin", that's a "what's the oldest you want to support". The software being built basically makes no difference; glibc will do what it does, the only limit will be placed by features added in newer glibc versions. The binaries produced from that, running on a new system with any newer glibc, have AFAIK last broken during that S390 incident I linked. (e.g. you wouldn't have gotten executables requiring executable stacks out of a normal GNU tool chain for quite some time by now. It's still possible to intentionally mangle your code and build options to get that result, but you need to either be trying, or do relatively cursed things [like Mono probably some binary loading shenanigans]).

    Either way — never pin glibc. And if your cmake or whatever complains about a glibc version conflict, remove the pins and use the newest version involved.

    (And about the execstack thing — I'm happy to hear your complaints if and only if you show up with an actual report of breakage that you encountered. No 3rd party phoning. Because what's at question in this case is the actual impact size, which to me seems quite limited.)

    > A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.

    That's not how DSO versioning works. Unless it was a horrible disaster, the old functions would remain available, but you'd be required to jump through hoops to build new software against it.

    Because glibc ships basically their entire version history in the library binary. That's the thing with DSO versioning.

    I do wonder if they could've done some versioning trick with the execstack thing, the problem there is that it's more about global system behavior than actual exposed ABIs. (By the way, libc isn't even what you would be "pinning" there, it's libdl. Splitting hairs though, as that's part of glibc.)