Just to be clear, OpenSSL isn't doing the wrong thing, based on the description in the blog post. The specification allows and even requires behavior similar to that.
This is uninteresting. CAs are well aware that they have to encode the subject DN and issuer DN identically to maximize interoperability. There are several implementations that require that.
If we were to make a new version of the spec for X.509 certificates, I would hope that we would eliminate all the non-UTF8 encodings so that this would be a non-issue.
Pretty much all the routers that are targeted by the ban would be OpenWrt derivatives, AFAICT. It’s basically the Android of routers, except without the Google resources.
Google Wifi Is one of the main lines that aren’t based on OpenWrt.
> We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies.
It would be awesome to have somebody show that OpenWrt-based routers are safe and secure. I looked into this problem about 10 years ago and my concluding was that stock OpenWrt was really questionable. Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-first-from-the-ground-up alternative with a real trustworthy update story.
[I was at Mozilla during the development of BrowserID but I didn’t work directly on it. I was a huge fan of the effort.]
Besides non-obvious UI issues, there were fundamental issues. One in particular that was very hard to overcome:
Very few people would choose to hide which websites they are logging into from the identity provider. People don’t care whether their IDP can see when/where they are authenticating. That’s assuming they could even understand the issue at all. They have to trust the IDP a lot either way, and this one detail is small, counterintuitive, and even oxymoronic to most people—Trust the IDP 99%, but jump through hoops to avoid trusting them 100%? Why?
There is value in the identity provider knowing when, and from which device, and from which location, and on which websites you are using the identity. Hiding any of this from the IDP hurts security. It is really hard to overcome this in a useable way. A lot of purported solutions implicitly assume users have device and key management abilities that even experts in this area rarely consistently practice.
So, then, are you really better off, i.e. receiving a net positive benefit?
Many implementations limit the RSA key size to 8,192 or 16,384 bits (because the maximum bit length determines indirectly how much stack space is required).
Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.
At https://rwc.iacr.org/2025/program.php you can see there is a talk scheduled to be given in a couple weeks titled "Testing Side-channel Security of Cryptographic Implementations against Future Microarchitectures" with the following bits in the abstract: "Using this framework, we conduct an empirical study of 18 proposed microarchitectural optimizations on 25 implementations of eight cryptographic primitives in five popular libraries. We find that every implementation would contain secret-dependent leaks, sometimes sufficient to recover a victim’s secret key, if these optimizations were realized. Ironically, some leaks are possible only because of coding idioms used to prevent leaks under the standard constant-time model."
Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...
> Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation.
This really oversimplifies the situation. Even at my most pessimistic, I believe just a very few, very small, parts need to be written in assembly language to maintain the "constant time" properties, and that's just until we can work together better with the Rust language team to eliminate these small gaps. Even before then, the Rust language team is doing a good job at independently improving and expanding the building blocks we need to get to entirely-safe (in the Rust `unsafe` sense) and high-performance crypto libraries in Rust.
> evidently faster than ring itself[1].
If you're running on an AVX-512 system, there is a notable performance gap, temporarily. This state will persist for a few months at most, most likely. It's inevitable that we (all the OpenSSL forks, and even including non-OpenSSL-forks like rust-crypto) all converge on more-or-less the same implementations and/or different implementations of the same optimizations.
I think that's a really good question. The way this worked out is worth studying in detail. What was the process with which the AES-GCM cipher suites for SSH were developed? What was the process with which the ChaCha20-Poly1305 cipher suites were developed? How did the difference in processes lead to the difference in results? Will anybody change their process based on these results?
There are multiple reasons for a user to want "dark mode":
* I just want everything to be dark on my screen because I like it.
* I am trying to use this device in a dark place.
* I want a dark, low-contrast background that doesn't compete with image colors.
The solutions to these three problems are all some kind of "dark mode" but each one needs a different solution. Sometimes one "dark mode" might work in conjunction with the user manually changing their brightness settings depending on the lighting in the environment, but not many people seem to design for that.
The the old yanking policy was extra work I did with the intent to help people. It was unfortunate that Cargo had that bug, but also I should have been much more diplomatic in how I dealt with it.
I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and eliminating all the remaining bits of C code in the next two quarters.
Feel free to reach out privately if you want to talk: [email protected].
> If std::fs::File::open() gives me Result with an io:Error that claims "File not found" but the underlying OS file open actually failed due to a permission error, you can see why that's a problem right? Even if this hypothetical OS doesn't expose any specific errors, "File not found" is misleading.
A more accurate analogy: You ask to open "example.txt" without supplying the path, and there is no "example.txt" in the current working directory. You will get "file not found."
Regardless, I agree we could have a better name than UnknownIssuer for this error.
Are you assuming that the set of certificates that is given as input is the complete search space? It isn't; the server might have failed to send some certificate that, if present, would have fixed the "unknown issuer" problem. Also, we fail fast on errors; as soon as we find a problem, we stop the search on that path. Because of these reasons, identifying a single error would be, potentially, misleading.
In some cases, e.g. the end-entity certificate is signed with an algorithm that isn't supported, or an RSA key that is too small, we could add special logic to diagnose that problem. However, all this special diagnostic logic would probably approach the size of the rest of the path building logic itself. It doesn't seem appropriate for something in the core of the TLB of the system. Perhaps at some point in the not-too-distant future we can provide some mode with more diagnostic logic, and find a way to clearly separate this diagnostic logic from the actual validation logic to ensure that the diagnostic logic doesn't influence the result.