Made all uses of openFd and dup set the close-on-exec flag, with a few
exceptions when starting a git-annex daemon.
Made openFdWithMode be used everywhere, rather than openFd.
Adding a new parameter to it ensures I checked everything.
And will help to make sure this gets considered in the future when
opening fds.
In lockPidFile, the only thing that keeps the pid file locked, once
daemonize re-runs the command in a new session, is that the fd is
inherited.
In Utility.LogFile.redir, the new fd it dups to does not have the
close-on-exec flag set, because this is used to set up the stdout and
stderr fds, which need to be inherited by child processes.
Same in Assistant.startDaemon where the browser gets started with the
original stdout and stderr.
This does nothing about uses of openFile and similar!
avoid overhead of fcntl when setting close-on-exec
unix-2.8.0 adds cloexec to OpenFileFlags, rather than needing to call
setFdOption after opening.
This also might avoid a race, if another thread started a process at
just the wrong time, before the flag got set, it could inherit the FD.
Unfortunately, the arm64-ancient build needs support for older versions
of unix than that, so had to ifdef. That build is still needed to
support using git-annex in termux on phones like mine, I have confirmed
today.
add: Fix crash adding filenames that are exactly 21 bytes long and begin
with a utf-8 character.
Also longer filenames that start with "....." would cause the same crash.
I also audited for other calls to truncateFilePath that could truncate it
to "". Most use pathmax so are not a problem. Backend.Utilities.genKeyName
could possibly truncate it like that, but appends the md5 so would not be a
problem either.
Joey Hess [Fri, 29 Aug 2025 16:45:33 +0000 (12:45 -0400)]
drop: --fast support when dropping from a remote
This is the same as --not --in $remote, but easier to type. And the
documentation of --fast helps also document that drop can do extra work
when used without --fast.
Joey Hess [Fri, 22 Aug 2025 17:35:33 +0000 (13:35 -0400)]
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.
Joey Hess [Fri, 22 Aug 2025 17:14:02 +0000 (13:14 -0400)]
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.
Joey Hess [Fri, 22 Aug 2025 16:54:43 +0000 (12:54 -0400)]
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.
Joey Hess [Thu, 21 Aug 2025 17:41:00 +0000 (13:41 -0400)]
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.
Joey Hess [Thu, 21 Aug 2025 15:20:20 +0000 (11:20 -0400)]
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.
Joey Hess [Thu, 21 Aug 2025 15:04:26 +0000 (11:04 -0400)]
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.
Joey Hess [Wed, 20 Aug 2025 19:14:01 +0000 (15:14 -0400)]
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.
Joey Hess [Thu, 14 Aug 2025 15:05:42 +0000 (11:05 -0400)]
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.
Joey Hess [Wed, 13 Aug 2025 19:21:22 +0000 (15:21 -0400)]
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.
Joey Hess [Wed, 13 Aug 2025 18:19:36 +0000 (14:19 -0400)]
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.
Joey Hess [Wed, 13 Aug 2025 17:18:35 +0000 (13:18 -0400)]
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).
projects / git-annex.git / log