| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
This can be deleted by the user at any time, but it's useful in case a
server is known to be compromised, or a problem is found with keysafe's
implementation that makes a backup insecure.
This commit was sponsored by Nick Daly on Patreon.
|
|
|
|
|
|
|
|
| |
This is useful both to test the server throttling of uploads, and to make
it harder for servers to know if an object actually contains secret key
information.
This commit was sponsored by Brock Spratlen on Patreon.
|
| |
|
| |
|
|
|
|
| |
keysafe does not run as root, so the normal ext2 disk reserve will do
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This way, the tor hidden service using it will be the only way it's
exposed.
|
| |
|
| |
|
|
|
|
|
| |
This seems to install, but stack is not copying it out to the home
directory. Hmm.
|
|
|
|
| |
This makes it clearer that it's not a chunk of data, but a Shamir share.
|
|
|
|
|
|
|
|
|
|
|
| |
There needs to be a 1:1 mapping between upload queues and servers,
otherwise using the upload queue risks two shards for the same object
being uploaded to the same server.
Also, fixed storeShards to give up on StoreAlreadyExists, rather than
trying another storage location. Otherwise, on a name collision,
the shards would be rejected by the servers, and be stored to their upload
queues.
|
|
|
|
| |
also, server upload queues in ~/.keysafe
|
|
|
|
|
| |
User has to remember they did this and use the same configuration on
restore.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|