From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 207701F953 for ; Fri, 5 Nov 2021 12:06:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232878AbhKEMIo (ORCPT ); Fri, 5 Nov 2021 08:08:44 -0400 Received: from cloud.peff.net ([104.130.231.41]:53824 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232837AbhKEMIn (ORCPT ); Fri, 5 Nov 2021 08:08:43 -0400 Received: (qmail 11548 invoked by uid 109); 5 Nov 2021 12:06:03 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 05 Nov 2021 12:06:03 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 18073 invoked by uid 111); 5 Nov 2021 12:06:03 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Fri, 05 Nov 2021 08:06:03 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 5 Nov 2021 08:06:02 -0400 From: Jeff King To: Adam Dinwoodie Cc: Junio C Hamano , git@vger.kernel.org, Fabian Stelzer Subject: Re: [PATCH] t/lib-git.sh: fix ACL-related permissions failure Message-ID: References: <20211104192533.2520-1-adam@dinwoodie.org> <20211105112525.GA25887@dinwoodie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211105112525.GA25887@dinwoodie.org> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Nov 05, 2021 at 11:25:25AM +0000, Adam Dinwoodie wrote: > > ... 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. ;) > 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