Recent comments posted to this site:
git-annex builds with stack have used tls-2.0.x since August. I think many other builds are still using older tls from before this change, eg Debian is still on tls-1.8.0.
So it's possible that more outdated servers will be causing problems as things continue to upgrade. It seems worth leaving this bug open for now.
Also it seems pretty clear that TLS 1.2 without EMS is insecure, but I don't know if the insecurity is of a kind that is likely to affect git-annex users. Bearing in mind that git-annex can be used to upload sensitive information to HTTP servers, caution is warrented.
Decrypting files in special remotes without git-annex has an
example using openssl dgst -sha1 -hmac
Here is what I get while cloning:
joey@darkstar:/tmp>git clone localhost:/tmp/manrepo xx
Cloning into 'xx'...
fatal: detected dubious ownership in repository at '/tmp/manrepo/.git'
To add an exception for this directory, call:
git config --global --add safe.directory /tmp/manrepo/.git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
This is with git 2.45.2, and since current git prevents cloning a repository in this situation, git-annex doesn't need to do anything.
I also tested what happens if the repository ownership allows cloning, but
after clonging and before git-annex init, the repository owner changes. In
that case, with current git-annex, git-annex-shell configlist
is able to
get the uuid from the remote repository despite the ownership snafu. Which is
ok.
git annex initremote icg1220-remote-dir type=rclone encryption=none rcloneremotename=':sftp,host=icg1220' rcloneprefix=remote-dir
. It just prints some log messages from rclone that it can't save config settings for this on the fly backend, but those seem to be purely informational.
Rclone has something called "connection strings" (https://rclone.org/docs/#connection-strings), which can make a separate rclone configuration unnecessary. E.g. you can use rclone ls :sftp,host=hostname:path/to/dir
to ls
a sftp remote without first setting it up in the config.
It might be possible to set such a connection string as the remote name in the special remote to avoid a separate rclone config, but I haven't actually tried it out.
The name of the cluster ends up in git-annex:proxy.log. So probably the
easiest thing to do is to git-annex initcluster
a new cluster with the new name,
change the git configs remote.foo.annex-cluster-node to be set to the new
name, and run git-annex updatecluster
.
That will remove all the nodes from the old cluster name and add them to the new cluster name, and without any nodes left the old cluster name will never be displayed anywhere.
importtree=yes remotes are always untrusted. The reason is that something else is assumed to be writing to those remotes, which is what populates them with files. And that could delete or change any file at any time. So if git-annex didn't untrust the remote, and relied on it to hold the only copy of a file, such a change would cause data loss.
There would need to be a new config setting to add the concept of guaranteed readonly importtree=yes remotes.
git-annex does not allow --numcopies to be set to 0 as that can cause data loss.
Reproducible here. Also this does break getting files from encrypted special remotes, not just the test suite.
The file is mode 444, which is a permission git-annex sets. Then git-annex opens it for write. Oops..
Bisected to 835283b86240ef4b68c44f4332ac1b644e08e49f.
Fixed.