Recent comments posted to this site:

@joern.mankiewicz, I see you found a bug and filed it, so will answer in the but report.

Barring bugs, adding another gpg key to a hybrid encryption special remote is as simple as git annex enableremote $theremote keyid+=$newkey

Comment by joey Fri Apr 7 16:52:59 2017

Setting remote.<name>.annex-readonly=true prevents git-annex sync from pushing changes to the remote. It also prevents any git-annex command from copying annexed file contents to the remote, or deleting annexed file contents. So I think it's ideal for this kind of situation.

There does seem to be room for configs to prevent sync from pulling/pushing without making the remote fully readonly. For example, the remote might be a source of content, that only knows about the files it added and not other files in the local repository, so dropping files from it should be allowed but not pushing to it.

So, I've added remote.<name>.annex-push and remote.<name>.annex-pull.

Comment by joey Wed Apr 5 16:11:57 2017

@anarcat, I'm not sure I follow how git-annex would use that. It does not currently use the tor control port at all when setting up its tor hidden service. But please file a todo item if I'm wrong and there's something to be improved.

(What would be useful is if tor came with the control port enabled by default, and perhaps protected by something like onion-grater. Then git-annex could use it when it installs its hidden service, instead of its current approach of prompting for the root password and modifying the torrc file.)

Comment by joey Wed Apr 5 15:47:55 2017

@oberix, the --autostart --foreground combination is only supported properly since git-annex version 6.20170214. Before that, the --forground was ignored when using --autostart.

Comment by joey Wed Apr 5 15:43:21 2017

you may want to consider using onion-grater to limit possible escalations in the use of that control port:

RFP: [[!debbug 859125]]

Comment by anarcat Thu Mar 30 14:49:12 2017

With systemd using --autostart --foreground either ignore foreground or quit immediatelly.

I managed to have the process stay alive with RemainAfterExit=on:

[Service]
User=%i
ExecStart=/usr/bin/git-annex assistant --autostart --foreground
ExecStop=/usr/bin/git-annex assistant --autostop
RemainAfterExit=on
Restart=on-failure
RestartSec=5

but git-annex processes does not maintain the --foreground option which is causing a lot of zombies in the long period (not totally clear why).

My current solution is to have a service for each annex repository and avoid --autosart but this is annoying because it require to pass the path as %I and wrap git-annex in bash script to get the repo owner as the user.

Comment by oberix Thu Mar 30 10:43:18 2017

Hi folks!

We are considering introducing git-annex with gcrypt in hybrid mode as secure storage for common data in our company and I'd rather not delete and reinit the repo everytime when somebody new is granted access. A little testing with current git-annex showed, that GCRYPT_FULL_REPACK with a forced git-push of all branches makes the git-repo accessible (I get the files) to the newcomer but not the annexed data (gpg error "No secret key" in git annex get, git annex info secretRepo just lists my first key).

Has anybody sucessfully tested adding keyids in hybrid-encryption later on? Which further steps where needed to make it work?

Thanks for any input! :)

Cheers

Jörn

Comment by joern.mankiewicz Tue Mar 21 22:08:30 2017

@joey - thanks, that's prompt feature request fulfilment :-)

Looking more closely at the duplicates, it turns out that not everything got duplicated, just the "older" episodes. It turns out the newer episodes do have guid values saved (as itemid in the metadata) and the older episodes do not. I think this is most likely because I was running a fairly old git-annex until about October 2016, on a fairly old OS install, but then upgraded to a more recent one (now about 6 months old) which does track them. My assumption (without checking every file) is the episodes downloaded before October 2016 are ones that got duplicated.

I've edited the main page and added a note that GUIDs are tracked in versions since 2015, since I didn't obviously find that listed anywhere before.

Ewen

Comment by ewen Tue Mar 21 21:46:27 2017

@rok it's a consequence of using smudge/clean filters; git add passes the file through the filters.

Comment by joey Tue Mar 21 17:43:33 2017

@ewen importfeed already tracks guids, since 2015. Relevant commit is [[!commit f95a8c867223b2e17d036d0d3377bf0fc9d3adff]]

You may well have an older version of git-annex that didn't do that. But there are probably also feeds that lack a useful guid, or that even make a change that changes the guid of an existing item.

With git annex metadata, you can see the itemid which is where the guid is stored.

PS, please post in todo when you have a request..

Comment by joey Tue Mar 21 17:28:27 2017