| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updated many dependencies, notably secret-sharing which dropped the dep on
polynomial, and so allows building with ghc 8.x.
Did not try to support building with older ghc because the semigroup-monid
transition would make it nontrivial.
Stackage lts-14.25 is a compromise, since the stack shipped in debian (even
unstable) is not able to handle newer ones.
This commit was sponsored by Eric Drechsel on Patreon.
|
|
|
|
|
|
|
|
| |
on it yet.
Threw an exception because the share directory was not created yet.
This commit was sponsored by Anthony DeRobertis on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If run with --totalshares larger than the number of servers, and the
--store-local directory is not writable, this causes keysafe to throw out
the unwritable directory and so error out early due to their not being
enough storage locations.
That's better than the old behavior, which was to try to use the
--store-local directory, fail and so proceed to storing the share on a
server. That would eventually fail with "no storage locations" when it runs
out of servers. That was bad, because shares were uploaded to servers, but
perhaps not enough for restore to work, and a new name/othername would be
needed to re-run the backup.
This is not a perfect fix; if the --store-local directory is writable at
first but for some reason the write of the share to it later fails, the
situation described above still happens.
This commit was sponsored by Jochen Bartl on Patreon.
|
|
|
|
|
|
|
|
| |
* New --add-storage-directory and --add-server options, which can be used
to make keysafe backup/restore using additional locations.
* Removed --store-local option; use --add-storage-directory instead.
This commit was sponsored by Thomas Hochstein on Patreon.
|
|
|
|
|
|
|
| |
This allows local storage locations to have levels too, and also get
shuffled nicely.
This commit was sponsored by Ethan Aubin.
|
| |
|
|
|
|
|
| |
This is worth doing to support falling back to HOME on systems using LDAP
or NIS where getpwent fails.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the server list to contain 3 servers although only 1 is running
so far; uploads to the others will be queued.
It also allows a server to be spread amoung multiple addresses, which may
be useful later for scaling.
This changes BackupRecord serialization, but it's not been in a keysafe
release yet, so that's not a problem.
This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
|
|
|
|
|
|
| |
To aid in backing up keysafe servers with minimal information leakage.
This commit was sponsored by Andrea Rota.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
In this case, an empty string is hashed to generate the PoW.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mashed up a argon2-based PoW with token buckets and bloom filters.
This is intended to prevent a few abuses including:
* Using a keysafe server for general file storage, by storing a whole
lot of chunks.
* An attacker guessing names that people will use, and uploading junk
to keysafe servers under those names, to make it harder for others to use
keysafe later.
* An attacker trying to guess the names used for objects on keysafe
servers in order to download them and start password cracking.
(As a second level of defense, since the name generation hash
is expensive already.)
Completely untested, but it builds!
This commit was sponsored by Andreas on Patreon.
|
| |
|
|
|
|
| |
controlling terminal and zenity was not installed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This does not seem to be necessary for the HTTP server, because servant
parses the StorableObjectIdent out of query path, so it can't contain `/`.
But, what if the HTTP server were running on windows? Then, `\` could be
embedded in the StorableObjectIdent or perhaps a drive letter, etc. So,
best to have a second level of defense against path injection.
|
|
|
|
| |
At this point, storage and retrival to servers basically works!
|
| |
|
| |
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
avoids short reads, and also if a backup program came along while the write
was happening, avoids short backups
|
| |
|
| |
|
|
|