Having worked at Google for a… while… my 100% uneducated guess is that this was a patched in behavior for internal Reasons. Like it made dependent software easier to deploy internally server-side or something. But then they just shipped it to customers as well (going further out on a limb and assuming good faith… by accident).
No one at $BIGTECH company does things for no reason. It was done for a reason. But if it’s not understandable outside, it was for an inside reason instead.
No one at $BIGTECH company does things for no reason.
No one at $BIGTECH does things for no reason, but often reasons like “I’ve worked 55 hours this week and id rather be in a hot tub than doing this” and “whoever wrote this thing I need to modify has been gone for ages and left no breadcrumbs” and “i havent internalized chesterton’s fence” conspire to create significant tracts of functionality that bear no causal relationship to the problem domain.
Tl;dr: big tech does lots of things that are unnecessary, and from anyone who matters’ point of view, there’s no difference.
It sounds like this isn’t a default source of trust, but an always-enabled additional source of trust. I don’t think requiring trusting hundreds of certificate authorities is reasonable. It sounds like this isn’t Apple adding 1 or 2 trusted CAs, it is them always trusting the full list. This seems pretty unnecessarily risky to me.
This exactly. That option is a request to override default trust settings, maybe because you’re in some internal environment where only certificates going back to a certain private CA root are OK to trust.
Surely Apple itself has these situations, where even if somehow someone managed to get a bad cert that would be accepted on the Web (via, say, spoofing or bad CA practices), their internal connections are intended to remain secure. I’m sure Apple has that kind of requirement in places; big tech companies understandably have some pretty wild things in their threat models.
MacOS really is a terrible Unix. So many command line tools are old or weird, so much so that there are multiple alternative packaging systems people use to work around the bad software Apple ships.
I would have made the same complaint about Solaris back when I was using it, except that this doesn’t make it a bad unix. Unix has suffered from weirdly divergent tools since the 1970s and the PWB / 7th Edition fork. Mac OS is a fine BSD, but it isn’t good with GNU. If you expect a good unix to have a GNU userland then I can expand an acronym for you :-) I agree the stale GNU utilities are annoying; it would be nice if Apple could soup up the FreeBSD utils enough that they could replace the GNU utils.
Hey, I was there in Solaris land too and lived out of a /usr/local/bin built from GNU tools. I’m not just talking about GNU vs BSD vs SysV choices though.
A lot of the MacOS stuff is just old or weird. Like in 2016 MacOS unzip still couldn’t handle files over 2GB big, despite mainline unzip having fixed that back in 2005. (Is that fixed now? I don’t have a Mac to check). less was compiled with some bizarre options too. This bug report we’re discussing here is a very bad choice they made about certificate behavior that breaks an important security feature in curl. Etc etc.
Every single Mac user I know installs Homebrew the very first thing. (The die-hards still use MacPorts). That’s a step I don’t have to do on my Windows machine running WSL Linux systems. Or on my Linux boxes.
Yeah, I’m actually rather of the opinion that ecosystem diversity is a UNIX strength and things like musl are a feature, not a bug.
I think the whiff here was that the behavior change isn’t documented.
I do agree it would be nice if Apple tracked more closely to latest versions, but seeing as there’s broadly accepted ways around that I don’t think it’s much of a problem.
Things like this is why I’m happy to have most of my environment built from nixpkgs on a Mac. Upstream everything from libraries to shell to tools. You can achieve a part of it through homebrew too. I’m glad we have systems to isolate the “MacOS binaries” side from the “user binaries”.
The bug is one thing, but Apple blaming LibreSSL for this is rich. I am surprisingly confident that OpenBSD, and thus LibreSSL, does not use the Keychain API.
I think there’s some crossed wires. If I understand correctly, gecko is suggesting that Apple (not Daniel) is shifting the blame to LibreSSL by bringing them up. You seem to be defending Daniel, who I think we all agree did nothing wrong.
I indeed quoted Daniel, but his wording was pretty much what Apple wrote as well. My reasoning extends to them; I don’t see them as blaming LibreSSL; I see them as confirming it’s their doing, with enough details that no one could argue curl was to blame. To me it roundly says: “Yes, this is due to our modifications to LibreSSL”
I hear you, but if e.g. Microsoft hypothetically were to say that some bug in curl was not a bug because it was due to the version of NetBSD sockets that Windows ships, I think most people would find that to be a disingenuous statement. Apple owns their changes to LibreSSL. This isn’t semantically different from saying that Safari not properly doing cert checks (hypothetically) isn’t a Safari bug because CryptoKit has the same behavior. I mean, okay, but you also own CryptoKit. Why bring up LibreSSL at all?
Back around 2007 or so, Apple shipped a version of Safari for Windows.
There was some sort of security issue on Windows at the time, something like DLLs on the desktop would be loaded preferentially.
Safari would download files to the desktop.
Therefore if you did a drive-by download of a DLL via Safari on Windows, you’d get a DLL on the desktop and then later any application launched from the desktop would load that DLL and you’d get arbitrary code execution.
(I think I’m remembering this right.)
Anyway, Microsoft insisted it was a “blended threat” with Safari because Safari would download files to the desktop by default…
That’s a rich thing for them to say. If placing a dll file on a desktop is considered an attack vector, I’d rather blame their whole threat model. LD_PRELOAD always felt more sane than just loading whatever would lie in the same directory. I’m glad Wine specifically does not support this behavior.
It’s only as if the problem is with the version of LibreSSL that Apple ships, which is different from the version of LibreSSL that the LibreSSL project ships
Don’t expect permissively licensed software distributed by a proprietary vendor to behave like the publicly available source code does. The whole point of curl’s license is that distributors have more rights than end users.
If you don’t like it you have other options - both in terms of software distributors and software licenses. Don’t blame Apple for complying with the spirit and letter of the curl and libreSSL licenses, and their commitments to their users.
Same applies to GPL Licensed software too, fwiw. In that case the modified source will at least hopefully be publicly available, but it’s often heavily modified and not upstreamed.
If GPLd software is distributed to an end user in binary form, the end user can request the source code used to build the binary. They don’t have that right for BSD licensed software.
I think it’s the “hopefully” in your reply that I reacted to. I wouldn’t get software from a vendor that doesn’t comply licenses. I mean I used to buy pirate games on CDROMs in southeast asia, but it was clear what to expect.
Your meaning was somewhat different though. When I say that you can request the source code used to build the binary, I don’t mean that ‘hopefully it will be publicly available’, I mean that I can request the source and the vendor will provide the exact source used to build the binary, otherwise they are in violation of the GPL. This is not the case with BSD.
You’re right, the complete version would be: “in that case, the modified source code will hopefully be publicly available; and if it’s not, you can request it and they’ll hopefully provide it; and if they don’t you can sue them and hopefully have a court order them to provide it”
in practical terms, Apple just wouldn’t ship curl if it were GPL, so people using curl on MacOS would be using the upstream version and would not be exposed to this security issue.
I’m left unclear on what’s going on. The Apple support person may not have understood the issue, or not communicated their findings well.
The main unanswered question I have is: is the curl Apple ships modified to produce this behavior, or is it a side effect of the changes in their LibreSSL lib?
I totally understand Apple modifying LibreSSL to use the system cert store in the Keychain as the default set of root certs, because otherwise IIRC it defaults back to reading a set of .cer files in some system directory as on Linux. Root certs are a platform feature whose implementation differs.
If Apple’s LibreSSL always uses those certs as fallbacks, regardless of a set of root certs passed to the API explicitly, that does seem like a bug, or misfeature.
Yeah, the reply reads like the Apple person didn’t actually understand the issue. Particularly this bit:
Because the server certificate can be validated successfully using the built-in system trust store
makes me think they thought it was about cert validation failures, not incorrect cert validation successes. (Not that that excuses Apple’s shitty response, which should come as no surprise).
I’m unclear on how you get from “I bought a device that bundles someone else’s priorities in past and future decisions about details” to, and I’m being facetiously literal, “I am the property of this device and its behavior”—is it that the unwanted behavior you can’t change puts demands on your time and attention? Where does the ownership arrow flip?
A Russian reversal is a style of pun where an ironic contrast between two environments is undercut and rewritten with new meaning by punning one of the noun-phrases or verbs. In this example, “owning” is used in two senses: first, “to have rightful possession of;” second, “to defeat or embarrass.” Channelling Yakov Smirnoff, who helped popularize the format:
In GNU/Linux systems, you own the software. In Apple systems, the software owns you!
I mean, I get the pun—and I suspect kevinc does too—but it seems like a huge semantic stretch from “Apple made a questionable decision in their bundled curl, so you might want to install your own curl” to “Apple’s preinstalled software owns you.” If someone wanted to make that argument they’d need a lot more than a hackneyed pun to do it, in my opinion.
I do get it, and it is a stretch, and the stretch is meant to be a bit absurd, right? That’s what I mean when I call my interpretation overly literal. But I also just want to understand more of the subculture that would make this gag, so I’d rather ask about where it comes from than assume.
Not exactly—I don’t expect an answer because this is the internet and you get only what people are willing to give. The point of my being facetious was to raise a real question while not being overly confrontational about it with a stranger, such that I might get an answer. But I think we’ve spun our wheels enough on this.
Sounds to me like a conflation of “won’t fix” and “not a bug.” OK, it behaves the way you want—but if your manpage made me expect one thing and the behavior does another thing, the bug is there in the contradiction.
Wow that is ridiculous. Really, Apple?
Having worked at Google for a… while… my 100% uneducated guess is that this was a patched in behavior for internal Reasons. Like it made dependent software easier to deploy internally server-side or something. But then they just shipped it to customers as well (going further out on a limb and assuming good faith… by accident).
No one at $BIGTECH company does things for no reason. It was done for a reason. But if it’s not understandable outside, it was for an inside reason instead.
No one at $BIGTECH does things for no reason, but often reasons like “I’ve worked 55 hours this week and id rather be in a hot tub than doing this” and “whoever wrote this thing I need to modify has been gone for ages and left no breadcrumbs” and “i havent internalized chesterton’s fence” conspire to create significant tracts of functionality that bear no causal relationship to the problem domain.
Tl;dr: big tech does lots of things that are unnecessary, and from anyone who matters’ point of view, there’s no difference.
It sounds like this isn’t a default source of trust, but an always-enabled additional source of trust. I don’t think requiring trusting hundreds of certificate authorities is reasonable. It sounds like this isn’t Apple adding 1 or 2 trusted CAs, it is them always trusting the full list. This seems pretty unnecessarily risky to me.
This exactly. That option is a request to override default trust settings, maybe because you’re in some internal environment where only certificates going back to a certain private CA root are OK to trust.
Surely Apple itself has these situations, where even if somehow someone managed to get a bad cert that would be accepted on the Web (via, say, spoofing or bad CA practices), their internal connections are intended to remain secure. I’m sure Apple has that kind of requirement in places; big tech companies understandably have some pretty wild things in their threat models.
MacOS really is a terrible Unix. So many command line tools are old or weird, so much so that there are multiple alternative packaging systems people use to work around the bad software Apple ships.
I would have made the same complaint about Solaris back when I was using it, except that this doesn’t make it a bad unix. Unix has suffered from weirdly divergent tools since the 1970s and the PWB / 7th Edition fork. Mac OS is a fine BSD, but it isn’t good with GNU. If you expect a good unix to have a GNU userland then I can expand an acronym for you :-) I agree the stale GNU utilities are annoying; it would be nice if Apple could soup up the FreeBSD utils enough that they could replace the GNU utils.
Hey, I was there in Solaris land too and lived out of a
/usr/local/binbuilt from GNU tools. I’m not just talking about GNU vs BSD vs SysV choices though.A lot of the MacOS stuff is just old or weird. Like in 2016 MacOS unzip still couldn’t handle files over 2GB big, despite mainline unzip having fixed that back in 2005. (Is that fixed now? I don’t have a Mac to check). less was compiled with some bizarre options too. This bug report we’re discussing here is a very bad choice they made about certificate behavior that breaks an important security feature in curl. Etc etc.
Every single Mac user I know installs Homebrew the very first thing. (The die-hards still use MacPorts). That’s a step I don’t have to do on my Windows machine running WSL Linux systems. Or on my Linux boxes.
Yeah, I’m actually rather of the opinion that ecosystem diversity is a UNIX strength and things like musl are a feature, not a bug.
I think the whiff here was that the behavior change isn’t documented.
I do agree it would be nice if Apple tracked more closely to latest versions, but seeing as there’s broadly accepted ways around that I don’t think it’s much of a problem.
Things like this is why I’m happy to have most of my environment built from nixpkgs on a Mac. Upstream everything from libraries to shell to tools. You can achieve a part of it through homebrew too. I’m glad we have systems to isolate the “MacOS binaries” side from the “user binaries”.
The bug is one thing, but Apple blaming LibreSSL for this is rich. I am surprisingly confident that OpenBSD, and thus LibreSSL, does not use the Keychain API.
That’s an unnecessarily ungenerous interpretation of “It comes with the version of LibreSSL that Apple ships”.
That to me quite obviously suggests Apple patches LibreSSL to cause this behavior.
I think there’s some crossed wires. If I understand correctly, gecko is suggesting that Apple (not Daniel) is shifting the blame to LibreSSL by bringing them up. You seem to be defending Daniel, who I think we all agree did nothing wrong.
That is exactly what I meant. Daniel’s response is great; Apple’s response is ridiculous.
I indeed quoted Daniel, but his wording was pretty much what Apple wrote as well. My reasoning extends to them; I don’t see them as blaming LibreSSL; I see them as confirming it’s their doing, with enough details that no one could argue curl was to blame. To me it roundly says: “Yes, this is due to our modifications to LibreSSL”
I hear you, but if e.g. Microsoft hypothetically were to say that some bug in curl was not a bug because it was due to the version of NetBSD sockets that Windows ships, I think most people would find that to be a disingenuous statement. Apple owns their changes to LibreSSL. This isn’t semantically different from saying that Safari not properly doing cert checks (hypothetically) isn’t a Safari bug because CryptoKit has the same behavior. I mean, okay, but you also own CryptoKit. Why bring up LibreSSL at all?
Back around 2007 or so, Apple shipped a version of Safari for Windows.
There was some sort of security issue on Windows at the time, something like DLLs on the desktop would be loaded preferentially.
Safari would download files to the desktop.
Therefore if you did a drive-by download of a DLL via Safari on Windows, you’d get a DLL on the desktop and then later any application launched from the desktop would load that DLL and you’d get arbitrary code execution.
(I think I’m remembering this right.)
Anyway, Microsoft insisted it was a “blended threat” with Safari because Safari would download files to the desktop by default…
That’s a rich thing for them to say. If placing a dll file on a desktop is considered an attack vector, I’d rather blame their whole threat model. LD_PRELOAD always felt more sane than just loading whatever would lie in the same directory. I’m glad Wine specifically does not support this behavior.
As someone who had to write a response to said vulnerability I was a bit taken aback.
But it was in our best interest to maintain a good relationship with Microsoft’s vulnerability management team, so I wrote it up as they described…
It’s only as if the problem is with the version of LibreSSL that Apple ships, which is different from the version of LibreSSL that the LibreSSL project ships
Ah sorry, yeah that makes the response make a lot more sense.
Don’t expect permissively licensed software distributed by a proprietary vendor to behave like the publicly available source code does. The whole point of curl’s license is that distributors have more rights than end users.
If you don’t like it you have other options - both in terms of software distributors and software licenses. Don’t blame Apple for complying with the spirit and letter of the curl and libreSSL licenses, and their commitments to their users.
Same applies to GPL Licensed software too, fwiw. In that case the modified source will at least hopefully be publicly available, but it’s often heavily modified and not upstreamed.
If GPLd software is distributed to an end user in binary form, the end user can request the source code used to build the binary. They don’t have that right for BSD licensed software.
Of course, and I acknowledged as much in the very comment you responded to.
Just don’t expect GPL licensed software distributed by a proprietary vendor to behave like the source code from the upstream project does.
Yes, but you can expect the changes to be published.
Yes, that’s what this part means:
I think it’s the “hopefully” in your reply that I reacted to. I wouldn’t get software from a vendor that doesn’t comply licenses. I mean I used to buy pirate games on CDROMs in southeast asia, but it was clear what to expect.
Your meaning was somewhat different though. When I say that you can request the source code used to build the binary, I don’t mean that ‘hopefully it will be publicly available’, I mean that I can request the source and the vendor will provide the exact source used to build the binary, otherwise they are in violation of the GPL. This is not the case with BSD.
You’re right, the complete version would be: “in that case, the modified source code will hopefully be publicly available; and if it’s not, you can request it and they’ll hopefully provide it; and if they don’t you can sue them and hopefully have a court order them to provide it”
There are many steps that can be taken before it goes to a court 🤷♂️
[Comment removed by author]
in practical terms, Apple just wouldn’t ship curl if it were GPL, so people using curl on MacOS would be using the upstream version and would not be exposed to this security issue.
I’m left unclear on what’s going on. The Apple support person may not have understood the issue, or not communicated their findings well.
The main unanswered question I have is: is the curl Apple ships modified to produce this behavior, or is it a side effect of the changes in their LibreSSL lib?
I totally understand Apple modifying LibreSSL to use the system cert store in the Keychain as the default set of root certs, because otherwise IIRC it defaults back to reading a set of .cer files in some system directory as on Linux. Root certs are a platform feature whose implementation differs.
If Apple’s LibreSSL always uses those certs as fallbacks, regardless of a set of root certs passed to the API explicitly, that does seem like a bug, or misfeature.
Yeah, the reply reads like the Apple person didn’t actually understand the issue. Particularly this bit:
makes me think they thought it was about cert validation failures, not incorrect cert validation successes. (Not that that excuses Apple’s shitty response, which should come as no surprise).
The joy of the software & hardware owning you instead of you owning the software & hardware!
I’m unclear on how you get from “I bought a device that bundles someone else’s priorities in past and future decisions about details” to, and I’m being facetiously literal, “I am the property of this device and its behavior”—is it that the unwanted behavior you can’t change puts demands on your time and attention? Where does the ownership arrow flip?
It’s a pun.
A Russian reversal is a style of pun where an ironic contrast between two environments is undercut and rewritten with new meaning by punning one of the noun-phrases or verbs. In this example, “owning” is used in two senses: first, “to have rightful possession of;” second, “to defeat or embarrass.” Channelling Yakov Smirnoff, who helped popularize the format:
I mean, I get the pun—and I suspect kevinc does too—but it seems like a huge semantic stretch from “Apple made a questionable decision in their bundled curl, so you might want to install your own curl” to “Apple’s preinstalled software owns you.” If someone wanted to make that argument they’d need a lot more than a hackneyed pun to do it, in my opinion.
Quoting from the article:
I do get it, and it is a stretch, and the stretch is meant to be a bit absurd, right? That’s what I mean when I call my interpretation overly literal. But I also just want to understand more of the subculture that would make this gag, so I’d rather ask about where it comes from than assume.
so this is facetious in the sense that you’re making a joke don’t expect an actual answer, right?
Not exactly—I don’t expect an answer because this is the internet and you get only what people are willing to give. The point of my being facetious was to raise a real question while not being overly confrontational about it with a stranger, such that I might get an answer. But I think we’ve spun our wheels enough on this.
Neat backdoor to perform woman-in-the-middle attacks, just inject a cert into the system store and all your scripts are vulnerable!
Sounds to me like a conflation of “won’t fix” and “not a bug.” OK, it behaves the way you want—but if your manpage made me expect one thing and the behavior does another thing, the bug is there in the contradiction.