add news item for git-annex 10.20250828

releasing package git-annex version 10.20250828

comments

Merge branch 'master' of ssh://git-annex.branchable.com

todo

initial report from ducky

prep release

remove dead code

remove para about conflicts

That was only ever relevant for the v1 upgrade!

reword

fix test suite breakage

640bc43c38e37f0acbc5d83d072af82e4e8cc5fa broke a test. Change that test
to not use encryption=shared. Which required some refactoring.

Sponsored-by: Joshua Antonishen

Merge branch 'master' of ssh://git-annex.branchable.com

improve docs of annex.youtube-dl-options

The options are used whenever yt-dlp is run, not only when finding the
url to download.

remove youtube-dl support, always use yt-dlp

The annex.youtube-dl-command git config is no longer used, git-annex always
runs the yt-dlp command, rather than the old youtube-dl command.

Sponsored-by: Leon Schuermann

Improved error message when yt-dlp is not installed and is needed to get a file from the web

issue resolved

report on failing test

Added a comment: Wrong place to post

Added a comment

Added a comment

Added a comment

initial report on copy to be stuck

Added a comment: Feedback on encryptonlycreds=yes

Added a comment: Download with the git-annex-install script fail

Added a comment

reject an insecure configuration

A user might expect onlyencryptcreds=yes to do some useful encryption of
the creds despite using encryption=shared. Prevent them from thinking
they have somehow secured the creds in their repository in that case.

Also reject onlyencryptcreds=yes encryption=none in case the user
somehow thinks there is creds-only encryption going on in that case.

Sponsored-by: Graham Spencer

fix specialRemote confusion with tahoe

tahoe: Fix bug that made initremote require an encryption= parameter,
despite git-annex encryption not being used with this special remote,
since tahoe handles encryption itself.

The chunking parameters were also accepted and won't be any longer either.
They were also not actually used.

c4ea3ca40ae6ba973287ca94e892e93973a8376e was the commit. At that point
specialRemote was being added to most remotes and I forgot tahoe doesn't
need these parameters.

Turns out that, when embedcreds=yes was used, it did *not* cause the
introducer-furl and shared-convergence-secret to be encrypted, even
though encryption= was specified. Which is only not a security hole
because encryption= was not documented to work with the tahoe special
remote at all!

It might be nice to support onlyencryptcreds=yes with tahoe, and it
would make sense to accept the encryption= parameter then, and only use
it for encrypting the creds. That would take some work, since the
encryption= parameter would need to be optional, and the usual encrypted
special remote code couldn't be used.

Sponsored-by: unqueued

don't refer to tahoe daemon

since tahoe no longer supports daemonization

error message typo

fix disrectory name

showOutput

tahoe store and retrieve both output messages which cannot be shut up with
--quiet. The messages go to stderr, which makes it hard to avoid
displaying them without hiding problems. This kinda sucks.

Using showOutput helps with output formatting, but with -J this output
is still scrambled in with the progress output.

tahoe: Support tahoe-lafs command versions newer than 1.16

tahoe start was deprecated and removed in 2020.

This feels like a very janky way to run a daemon, but it does work.

Sponsored-by: k0ld

comment

reorder

update test suite for change

fd89e611b2310b46368c91bcd79999b0ba8462a3 changed the exit code of
git-annex sync which broke the test suite

I'm actually a bit surprised that this test's export works after the
sync fails. huh

add test case for enableremote changing encryption

As fixed in 6b63fb7ea29f39b0fe7632dae6951c589115ee37

Sponsored-by: Brock Spratlen

prevent changing onlyencryptcreds of existing remote

That would break accessing data already stored in the remote, the same
as changing encryption type would do.

Sponsored-by: Jack Hill

Don't allow the type of encryption of an existing special remote to be changed.

eg, git-annex enableremote foo encryption=none will not remove encryption,
and other encryption= settings don't change the type of encryption used.
Either of which would render data stored in a special remote inaccessible.

Probably fixes reversion introduced in
71f78fe45dc91dbef0bedd79b33d6a9fed85704d.
That commit got rid of the hasEncryptionConfig check, which I think would
have detected this before. I've not gone back to verify that.

Sponsored-by: mycroft

Removed support for git versions older than 2.22.

Which fixed an OOM with unlocked files.

