11–20 of 78 posts
Limiting values to 255 bytes is quite constraining, to say the least.
Also, it seems that there are no transactions in kivaloo. That makes a big difference.
Earlier quoted context omitted.
Especially since the user is expected to download the client for the service from that website. You mean the GPG-signed client code?
Well yeah but the GPG key is also served insecurely: http://www.tarsnap.com/tarsnap-signing-key-2020.asc
Slighlty offtopic, but it's ironic how a service with the tagline "Online backups for the truly paranoid" serves insecure connections to its website and doesn't employ HSTS. Especially since the user is expected to download the client for the service from that website. Kind of a reckless decision.
Especially since the user is expected to download the client for the service from that website. You mean the GPG-signed client code?
Considering there's no disadvantage in deploying HSTS and there's no good reason to serve an insecure website, especially since they already have HTTPS set up, I'm baffled by that decision. Maybe it's just an oversight but that's not too reassuring either.
I would be curious how this compares to LMDB. They both use B+Trees (which are just B-trees with siblings linked). Limiting values to 255 bytes is quite constraining, to say the least. Also, it seems that there are no transactions in kivaloo. That makes a big difference.
And sure, small values and a lack of transactions are intentional limitations which allowed me to improve performance for the use case I cared about. Of course there's nothing stopping you from constructing that functionality in other ways; in fact I'm planning on releasing a daemon which provides key-blob storage by storing large objects in Amazon S3 and using the core kivaloo functionality as an indirection table.
I would be curious how this compares to LMDB. They both use B+Trees (which are just B-trees with siblings linked). Limiting values to 255 bytes is quite constraining, to say the least. Also, it seems that there are no transactions in kivaloo. That makes a big difference.
Earlier quoted context omitted.
Especially since the user is expected to download the client for the service from that website. You mean the GPG-signed client code?
Well, if the user actually checks the signatures and remembers from their last visit that their should be one coming along with the software, maybe. That's a big if though. Considering there's no disadvantage in deploying HSTS and there's no good reason to serve an insecure website, especially since they already have HTTPS set up, I'm baffled by that decision. Maybe it's just an oversight but that's not too reassurin…
HTTPS+HSTS adds no security here.
The only (reasonable) way to validate a payload end-to-end is an offline signature validation. This is true regardless of transport-level security measures like HTTPS.
Doing this properly with gpg makes even more sense due to the service targeting the paranoid, who is exactly the group of individuals who are certain to validate a signature.
> Considering there's no disadvantage in deploying HSTS and there's no good reason to serve an insecure website, especially since they already have HTTPS set up, I'm baffled by that decision. Maybe it's just an oversight but that's not too reassuring either.
It's easy, but adds nothing in ways of security here. Just privacy.
(Not that privacy does not have value, of course, but that's an entirely different argument.)
Interesting that the author is here commenting as well on a 9 year old project.
Earlier quoted context omitted.
Well, if the user actually checks the signatures and remembers from their last visit that their should be one coming along with the software, maybe. That's a big if though. Considering there's no disadvantage in deploying HSTS and there's no good reason to serve an insecure website, especially since they already have HTTPS set up, I'm baffled by that decision. Maybe it's just an oversight but that's not too reassurin…
> Well, if the user actually checks the signatures and remembers from their last visit that their should be one coming along with the software, maybe. That's a big if though. HTTPS+HSTS adds no security here. The only (reasonable) way to validate a payload end-to-end is an offline signature validation. This is true regardless of transport-level security measures like HTTPS. Doing this properly with gpg makes even mor…
Last release 2011-10-11? Interesting that the author is here commenting as well on a 9 year old project.