Re: [PATCH] t/lib-git.sh: fix ACL-related permissions failure

From: Jeff King <peff@peff.net>
Date: Nov 5, 2021, 12:06 UTC
Message-ID: <YYUeKt0xQm/6QT+w@coredump.intra.peff.net>
In-Reply-To: <20211105112525.GA25887@dinwoodie.org>

On Fri, Nov 05, 2021 at 11:25:25AM +0000, Adam Dinwoodie wrote:

Show 11 quoted lines

> > ... I am not quite sure how this explains "tests relating to ssh
> > signing failing on Cygwin".  After all, this piece of code is
> > lazy_prereq, which means that ssh-keygen in this block that fails
> > (due to a less restrictive permissions) would merely mean that tests
> > that are protected with GPGSSH prerequisite will be skipped without
> > causing test failures.  After all that is the whole point of
> > computing prereq on the fly.
> 
> The issue is that the prerequisite check isn't _just_ checking a
> prerequisite: it's also creating an SSH key that's used without further
> modification by the tests.

This is sort of a side note to your main issue, but I think that relying on a lazy_prereq for side effects is an anti-pattern. We make no promises about when or how often the prereqs might be run, and we try to insulate them from the main tests (by putting them in a subshell and switching their cwd).

It does happen to work here because the prereq script writes directly to $GNUPGHOME, and we run the lazy prereqs about when you'd expect. So I don't think it's really in any danger of breaking, but it is definitely not using the feature as it was intended. :)

I think the more usual way would be to have an actual test_expect_success block that creates the keys as a setup step (possibly triggered by a function, since it's included via lib-gpg.sh). If we don't want to decide whether we have the GPGSSH prereq until then, then that test can call test_set_prereq. See the LONG_REF case in t1401 for an example.

Again, that's mostly a tangent to your issue, and maybe not worth futzing with at this point in the release cycle. I'm mostly just registering my surprise. ;)

Show 15 quoted lines

> There are three cases to consider:
> 
> - On systems where this prerequisite check fails, a key may or may not
>   be created, but the tests that rely on the key won't be run, so it
>   doesn't matter either way.
> 
> - On (clearly the mainline) systems where this check passes and there
>   are no ACL problems, the key that's generated is stored with
>   sufficiently restrictive permissions that the tests that rely on the
>   key can pass.
> 
> - On my system, where ACLs are a problem, the prerequisite check passes,
>   and a key is created, but it has permissions that are too permissive.
>   As a result, when a test calls OpenSSH to use that key, OpenSSH
>   refuses due to the permissions, and the test fails.

FWIW, that explanation makes perfect sense to me (and your patch seems like the right thing to do).

-Peff