cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #prjunnamed
gatecat[m] has quit [Quit: Idle timeout reached: 172800s]
povikMartinPovie has quit [Quit: Idle timeout reached: 172800s]
povikMartinPovie has joined #prjunnamed
<povikMartinPovie>
why does cargo fmt want to reformat much of the codebase for me? is this a version mismatch on fmt?
<Wanda[cis]>
are you using nightly?
<Wanda[cis]>
one of the configuration options we're using is only supported on nightly and silently ignored on stable
<Wanda[cis]>
which is incredibly annoying
<povikMartinPovie>
not sure what version I'm on
<povikMartinPovie>
what option is this?
<Wanda[cis]>
so while prjunnamed only uses stable rust features and is supposed to work with stable rustc, this is not the case for rustfmt unfortunately
<povikMartinPovie>
do you expect allowing an input or output to conflict with a name attached to a different net?
<povikMartinPovie>
i.e. do those live in a different namespace?
<whitequark[cis]>
undefined currently
<whitequark[cis]>
we need to fix a TODO in a verifier somehow
<mei[m]>
<povikMartinPovie> "Screenshot 2025-03-12 at 12.03.3..." <- gah, I feel a bit responsible since I was the one to set up the cargo-deny (motivated by reasons other than rustsec, but i left rustsec at default enabled). In my defense, when I was setting this up, it showed an unmaintained notice with "hey, this is a motherfucking soundness issue" in the body. should I look into whether this can be configured to only show genuine security
<mei[m]>
issues and not just plain unmaintained crates?
<whitequark[cis]>
<mei[m]> "gah, I feel a bit responsible..." <- yes
<whitequark[cis]>
i do not care about 'security' in prjunnamed in the slightest
<whitequark[cis]>
especially not the weirdass OCD driven bullshit that rustsec does
<mei[m]>
whitequark[cis]: okay, remind me on friday
<whitequark[cis]>
okay
<mei[m]>
whitequark[cis]: yeah, definitely. the extent to which they are useful is to know about potential soundness issues before we step on that rake ourselves
<whitequark[cis]>
mei[m]: this is the case but i feel like rustsec getting a hang of those is almost coincidental
<whitequark[cis]>
like, logic bugs are exactly as bad as soundness bugs for us
<whitequark[cis]>
i would care way more about easy-smt2 bugs than e.g. some UB we aren't even likely to trigger
<mei[m]>
yes. though do keep in mind that UB is unique in the level of spooky-action-at-a-distance it can cause
<whitequark[cis]>
I do know that!
<whitequark[cis]>
the thing is, as much as I love to preach that to nonbelievers, in practice it's mostly local because any time you use memory it acts as a barrier
<whitequark[cis]>
there are some really clever (and exploitation-relevant) examples of nonlocality, but most UB is just "oh, this segfaults" *even if the entire execution is meaningless as a result formally*
<whitequark[cis]>
to make a concrete example: what's worse, UB in LLVM or a miscompilation in LLVM?
<povikMartinPovie>
I'm surprised rust has these issues. Does it come from unsafe rust?
<Wanda[cis]>
people do all sorts of batshit things with unsafe rust
<whitequark[cis]>
povikMartinPovie: oh, Rust is even more aggressive about UB that C-family, specifically because it has safe code
<Wanda[cis]>
and given how easy it is to do UB in Rust
<whitequark[cis]>
e.g. alias analysis is much stronger
<Wanda[cis]>
you bet there's UB
<povikMartinPovie>
I'm baffled, doesn't it defy the exercise of the language to be memory safe if the UB is even more agressive?
<whitequark[cis]>
nope!
<Wanda[cis]>
accidentally materialized two `&mut`s to the same thing at the same time? whoops you're now in UB land, despite never actually using them to access memory
<povikMartinPovie>
right, but that's a mistake in the unsafe land
<povikMartinPovie>
is there UB outside unsafe?
<Wanda[cis]>
nope, that's the whole point of unsafe
<Wanda[cis]>
that is, unless you hit a soundness bug
<Wanda[cis]>
whether in the compiler, std library, or some random unsafe code pulled from some crate
<povikMartinPovie>
ok, thanks
<whitequark[cis]>
"undefined behavior" is exactly the same thing as "an assumption the compiler can make without formulating a proof confirming it"
<whitequark[cis]>
every time you do the latter (e.g. that two `&mut` pointers can't alias) you create the former
<Wanda[cis]>
would never happen in the rust compiler of course, it's so highly vetted
<whitequark[cis]>
so a compiler without UB is a compiler which is incredibly restrictive in the set of optimizations it can do. the JVM for example can do almost nothing statically and that's why it needs a JIT and guards that cause deoptimization
<Wanda[cis]>
oh it finally no longer compiles with current rustc
<whitequark[cis]>
the C or C++ compilers can make whatever assumptions they please (insofar as the standard lets them to) and it is on you to make that proof. nobody gives a shit which is why C is responsible for over half the exploitable vulnerabilities I think?
<whitequark[cis]>
the Rust compiler has "a type system" and "a borrow checker" which require you to structure your code in such a way as to formulate these proofs (non-interactively), plus "unsafe {}" which do not require anything of you but the proof is still on you to make
<whitequark[cis]>
culturally people sometimes give a shit and that is why the amount of exploitable vulnerabilities is a lot less
<whitequark[cis]>
but like, sprinkling unsafe {} does not do anything besides "turn off the non-interactive proof checker". it does not absolve you of making the proof. it merely disables the diagnostics that would tell you that your proof makes no sense
<mei[m]>
Wanda[cis]: there's a modern, maintained alternative at cve-rs
<Wanda[cis]>
oh good I'll pick it up when I need to extend my lifetimes
<whitequark[cis]>
but to go back to unnamed: I care about soundness bugs in prjunnamed itself a whole lot more than I care about UB in a dependency
<whitequark[cis]>
one of these is almost certainly exploitable with a crafted input. the other is almost certainly benign in practice, however bad the theoretical worst case is
<whitequark[cis]>
lifetimes are fucked? cool, we don't do anything clever in prjunnamed itself so there's a good chance we have zero exposure to the fuckedness and it's unimportant
<whitequark[cis]>
certain netlists have a missing not after being transformed? terrifyin