Git development
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode
Date: Sun, 2 Aug 2026 22:09:52 +0000	[thread overview]
Message-ID: <am_AL9dymrkidizF@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqv79vha69.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

On 2026-07-31 at 07:48:14, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > Git has historically allowed either lowercase or uppercase hex for
> > object IDs, but it has always emitted only lowercase.  This has caused
> > people to expect only lowercase and not handle uppercase.
> 
> It is violation of Postel's Law by other people.  We do not
> necessarily have to follow suit.

Postel's Law was a great idea on the early Internet, but it is
unfortunately no longer a good idea.  The problem is that being liberal
in what you accept these days usually has security implications.

TLS cannot be liberal in what it accepts because that means potentially
allowing attacker-controlled data.  Even HTTP cannot do that because
we've seen where refusing to reject requests with both Content-Length
and Transfer-Encoding: chunked means that two parts of a backend can
disagree on the content, allowing request smuggling.

We've seen these problems in our code where not caring about CR comes
back to bite us on Windows in a security-sensitive way.

Modern development effectively requires being clear and definitive about
what data is accepted and what is not, as well as what meaning is given
to the data that is accepted.

> Even though I said throwing object names in a single category makes
> sense, it may make sense to treat the object names that we locally
> use to access our own object database and those that we use when
> talking with _other_ people on the net separately for the Robustness
> principle, we keep being strict in what we produce and stick to
> lowercase, while accepting uppercase produced by those third-party
> reimplementations of Git.

Unfortunately, that also doesn't fix most of the security problems I've
seen, which involve object IDs that get passed on the command line when
tools invoke Git.  It does fix the problem with round-tripping objects
between hash algorithms, though, but I don't really want to audit every
use of oid_to_hex in our codebase to half-fix this situation.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  parent reply	other threads:[~2026-08-02 22:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 23:32 [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 1/6] hex: add functionality for lowercase-only hex brian m. carlson
2026-07-31  7:38   ` Junio C Hamano
2026-07-29 23:32 ` [RFC PATCH 2/6] hex: allow specifying hex type with hex2chr brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 3/6] hex: make hex_to_bytes accept kind of hex to use brian m. carlson
2026-07-31  7:38   ` Junio C Hamano
2026-08-01 14:35     ` Jeff King
2026-07-29 23:32 ` [RFC PATCH 4/6] hex: label usages of hex parsing for object IDs brian m. carlson
2026-07-31  3:24   ` Junio C Hamano
2026-07-29 23:32 ` [RFC PATCH 5/6] object-name: use hexval brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode brian m. carlson
2026-07-31  7:48   ` Junio C Hamano
2026-07-31 12:33     ` Junio C Hamano
2026-08-02 22:09     ` brian m. carlson [this message]
2026-08-04 19:32       ` Junio C Hamano
2026-08-04 21:46         ` brian m. carlson
2026-08-05  3:09       ` Michael Montalbo
2026-07-30  8:21 ` [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only Junio C Hamano
2026-07-30 21:18   ` brian m. carlson
2026-08-01 14:45     ` Jeff King
2026-08-01 18:22       ` Junio C Hamano
2026-08-02 21:55       ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=am_AL9dymrkidizF@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox