I'm hoping some organizations will step forward to fund work on this.
(Note that curl on Ubuntu 26.10 now has CRLite support baked via upki -- unfortunately that doesn't help with this because AIUI CRLite is only for end entities, not for intermediate certificates.)
The Go and Rustls upgrades specifically block the intermediate certs because neither of these use the system revocation lists, I believe. Once you upgrade to a trust store without the root cert for the CA this will also solve the issue. Not sure about other ecosystems.
Linux - the platform which offers no ability to revoke an intermediate certificate, thus necessitating every certificate library to implement its own blocking?
Windows is already blocking the compromised CAs as of today with no need for users to upgrade anything.
Every certificate library has to implement its own blocking no matter which platform you run on. Windows provides an API to do this at the system level, which means nothing if a given application vendors their own TLS library.
It's uncommon on Windows for applications to use a third party certificate verification library because Windows provides an API that does it. On Linux, you have no choice because all the platform provides is a bundle of PEM certificates.
> uncommon on Windows for applications to use a third party certificate verification library
I bet you have at least one copy of OpenSSL on your Windows system, probably multiple. Using the Windows native APIs is work. OpenSSL just works everywhere.
(Also, "the platform" doesn't technically even provide the cert bundle, depending on exact distro & packages.)
I'm keen to follow along with Wild as their intent is to be incremental, and Zig recently announced incremental linking support. I'm also a fan as its cool to seen an Australian working full time on open source (I'm also Australian)
Edit to add: I think David's talk on Wild [0] is an interesting summary of what a linker is and why its hard to make incremental
I think the way I've talked about incremental linking may have given a somewhat misleading impression. I'm not against incremental linking, and I'm not denying its possible usefulness. But especially when I was developing lld, I felt that we should focus first on speeding up full links.
Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?
In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.
Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.
I don’t think it’s completely unfair to say that the Neo is based on a chip that was first announced in Sep 2024 while the Intel chip is from Apr 2026.
Also, I think the battery life most people are practically interested in is more like running (close to) idle and less like the number of Watts spent when running maxed out, and I wouldn’t be surprised if Arm chips still win on that metric…
Plus it’s a phone chip. Yeah it’s used in the Neo but it’s no M5.
It’s good Intel got to this point, but you can’t declare them tied with Apple. They qualified for the real race, which us great, but they're not going to win with that chip.
I haven’t followed the PC chip business anywhere near as much as I used to around the turn of the millennium. I was under the impression Intel actually made a few chips that could go quite low power. The problem was their performance sucked.
It’s good that this performs good and can go low power, but the big question to me is whether they can scale it up without it becoming a power sucking furnace.
There’s no other comment somewhere in here, where someone is pointing out that that was in FP64, which is not something most people use. Especially people who are going to buy a computer like this.
I suspect for me personally, integer use matters far, far, far more than anything else.
It might be used a little bit in other places, wouldn’t surprise me one bit. And it’s good that the computers are capable of it. Even if someone can’t get a more powerful computer, it’s nice that they have the ability to use it for almost anything (within some limits) if they’re patient.
But as you said, if your workflow really needs FP64 you’re probably not reaching for a MacBook Neo or this Intel thing.
I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project.
Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.
I understand there's probably a big thorny problem of duplicating the corporate process/policies on the human level that ensure compliance, but is the back-end software pipelining stuff to CT logs not also something that can be replicated? Or is it not part of the server side stuff which has been open sourced?
Our code for sending stuff to CT logs is fully open source. But that's the tiniest slice of our compliance regime -- the vast majority of it is things like audit logging certain events, preserving audit logs in specific ways for certain amounts of time, ensuring dual-controls on all systems, being both audited and penetration tested annually, maintaining firewalls and vulnerability scanning tools, etc.
It's absolutely possible to spin up another new CA; lots of folks have done so over the years. But having time, and money, and prior experience all help a lot.
That's the policy, but we've been a bit more conservative in practice. `main` currently targets 1.88, but that's only because a security issue in the time crate has forced our hand (one reason I don't like the time crate all that much). Before that, it was 1.83 (from November 2024). Our last release targets 1.71 (from July 2023).
https://discourse.ubuntu.com/t/an-update-on-upki/77063
My interest in building OneCRL support into upki has definitely increased this week. Issue:
https://github.com/rustls/upki/issues/229
I'm hoping some organizations will step forward to fund work on this.
(Note that curl on Ubuntu 26.10 now has CRLite support baked via upki -- unfortunately that doesn't help with this because AIUI CRLite is only for end entities, not for intermediate certificates.)
reply