Debian oldoldstable is the oldest version of git that git-annex needs to
support, since it's used in the amd64ancient build. That has 2.30.

At this point, the only complication git-annex for an bug in old
versions of git is that git bundle was broken before git 2.31.
That prevents git-remote-annex from working with git 2.30.

Sponsored-by: Luke T. Shumaker

cleanup too long line

remove git version check for adjusted branch

2686d2d7ea44d9b5d8243da6fc9f2df1d2441a71 made git older than 2.5 not be
supported, so this check for an older version is not longer needed.

Sponsored-by: Kevin Mueller

Removed support for git versions older than 2.5.

This entirely removes Git.BuildVersion, which avoids the possibility that
git-annex will behave differently based on the version of git it was built
with, rather than the version it's used with.

Debian oldoldstable is the oldest version of git that git-annex needs to
support, since it's used in the amd64ancient build.

cabal configure will fail if the git version is too old.

Sponsored-by: Nicholas Golder-Manning

onlyencryptcreds=yes

initremote: When onlyencryptcreds=yes is used along with embedcreds=yes,
and encryption is enabled, only encrypt the embedded creds, without
encrypting the content of the special remote.

Useful for exporttree=yes/importtree=yes remotes.

Sponsored-by: Joshua Antonishen

bug

bug

remove now unused parameters

comment

fixed

improve error when unable to reverse adjust merge

Give the user a hint about what to do, as well as what they should have
done to avoid the problem.

error out when another branch has been manually merged into the adjusted branch

This avoids losing the merge commit when re-running git-annex adjust in the
adjusted branch.

It also makes git-annex sync error out, rather than displaying a warning
and exiting successfully.

Sponsored-by: Leon Schuermann on Patreon

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: Reproduce Issue

Added a comment: encryption=credsonly

bug

update

warn and refuse to autoenable a special remote when name is in use

Improve behavior when there are special remotes configured with
autoenable=yes with names that conflict with other remotes.

The use of remoteList' is to avoid using the cached remote list in the case
where there are two special remotes both configured to autoenable and both
with the same name. Once the 1st is autoenabled, this makes reload the
remote list and so see the 1st, and so refuse to autoenable the second.

This adds a little bit of overhead, but it should be sufficiently small not
to need optimising.

Sponsored-by: Dartmouth College's OpenNeuro project

followup

close

simplify

info: Added --show option

To pick which parts of the info to calculate and display.

Sponsored-by: Dartmouth College's DANDI project

comment

Merge branch 'master' of ssh://git-annex.branchable.com

close

Bump aws build dependency to 0.24.1

That's the version in Debian stable now. And this removes a lot of ifdefs.

Also I'm pretty sure a recent commit broke building with older versions of
aws, although that could be fixed with sufficent testing.

probe AWS datacenter

S3: When initremote is given the name of a bucket that already exists,
automatically set datacenter to the right value, rather than needing it to
be explicitly set.

This needs aws-0.23. But, initremote stores the datacenter value, so
a remote set up this way can be used with git-annex built with an older aws.

This is not done when signature=anonymous, because in that case,
using AWS.defaultRegion works fine for accessing buckets on other
datacenters.

It feels a bit round-about to need to do this probing. But without it,
the problem seems to be that, with a v4 signature, the location constraint
is included in the Authorization header. When that is the wrong location,
AWS S3 rejects it. I do wonder though if there is an easier way that I
am currently missing.

Sponsored-by: Dartmouth College's DANDI project

fix default region reversion

Commit 215640096f6a3469c119d50373f3035cf19fe130 caused the default
region for S3 to change to us-east-2. This was due to regionInfo having
an undocumented property that the first item in the list is for the
default region.

Avoid relying on regionInfo for defaultRegion.

Sponsored-by: Dartmouth College's DANDI project

wishlist of faster/specific info for a remote

S3: Default to signature=v4 when using an AWS endpoint

* S3: Default to signature=v4 when using an AWS endpoint, since some
  AWS regions need v4 and all support it. When host= is used to specify
  a different S3 host, the default remains signature=v2.
* webapp: Support setting up S3 buckets in regions that need v4
  signatures.

For the webapp, went ahead and added all current S3 regions
(except govcloud, which  is not usable by everyone).

