Minor correction: it falls back to Apples CA store if the initial check fails. So wouldn’t add more computation for nothing.

However I do agree that it’s not the expected result and thus bad behaviour.

Given how Apple generally favour backwards incompatible changes and that this feature is added into curl, this does feel like there is more to this story than Apple is letting on. Perhaps it’s used for developer diagnostic tools or AppStore validation?

This is the kind of behaviour (corporate and software) that I would anticipate if some government has ordered them to secretly install it as a back door — a government-controlled item in the CA store (which isn't necessarily obvious, I think it just means at least one private key got copied), a requirement that all first-party software must use that store, and a requirement not to admit that this is a problem.

> Minor correction: it falls back to Apples CA store if the initial check fails. So wouldn’t add more computation for nothing.

Not GP but that is extra computation? It should just fail at that point, instead it's doing computation. According to the result, it's then either 'for nothing', or in order to give the incorrect result.

I disagree, but please read my comment through because if you take the first part of the comment alone then it might read as defending Apple, when I'm really not.

That's a failure scenario though. If your application is failing a CA check against an authority you've pinned then your infra and application is already broken in ways that the extra computation is meaningless. It is your certificates or application that then need correcting.

In terms of computational overhead (and only computational overhead!), where it matters is the happy path because That's where the overhead of additional computation would affect the performance for your operational infra and thus your users (and we are talking about this specific scenario and not some more generalised discussion about TLS). If you follow the happy path then Apples change, as serious as it is, doesn't affect the behaviour or your application.

I'm not defending Apple here. Whether intended as one or not, this change is a literal backdoor. And it needs to be framed as such. Arguing it as a computation overhead is, at best, missing the significance of this change in behaviour.

So the real problem isn't computational overhead, it's the question of what signing authorities are given permissions to write certificates for your pinned endpoints that wouldn't / shouldn't have had under curl's default code and expected behaviour. ie who now has a backdoor?

I’m saying calling this a problem because it might add a computational overhead is missing the severity of the problem.

This is a problem because it creates a backdoor.

I also disagree it creates a computation overhead because it’s only engaged outside of normal operation (ie when your application is already broken or if someone is intentionally exploiting that backdoor). but the computation argument is more of a distraction from the real problem.

So definitely not defending Apple. I’m saying it’s more serious than just a computation problem.

Hm, ok. I don't think they did miss the severity though, at least by my reading of:

> That means that this "feature" by Apple either adds more computation for nothing, or breaks the verification model that is expected.

they're saying one of two things happens: you get the wrong result (more severe than amount of computation) or you (because the cert it does have is not in Apple's store either) get the correct result, but wasted cycles doing something that you didn't want it to do and risked getting the wrong result.

You, not they. The “they” in this context is the author of curl. And Daniel is fully aware of the problems this change makes.

Whereas you’re the one barking on about computational overhead.

No, that's a quote from the top-level commenter (who wasn't me, as I said when I first commented), hence 'they', because they said that, not me.

My apologies. Full of confidence of at the moment so must have misread your comment.

Cold!! I’m full of cold, Not confidence.

Never attribute to stupidity that which could be explained by malice (especially if the malicious actor uses Hanlon's razor in defense).