{"thread":{"id":"61649","subject":"[PATCH 0/3] Advertise OS version","startedAt":"2024-06-19T12:57:37Z","lastAt":"2024-12-10T18:52:12Z","messageCount":22,"participants":["Christian Couder","Dragan Simic","Jeff King","rsbecker@nexbridge.com","Eric Sunshine","brian m. carlson","Junio C Hamano","Usman Akinyemi"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"497343","messageId":"20240619125708.3719150-1-christian.couder@gmail.com","threadId":"61649","inReplyTo":null,"subject":"[PATCH 0/3] Advertise OS version","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-19T12:57:05Z","receivedAt":"2024-06-19T12:57:37Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"For debugging and statistical purposes, it can be useful for Git\nservers to know the OS the client are using.\n\nSo let's add a new 'os-version' capability to the v2 protocol, in the\nsame way as the existing 'agent' capability that lets clients and\nservers exchange the Git version they are running.\n\nThis sends the same info as `git bugreport` is already sending, which\nuses uname(2). It should be the same as what `uname -srvm` returns,\nexcept that it is sanitized in the same way as the Git version sent by\nthe 'agent' capability is sanitized (by replacing character having an\nascii code less than 32 or more than 127 with '.').\n\nCI tests are currently failing on Windows as it looks like uname(1)\nand uname(2) don't report the same thing:\n\n  -os-version=MINGW64_NT-10.0-20348.3.4.10-87d57229.x86_64.2024-02-14.20:17.UTC.x86_64\n  +os-version=Windows.10.0.20348\n\n(See: https://github.com/chriscool/git/actions/runs/9581822699)\n\nThoughts?\n\nChristian Couder (3):\n  version: refactor strbuf_sanitize()\n  version: refactor get_uname_info()\n  connect: advertise OS version\n\n Documentation/gitprotocol-v2.txt | 18 +++++++++\n builtin/bugreport.c              | 13 +------\n connect.c                        |  3 ++\n serve.c                          | 12 ++++++\n t/t5555-http-smart-common.sh     |  3 ++\n t/t5701-git-serve.sh             |  3 ++\n version.c                        | 67 ++++++++++++++++++++++++++++----\n version.h                        | 10 +++++\n 8 files changed, 111 insertions(+), 18 deletions(-)\n\n-- \n2.45.2.563.g6aa460b3cb\n\n"},{"id":"497344","messageId":"20240619125708.3719150-2-christian.couder@gmail.com","threadId":"61649","inReplyTo":"20240619125708.3719150-1-christian.couder@gmail.com","subject":"[PATCH 1/3] version: refactor strbuf_sanitize()","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-19T12:57:06Z","receivedAt":"2024-06-19T12:57:38Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"The git_user_agent_sanitized() function performs some sanitizing to\navoid special characters being sent over the line and possibly messing\nup with the protocol or with the parsing on the other side.\n\nLet's extract this sanitizing into a new strbuf_sanitize() function, as\nwe will want to reuse it in a following patch.\n\nFor now the new strbuf_sanitize() function is still static as it's only\nneeded locally.\n\nWhile at it, let's also make a few small improvements:\n  - use 'size_t' for 'i' instead of 'int',\n  - move the declaration of 'i' inside the 'for ( ... )',\n  - use strbuf_detach() to explicitely detach the string contained by\n    the 'buf' strbuf.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n version.c | 18 +++++++++++-------\n 1 file changed, 11 insertions(+), 7 deletions(-)\n\ndiff --git a/version.c b/version.c\nindex 41b718c29e..331ee6c372 100644\n--- a/version.c\n+++ b/version.c\n@@ -5,6 +5,15 @@\n const char git_version_string[] = GIT_VERSION;\n const char git_built_from_commit_string[] = GIT_BUILT_FROM_COMMIT;\n \n+static void strbuf_sanitize(struct strbuf *buf)\n+{\n+\tstrbuf_trim(buf);\n+\tfor (size_t i = 0; i < buf->len; i++) {\n+\t\tif (buf->buf[i] <= 32 || buf->buf[i] >= 127)\n+\t\t\tbuf->buf[i] = '.';\n+\t}\n+}\n+\n const char *git_user_agent(void)\n {\n \tstatic const char *agent = NULL;\n@@ -24,15 +33,10 @@ const char *git_user_agent_sanitized(void)\n \n \tif (!agent) {\n \t\tstruct strbuf buf = STRBUF_INIT;\n-\t\tint i;\n \n \t\tstrbuf_addstr(&buf, git_user_agent());\n-\t\tstrbuf_trim(&buf);\n-\t\tfor (i = 0; i < buf.len; i++) {\n-\t\t\tif (buf.buf[i] <= 32 || buf.buf[i] >= 127)\n-\t\t\t\tbuf.buf[i] = '.';\n-\t\t}\n-\t\tagent = buf.buf;\n+\t\tstrbuf_sanitize(&buf);\n+\t\tagent = strbuf_detach(&buf, NULL);\n \t}\n \n \treturn agent;\n-- \n2.45.2.563.g6aa460b3cb\n\n"},{"id":"497345","messageId":"20240619125708.3719150-3-christian.couder@gmail.com","threadId":"61649","inReplyTo":"20240619125708.3719150-1-christian.couder@gmail.com","subject":"[PATCH 2/3] version: refactor get_uname_info()","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-19T12:57:07Z","receivedAt":"2024-06-19T12:57:41Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Some code from \"builtin/bugreport.c\" uses uname(2) to get system\ninformation.\n\nLet's refactor this code into a new get_uname_info() function, so\nthat we can reuse it in a following commit.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n builtin/bugreport.c | 13 ++-----------\n version.c           | 20 ++++++++++++++++++++\n version.h           |  7 +++++++\n 3 files changed, 29 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin/bugreport.c b/builtin/bugreport.c\nindex b3cc77af53..b24f876c41 100644\n--- a/builtin/bugreport.c\n+++ b/builtin/bugreport.c\n@@ -11,10 +11,10 @@\n #include \"diagnose.h\"\n #include \"object-file.h\"\n #include \"setup.h\"\n+#include \"version.h\"\n \n static void get_system_info(struct strbuf *sys_info)\n {\n-\tstruct utsname uname_info;\n \tchar *shell = NULL;\n \n \t/* get git version from native cmd */\n@@ -23,16 +23,7 @@ static void get_system_info(struct strbuf *sys_info)\n \n \t/* system call for other version info */\n \tstrbuf_addstr(sys_info, \"uname: \");\n-\tif (uname(&uname_info))\n-\t\tstrbuf_addf(sys_info, _(\"uname() failed with error '%s' (%d)\\n\"),\n-\t\t\t    strerror(errno),\n-\t\t\t    errno);\n-\telse\n-\t\tstrbuf_addf(sys_info, \"%s %s %s %s\\n\",\n-\t\t\t    uname_info.sysname,\n-\t\t\t    uname_info.release,\n-\t\t\t    uname_info.version,\n-\t\t\t    uname_info.machine);\n+\tget_uname_info(sys_info);\n \n \tstrbuf_addstr(sys_info, _(\"compiler info: \"));\n \tget_compiler_info(sys_info);\ndiff --git a/version.c b/version.c\nindex 331ee6c372..10b9fa77d1 100644\n--- a/version.c\n+++ b/version.c\n@@ -1,6 +1,7 @@\n #include \"git-compat-util.h\"\n #include \"version.h\"\n #include \"strbuf.h\"\n+#include \"gettext.h\"\n \n const char git_version_string[] = GIT_VERSION;\n const char git_built_from_commit_string[] = GIT_BUILT_FROM_COMMIT;\n@@ -41,3 +42,22 @@ const char *git_user_agent_sanitized(void)\n \n \treturn agent;\n }\n+\n+int get_uname_info(struct strbuf *buf)\n+{\n+\tstruct utsname uname_info;\n+\n+\tif (uname(&uname_info)) {\n+\t\tstrbuf_addf(buf, _(\"uname() failed with error '%s' (%d)\\n\"),\n+\t\t\t    strerror(errno),\n+\t\t\t    errno);\n+\t\treturn -1;\n+\t}\n+\n+\tstrbuf_addf(buf, \"%s %s %s %s\\n\",\n+\t\t    uname_info.sysname,\n+\t\t    uname_info.release,\n+\t\t    uname_info.version,\n+\t\t    uname_info.machine);\n+\treturn 0;\n+}\ndiff --git a/version.h b/version.h\nindex 7c62e80577..afe3dbbab7 100644\n--- a/version.h\n+++ b/version.h\n@@ -7,4 +7,11 @@ extern const char git_built_from_commit_string[];\n const char *git_user_agent(void);\n const char *git_user_agent_sanitized(void);\n \n+/*\n+  Try to get information about the system using uname(2).\n+  Return -1 and put an error message into 'buf' in case of uname()\n+  error. Return 0 and put uname info into 'buf' otherwise.\n+*/\n+int get_uname_info(struct strbuf *buf);\n+\n #endif /* VERSION_H */\n-- \n2.45.2.563.g6aa460b3cb\n\n"},{"id":"497346","messageId":"20240619125708.3719150-4-christian.couder@gmail.com","threadId":"61649","inReplyTo":"20240619125708.3719150-1-christian.couder@gmail.com","subject":"[PATCH 3/3] connect: advertise OS version","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-19T12:57:08Z","receivedAt":"2024-06-19T12:57:41Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"As some issues that can happen with a Git client can be operating system\nspecific, it can be useful for a server to know which OS a client is\nusing. In the same way it can be useful for a client to know which OS\na server is using.\n\nLet's add OS information exchange to the protocol in the same way some\ngit version exchange is performed.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n Documentation/gitprotocol-v2.txt | 18 ++++++++++++++++++\n connect.c                        |  3 +++\n serve.c                          | 12 ++++++++++++\n t/t5555-http-smart-common.sh     |  3 +++\n t/t5701-git-serve.sh             |  3 +++\n version.c                        | 29 +++++++++++++++++++++++++++++\n version.h                        |  3 +++\n 7 files changed, 71 insertions(+)\n\ndiff --git a/Documentation/gitprotocol-v2.txt b/Documentation/gitprotocol-v2.txt\nindex 414bc625d5..f676b2dc7a 100644\n--- a/Documentation/gitprotocol-v2.txt\n+++ b/Documentation/gitprotocol-v2.txt\n@@ -190,6 +190,24 @@ printable ASCII characters except space (i.e., the byte range 32 < x <\n and debugging purposes, and MUST NOT be used to programmatically assume\n the presence or absence of particular features.\n \n+os-version\n+~~~~~~~~~~\n+\n+In the same way as the `agent` capability above, the server can\n+advertise the `os-version` capability with a value `X` (in the form\n+`os-version=X`) to notify the client that the server is running an\n+operating system that can be identified by `X`. The client may\n+optionally send its own `os-version` string by including the\n+`os-version` capability with a value `Y` (in the form `os-version=Y`)\n+in its request to the server (but it MUST NOT do so if the server did\n+not advertise the os-version capability). The `X` and `Y` strings may\n+contain any printable ASCII characters except space (i.e., the byte\n+range 32 < x < 127), and are typically made from the result of\n+`uname -srvm`. The os-version strings are purely informative for\n+statistics and debugging purposes, and MUST NOT be used to\n+programmatically assume the presence or absence of particular\n+features.\n+\n ls-refs\n ~~~~~~~\n \ndiff --git a/connect.c b/connect.c\nindex 0d77737a53..3a48806ddc 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -489,6 +489,9 @@ static void send_capabilities(int fd_out, struct packet_reader *reader)\n \tif (server_supports_v2(\"agent\"))\n \t\tpacket_write_fmt(fd_out, \"agent=%s\", git_user_agent_sanitized());\n \n+\tif (server_supports_v2(\"os-version\"))\n+\t\tpacket_write_fmt(fd_out, \"os-version=%s\", os_version_sanitized());\n+\n \tif (server_feature_v2(\"object-format\", &hash_name)) {\n \t\tint hash_algo = hash_algo_by_name(hash_name);\n \t\tif (hash_algo == GIT_HASH_UNKNOWN)\ndiff --git a/serve.c b/serve.c\nindex aa651b73e9..77eb5ebdaa 100644\n--- a/serve.c\n+++ b/serve.c\n@@ -29,6 +29,14 @@ static int agent_advertise(struct repository *r UNUSED,\n \treturn 1;\n }\n \n+static int os_version_advertise(struct repository *r UNUSED,\n+\t\t\t   struct strbuf *value)\n+{\n+\tif (value)\n+\t\tstrbuf_addstr(value, os_version_sanitized());\n+\treturn 1;\n+}\n+\n static int object_format_advertise(struct repository *r,\n \t\t\t\t   struct strbuf *value)\n {\n@@ -121,6 +129,10 @@ static struct protocol_capability capabilities[] = {\n \t\t.name = \"agent\",\n \t\t.advertise = agent_advertise,\n \t},\n+\t{\n+\t\t.name = \"os-version\",\n+\t\t.advertise = os_version_advertise,\n+\t},\n \t{\n \t\t.name = \"ls-refs\",\n \t\t.advertise = ls_refs_advertise,\ndiff --git a/t/t5555-http-smart-common.sh b/t/t5555-http-smart-common.sh\nindex 3dcb3340a3..c67739236f 100755\n--- a/t/t5555-http-smart-common.sh\n+++ b/t/t5555-http-smart-common.sh\n@@ -124,9 +124,12 @@ test_expect_success 'git receive-pack --advertise-refs: v1' '\n '\n \n test_expect_success 'git upload-pack --advertise-refs: v2' '\n+\t# Octal intervals \\001-\\040 and \\177-\\377\n+\t# corresponds to decimal intervals 1-32 and 127-255\n \tcat >expect <<-EOF &&\n \tversion 2\n \tagent=FAKE\n+\tos-version=$(uname -srvm | tr -d \"\\n\" | tr \"[\\001-\\040][\\177-\\377]\" \".\")\n \tls-refs=unborn\n \tfetch=shallow wait-for-done\n \tserver-option\ndiff --git a/t/t5701-git-serve.sh b/t/t5701-git-serve.sh\nindex c48830de8f..9c9a707e6a 100755\n--- a/t/t5701-git-serve.sh\n+++ b/t/t5701-git-serve.sh\n@@ -13,9 +13,12 @@ test_expect_success 'test capability advertisement' '\n \twrong_algo sha1:sha256\n \twrong_algo sha256:sha1\n \tEOF\n+\t# Octal intervals \\001-\\040 and \\177-\\377\n+\t# corresponds to decimal intervals 1-32 and 127-255\n \tcat >expect.base <<-EOF &&\n \tversion 2\n \tagent=git/$(git version | cut -d\" \" -f3)\n+\tos-version=$(uname -srvm | tr -d \"\\n\" | tr \"[\\001-\\040][\\177-\\377]\" \".\")\n \tls-refs=unborn\n \tfetch=shallow wait-for-done\n \tserver-option\ndiff --git a/version.c b/version.c\nindex 10b9fa77d1..5b20ea0d7c 100644\n--- a/version.c\n+++ b/version.c\n@@ -61,3 +61,32 @@ int get_uname_info(struct strbuf *buf)\n \t\t    uname_info.machine);\n \treturn 0;\n }\n+\n+const char *os_version(void)\n+{\n+\tstatic const char *os = NULL;\n+\n+\tif (!os) {\n+\t\tstruct strbuf buf = STRBUF_INIT;\n+\n+\t\tget_uname_info(&buf);\n+\t\tos = strbuf_detach(&buf, NULL);\n+\t}\n+\n+\treturn os;\n+}\n+\n+const char *os_version_sanitized(void)\n+{\n+\tstatic const char *os_sanitized = NULL;\n+\n+\tif (!os_sanitized) {\n+\t\tstruct strbuf buf = STRBUF_INIT;\n+\n+\t\tstrbuf_addstr(&buf, os_version());\n+\t\tstrbuf_sanitize(&buf);\n+\t\tos_sanitized = strbuf_detach(&buf, NULL);\n+\t}\n+\n+\treturn os_sanitized;\n+}\ndiff --git a/version.h b/version.h\nindex afe3dbbab7..349952c8f2 100644\n--- a/version.h\n+++ b/version.h\n@@ -14,4 +14,7 @@ const char *git_user_agent_sanitized(void);\n */\n int get_uname_info(struct strbuf *buf);\n \n+const char *os_version(void);\n+const char *os_version_sanitized(void);\n+\n #endif /* VERSION_H */\n-- \n2.45.2.563.g6aa460b3cb\n\n"},{"id":"497348","messageId":"0448495385b009f25a66b0712afb28f1@manjaro.org","threadId":"61649","inReplyTo":"20240619125708.3719150-1-christian.couder@gmail.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-06-19T13:18:40Z","receivedAt":"2024-06-19T13:18:45Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Christian,\n\nOn 2024-06-19 14:57, Christian Couder wrote:\n> For debugging and statistical purposes, it can be useful for Git\n> servers to know the OS the client are using.\n> \n> So let's add a new 'os-version' capability to the v2 protocol, in the\n> same way as the existing 'agent' capability that lets clients and\n> servers exchange the Git version they are running.\n> \n> This sends the same info as `git bugreport` is already sending, which\n> uses uname(2). It should be the same as what `uname -srvm` returns,\n> except that it is sanitized in the same way as the Git version sent by\n> the 'agent' capability is sanitized (by replacing character having an\n> ascii code less than 32 or more than 127 with '.').\n\nThis may probably be a useful debugging feature, but I strongly\nsuggest that a configuration knob exists that makes disabling it\npossible.  For security reasons, some users may not want to\npublicly advertise their OSes and kernel versions.  Count me in\nas one of such users. :)\n\n> CI tests are currently failing on Windows as it looks like uname(1)\n> and uname(2) don't report the same thing:\n> \n> \n> -os-version=MINGW64_NT-10.0-20348.3.4.10-87d57229.x86_64.2024-02-14.20:17.UTC.x86_64\n>   +os-version=Windows.10.0.20348\n> \n> (See: https://github.com/chriscool/git/actions/runs/9581822699)\n> \n> Thoughts?\n> \n> Christian Couder (3):\n>   version: refactor strbuf_sanitize()\n>   version: refactor get_uname_info()\n>   connect: advertise OS version\n> \n>  Documentation/gitprotocol-v2.txt | 18 +++++++++\n>  builtin/bugreport.c              | 13 +------\n>  connect.c                        |  3 ++\n>  serve.c                          | 12 ++++++\n>  t/t5555-http-smart-common.sh     |  3 ++\n>  t/t5701-git-serve.sh             |  3 ++\n>  version.c                        | 67 ++++++++++++++++++++++++++++----\n>  version.h                        | 10 +++++\n>  8 files changed, 111 insertions(+), 18 deletions(-)\n"},{"id":"497351","messageId":"20240619134533.GA943023@coredump.intra.peff.net","threadId":"61649","inReplyTo":"0448495385b009f25a66b0712afb28f1@manjaro.org","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-19T13:45:33Z","receivedAt":"2024-06-19T13:45:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 19, 2024 at 03:18:40PM +0200, Dragan Simic wrote:\n\n> Hello Christian,\n> \n> On 2024-06-19 14:57, Christian Couder wrote:\n> > For debugging and statistical purposes, it can be useful for Git\n> > servers to know the OS the client are using.\n> > \n> > So let's add a new 'os-version' capability to the v2 protocol, in the\n> > same way as the existing 'agent' capability that lets clients and\n> > servers exchange the Git version they are running.\n> > \n> > This sends the same info as `git bugreport` is already sending, which\n> > uses uname(2). It should be the same as what `uname -srvm` returns,\n> > except that it is sanitized in the same way as the Git version sent by\n> > the 'agent' capability is sanitized (by replacing character having an\n> > ascii code less than 32 or more than 127 with '.').\n> \n> This may probably be a useful debugging feature, but I strongly\n> suggest that a configuration knob exists that makes disabling it\n> possible.  For security reasons, some users may not want to\n> publicly advertise their OSes and kernel versions.  Count me in\n> as one of such users. :)\n\nAgreed. We do send the Git version, which is already a slight privacy\nissue (though it can be overridden at both build-time and run-time). But\nOS details seems like crossing a line to me.\n\nI don't mind if this is present but disabled by default, but then I\nguess it is not really serving much of a purpose, as hardly anybody\nwould enable it. Which makes collecting large-scale statistics by\nhosting providers pretty much useless (and I don't think it is all that\nuseful for debugging individual cases).\n\n-Peff\n"},{"id":"497352","messageId":"04b714d3e949c30bae0e26231e923fc4@manjaro.org","threadId":"61649","inReplyTo":"20240619134533.GA943023@coredump.intra.peff.net","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-06-19T13:50:34Z","receivedAt":"2024-06-19T13:50:38Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Jeff,\n\nOn 2024-06-19 15:45, Jeff King wrote:\n> On Wed, Jun 19, 2024 at 03:18:40PM +0200, Dragan Simic wrote:\n>> On 2024-06-19 14:57, Christian Couder wrote:\n>> > For debugging and statistical purposes, it can be useful for Git\n>> > servers to know the OS the client are using.\n>> >\n>> > So let's add a new 'os-version' capability to the v2 protocol, in the\n>> > same way as the existing 'agent' capability that lets clients and\n>> > servers exchange the Git version they are running.\n>> >\n>> > This sends the same info as `git bugreport` is already sending, which\n>> > uses uname(2). It should be the same as what `uname -srvm` returns,\n>> > except that it is sanitized in the same way as the Git version sent by\n>> > the 'agent' capability is sanitized (by replacing character having an\n>> > ascii code less than 32 or more than 127 with '.').\n>> \n>> This may probably be a useful debugging feature, but I strongly\n>> suggest that a configuration knob exists that makes disabling it\n>> possible.  For security reasons, some users may not want to\n>> publicly advertise their OSes and kernel versions.  Count me in\n>> as one of such users. :)\n> \n> Agreed. We do send the Git version, which is already a slight privacy\n> issue (though it can be overridden at both build-time and run-time). \n> But\n> OS details seems like crossing a line to me.\n> \n> I don't mind if this is present but disabled by default, but then I\n> guess it is not really serving much of a purpose, as hardly anybody\n> would enable it. Which makes collecting large-scale statistics by\n> hosting providers pretty much useless (and I don't think it is all that\n> useful for debugging individual cases).\n\nI agree that it should actually be disabled by default, for privacy\nand security reasons, but that would actually defeat its purpose, so\nI'm not really sure should it be merged.\n"},{"id":"497354","messageId":"CAP8UFD2k9YBoKf_=fj1UKNK+=J-2vMenwt8QyTXXSaf=uX6Otg@mail.gmail.com","threadId":"61649","inReplyTo":"04b714d3e949c30bae0e26231e923fc4@manjaro.org","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-19T14:01:57Z","receivedAt":"2024-06-19T14:02:12Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org> wrote:\n\n> > I don't mind if this is present but disabled by default, but then I\n> > guess it is not really serving much of a purpose, as hardly anybody\n> > would enable it. Which makes collecting large-scale statistics by\n> > hosting providers pretty much useless (and I don't think it is all that\n> > useful for debugging individual cases).\n>\n> I agree that it should actually be disabled by default, for privacy\n> and security reasons, but that would actually defeat its purpose, so\n> I'm not really sure should it be merged.\n\nOne possibility is to send just the `sysname`, described as 'Operating\nsystem name (e.g., \"Linux\")', field of the struct utsname filled out\nby uname(2) by default.\n\nIt should be the same as what `uname -s` prints, so \"Linux\" for a\nLinux machine, and might be acceptable regarding privacy concerns.\n\nAnd then there might be a knob to deactivate it completely or to make\nit more verbose (which might be useful for example in a corporate\ncontext).\n"},{"id":"497355","messageId":"4ba6dececcfb3dcec5c8b7e64657a1ff@manjaro.org","threadId":"61649","inReplyTo":"CAP8UFD2k9YBoKf_=fj1UKNK+=J-2vMenwt8QyTXXSaf=uX6Otg@mail.gmail.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-06-19T14:19:57Z","receivedAt":"2024-06-19T14:19:59Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-06-19 16:01, Christian Couder wrote:\n> On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org> \n> wrote:\n> \n>> > I don't mind if this is present but disabled by default, but then I\n>> > guess it is not really serving much of a purpose, as hardly anybody\n>> > would enable it. Which makes collecting large-scale statistics by\n>> > hosting providers pretty much useless (and I don't think it is all that\n>> > useful for debugging individual cases).\n>> \n>> I agree that it should actually be disabled by default, for privacy\n>> and security reasons, but that would actually defeat its purpose, so\n>> I'm not really sure should it be merged.\n> \n> One possibility is to send just the `sysname`, described as 'Operating\n> system name (e.g., \"Linux\")', field of the struct utsname filled out\n> by uname(2) by default.\n> \n> It should be the same as what `uname -s` prints, so \"Linux\" for a\n> Linux machine, and might be acceptable regarding privacy concerns.\n> \n> And then there might be a knob to deactivate it completely or to make\n> it more verbose (which might be useful for example in a corporate\n> context).\n\nI'd be fine with advertising \"Linux\" (or \"Windows\") only by default,\nbecause it doesn't reveal much from the privacy and security standpoint,\nbut allows rather usable statistics to be collected.\n\nA configuration knob that would allow it to be disabled entirely, or\nbe enabled with more details to be sent would also be fine with me.\n"},{"id":"497356","messageId":"000001dac256$d804a510$880def30$@nexbridge.com","threadId":"61649","inReplyTo":"4ba6dececcfb3dcec5c8b7e64657a1ff@manjaro.org","subject":"RE: [PATCH 0/3] Advertise OS version","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-19T14:41:54Z","receivedAt":"2024-06-19T14:42:29Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Wednesday, June 19, 2024 10:20 AM, Dragan Simic wrote:\n>On 2024-06-19 16:01, Christian Couder wrote:\n>> On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org>\n>> wrote:\n>>\n>>> > I don't mind if this is present but disabled by default, but then I\n>>> > guess it is not really serving much of a purpose, as hardly anybody\n>>> > would enable it. Which makes collecting large-scale statistics by\n>>> > hosting providers pretty much useless (and I don't think it is all\n>>> > that useful for debugging individual cases).\n>>>\n>>> I agree that it should actually be disabled by default, for privacy\n>>> and security reasons, but that would actually defeat its purpose, so\n>>> I'm not really sure should it be merged.\n>>\n>> One possibility is to send just the `sysname`, described as 'Operating\n>> system name (e.g., \"Linux\")', field of the struct utsname filled out\n>> by uname(2) by default.\n>>\n>> It should be the same as what `uname -s` prints, so \"Linux\" for a\n>> Linux machine, and might be acceptable regarding privacy concerns.\n>>\n>> And then there might be a knob to deactivate it completely or to make\n>> it more verbose (which might be useful for example in a corporate\n>> context).\n>\n>I'd be fine with advertising \"Linux\" (or \"Windows\") only by default, because it\n>doesn't reveal much from the privacy and security standpoint, but allows rather\n>usable statistics to be collected.\n>\n>A configuration knob that would allow it to be disabled entirely, or be enabled with\n>more details to be sent would also be fine with me.\n\nWhile in the code, can I suggest including the OpenSSL version used in the build? This came up in at a customer a few weeks ago and they could not answer the question of what git build they were using. Turned out it used the wrong OpenSSL header compared to what they had installed.\n\n"},{"id":"497357","messageId":"20240619145042.GA957055@coredump.intra.peff.net","threadId":"61649","inReplyTo":"CAP8UFD2k9YBoKf_=fj1UKNK+=J-2vMenwt8QyTXXSaf=uX6Otg@mail.gmail.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-19T14:50:42Z","receivedAt":"2024-06-19T14:50:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 19, 2024 at 04:01:57PM +0200, Christian Couder wrote:\n\n> On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org> wrote:\n> \n> > > I don't mind if this is present but disabled by default, but then I\n> > > guess it is not really serving much of a purpose, as hardly anybody\n> > > would enable it. Which makes collecting large-scale statistics by\n> > > hosting providers pretty much useless (and I don't think it is all that\n> > > useful for debugging individual cases).\n> >\n> > I agree that it should actually be disabled by default, for privacy\n> > and security reasons, but that would actually defeat its purpose, so\n> > I'm not really sure should it be merged.\n> \n> One possibility is to send just the `sysname`, described as 'Operating\n> system name (e.g., \"Linux\")', field of the struct utsname filled out\n> by uname(2) by default.\n\nThat would be better to me. I still don't love it, but I admit it's\ncoming more from a knee-jerk response than from some rational argument\nagainst people knowing I run Linux.\n\nSince HTTP user-agent fields are common, we can look at those for prior\nart. curl sends its own version but nothing else. Most browsers do seem\nto include some OS information. My version of firefox gives its own\nversion along with \"Linux x86_64\". So basically \"uname -sm\".\n\n> And then there might be a knob to deactivate it completely or to make\n> it more verbose (which might be useful for example in a corporate\n> context).\n\nYes, I think we should definitely have an option to suppress or override\nit, just like we do for the user-agent string.\n\n-Peff\n"},{"id":"497358","messageId":"20240619145246.GB957055@coredump.intra.peff.net","threadId":"61649","inReplyTo":"000001dac256$d804a510$880def30$@nexbridge.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-19T14:52:46Z","receivedAt":"2024-06-19T14:52:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 19, 2024 at 10:41:54AM -0400, rsbecker@nexbridge.com wrote:\n\n> >A configuration knob that would allow it to be disabled entirely, or\n> >be enabled with more details to be sent would also be fine with me.\n> \n> While in the code, can I suggest including the OpenSSL version used in\n> the build? This came up in at a customer a few weeks ago and they\n> could not answer the question of what git build they were using.\n> Turned out it used the wrong OpenSSL header compared to what they had\n> installed.\n\nAt the point you are dealing one-on-one with somebody, I don't think\nprotocol-level messages like this are the best spot for debugging. But\nit might make sense to teach \"git version --build-options\" to report the\nopenssl version.\n\n-Peff\n"},{"id":"497359","messageId":"000701dac259$0a768bb0$1f63a310$@nexbridge.com","threadId":"61649","inReplyTo":"20240619145246.GB957055@coredump.intra.peff.net","subject":"RE: [PATCH 0/3] Advertise OS version","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-19T14:57:38Z","receivedAt":"2024-06-19T14:57:53Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Wednesday, June 19, 2024 10:53 AM, Peff wrote:\n>On Wed, Jun 19, 2024 at 10:41:54AM -0400, rsbecker@nexbridge.com wrote:\n>\n>> >A configuration knob that would allow it to be disabled entirely, or\n>> >be enabled with more details to be sent would also be fine with me.\n>>\n>> While in the code, can I suggest including the OpenSSL version used in\n>> the build? This came up in at a customer a few weeks ago and they\n>> could not answer the question of what git build they were using.\n>> Turned out it used the wrong OpenSSL header compared to what they had\n>> installed.\n>\n>At the point you are dealing one-on-one with somebody, I don't think protocol-level\n>messages like this are the best spot for debugging. But it might make sense to teach\n>\"git version --build-options\" to report the openssl version.\n\nMuch better idea. Will look into it. Thanks.\n\n"},{"id":"497360","messageId":"000a01dac25c$df7b23e0$9e716ba0$@nexbridge.com","threadId":"61649","inReplyTo":"20240619145042.GA957055@coredump.intra.peff.net","subject":"RE: [PATCH 0/3] Advertise OS version","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-19T15:25:04Z","receivedAt":"2024-06-19T15:25:20Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Wednesday, June 19, 2024 10:51 AM, Peff wrote:\n>On Wed, Jun 19, 2024 at 04:01:57PM +0200, Christian Couder wrote:\n>\n>> On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org> wrote:\n>>\n>> > > I don't mind if this is present but disabled by default, but then\n>> > > I guess it is not really serving much of a purpose, as hardly\n>> > > anybody would enable it. Which makes collecting large-scale\n>> > > statistics by hosting providers pretty much useless (and I don't\n>> > > think it is all that useful for debugging individual cases).\n>> >\n>> > I agree that it should actually be disabled by default, for privacy\n>> > and security reasons, but that would actually defeat its purpose, so\n>> > I'm not really sure should it be merged.\n>>\n>> One possibility is to send just the `sysname`, described as 'Operating\n>> system name (e.g., \"Linux\")', field of the struct utsname filled out\n>> by uname(2) by default.\n>\n>That would be better to me. I still don't love it, but I admit it's coming more from a\n>knee-jerk response than from some rational argument against people knowing I run\n>Linux.\n>\n>Since HTTP user-agent fields are common, we can look at those for prior art. curl\n>sends its own version but nothing else. Most browsers do seem to include some OS\n>information. My version of firefox gives its own version along with \"Linux x86_64\".\n>So basically \"uname -sm\".\n>\n>> And then there might be a knob to deactivate it completely or to make\n>> it more verbose (which might be useful for example in a corporate\n>> context).\n>\n>Yes, I think we should definitely have an option to suppress or override it, just like\n>we do for the user-agent string.\n\nInstead of an override, what about a knob that specifies the uname command to use to build the value. Personally, I would use `uname -s -r -v` on NonStop to get the kernel version used in the build. The difficulty on my platform is that this is not truly useful info. The effective build OS compatibility version is in a #define __L_Series_RVU and __H_Series_RVU, so the knob might be needed in git_compat_util.h or similar. This comes from the compiler arguments, which are not yet captured.\n\n"},{"id":"497361","messageId":"49c7b3b5607cd502e12d1aadda150d0d@manjaro.org","threadId":"61649","inReplyTo":"000001dac256$d804a510$880def30$@nexbridge.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-06-19T15:53:41Z","receivedAt":"2024-06-19T15:53:43Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-06-19 16:41, rsbecker@nexbridge.com wrote:\n> On Wednesday, June 19, 2024 10:20 AM, Dragan Simic wrote:\n>> On 2024-06-19 16:01, Christian Couder wrote:\n>>> On Wed, Jun 19, 2024 at 3:50 PM Dragan Simic <dsimic@manjaro.org>\n>>> wrote:\n>>> \n>>>> > I don't mind if this is present but disabled by default, but then I\n>>>> > guess it is not really serving much of a purpose, as hardly anybody\n>>>> > would enable it. Which makes collecting large-scale statistics by\n>>>> > hosting providers pretty much useless (and I don't think it is all\n>>>> > that useful for debugging individual cases).\n>>>> \n>>>> I agree that it should actually be disabled by default, for privacy\n>>>> and security reasons, but that would actually defeat its purpose, so\n>>>> I'm not really sure should it be merged.\n>>> \n>>> One possibility is to send just the `sysname`, described as \n>>> 'Operating\n>>> system name (e.g., \"Linux\")', field of the struct utsname filled out\n>>> by uname(2) by default.\n>>> \n>>> It should be the same as what `uname -s` prints, so \"Linux\" for a\n>>> Linux machine, and might be acceptable regarding privacy concerns.\n>>> \n>>> And then there might be a knob to deactivate it completely or to make\n>>> it more verbose (which might be useful for example in a corporate\n>>> context).\n>> \n>> I'd be fine with advertising \"Linux\" (or \"Windows\") only by default, \n>> because it\n>> doesn't reveal much from the privacy and security standpoint, but \n>> allows rather\n>> usable statistics to be collected.\n>> \n>> A configuration knob that would allow it to be disabled entirely, or \n>> be enabled with\n>> more details to be sent would also be fine with me.\n> \n> While in the code, can I suggest including the OpenSSL version used in\n> the build? This came up in at a customer a few weeks ago and they\n> could not answer the question of what git build they were using.\n> Turned out it used the wrong OpenSSL header compared to what they had\n> installed.\n\nMakes sense to me, but only in the non-default \"advertise more details\"\nmode of the new configuration knob.\n"},{"id":"497369","messageId":"CAPig+cT4PUUH5XCvmioYA-M=bOTed5jM08MpruScOZyvk8VVnw@mail.gmail.com","threadId":"61649","inReplyTo":"20240619125708.3719150-2-christian.couder@gmail.com","subject":"Re: [PATCH 1/3] version: refactor strbuf_sanitize()","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-06-19T18:40:15Z","receivedAt":"2024-06-19T18:40:27Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jun 19, 2024 at 8:57 AM Christian Couder\n<christian.couder@gmail.com> wrote:\n> The git_user_agent_sanitized() function performs some sanitizing to\n> avoid special characters being sent over the line and possibly messing\n> up with the protocol or with the parsing on the other side.\n>\n> Let's extract this sanitizing into a new strbuf_sanitize() function, as\n> we will want to reuse it in a following patch.\n>\n> For now the new strbuf_sanitize() function is still static as it's only\n> needed locally.\n>\n> While at it, let's also make a few small improvements:\n>   - use 'size_t' for 'i' instead of 'int',\n>   - move the declaration of 'i' inside the 'for ( ... )',\n>   - use strbuf_detach() to explicitely detach the string contained by\n>     the 'buf' strbuf.\n\ns/explicitely/explicitly/\n\n> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>\n"},{"id":"497392","messageId":"ZnNftSO13KlmFbQ3@tapette.crustytoothpaste.net","threadId":"61649","inReplyTo":"20240619145042.GA957055@coredump.intra.peff.net","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-06-19T22:46:13Z","receivedAt":"2024-06-19T22:46:21Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-06-19 at 14:50:42, Jeff King wrote:\n> On Wed, Jun 19, 2024 at 04:01:57PM +0200, Christian Couder wrote:\n> \n> > One possibility is to send just the `sysname`, described as 'Operating\n> > system name (e.g., \"Linux\")', field of the struct utsname filled out\n> > by uname(2) by default.\n> \n> That would be better to me. I still don't love it, but I admit it's\n> coming more from a knee-jerk response than from some rational argument\n> against people knowing I run Linux.\n> \n> Since HTTP user-agent fields are common, we can look at those for prior\n> art. curl sends its own version but nothing else. Most browsers do seem\n> to include some OS information. My version of firefox gives its own\n> version along with \"Linux x86_64\". So basically \"uname -sm\".\n\nIf we choose to enable this, this is the right level of detail, yeah.\nWe could also allow a distributor to set this value at compile time,\nmuch like Debian does for Postfix and OpenSSH.  For Postfix, it's simply\n\"(Debian)\", which doesn't give much information.\n\nTo me as a server administrator interested in statistics, it's useful to\nme to know OS name and version (as in, how many users are still using an\nancient version of CentOS?), since that tells me about things like\nsupported TLS versions which is helpful, but as a user I don't think\nthat's an appropriate level of detail to share.  And I also worry about\nfingerprinting and tracking, which is a giant problem with HTTP\nuser-agents.  This is especially true if you're using something like\nFreeBSD RISC-V, which is just not that common.\n\n> > And then there might be a knob to deactivate it completely or to make\n> > it more verbose (which might be useful for example in a corporate\n> > context).\n> \n> Yes, I think we should definitely have an option to suppress or override\n> it, just like we do for the user-agent string.\n\nI definitely think we should have both.  I'm sure we'll have some server\nmaintainer or repository administrator who tries to reject \"bad\" OSes\n(like someone who doesn't like their employees using WSL, for example).\nWe've already had people propose to reject access based on the version\nnumber in the name of \"security\", despite the fact that most Linux\ndistros just backport security patches and thus the version number is\nnot usually interesting in that regard.  Again, HTTP user-agents tell us\nthat people will make access control decisions here even though they\nshould not.\n\nWe'll want to honour people's decisions to remain a mystery or to work\naround broken server implementations, or just to make it harder to track\nor fingerprint them.\n\nI also think the documentation should state that for the user-agent and\nos-version fields that they are merely informative, can be changed, and\nMUST NOT be used for access control.  That doesn't mean people will\nhonour it, but it does mean that we can and should feel free to break\nimplementations that don't comply.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"497404","messageId":"20240620152521.GB1555496@coredump.intra.peff.net","threadId":"61649","inReplyTo":"ZnNftSO13KlmFbQ3@tapette.crustytoothpaste.net","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-20T15:25:21Z","receivedAt":"2024-06-20T15:25:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 19, 2024 at 10:46:13PM +0000, brian m. carlson wrote:\n\n> We'll want to honour people's decisions to remain a mystery or to work\n> around broken server implementations, or just to make it harder to track\n> or fingerprint them.\n\nYep, I agree with everything you said, especially this part.\n\n> I also think the documentation should state that for the user-agent and\n> os-version fields that they are merely informative, can be changed, and\n> MUST NOT be used for access control.  That doesn't mean people will\n> honour it, but it does mean that we can and should feel free to break\n> implementations that don't comply.\n\nI think Christian's proposed documentation did have something along\nthese lines.\n\nI do kind of wonder if we even need a separate \"os-version\" field, and\nif it couldn't simply be plugged into the user-agent string (making it\n\"git/1.2.3 Linux x86_64\" or something). But maybe that introduces more\nhassles with respect to configuring/overriding the two parts separately.\n\n-Peff\n"},{"id":"497412","messageId":"xmqqfrt7y3xp.fsf@gitster.g","threadId":"61649","inReplyTo":"20240619125708.3719150-1-christian.couder@gmail.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-20T16:28:02Z","receivedAt":"2024-06-20T16:28:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> For debugging and statistical purposes, it can be useful for Git\n> servers to know the OS the client are using.\n>\n> So let's add a new 'os-version' capability to the v2 protocol, in the\n> same way as the existing 'agent' capability that lets clients and\n> servers exchange the Git version they are running.\n>\n> This sends the same info as `git bugreport` is already sending, which\n> uses uname(2). It should be the same as what `uname -srvm` returns,\n> except that it is sanitized in the same way as the Git version sent by\n> the 'agent' capability is sanitized (by replacing character having an\n> ascii code less than 32 or more than 127 with '.').\n>\n> CI tests are currently failing on Windows as it looks like uname(1)\n> and uname(2) don't report the same thing:\n>\n>   -os-version=MINGW64_NT-10.0-20348.3.4.10-87d57229.x86_64.2024-02-14.20:17.UTC.x86_64\n>   +os-version=Windows.10.0.20348\n>\n> (See: https://github.com/chriscool/git/actions/runs/9581822699)\n\nI think we already heard from enough people to cover the spectrum of\nopinions.  I'd have to say that needs to be carefully kept to the\nminimum what we send in the 'user-agent' like manner.  The \"git\nbugreport\" is an opt-in \"these should help you in helping me\"\nfeature, designed to allow further redacting by the user before\nsending it out, and should not be compared with \"on by default for\neverybody\" telemetry data.\n\nI personally like the idea to add to user-agent, instead of adding a\nnew capability.  What is the true motivation behind this?  Is this\nthing meant to gather statistics from potentially non-paying general\npublic from hosting providers, or is this primarily for $CORP IT\nfolks to make sure that nobody is being too stale?\n"},{"id":"508869","messageId":"20241209161445.10321-1-usmanakinyemi202@gmail.com","threadId":"61649","inReplyTo":"xmqqfrt7y3xp.fsf@gitster.g","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-12-09T16:14:44Z","receivedAt":"2024-12-09T16:20:09Z","isPatch":true,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello,\n\nThank you to everyone who participated in this discussion. I am Usman\nAkinyemi, one of the two selected Outreachy interns. I have been\nselected to work on the project “Finish adding an 'os-version'\ncapability to Git protocol v2,” which involves implementing the\nfeatures discussed in this thread.\n\nYou can find the full discussion about my proposal for this project\nhere: https://public-inbox.org/git/CAPSxiM_rvt-tkQjHYmYNv-Wyr0=X4+123dt=vZKtc++PGRjQMQ@mail.gmail.com/\n\nIn summary, this is an outline of my proposal and what I plan to\nimplement, which has been influenced by the discussion in this thread:\n\n- Send only the OS name by default while allowing a knob (custom\nconfiguration) to specify other information (e.g., version details) and disable\n sending OS names and any other information entirely.\n\nAfter discussing with my mentor, @Christian, we think that adding\nthis as a new capability (os-version) is a better option compared to\nappending it to the user-agent. This ensures that we do not disrupt\npeople's scripts that collect statistics from the user-agent or\nperform other actions.\n\nIntentions of implementing this project:\n- For statistical purposes.\n- Most importantly, for security and debugging purposes. This will\nallow servers to instruct users to upgrade or perform specific\ndebugging actions when necessary.\n\nFor example:-\nA server seeing that a client is using an old Git version\nthat has security issues on one platform, like MacOS, could check if\nthe user is indeed running MacOS before sending it a message to\nupgrade.\n\nAlso a server seeing a client that could benefit from an upgrade, for\nexample for performance reasons, could better customize the message it\nsends to the client to nudge it to upgrade. If the client is on\nWindows for example the server could send it a link to\nhttps://gitforwindows.org/ as part of the message.\n\nPlease, if anyone has any suggestion or addition or concerns that\nmight, kindly add. Thank you very much.\n\nThank you very much!\n\nUsman\n"},{"id":"508871","messageId":"00e201db4a58$3b198fb0$b14caf10$@nexbridge.com","threadId":"61649","inReplyTo":"20241209161445.10321-1-usmanakinyemi202@gmail.com","subject":"RE: [PATCH 0/3] Advertise OS version","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-12-09T16:34:28Z","receivedAt":"2024-12-09T16:34:45Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 9, 2024 11:15 AM, Usman Akinyemi wrote:\n>Thank you to everyone who participated in this discussion. I am Usman Akinyemi,\n>one of the two selected Outreachy interns. I have been selected to work on the\n>project “Finish adding an 'os-version'\n>capability to Git protocol v2,” which involves implementing the features discussed in\n>this thread.\n>\n>You can find the full discussion about my proposal for this project\n>here: https://public-inbox.org/git/CAPSxiM_rvt-tkQjHYmYNv-\n>Wyr0=X4+123dt=vZKtc++PGRjQMQ@mail.gmail.com/\n>\n>In summary, this is an outline of my proposal and what I plan to implement, which\n>has been influenced by the discussion in this thread:\n>\n>- Send only the OS name by default while allowing a knob (custom\n>configuration) to specify other information (e.g., version details) and disable\n>sending OS names and any other information entirely.\n>\n>After discussing with my mentor, @Christian, we think that adding this as a new\n>capability (os-version) is a better option compared to appending it to the user-\n>agent. This ensures that we do not disrupt people's scripts that collect statistics\n>from the user-agent or perform other actions.\n>\n>Intentions of implementing this project:\n>- For statistical purposes.\n>- Most importantly, for security and debugging purposes. This will allow servers to\n>instruct users to upgrade or perform specific debugging actions when necessary.\n>\n>For example:-\n>A server seeing that a client is using an old Git version that has security issues on\n>one platform, like MacOS, could check if the user is indeed running MacOS before\n>sending it a message to upgrade.\n>\n>Also a server seeing a client that could benefit from an upgrade, for example for\n>performance reasons, could better customize the message it sends to the client to\n>nudge it to upgrade. If the client is on Windows for example the server could send it\n>a link to https://gitforwindows.org/ as part of the message.\n>\n>Please, if anyone has any suggestion or addition or concerns that might, kindly add.\n>Thank you very much.\n\nIs this build-time or runtime? If run-time, please make sure the code is portable or provides\nhooks so that non-linux systems can contribute content.\n\nThanks,\nRandall\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n\n\n\n"},{"id":"508939","messageId":"CAPSxiM8hYPAuZhiTX06jmw7FRr0_6P5+4WjudM9Ad84Lid6gDA@mail.gmail.com","threadId":"61649","inReplyTo":"00e201db4a58$3b198fb0$b14caf10$@nexbridge.com","subject":"Re: [PATCH 0/3] Advertise OS version","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-12-10T18:51:59Z","receivedAt":"2024-12-10T18:52:12Z","isPatch":true,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Mon, Dec 9, 2024 at 10:04 PM <rsbecker@nexbridge.com> wrote:\n>\n> On December 9, 2024 11:15 AM, Usman Akinyemi wrote:\n> >Thank you to everyone who participated in this discussion. I am Usman Akinyemi,\n> >one of the two selected Outreachy interns. I have been selected to work on the\n> >project “Finish adding an 'os-version'\n> >capability to Git protocol v2,” which involves implementing the features discussed in\n> >this thread.\n> >\n> >You can find the full discussion about my proposal for this project\n> >here: https://public-inbox.org/git/CAPSxiM_rvt-tkQjHYmYNv-\n> >Wyr0=X4+123dt=vZKtc++PGRjQMQ@mail.gmail.com/\n> >\n> >In summary, this is an outline of my proposal and what I plan to implement, which\n> >has been influenced by the discussion in this thread:\n> >\n> >- Send only the OS name by default while allowing a knob (custom\n> >configuration) to specify other information (e.g., version details) and disable\n> >sending OS names and any other information entirely.\n> >\n> >After discussing with my mentor, @Christian, we think that adding this as a new\n> >capability (os-version) is a better option compared to appending it to the user-\n> >agent. This ensures that we do not disrupt people's scripts that collect statistics\n> >from the user-agent or perform other actions.\n> >\n> >Intentions of implementing this project:\n> >- For statistical purposes.\n> >- Most importantly, for security and debugging purposes. This will allow servers to\n> >instruct users to upgrade or perform specific debugging actions when necessary.\n> >\n> >For example:-\n> >A server seeing that a client is using an old Git version that has security issues on\n> >one platform, like MacOS, could check if the user is indeed running MacOS before\n> >sending it a message to upgrade.\n> >\n> >Also a server seeing a client that could benefit from an upgrade, for example for\n> >performance reasons, could better customize the message it sends to the client to\n> >nudge it to upgrade. If the client is on Windows for example the server could send it\n> >a link to https://gitforwindows.org/ as part of the message.\n> >\n> >Please, if anyone has any suggestion or addition or concerns that might, kindly add.\n> >Thank you very much.\n>\nHello Randall,\n\n> Is this build-time or runtime? If run-time, please make sure the code is portable or provides\n> hooks so that non-linux systems can contribute content.\n>\nThanks for pointing this out.\n\nYeah, the aim is to have it at runtime and to have hooks that can be\nused by non-linux systems.\n\nThank you.\nUsman.\n> Thanks,\n> Randall\n>\n> --\n> Brief whoami: NonStop&UNIX developer since approximately\n> UNIX(421664400)\n> NonStop(211288444200000000)\n> -- In real life, I talk too much.\n>\n>\n>\n"}]}