b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
21 lines
1.1 KiB
Markdown
21 lines
1.1 KiB
Markdown
Combining git-annex with [Shamir secret sharing](http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
|
|
is an useful way to securely back up highly sensitive files,
|
|
such as a gpg key or bitcoin wallet.
|
|
|
|
Shamir secret sharing creates N shares of a file, of which any M can be
|
|
used to reconstitute the original file. Anyone who has less than M shares
|
|
cannot tell anything about the original file, other than its size.
|
|
|
|
Where git-annex comes in is as a way to manage these shares. They can be
|
|
added to the annex, and then git-annex used to move one share to each clone
|
|
of the repository. Since git-annex keeps track of where each file is
|
|
stored, this can aid later finding the shares again when they're needed, as
|
|
well as making ongoing management of the shares easier.
|
|
|
|
Note that this conveniece comes at a price: Any attacker who gets a copy
|
|
of the git repository can use it to figure out where the shares are
|
|
located. While this is not a crippling flaw, and can be worked around, it
|
|
needs to be considered when implementing this technique.
|
|
|
|
Here is an example of this method being used for a ~/.gnupg directory:
|
|
<http://git.kitenet.net/?p=gpg.git;a=blob;f=README.sss>
|