With crypto publicly available tests come in form of KATs (Known Answer Tests), it ensures that the implementation works for certain inputs and thus it'll probably work for the whole domain, but it does not protect from subtle forms of weaknesses such as side channels.
The short version is that absolutely no-one should ever use this.
Iroh is a project that combines existing IETF standards in an interesting way. For example we use raw public keys in TLS for the key exchange https://datatracker.ietf.org/doc/html/rfc7250 instead of coming up with our own key exchange scheme.
Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.
We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.
I'm sceptical of verifying or generating ZKPs due to the cost of running a RISC-V program. But I guess if we have LLM inference in protocols, this might be acceptable. I'm not sure how it's fully used in the protocol and whether it sits on a critical path.
I know internally they use an IPsec implementation written by Rust (I think in the iCloud infra). Heard this from an ex-Apple engineer Ben (forgot his last name) that did a wonderful presentation of Rust from first principles. He said that it was hard to get people in on Rust when most would argue for Swift.
Heaps excited about this because there's a dearth of work in application crypto as the mindshare is dominated by PQC or Crapto.
I am a little sceptical of this because of the need for ZKP and running a RISC-V program for protocol interactions (I only had a cursory glance). But if we can do LLM inference as standard in protocols these days then this probably has a chance.
I was interested in Nix because it could automate setup and configuration of macOS features. But all it does is usually run defaults or some intermediatary. In the end I stuck with brew and wrote an idempotent setupmac() function in my bash_profile (I use bash 5) with the aid of chatgpt since it knows all the cool defaults commands, and it’s pretty much solved setting up a new account or mac (alongside a Brewfile I maintain in my dotfiles). I don’t need any of those highfalutin tools.
I am, like, two minutes away from getting my configuration back on a fresh Mac or Linux system without Nix, so configuration management is just irrelevant to me. I am evaluating it as a package manager and a way to setup development environments.
Homebrew is a non-profit project run entirely by volunteers, not employees. We need your funds to pay for software, hardware and hosting around continuous integration and future improvements to the project. Every donation will be spent on making Homebrew better for our users. Please consider a regular donation through GitHub Sponsors, OpenCollective and Patreon.
I donate to a lot of open source projects that I benefit from, but I’ve never really thought about Homebrew. I will get onto it.
Apple employees did. Not Apple themselves. As for hosting, it was hosted on an equivalent of SourceForge, where many other opensource projects unaffiliated with Apple were.
And we all know how MacPorts failed to actually gain any significant momentum.
Oh, didn't read that part of the news. That's great. Ability to run x64 docker images seminatively was one of the big reasons I jumped to the M1 platform when it came out and I was baffled that they would remove it.
What happened to Orbstack for like 9 months until earlier this year? Suddenly everything went silent for a bit and I was pretty concerned. Glad y’all are back!!!!
Thank you for sharing this - I looked into OrbStack a few months ago, and this was the reason I didn't use it (as my primary purpose was to have an external wifi adapter for wifi pwnage).
I've successfully tinkered with USB/IP with Apple containers, but it does require loading a custom kernel (which they make pretty easy, thankfully). On the host side, macOS also doesn't make it easy to unload a driver that attaches automatically.
The short version is that absolutely no-one should ever use this.
Ditto.
reply