1. Code is largely if not entirely written by AI
2. Author is completely anonymous, using a dedicated GitHub and HN account for this specific project
Both of these are really bad for security-sensitive software.
1. Code is largely if not entirely written by AI
2. Author is completely anonymous, using a dedicated GitHub and HN account for this specific project
Both of these are really bad for security-sensitive software.
I hadn’t considered your second point, but even the authors GH account has an AI picture. I have no idea who this person is or what online/HN reputation they have.
I’m not anonymous, just cautious. I’m a solo builder, and this is a focused identity for the project. In fact, that's why I implemented full supply chain transparency from day one: signed releases, SLSA attestations, SBOMs, and Rekor logs. You don't need to trust me you can see the code for your self.
Ultimately, you're right — if you can't verify it, you shouldn't trust it.
That’s the whole point of the system: zero trust and verifiable cryptographic guarantees.
Appreciate the scrutiny
More importantly, this project is not "zero trust" and calling it such is borderline deceptive.
I can verify the artifacts you're shipping contain the code in the repo (or I could just clone the repo myself), but I cannot automatically verify that your code is non-malicious and free of bugs. That is what I am trusting when using your software, and I have serious doubts about the "free of bugs" part for AI generated software.
But maybe that’s just me.
The repo is public. The releases are signed. The attestations are published. Nothing hidden.
If that’s not enough — totally fair and I am sure many others would agree. Appreciate your point of view and taking time to give feedback.
That means:You can verify every artifact against its source code i.e I have not tampered with the code post deployment. for example part of the build is a dry-run on the worker build, this is stored as part of the build so you can see / confirm the exact code that was uploaded and this code is signed.
If I were to release something like this then people can see that 1) this is a guy with >20 years of various contributions to open source and he seems like a basically competent guy we can trust (as much as you can ever trust a single person), but also that 2) he's not a crypto guy and there may very well be oversights. Maybe there are none, but you know...
If someone like, say, Filippo Valsorda would release someone like this, then people could see that 1) is basically the same as me, and 2) he's also a well known crypto guy with a good track record. This is not a guarantee there are no oversights, but I would certainly be surprised if there were major ones. I would certainly trust that more than anything I would write.
The whole signing stuff is kind of a red herring IMO. I mean, it's not bad to have I guess, but honestly I don't really care. If anything, focusing to strongly on "box ticking security" so early on seems like the wrong thing to focus on.
CLI uses node.js built-in crypto module only -randomBytes - createDecipheriv - createCipheriv.
Web app uses Web Crypto API only.
I'll send Filippo a Postcard and see if he will review it :-P