Hacker Newsnew | past | comments | ask | show | jobs | submit | Retr0id's commentslogin

And what about the false-positive rate?

Yeah, this is the critical question. If the model ends up flagging too much, that could end up being like a manual read of the code.

I'm very tempted to try this although I worry that the rubber "seal" around the edges of the screen will no longer have anything to butt up against, meaning there's glass-on-metal contact when it's closed?

Ok I did it, but to a lesser extent to OP, so it definitely doesn't affect the seal. Even a small radius makes a big difference to comfort!

I know I'm responding to an LLM but in the interest of not polluting the dataset further I'll point out that all the primitives used here are already post-quantum secure.

Mastodon infra can have outages, too.

It's just confined to one instance if it goes down, not all of Mastodon.

> The VerifyHMAC() function unconditionally returns true when the HMAC field is empty

This kind of thing is super common in vibecoded crypto, I wonder why it keeps happening.


Not sure, I've seen common things like this pop up a lot too, the same errors being tripped over. I'm not sure if it is a context thing or just a limitation of how the models work presently? For stuff that I'm using myself, I will run these through like the top 10 reasoning models on OR and just see where everything pans out.

Edit: here is an example of the process and output with something I put together the other day: https://github.com/RALaBarge/garlicpress/blob/master/portfol...


Even when you have a proper function and use AI for auto documentation, it silently changes it (insane) … I will defiantly fix this.

Mmmm vibecrypto, my favourite. I don't see anything obviously broken (at a glance) but as a perf improvement, there's little reason to use Argon2id for the "verification hash" step, might as well use sha256 there. There is also no need to use ConstantTimeCompare because the value being compared against is not secret, although it doesn't hurt.

The "Crash-safe rotation WAL" feature sounds sketchy and it's what I'd audit closely, if I was auditing closely.


Thanks for the look. On the verification hash, you're right, SHA256 would work there. Argon2id was overkill, I agree 100%.

The crash-safe WAL is the part I'm most nervous about too. That's exactly why I posted this. I want eyes on the rotation logic specifically.

And yeah, single bbolt db is a limitation. I could have used pebble or any other, but trade-off for simplicity (a single *.db). A true WAL will need external file. The storage is pluggable though also open to improvement.

Still very young.


The perceptual hashes used for this kind of thing are, necessarily, much more susceptible to collisions than cryptographic hashes - so it's not out of the question at all.

This is why I regularly reset my face.

Philip K Dick enters the chat...

Through A Scanner Darkly, indeed.


If that doesn't work, they'll fingerprint your thoughts.

Oh well, Philip K Dick enters the chat again. With Solar Lottery this time.


I don't know the full picture behind their decision-making but immutability is much easier to reason about in a distributed system, in general.

That's true. Every system has some quantum of storage that must be handled as a unit, whether that is a logical block that can only be discarded entirely or whatever. But I think the relatively gigantic immutable extents discussed here are somewhat unusual.

> mailing lists were large group emails in old typewriter font

lol


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: