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

Because the authors found out about it by chance on Hacker News.

That said, these issues are not a big deal.

The first one concerns someone manually reading a signature with cat (which is completely untrusted at that stage, since nothing has been verified), then using the actual tool meant to parse it, and ignoring that tool’s output. cat is a different tool from minisign.

If you manually cat a file, it can contain arbitrary characters, not just in the specific location this report focuses on, but anywhere in the file.

The second issue is about trusting an untrusted signer who could include control characters in a comment.

In that case, a malicious signer could just make the signed file itself malicious as well, so you shouldn’t trust them in the first place.

Still, it’s worth fixing. In the Zig implementation of minisign, these characters are escaped when printed. In the C implementation, invalid strings are now rejected at load time.


If a website can crash your browser, the problem is your browser...

Doesn't seem to work with Zig?

LLMs don't need your secret tokens (but MCP servers hand them over anyway): https://00f.net/2025/06/16/leaky-mcp-servers/

Encrypting sensitive data can be more useful than blocking entire requests, as LLMs can reason about that data even without seeing it in plain text.

The ipcrypt-pfx and uricrypt prefix-preserving schemes have been designed for that purpose.


Yet another CLI.

Why does every AI provider need to have its own tool, instead of contributing to existing tools like Roo Code or Opencode?


I just end up using most of these models with Claude Code as the tooling because it just seems to work better than anything else. Crush also works well.


My 2ct: Because providers want to make their model run optimally and maybe some of them try to build a moat.


> providers want to make their model run optimally

Because they couldn't do it by contributing to existing opensource tools?


For macOS users, the sandbox-exec tool still works perfectly to avoid that kind of horror story.

On Linux, a plethora of options exist (Bubblewrap, etc).


Static key, random 12 byte nonces, no per-session key for temp buffers.


"Sqlite [...] encryption extension is a $2000 add-on".

SqliteMultipleCiphers has been around for ages and is free https://utelle.github.io/SQLite3MultipleCiphers/

And Turso Database supports encryption out of the box: https://docs.turso.tech/tursodb/encryption


There’s also SQLCipher, it’s been in development since 2009 and works quite well:

https://github.com/sqlcipher/sqlcipher


How do you use these in practice? Both Python and Go don’t make it easy to link a different variation of SQLite with one of these plugins compiled in. How do you make it work?


I don't think SqliteMultipleCiphers can be built into a runtime loadable extension (and the Turso thing is just a copy of it).

I'm confident that a scheme based on tweakable block cyphers (like Adiantum or AES XTS) could be made into decent runtime loadable extension.

I implemented such schemes for my Go driver, but Go code is not really ideal to make a runtime loadable extension of (it'd have to be ported to C/Rust/zig).

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


Really depends on the application. WebAssembly can't use SIMD intrinsics and CPU-specific instructions besides simd128 and what the compiler can do.

At least for cryptography, WebAssembly can be very slow and can hardly provide any guarantee against side channels.


Well deserved. Congrats jbk!


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

Search: