The purpose of a system is what it does.

This phrase is practically https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A... now

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).

BenQ PD2730S.

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.

That helps a bit but doesn't solve everything.

If you want to make a CI performant, you'll need to use some of its features like caches, parallel workers, etc. And GHA usability really fall short there.

The only reason I put up with it is that it's free for open source projects and integrated in GitHub, so it took over Travis-ci a few years ago.

Devil's advocate: They could make the github CLI capable of doing all of those things (if it's not already), and then the only thing the container needs is a token.

There are multiple ways you can do this already from within a script

Ah, the Dropbox comment.

> For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

Ive had good luck using: https://github.com/actions/github-script

When the cli didnt have support for what I needed

i just told the op that there are multiple ways to archive that without using api keys when in a script.

one of them beeing echoing text to a file. to me, your comparison makes no sense.

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."

Which CA's will issue short-lived certificates without negotiating a custom ($$$) contract with them?

Google Trust Services lets you go down to 1 day using ACME. No payment required.

Let's Encrypt, they said a while back they want to allow issuing certs for fewer than 90 days.

That's true, although it's still not possible to actually get one yet.

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-...

> see this issue filed by Josh Triplett

Check who you are replying to ;)

Yeah, I realize, and I am looking forward to having multiple options to choose from that all have the same license compatibility. It's nice that there's a short-term solution that's available for people who need to ship things soon, and it's nice that there's a longstanding library (ring) that'll long-term will be capable of providing a compatible solution as well.

> 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.

What kind of improvement are you looking for? A `blackbox` intrinsic with stronger guarantees?

> But it took until 2023 for someone to do the legwork to figure out how broken it was.

It took until 2023 for somebody to publicly disclose the problem.

The first fix for it was described in RFC 5647, which was published in August 2009 (first draft was submitted in June 27, 2008).

So how did it happen that GCM modes for SSH contained a fix, but ChaCha20-Poly1305 did not?

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.