RE: [PATCH v2 6/6] version: introduce osversion.command config for os-version output

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

 



On January 17, 2025 5:34 PM, Junio C Hamano wrote:
>Usman Akinyemi <usmanakinyemi202@xxxxxxxxx> writes:
>
>> Let's introduce a new configuration option, `osversion.command`, to
>> handle the string exchange between servers and clients. This option
>> allows customization of the exchanged string by leveraging the output
>> of the specified command. This customization might be especially
>> useful on some quite uncommon platforms like NonStop where interesting
>> OS information is available from other means than uname(2).
>
>After reading the above rationale, I doubt the usefulness of this feature
even more.
>
>Shouldn't that kind of anomalies be handled by compat/ layer to make their
>uname(2) emulated, or allow get_uname_info() to be customized at compile
time
>by platform implementations, to yield more useful pieces of information
instead?
>
>That way, we do not need to add another mechanism that lets people spawn an
>arbitrary command while Git is running, we do not need to worry about
security
>implications, and we do not need to worry about people abusing the facility
to
>throw totally random and useless garbage information at the other end to
make
>their stats useless.
>
>I'll skip the overly wide documentation changes.
>
>> diff --git a/Documentation/config/transfer.txt
>> b/Documentation/config/transfer.txt
>> ...
>> diff --git a/Documentation/gitprotocol-v2.txt
>> b/Documentation/gitprotocol-v2.txt
>> ...
>
>> +test_expect_success 'test capability advertisement with
osVersion.command
>config set' '
>> +	test_config osVersion.command "uname -srvm" &&
>
>If osversion.command configuration variable turns out to be acceptable
addition, I
>do not think we want to use "uname -srvm" as its value for its test.  Do
you know
>for sure how portable srvm is?
>
>If you use something like "printf ' \001a\011b\015\012c '", you do not even
have
>to worry about how portable srvm is and on top, you can test your
unprintable-
>redacting logic in the code.
>
>But all of that may be moot, if we take the "fewer customization at
runtime"
>approach.

On my box, uname -srvm = "NONSTOP_KERNEL L24 08 NSV-D". Is this going to
Break anything?





[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