Re: [PATCH v2 00/12] fsmonitor: Implement fsmonitor for Linux

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 19, 2022, 19:11 UTC
Message-ID: <221019.8635bjhbds.gmgdl@evledraar.gmail.com>
In-Reply-To: <CAPig+cRi8RVdmPbDdTzDCpXKjUsbOJNc5Pr+d02OQ9jENHUjfQ@mail.gmail.com>

On Tue, Oct 18 2022, Eric Sunshine wrote:

Show 28 quoted lines

> On Tue, Oct 18, 2022 at 9:22 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Tue, Oct 18 2022, Glen Choo wrote:
>> > I'm not too familiar with the CI, but I took a quick peek at ci/lib.sh
>> > and noticed that none of the jobs build with sha1dc, not even the Linux
>> > or Windows ones, so..
>>
>> All of our jobs except the OSX one build with SHA1_DC, because it's the
>> default.
>>
>> Per my just-sent
>> https://lore.kernel.org/git/cover-v2-0.4-00000000000-20221019T010222Z-avarab@gmail.com/
>> the blind spot has been lack fo SHA1_DC on OSX, for others it's the
>> reverse, we don't test e.g. BLK_SHA1.
>>
>> In practice we've been catching SHA-implementation specific code early
>> because the OSX implementation was different, but in this case it's
>> OSX-only code, so it only supported the Apple Common Crypto backend.
>
> I don't know how germane it is to the current thread, but previous
> discussions[1,2,3,4] favored dropping use of Apple's Common Crypto
> altogether since it doesn't seem to buy us much (or anything) and is
> incomplete; it doesn't support all of the OpenSSL API Git uses.
>
> [1]: https://lore.kernel.org/git/CAPig+cTfMx_kwUAxBRHp6kNSOtXsdsv=odUQSRYVpV21DnRuvA@mail.gmail.com/
> [2]: https://lore.kernel.org/git/CAMYxyaVQyVRQb-b0nVv412tMZ3rEnOfUPRakg2dEREg5_Ba5Ag@mail.gmail.com/T/
> [3]: https://lore.kernel.org/git/20160102234923.GA14424@gmail.com/
> [4]: https://lore.kernel.org/git/CAPig+cQ5kKAt2_RQnqT7Rn=uGmHV9VvxpQ+UgDPOj=D=pq6arg@mail.gmail.com/

Yeah, maybe. I'd be 100% OK with that happening, but I don't use OSX outside fo CI really, so I wanted to avoid scope creep to "non-SHA stuff we use OpenSSL/AppleCommonCrypto/whatever" for, in the cases where we can/do use OpenSSL/AppleCommonCrypto/whatever for SHA also.

I.e. that's basically a question about what https://, git-imap-send etc. should be using if not vanilla OpenSSL & the like.

But if you/someone can come up with a patch that confidently asserts that it's useless & drops it I'd be happy to either integrate it & submit it as part of this series if it makes things simpler, or alternatively re-roll on top of it.

I'm just not confident in making that case myself, since I hardly use the platform, am not too familiar with the various concerns (aside from skimming the links above), and don't really have interest in pursuing that.

OTOH if you do want to make the case for dropping Apple Common Crypto that would also presumably be much easier after this series, once we're past justifying the hurdle of "wait, we're switching the thing we use for SHA-1 by default, which we build practically everything in git on?" :)

1. https://lore.kernel.org/git/CAPig+cQ5kKAt2_RQnqT7Rn=uGmHV9VvxpQ+UgDPOj=D=pq6arg@mail.gmail.com/