insanitybit

4,421 karmajoined hace 4 años

Mastodon: https://infosec.exchange/@insanitybit Github: https://github.com/insanitybit

Rapid7 -> Dropbox -> Grapl -> Datadog

comments

hace 9 horasdiscuss

> There are no such invariants in Zig.

Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.

> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".

A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.

> There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.

Can be, yes.

> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools

This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.

hace 9 horasdiscuss

You can grep for every memory safety violation in rust.

hace 9 horasdiscuss

I've had zero issues with Codex. If it flags something it seems to have a slower "review before proceeding" phase but it does proceed.

hace 19 horasdiscuss

This is going in circles. I think my point has been made. You can grep for every memory safety violation in Rust, that is a win. Pointer aliasing is apparently not UB in Zig, that's cool, assuming that's what you are referring to - but I just can't stress enough how little this matters to my point.

> And they are actual bugs that I've take extra time to (statistically) verify.

I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?

> And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.

My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?

> Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.

I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.

I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.

Given that Fable is so gutted and Anthropic added the absurd data retention policy for it, I'm going to advocate that we prioritize support for as many other models as we can at work.

I'm writing a programming language with a "capability security model". That's enough to trigger Fable, it won't work on the language. It's hilarious. The mere presence of the word "security" seems to be enough to trip it up.

I write rust and barely interact with the community. I used to. I spoke at the first rustconf, even. I don't really care to engage with the rust community anymore (I cut myself off entirely from most online communities tbh).

I might stay away from a particularly toxic community or one with wildly different values, but I don't really get why you wouldn't write Rust just because of how some people post about it. Odd tbh. I find the whole thing about "oh the rust zealots" hand wringing stuff so silly, really.

> They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.

I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.

Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.

> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.

I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.

Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.

From my perspective.

1. 128 known bugs were fixed.

2. 237 potential bugs were made grep'able.

That is a massive win to me.

anteayerdiscuss

So there were 128 known problems fixed and you've found 237 potential bugs that were greppable. And you think that's a regression?

anteayerdiscuss

As opposed to the known problems caused by using Zig?

anteayerdiscuss

I think that's an interesting point that the models wrote SAFETY comments that are so obviously not what SAFETY comments are for. A SAFETY comment can never be about callers, that's the whole point of `unsafe`.

anteayerdiscuss

These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.

anteayerdiscuss

This is just a hit piece and it's embarrassing to post it on your project's website. Could've been a tweet.

hace 5 díasdiscuss

Why would I give a shit about this person's personal conversations being boring? Make new friends, idk. I don't talk about AI outside of technical forums where it's relevant or maybe work.

> Just stop wanging on about it like you discovered the secret to eternal life.

I mean, I'm going to talk about whatever the fuck I want to talk about so long as I'm in the relevant forum for that topic.

hace 7 díasdiscuss

I'm on HN to read comments. This is a social forum. Insight and opinions are the value proposition.

hace 12 díasdiscuss

I feel like I was an employee, I don't really recall the details when I spun up my C-Corp tbh. It does seem that a CEO can take a $0 salary.

hace 12 díasdiscuss

If you're raising VC money then I assume you're not an LLC. But I think you're right that the owner can take a $0 salary.

hace 12 díasdiscuss

I basically specified that I'd make the highest salary and no more than that. It felt like a fair policy at least, it took a lot of guess work out of it. If I wanted to bring someone in at X00K, I had to make X00K.

I started off making significantly less than I did as a dev (~30-50k + I had spent months with 0 salary before raising), within ~2 years I was making a bit more and I capped out around there.