On 24/01/2026 19:31, ASSI via Cygwin-apps wrote:
Jon Turney via Cygwin-apps writes:
If a mirror has setup.zst but no setup.zst.sig, setup immediately stops
with an error.
This caused a few reports recently, when exactly that situation occured
(presumbly due to the precise timing of the mirror update).
Does that happen with specific mirrors only? I've never seen anything
like that.
It's very rare, but I can recall it happening one or two times.
But in this particular instance it was mirrors.kernel.org which had the
inconsistent state, which caused some github-based CI to fail, so I
heard about it...
This can't be simply fixed by by making the update of those files on
sourceware locally atomic in calm, because a remote rsync fetches each
file at a different point in time.
Not only that, it will commit them to visible state at the remote end
at different times as well.
(Even if we do the crazy, but apparently wanted dance of (i) remove
setup.zst, (ii) make setup.zst elsewhere, (iii) move setup.zst.sig into
place, (iv) move setup.zst into place, we still have the possibility of
a mirror ending up with mismatched file and signature, which is
still immediately fatal)
Being atomic on sourceware doesn't solve the problem on the receiving
site. We are in a bit of a pickle due to the fact that the "release"
directory is contained at the same level as the setup.ini files. I
Yeah, it would be a lot nicer to have these files in a 'manifest'
directory at the same level as (parallel to) 'release', or something...
think it should be possible to use LVM snapshots and/or bind mounts (for
the release directory) to get around that and have only the stable state
exposed at any time. Using bind mounts assumes that we can use the exch
command to atomically swap the two directories after each update is
complete. Each rsync mirror transfer must never see the swap, so it'll
probably need to trigger an LVM snapshot at the start of the transfer.
That still has the possibility of briefly having an incomplete set of
files at the remote end, but at least one won't need to wait for the
next sync to resolve.
>> ini.cc | 4 ++-->> 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ini.cc b/ini.cc
index 006d710..371d267 100644
--- a/ini.cc
+++ b/ini.cc
@@ -242,8 +242,8 @@ do_remote_ini (Feedback &myFeedback)
ini_file = get_url_to_membuf (current_ini_name, myFeedback);
ini_file = check_ini_sig (ini_file, ini_sig_file, sig_fail,
n->url.c_str (), current_ini_sig_name.c_str
(), myFeedback);
- // stop searching as soon as we find a setup file
- if (ini_file)
+ // stop searching as soon as we find a ini file with a valid signature
+ if (ini_file && !sig_fail)
break;
}
if (ini_file)
LGTM. It may or may not solve the problem depending on which race was
lost, but let's see.
Thanks for taking a look.
All things considered, the better route would be to embed a signature
into the setup.ini (and keep the detached signature on the resulting
file for backwards compatibility). So something like that perhaps:
Yes, that would be ideal.
It would probably be nice if the signature could be generated and
validated with standard tools, which perhaps means using 'gpg --clearsign'.
(which probably breaks anything else reading the existing .ini files, so
we'd still need to keep that around for backwards compatibility)
Unfortunately, whatever approach is taken, this is all much harder work
than it should be, because we don't use libgpgme, but lots of low-level
grovelling around with libgpg instead.
(It's my understanding that we can't (or couldn't) use gpgme, because
that relies on invoking a copy of gpg via a pipe, which is obviously no
good for a stand-alone installer)
