Recent comments posted to this site:
If you're worried about lost+found containing non-annexed content, you can
copy (cp
) the files, rather than moving them (mv
). After adding the
files, git annex unused
will find any non-annexed ones that were added,
and they can then be removed.
This tip was written before git annex reinject --known
existed, but that
is also a good way to do it.
git annex add recovered-content
lost+found does not contain only annexed file, right? It may contain any kind of file not originally annexed.
Examples:
- a file that was imported in the regular git part of the git annex repository
- a corrupted variant of an annexed file
- a git pack, a git index or any git administrative file
- a file totally unrelated that happened to be on the same filesystem.
In all these cases, this command will result in new additions to the annex.
This is not what a recovery should do, is it?
Shouldn't that become rather something like:
git annex reinject --known
To clarify, this only prevents SHA1 collision attacks from causing problems with annexed files. Files checked into the git repository itself are still vulnerable to collision attacks.
It seems git-annex needs some way to verify that all blobs match its expected format for this security to be strong. My histories have tons of huge binary blobs in them from when I tried upgrading to v6 before it was stable and got a lot of data committed raw. I guess I need to rewrite my history to contain only verified blobs?
It's really too bad git hasn't upgraded to a newer hashing function by now. They should make a plan to do that at least once a decade.
@dvicory if someone only knows the onion service address, they can do
nothing to your repository except connect to it and get rejected
due to failure to authenticate. They need the authentication data too
in order to do any of those things. That was talking about the
addresses generated by git annex peer --gen-addresses
,
which include authentication data.
I've improved the wording to avoid confusion between git-annex's addresses and onion addresses.
In the security section, you say that
Anyone who learns the address of a peer can connect to that peer, download the whole history of the git repository, and any available annexed files. They can also upload new files to the peer, and even remove annexed files from the peer. So consider ways that the address of a peer might be exposed.
Do you mean the addresses from git annex peer --gen-addresses
here? Say, if someone has only my onion service address, and none of the authentication data that is normally placed in .git/annex/creds/
, what can they do with my git repository? I think I might be confused by the use of "address" because of onion addresses, which are not private.
Finally got around to playing with this today figured i'd post an example for anyone looking fr this in the future. Please forgive the TCL code if that isn't your thing.
- Adding the "cost command" to your remotes - Example here https://gist.github.com/zpeters/d288531db95aa69a495944a261d17b1c
- The actual script being referenced is really basic. It's basically taking the name of the remote as an argument and depending on where i am it will give that remote a "high" or "low" cost. Code here https://gist.github.com/zpeters/89ba09289c89225ae5344e65c3562e6c
- The cost script needs to know if I'm "home" or not. Here is an example of "whereami" https://gist.github.com/zpeters/cb8c2be53fd41b4d04a78fe81aaaea58
@Sundar, good question.
git annex enableremote
will always refuse to enable the remote if there's
a missing parameter, and prompt for the parameter. Finding the right value
is up to you. Most of the time, no additional parameters are needed, or
the parameters are fairly self-explanatory, eg login passwords for remote
services.
The difficulty with directory special remotes is that my /foo may not be the same as your /foo, so it can't reuse the directory= that was provided to initremote, and it's up to you to enter the right directory path.
I think this needs to come down to documentation in the repository. The
description of the remote (set by git annex describe
is a reasonable place to put that, unless you have somewhere better.