Sponsored-by: Dartmouth College's DANDI project

document "anonymous" in ValueDesc

comment

Merge branch 'master' of ssh://git-annex.branchable.com

add https://pypi.org/project/git-annex-remote-internxt/

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: repodata is empty again :(

stack.yaml: Update to lts-24.2.

Add YouTube link

Updated the S3-special-remote example and prose based on recent B2 experience

comment

reword

link to new page

add section on security

inline didn't work due to extension

layout

add example git-annex-p2p-unix-sockets program and end-user docs

improve AuthToken display in P2P --debug

Using an empty string to obscure the AuthToken made it impossible to
tell if one was really being presented or not.

Merge branch 'master' into genericp2p

Merge branch 'master' of ssh://git-annex.branchable.com

update design doc with changes from genericp2p branch

That branch is basically ready to merge, but needs more testing in a
chicken and egg situation.

Added a comment

avoid broken pipe zombies

hClose crashes if the pipe is broken, preventing waiting for the process

remotedaemon support for generic P2P transports

RemoteDaemon.Transport.Tor was refactored into this, and most of the
code is reused between them.

getSocketFile does not yet deal with repositories on crippled
filesystems that don't support sockets. Annex.Ssh detects that and
allows the user to set an environment variable, and something similar
could be done here.

And it does not deal with a situation where there is no path to the
socket file that is not too long. In that situation it would crash out
I suppose. Probably though, remotedaemon is ran from the top of the
repo, and in that case the path is just ".git/annex/p2p/<md5>" so nice
and short.

This seems to mostly work. But I don't yet have a working git-annex-p2p-
command to test it with.

And with my not quite working git-annex-p2p-foo test script, running
remotedaemon results in an ever-growing number of zombie processes
that it's not waiting on.

changed design for p2p generic socket

Having the git-annex-p2p-<netname> command output the socket filename
left git-annex scrambling to listen to it in order to not miss incoming
connections. And if the command uses something like socat UNIX-CONNECT,
that expects the socket to be accepting connections and errors out when
it's not, that would be a problem.

Rather than complicating the protocol with git-annex needing to send
back a message when it's listening to the socket, simplified it by
having git-annex provide the socket path to the command.

This does mean that, if a P2P network has its own place it expects to
find a socket file, the git-annex-p2p-<netname> command would need to
somehow arrange for it to use the git-annex socket path. A symlink would
be one way to handle that situation.

Add yann's TdF talk about life in git annex

add git-remote-p2p-annex

Added git-remote-p2p-annex, which allows git pull and push to P2P networks
provided by external commands.

This is a refactor of git-remote-tor-annex, and should just work. Except
possibly for quirks with the address parsing. I've checked that the address
parsing basically works.

One thing I don't understand is why git-remote-tor-annex removes "/*" from
the end of the address. The git history does not provide any hints. So I
didn't make git-remote-p2p-annex do the same. Maybe that is needed in some
situation? But, a P2P address could contain "/", so removing it would be a
problem. I can't see anything in gitremote-helpers(7) about why the url
might get such a thing added to the end of it. My guess is that is not
needed for tor either (but does no harm there since onion addresses never
contain "/").

At this point, the implementation of generic P2P transports needs only
remotedaemon support.

use Annex.ExternalAddonProcess for P2P.Generic processes

These are another sort of external addon process, and this makes several
things work including shell scripts on windows. And it makes for nicer
error messages when the command is not in the path.

Note that the refactored startExternalAddonProcess used by this
does not use propGitEnv to set git environment variables in the
environment. Unlike startExternalAddonProcessProtocol which does.
This is because it runs in IO and does not have access to that
information. But also, I don't think that P2P.Generic processes need
that.

p2p --enable

p2p: Added --enable option, which can be used to enable P2P networks
provided by external commands git-annex-p2p-<netname>

Made git-annex p2p --enable tor behave the same as git-annex enable-tor,
to make tor a bit less of a special case. However, it canot be run as root,
since it cannot take the user id parameter.

support P2PAnnex in connectPeer

This is probably enough to support accessing remotes using p2p-annex:: urls.
Not tested yet of course since there is not yet support for serving the
other side of such a connection, or for setting up such a connection.

P2P.Generic has an implementation of the whole interface to the
git-annex-p2p-<netname> commands.