Re: [PATCH 3/4] connect: advertise OS version

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

 



On Wed, Jan 8, 2025 at 9:45 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Usman Akinyemi <usmanakinyemi202@xxxxxxxxx> writes:
>
> >> Is there a need for a registry of canonical os-version strings?  One
> >> reason why you would want this user-settable (as opposed to being
> >> derived from "uname -s") is that a system that is presumably the
> >> same in end-user perception can call itself in different names (your
> >> Windows/MINGW64 example) and having the users set it to a string
> >> chosen from a small repertoire, the other end would be able to
> >> identify them more easily.  I do not think it is a necessarily a
> >> good idea to limit what value the users can set to this
> >> configuration variable, but at least with a published guideline on
> >> calling various types of systems (and an explanation on the reason
> >> why we publish such a guideline), users would make an informed
> >> decision when picking what string to send.
> >
> > We plan to implement another config option `osVersion.format`, which
> > allow users to fully customize the string sent to the other side using
> > placeholders,
>
> Sorry, you lost me.
>
> I was wondering if we want to (informally at first) make it _less_
> flexible, so that we can prevent people from being "creative" when
> the value of being creative is negative.  Adding even more ways to
> customize the string to subject the receiving/inspecting end to more
> unnecessary variations to call the same thing in different names is
> the last thing we want to see in that context, isn't it?
>
> If you have "any random string goes" configuration mechanism, it is
> pretty much game over.  You do not need to add an elaborate .format
> mechanism to let users throw random garbage at the other side of the
> connection.
Thanks for the explanation.
Instead of having .format that will allow user to have multiple
variation or different placeholder,
we can allow it to take only specific values for examples:
- "full" which would mean the same thing as  the result of `uname -srvm`,
- "default" or "short" which would mean the same thing as  the result
of `uname -s`,
- "medium"  which would mean the same thing as  the result of `uname -sr`.

What is your thought about this ?

Thank you.
>
> >> > +# Trim and replace each character with ascii code below 32 or above
> >> > +# 127 (included) using a dot '.' character.
> >> > +# Octal intervals \001-\040 and \177-\377
> >> > +# corresponds to decimal intervals 1-32 and 127-255
> >> > +test_redact_non_printables () {
> >> > +    tr -d "\n" | tr "[\001-\040][\177-\377]" "."
> >> > +}
> >>
> >> Just being curious.  Do we need to worry about carriage-returns not
> >> just line-feeds, and if not why?
> > The function `tr "[\001-\040][\177-\377]" "."` already replace the
> > carriage-returns with "."
>
> That is exactly my point.  LF are stripped; I do not see a sensible
> reason why shouldn't CR be removed the same way.
Yeah, I will add that in the next iteration.

Thank you.
Usman.
>
> Thanks.





[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