I've had people tell me that they trust postres RLS as their security boundary and that it's fine to expose.

ctrl + f "zizmor" 8 found

I endose this article.

uv defaults to its own trust store afaik lol

maybe they meant it "should" be your friend but actually isn't in this case :-)

It was.

The vast majority of web services are not written in memory unsafe languages so this is not surprising.

One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.

I don't think the definition of "memory safe" has ever required full end to end stack conformance with a proof. Very few languages have achieved that, though some have. Most people call Java memory safe, C#, Python, Typescript, etc - all of those fall short of a formally verified, sound type system with a verified toolchain.

Not to talk about Go, which has intentional unchecked-at-runtime UB (data races) yet many argue to consider it memory safe (and I have a feeling that the same people arguing Rust isn't memory safe are also there. Just a feeling though).

lol do you think that cve-rs was required? there is literally an l-unsound tag on rustc's github, this isn't some embarrassing or secret thing.

Safe rust is safe, granting `unsafe` and compiler errors. This isn't a secret.

What's l- here? Literal?

"I" stands for "issue"

https://github.com/rust-lang/rust/labels?q=unsound

lol I was writing `l` because I thought it was `labeled-unsound` for like a fucking decade

For a long time `loop {}` was undefined behavior. Lots of l-unsounds are really nuts but a few are not.

The reality is that if this were actually code that people wrote, well, it wouldn't have sat around for a decade.

Afaik loop {} has never been UB, however because llvm started as a c++ compiled where it is, this has been causing miscompilations in rust and C for… nearly two decades (llvm issue 965).

Sure, I think it was still under the same unsound tag regardless.

Unsoundness and UB are very different things, UB tells users of the language "don't do that it's wrong", unsoundness tells users of the language "be careful we need to fix that", it's a bug.

I don't care, nor should anyone else

Rust has no formal spec? Really?

It's a work in progress. The Reference (https://doc.rust-lang.org/reference) is slowly getting more complete over time. Other ongoing efforts include a-mir-formality (https://github.com/rust-lang/a-mir-formality), minirust (https://github.com/minirust/minirust), the FLS (https://github.com/rust-lang/fls), and Rust via Desugarings (https://nadrieril.github.io/rust-via-desugarings/). But writing a 100% complete and correct formal spec is hard! Not even C gets this right, the C standard has holes which lead to miscompilations and UB in practice: https://www.ralfj.de/blog/2020/12/14/provenance.html

This doesn't work when every candidate holds the same position.

I mostly use Haiku for really, really basic stuff, never for actual engaging work. I've used it for first-pass analysis to triage bugs, for example - all it does is related N bugs together to see if any potentially relate. Then I have Sonnet investigate further.