dochtman

I could see how they float to the top organically, so it might be just the unreplyable aspect that is automated?

N = 1, but at startup scale we have definitely not had a hard time hiring skilled Rust devs. Just go on /r/rust and advertise your (non-crypto) job and get a lot of inbound.

(We were specifically looking for remote folks near EU time zones, maybe local in SF is harder?)

A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation:

https://github.com/rustls/rustls

Some thoughts on lessons learned from other projects/vulnerabilities:

https://docs.rs/rustls/latest/rustls/manual/index.html

The discussion about alternatives doesn't need to be related to switching under the timeline of a routine security release, right? I would say that every security release would increase activation energy to switch to another provider, even if that happens asynchronously relative to addressing the security release.

Assuming that good alternatives are available of course. (I'm a rustls maintainer, so obviously I think that's a pretty good alternative -- we have a C FFI, too!)

In NIP-04 I noticed that DMs can be encrypted using AES-CBC. IIUC, this is not a very robust mode for using AES. Seems surprising for a greenfield project.

Difference in EUR is also pretty crazy. My 16" M1 Max was about EUR 1000 cheaper than a similarly specced M2 Max, about a 28% increase.

Note that Apple is known er use Rust for some of its infrastructure and Google is adopting Rust in a big way in Android and Fuchsia.

I would be curious for a similar dissection of modern macOS. My intuitive sense is that it is a little better though there are probably still at least 5 layers of stuff.

So to some extent, does doing this better at the scale of a modern user-facing OS provide enough return on investment?

Install Asahi on all their machines?

I actually tried this 6 months ago and in no way found the Linux experience better than macOS even though I would on principle prefer living with an open source OS (I also don’t actually notice a lot of issues on macOS). Of course that was still pretty early for Linux on M1 so I’ll probably try it again in the future.

Googled the link, posted a little too quickly. Fixed it up.

Previously:

https://news.ycombinator.com/item?id=31205072

(Edited to point to page 1.)

Happily, so far the estuary for buccaneers has proven to be much more robust.

On the Metal has been discontinued, but highly recommend giving it a listen: https://podcasts.apple.com/nl/podcast/on-the-metal/id1488187....

In the security/cryptography space, Security Cryptography Whatever is pretty great (with tptacek): https://securitycryptographywhatever.buzzsprout.com/.

Maybe a comparison to ICU4X is more interesting.

Nothing in the QUIC spec mandates the use of well-known CAs, as far as I know. (And QUIC-TLS is a separate spec because the crypto protocol is a natural extension point in QUIC -- experiments for QUIC with Noise already exist.)

One depending on the other seems like the worst of both worlds: more code to compile for everyone.

Personally I still prefer chrono's API; chrono is also much more conservative about the MSRV (currently at 1.38) whereas time consistently bumps to N - 3, which seems like a meaningful difference.

time depends on the libc timezone parsing with some fairly involved workarounds to avoid hitting undefined behavior, while we incorporated time zone parsing in Rust with some caching for chrono.

So I think these are meaningful differences -- feels unlikely that these projects will merge.

Yes, the time crate was rebooted after 0.1 and got a new maintainer.

I think we're starting to do better again with Chrono, hopefully it won't take us too long to get out a solid 0.5 release.

(I'm one of the current Chrono maintainers -- the previous maintainer burnt out on the project earlier this year, at which point the project sorely needed some TLC.)

Work is ongoing to use FiatCrypto-based implementations for the primitives, which is discussed a bit here:

https://www.crowdsupply.com/sutajio-kosagi/precursor/updates...

A standard or a specification? Anyway, hopefully Ferrocene will be able to provide those folks what they need.

https://ferrous-systems.com/ferrocene/

In my understanding it would be hard to make the case that Rust actually has more undefined behavior than C -- most kinds of undefined behavior in C have been carefully avoided in Rust, although, yes, there is no piece of paper ratified by a bunch of national technology institutes that describes Rust.

See also this recent blog post:

https://blog.m-ou.se/rust-standard/

There are fairly comprehensive measurements from 2019:

https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html

I'm pretty sure current versions of rustls are faster than the ones from 2019, but I don't have an intuition for how OpenSSL performance has evolved in the past three years.

I'd like to do another comparison some time soon.

(Yes, the underlying ring crypto library should take advantages of specific instructions available on common CPU architectures.)

Reminder that rustls exists as a pretty mature TLS implementation in safe Rust (thus systematically avoiding issues like this). Thanks to Brian Smith for creating the webpki crate which was thoroughly engineered from the start to avoid stuff like this.

rustls has C bindings these days: https://github.com/rustls/rustls-ffi

I've started work on Python bindings too, with the idea that it probably wouldn't be crazy hard to do something that can pass as an `ssl.SSLSocket`. Please sponsor me on GitHub if that's something you'd like to use (https://github.com/sponsors/djc).

Note, we're aware that by far the biggest impediment to adopting rustls is the lack of support for IP addresses in certificates (we currently need a DNS name). This work is funded and should be completed in the next few months.

Note that the ring maintainer has long since stopped yanking releases.

More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.

There's the bencher crate as well, which provides a similar API to nightly through macros that work on stable. On one of the projects I maintain we reverted from criterion to bencher because the criterion results sometimes made no sense.

For 1.1 and 2, the byte stream is the same for TCP vs TLS over TCP. For 3, it uses one stream per request over a QUIC connection which is always encrypted.

Was a bit disappointed to discover that the advertised Prusti Assistant VS Code assistant sort of silently sits there waiting ("Checking requirements...") if you don't have Java installed.

I feel like assuming Java is installed doesn't really fit the audience.

It is.

This. I currently pay for Netflix, Disney Plus and Apple TV+. If I encounter something I still can't watch, I'm reasonably likely to fire up Transmission.

You assume wrongly, Pythonista has been in use for both genders for a long time (more than a decade).

Find a job with similar pay but a goal you care (substantially) more about?