e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
47 lines
2 KiB
Markdown
47 lines
2 KiB
Markdown
git-annex users entrust it with data that is often intensively private.
|
|
Here's some things to know about how to maintain your privacy while using
|
|
git-annex.
|
|
|
|
## browsing this web site
|
|
|
|
This website supports https. [Use it.](https://git-annex.branchable.com/privacy/)
|
|
|
|
## repository contents
|
|
|
|
In general, anyone who can clone a git repository gets the ability to see
|
|
all current and past filenames in the repository, and their contents.
|
|
It's best to assume this also holds true for git-annex, as a general rule.
|
|
|
|
There are some obvious exceptions: If you `git annex dropunused` old
|
|
content from all your repositories, then it's *gone*. If you `git annex
|
|
move` files to a offline drive then only those with physical access can see
|
|
their content. (The names of the files are still visible to anyone with a
|
|
clone of the repository.)
|
|
|
|
git-annex can encrypt data stored in special remotes. This allows you to
|
|
store files in the cloud without exposing their file names, or their
|
|
contents. See [[design/encryption]] for details.
|
|
|
|
When using the shared encryption method, the encryption key gets stored
|
|
in git, and so anyone who has a clone of your repository can decrypt files
|
|
from the encrypted special remote.
|
|
|
|
When using encryption with a GPG key or keys, only those with access to the
|
|
GPG key can decrypt the content of files stored in an encrypted special
|
|
remote.
|
|
|
|
## bug reporting
|
|
|
|
When you file a [[bug|bugs]] report on git-annex, you may need to provide
|
|
debugging output or details about your repository. In general, git-annex
|
|
does not sanitize `--debug` output at all, so it may include the names of
|
|
files or other repository details. You should review any debug or other
|
|
output you post, and feel free to remove identifying information.
|
|
|
|
Note that the git-annex assistant *does* sanitize XMPP protocol information
|
|
logged when debugging is enabled.
|
|
|
|
If you prefer not to post information publicaly, you can send a GPG
|
|
encrypted mail to Joey Hess <id@joeyh.name> (gpg key ID 2512E3C7).
|
|
Or you can post a public bug report, and send a followup email with private
|
|
details.
|