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
101 lines
4.3 KiB
Markdown
101 lines
4.3 KiB
Markdown
[[!toc]]
|
|
|
|
git-annex mostly does not use encryption. Anyone with access to a git
|
|
repository can see all the filenames in it, its history, and can access
|
|
any annexed file contents.
|
|
|
|
Encryption is needed when using [[special_remotes]] like Amazon S3, where
|
|
file content is sent to an untrusted party who does not have access to the
|
|
git repository.
|
|
|
|
Such an encrypted remote uses strong ([[symmetric|design/encryption]] or
|
|
asymmetric) encryption on the contents of files, as well as HMAC hashing
|
|
of the filenames. The size of the encrypted files, and access patterns
|
|
of the data, should be the only clues to what is stored in such a
|
|
remote.
|
|
|
|
You should decide whether to use encryption with a special remote before
|
|
any data is stored in it. So, `git annex initremote` requires you
|
|
to specify "encryption=none" when first setting up a remote in order
|
|
to disable encryption. To use encryption, you run
|
|
run `git-annex initremote` in one of these ways:
|
|
|
|
* `git annex initremote newremote type=... encryption=hybrid keyid=KEYID ...`
|
|
* `git annex initremote newremote type=... encryption=shared`
|
|
* `git annex initremote newremote type=... encryption=pubkey keyid=KEYID ...`
|
|
|
|
## hybrid encryption keys
|
|
|
|
The [[hybrid_key_design|design/encryption]] allows additional
|
|
encryption keys to be added on to a special remote later. Due to this
|
|
flexibility, it is the default and recommended encryption scheme.
|
|
|
|
git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID ...
|
|
|
|
Here the KEYID(s) are passed to `gpg` to find encryption keys.
|
|
Typically, you will say "keyid=2512E3C7" to use a specific gpg key.
|
|
Or, you might say "keyid=joey@kitenet.net" to search for matching keys.
|
|
|
|
To add a new key and allow it to access all the content that is stored
|
|
in the encrypted special remote, just run `git annex
|
|
enableremote` specifying the new encryption key:
|
|
|
|
git annex enableremote myremote keyid+=788A3F4C
|
|
|
|
While a key can later be removed from the list, note that
|
|
that will **not** necessarily prevent the owner of the key
|
|
from accessing data on the remote (which is by design impossible to prevent,
|
|
short of deleting the remote). In fact the only sound use of `keyid-=` is
|
|
probably to replace a revoked key:
|
|
|
|
git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
|
|
|
|
See also [[encryption_design|design/encryption]] for other security
|
|
risks associated with encryption.
|
|
|
|
## shared encryption key
|
|
|
|
Alternatively, you can configure git-annex to use a shared cipher to
|
|
encrypt data stored in a remote. This shared cipher is stored,
|
|
**unencrypted** in the git repository. So it's shared among every
|
|
clone of the git repository.
|
|
|
|
git annex initremote newremote type=... encryption=shared
|
|
|
|
The advantage is you don't need to set up gpg keys. The disadvantage is
|
|
that this is **insecure** unless you trust every clone of the git
|
|
repository with access to the encrypted data stored in the special remote.
|
|
|
|
## regular public key encryption
|
|
|
|
This alternative simply encrypts the files in the special remotes to one or
|
|
more public keys. It might be considered more secure due to its simplicity
|
|
and since it's exactly the way everyone else uses gpg.
|
|
|
|
git annex initremote newremote type=.... encryption=pubkey keyid=KEYID ...
|
|
|
|
A disavantage is that is not easy to later add additional public keys
|
|
to the special remote. While the `enableremote` parameters `keyid+=` and
|
|
`keyid-=` can be used, they have **no effect** on files that are already
|
|
present on the remote. Probably the only use for these parameters is
|
|
to replace a revoked key:
|
|
|
|
git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
|
|
|
|
But even in this case, since the files are not re-encrypted, the revoked
|
|
key has to be kept around to be able to decrypt those files.
|
|
(Of course, if the reason for revocation is
|
|
that the key has been compromised, it is **insecure** to leave files
|
|
encrypted using that old key, and the user should re-encrypt everything.)
|
|
|
|
(Because filenames are MAC'ed, a cipher still needs to be
|
|
generated (and encrypted to the given key IDs).)
|
|
|
|
## MAC algorithm
|
|
|
|
The default MAC algorithm to be applied on the filenames is HMACSHA1. A
|
|
stronger one, for instance HMACSHA512, one can be chosen upon creation
|
|
of the special remote with the option `mac=HMACSHA512`. The available
|
|
MAC algorithms are HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384, and
|
|
HMACSHA512. Note that it is not possible to change algorithm for a
|
|
non-empty remote.
|