| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bugs with entry of gpg keyid in the keysafe.log. Gpg.anyKey was being
used in writing the log, which made the log contain gpg keys with an empty
keyid.
Fix bug in --autostart that caused the full gpg keyid to be
used in the name, so restores would only work when --gpgkeyid was
specifid.
Added a Distinguisher data type rather than the Gpg.anyKey hack.
This commit was sponsored by Thom May on Patreon.
|
| |
|
|
|
|
|
|
| |
offer to back them up.
Only ask once per key.
This commit was sponsored by Thomas Hochstein on Patreon.
|
| |
|
|
|
|
|
| |
Allow deserializing SecretKeySource so we can later know what gpg keys are
backed up.
Converted KeyId to Text as JSON can't handle ByteString.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The server has to run the hash once to verify a request, so a hash that
took 4 seconds could make the server do too much work if it's being flooded
with requests.
So, made the hash much less expensive.
This required keeping track of fractional seconds. Actually, I used
Rational for them, to avoid most rounding problems. That turned out nice.
I've only tuned the proofOfWorkHashTunable on my fanless overheating
laptop so far. It seems to be fairly reasonablly tuned though.
|
| | |
|
| |
|
|
| |
This way the requirement can be varied for different operations.
|
| |
|
|
|
| |
This changed the storage format, not that it matters because nobody is
using it yet.
|
| |
|
|
| |
This makes it clearer that it's not a chunk of data, but a Shamir share.
|
| |
|
|
|
|
| |
The keyid used as a salt in the shardIdents does not prevent rainbow table
attacks, since it's often anyKey (""). The obscure name combined with the
username does make rainbow tables unlikely to be useful though.
|
| | |
|
| | |
|
| |
|
|
| |
also, restore actually works!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This should be good enough to let the keysafe UI comment on
how good a password the user chooses.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Needed for efficient serialization of shares, unless upstream takes my
suggestion to make the finite field be size 256.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
