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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 18 2022, Eric Sunshine wrote:

> On Tue, Oct 18, 2022 at 9:22 PM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> 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@xxxxxxxxx/
>> 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@xxxxxxxxxxxxxx/
> [2]: https://lore.kernel.org/git/CAMYxyaVQyVRQb-b0nVv412tMZ3rEnOfUPRakg2dEREg5_Ba5Ag@xxxxxxxxxxxxxx/T/
> [3]: https://lore.kernel.org/git/20160102234923.GA14424@xxxxxxxxx/
> [4]: https://lore.kernel.org/git/CAPig+cQ5kKAt2_RQnqT7Rn=uGmHV9VvxpQ+UgDPOj=D=pq6arg@xxxxxxxxxxxxxx/

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@xxxxxxxxxxxxxx/




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux