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

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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.

I am afraid that is debatable, though.

I would grant you that you can increase the attack surface by being
carelessly liberal.  Recall my example of allowing mixed-case names
for loose object files and storing them verbatim on a case-sensitive
filesystem without normalizing the names; that is an example of
being carelessly liberal.

But is it a good excuse to give up being careful, declare it is
impossible to be careful enough, and punt?

Will queue, but I invite others to chime in.  My practical side says
we should just take the series as it is much less work for us to
declare that any incompatibility fallout is the problem of other
people who have reimplementations of Git, but my more principled
side feels dirty, just for saying this ;-).

Thanks.


  reply	other threads:[~2026-08-04 19:32 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
2026-08-04 19:32       ` Junio C Hamano [this message]
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=xmqqldalvfzx.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /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