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
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
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.
c4ea3ca40a 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
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.
fd89e611b2 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
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
71f78fe45d.
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
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
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
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
