passff VS kvass

Also, there's a firefox extension https://addons.mozilla.org/en-US/firefox/addon/passff/ (on github: https://github.com/passff/passff)

It requires the user to run a daemon that reads ~/.passwordstore passwords and feed it to the extension https://github.com/passff/passff-host - but the design is pretty transparent to inspection if you're inclined to check

The reason I currently use pass is that it has Firefox integration through PassFF: https://github.com/passff/passff

Hi mbreeze!

> this seems to just be a SQLite database with values in fields?

Sqlite is used as a storage format ("SQLite competes with fopen()"). The key-value pairs are stored as a modified Append-Only CRDT. The LUB-Operation (to merge to states while syncing) is implemented here: https://github.com/maxmunzel/kvass/blob/e32fdabdc86b039f716c...

> anyone with access to the file would be able to see all data stored?

Yes, attackers with access to your fs are not part of my attacker model. I rely on disk encryption for that matter.

> Do the clients cache data locally? It looks like you're basically syncing from the server for every request. You're already making a round trip to the server for a request anyway, so why not keep state only on the server? I can understand an offline-only mode, but this would require a significantly more robust sync mechanism. If this was the goal, I'd love to see this discussed more in the README too.

The sync mechanism is actually pretty solid, as its based on CRDTs. One of the applications of kvass is central management of config files, so automatic syncing and offline fallback are important.

> What is the purpose of the ProcessID?

The Counter Variable implements a rudimentary implementation of Lamport clocks. To get a total order from Lamport clocks, you need ordered, distinct process ids. The process id's don't really need to mean anything and the Lamport clock is itself just a fallback for the case that the wall-clock timestamps collide (see the Max() function), so it's practical to just draw them randomly.

> I didn't see any authn/authz in the requests. You're also unmarshalling random data from the request w/o confirming that it is valid first. This seems risky to me and could potentially crash the server if I were to send it random data.

Authentication is provided by the GCM mode of AES. As I decrypt (and thereby verify) early, I can assume to work on trustworthy payloads. GCM is also non-malleable unlike for example CBC or CTR.

As suggested by losfair, I'll switch to PSK TLS as soon as it's available or just put HTTPS in front of the end-points. But that's not high-priority right now.

Show HN: Kvass, a personal key-value store\ (51 comments)