threads / discuss / 62486

Trailers Containing Underscore or Dot Characters

Subject: Trailers Containing Underscore or Dot Characters

## tl;dr

8 messages between Nov 13, 2024 and Nov 18, 2024.

replies: 7people: 5as markdown or json

ふじを· Nov 13, 2024, 07:40 UTC · lore

Hi everyone, First of all, thank you for making such a tool. I am grateful to use this tool every day.

I encountered the issue with trailers containing Underscore or Dot characters. I don't know if this behavior is OK as a specification, or not. So I created the post.

What did you do before the bug happened? (Steps to reproduce your issue)
I added coommit with trailers which have "_" or "." in each key.
```
git commit -m "Test" --trailer "test_hoge: fuga" --trailer "test.hoge:
fuga" --trailer "test-hoge: fuga"
```
What did you expect to happen? (Expected behavior)
I expcted that they are shown like this.
```
# git show
    Test
    test_hoge: fuga
    test.hoge: fuga
    test-hoge: fuga
```
What happened instead? (Actual behavior)
Actually, some of them are unexpected value.
```
# git show
commit 70afae811def2345bead6660e0f3183662c9f4df (HEAD -> master)
Author: Your Name <you@example.com>
Date:   Wed Nov 13 08:28:19 2024 +0300
    Test
    test_hoge: fuga:
    test.hoge: fuga:
    test-hoge: fuga
```
What's different between what you expected and what actually happened?

The one for `--trailer "test-hoge: fuga"` is finished with nothing. But The others for ones which have "_" or "." are finished with ":".

Anything else you want to add:

I want to use such characters to add some key-value received other service (e.g. GitHub Actions) as is. Is there any chance that characters like _ and . will be allowed in the trailer's key?

By the way, I tried the investigation for the current specification. I hope this is helpful in some way.

[1] This behavior occured when executing `git interpret-trailers`. ``` # echo msg > msg # git interpret-trailers --trailer "test_hoge: test" --trailer "test.hoge: test" --trailer "test-hoge: test" --in-place msg ``` ``` # cat msg msg test_hoge: test: test.hoge: test: test-hoge: test ``` [2] There might be the cause in the process of the persing trailers. if they have such characters, the whole of the trailer option values are interpreted as one token even though they have ":" if they have such characters.

I checked the source code at
- parse_trailers_from_command_line_args
https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L748C1-L764C4
- -> find_separator
https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L614C1-L642C1

[System Info] git version: git version 2.43.0 cpu: aarch64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.10.11-orbstack-00280-g1304bd068592 #21 SMP Sat Sep 21 10:45:28 UTC 2024 aarch64 compiler info: gnuc: 13.2 libc info: glibc: 2.39 $SHELL (typically, interactive shell): <unset> [Enabled Hooks]

Christian Couder· Nov 13, 2024, 21:57 UTC · re: ふじを · lore

Re: Trailers Containing Underscore or Dot Characters

Hi,
On Wed, Nov 13, 2024 at 8:40 AM ふじを <ffjlabo@gmail.com> wrote:
Show 44 quoted lines
>
> Hi everyone,
> First of all, thank you for making such a tool. I am grateful to use
> this tool every day.
>
> I encountered the issue with trailers containing Underscore or Dot characters.
> I don't know if this behavior is OK as a specification, or not. So I
> created the post.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> I added coommit with trailers which have "_" or "." in each key.
> ```
> git commit -m "Test" --trailer "test_hoge: fuga" --trailer "test.hoge:
> fuga" --trailer "test-hoge: fuga"
> ```
> What did you expect to happen? (Expected behavior)
> I expcted that they are shown like this.
> ```
> # git show
>     Test
>     test_hoge: fuga
>     test.hoge: fuga
>     test-hoge: fuga
> ```
>
> What happened instead? (Actual behavior)
>
> Actually, some of them are unexpected value.
> ```
> # git show
> commit 70afae811def2345bead6660e0f3183662c9f4df (HEAD -> master)
> Author: Your Name <you@example.com>
> Date:   Wed Nov 13 08:28:19 2024 +0300
>     Test
>     test_hoge: fuga:
>     test.hoge: fuga:
>     test-hoge: fuga
> ```
>
> What's different between what you expected and what actually happened?
>
> The one for `--trailer "test-hoge: fuga"` is finished with nothing.
> But The others for ones which have "_" or "." are finished with ":".
Yeah, that's because '-' is allowed in trailer keys while '_' and '.' are not.

The underlying issue is that when we are given a full commit message that might contain trailers and we have to parse it and find the trailers in it, the more special characters we allow in trailer keys, the higher the risk that regular text will be wrongly considered trailer keys.

Show 6 quoted lines
> Anything else you want to add:
>
> I want to use such characters to add some key-value received other
> service (e.g. GitHub Actions) as is.
> Is there any chance that characters like _ and . will be allowed in
> the trailer's key?

It's true that for trailers that are passed through --trailer options, we could probably relax the restrictions for trailer keys. We could also add config options to be more flexible in the general case. I think patches implementing these could be well received.

Show 16 quoted lines
> By the way, I tried the investigation for the current specification.
> I hope this is helpful in some way.
>
> [1] This behavior occured when executing `git interpret-trailers`.
> ```
> # echo msg > msg
> # git interpret-trailers --trailer "test_hoge: test" --trailer
> "test.hoge: test" --trailer "test-hoge: test" --in-place msg
> ```
> ```
> # cat msg
> msg
> test_hoge: test:
> test.hoge: test:
> test-hoge: test
> ```

Yeah `git commit --trailer ...` and `git interpret-trailers ...` use the same underlying trailer parsing code.

Show 10 quoted lines
> [2] There might be the cause in the process of the persing trailers.
> if they have such characters, the whole of the trailer option values
> are interpreted as one token even though they have ":" if they have
> such characters.
>
> I checked the source code at
> - parse_trailers_from_command_line_args
> https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L748C1-L764C4
> - -> find_separator
> https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L614C1-L642C1

Yeah, find_separator() could definitely have options to be more relaxed about what a trailer key is.

Best, Christian.

Junio C Hamano· Nov 13, 2024, 22:31 UTC · re: Christian Couder · lore

Re: Trailers Containing Underscore or Dot Characters

Christian Couder <christian.couder@gmail.com> writes:
Show 13 quoted lines
>> Date:   Wed Nov 13 08:28:19 2024 +0300
>>     Test
>>     test_hoge: fuga:
>>     test.hoge: fuga:
>>     test-hoge: fuga
>> ```
>>
>> What's different between what you expected and what actually happened?
>>
>> The one for `--trailer "test-hoge: fuga"` is finished with nothing.
>> But The others for ones which have "_" or "." are finished with ":".
>
> Yeah, that's because '-' is allowed in trailer keys while '_' and '.' are not.
Thanks for responding.

I did not offhand recall seeing anywhere in our documentation set that defines what a valid trailer key looks like, so I went and read the interpret-trailers manual page and did not find any. For example, is this a valid trailer line, even if we know '-' is "allowed in trailer keys"?

	-test: fuga

Is this a valid trailer line, when your configuration adds '-' to the set of separator characters?

	test- fuga

We do not even have an entry in the glossary for "trailer", and that probably is the first thing we need to fix.

Patrick Steinhardt· Nov 15, 2024, 07:42 UTC · re: Junio C Hamano · lore

Re: Trailers Containing Underscore or Dot Characters

On Thu, Nov 14, 2024 at 07:31:20AM +0900, Junio C Hamano wrote:
Show 33 quoted lines
> Christian Couder <christian.couder@gmail.com> writes:
> 
> >> Date:   Wed Nov 13 08:28:19 2024 +0300
> >>     Test
> >>     test_hoge: fuga:
> >>     test.hoge: fuga:
> >>     test-hoge: fuga
> >> ```
> >>
> >> What's different between what you expected and what actually happened?
> >>
> >> The one for `--trailer "test-hoge: fuga"` is finished with nothing.
> >> But The others for ones which have "_" or "." are finished with ":".
> >
> > Yeah, that's because '-' is allowed in trailer keys while '_' and '.' are not.
> 
> Thanks for responding.
> 
> I did not offhand recall seeing anywhere in our documentation set
> that defines what a valid trailer key looks like, so I went and read
> the interpret-trailers manual page and did not find any.  For
> example, is this a valid trailer line, even if we know '-' is
> "allowed in trailer keys"?
> 
> 	-test: fuga
> 
> Is this a valid trailer line, when your configuration adds '-' to
> the set of separator characters?
> 
> 	test- fuga
> 
> We do not even have an entry in the glossary for "trailer", and that
> probably is the first thing we need to fix.

The second thing we should be fixing is that git-interpret-trailers(1) allows us to add invalid trailers:

    $ touch file
    $ git interpret-trailers --in-place file --trailer 'Valid-trailer: bar'
    $ git interpret-trailers --parse file
    Valid-trailer: bar
    $ git interpret-trailers --in-place file --trailer 'Invalid_trailer: bar'
    $ git interpret-trailers --parse file
    $ cat file
    Valid-trailer: bar
    Invalid_trailer: bar:

After the second invocation of git-interpret-trailers(1) it is unable to find any trailers anymore due to the bogus format of the second trailer line.

Patrick
Junio C Hamano· Nov 18, 2024, 01:07 UTC · re: Patrick Steinhardt · lore

Re: Trailers Containing Underscore or Dot Characters

Patrick Steinhardt <ps@pks.im> writes:
Show 17 quoted lines
> The second thing we should be fixing is that git-interpret-trailers(1)
> allows us to add invalid trailers:
>
>     $ touch file
>     $ git interpret-trailers --in-place file --trailer 'Valid-trailer: bar'
>     $ git interpret-trailers --parse file
>     Valid-trailer: bar
>     $ git interpret-trailers --in-place file --trailer 'Invalid_trailer: bar'
>     $ git interpret-trailers --parse file
>     $ cat file
>
>     Valid-trailer: bar
>     Invalid_trailer: bar:
>
> After the second invocation of git-interpret-trailers(1) it is unable to
> find any trailers anymore due to the bogus format of the second trailer
> line.

A good point. Thanks.

kristofferhaugsbakk@fastmail.com· Nov 17, 2024, 19:33 UTC · re: Junio C Hamano · lore

[PATCH] Documentation/glossary: describe "trailer"

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
    On Wed, Nov 13, 2024, at 23:31, Junio C Hamano wrote:
    > Christian Couder <christian.couder@gmail.com> writes:
    > > [...]
    > We do not even have an entry in the glossary for "trailer", and that
    > probably is the first thing we need to fix.
    
    ---
    
    • Tags: What the Linux Kernel uses
    • Footers: Lots of people around the Internet apparently. Like on
      Stackoverflow. Or Chromium: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-footers.html
 Documentation/glossary-content.txt | 5 +++++
 1 file changed, 5 insertions(+)
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 42afe048691..575c18f776e 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -696,6 +696,11 @@ the `refs/tags/` hierarchy is used to represent local tags..
 	that each contain very well defined concepts or small incremental yet
 	related changes.
 
+[[def_trailer]]trailer::
+	Key-value metadata.  Trailers are optionally found at the end of
+	a commit message.  Might be called "footers" or "tags" in other
+	communities.  See linkgit:git-interpret-trailers[1].
+
 [[def_tree]]tree::
 	Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
 	object>> together with the dependent <<def_blob_object,blob>> and tree objects
-- 
2.47.0
Junio C Hamano· Nov 18, 2024, 00:40 UTC · re: kristofferhaugsbakk@fastmail.com · lore

Re: [PATCH] Documentation/glossary: describe "trailer"

kristofferhaugsbakk@fastmail.com writes:
Show 12 quoted lines
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index 42afe048691..575c18f776e 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -696,6 +696,11 @@ the `refs/tags/` hierarchy is used to represent local tags..
>  	that each contain very well defined concepts or small incremental yet
>  	related changes.
>  
> +[[def_trailer]]trailer::
> +	Key-value metadata.  Trailers are optionally found at the end of
> +	a commit message.  Might be called "footers" or "tags" in other
> +	communities.  See linkgit:git-interpret-trailers[1].
Sounds sensible.
Christian Couder· Nov 18, 2024, 07:32 UTC · re: kristofferhaugsbakk@fastmail.com · lore

Re: [PATCH] Documentation/glossary: describe "trailer"

On Sun, Nov 17, 2024 at 8:34 PM <kristofferhaugsbakk@fastmail.com> wrote:
Show 21 quoted lines
>
>     • Tags: What the Linux Kernel uses
>     • Footers: Lots of people around the Internet apparently. Like on
>       Stackoverflow. Or Chromium: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-footers.html
>
>  Documentation/glossary-content.txt | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index 42afe048691..575c18f776e 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -696,6 +696,11 @@ the `refs/tags/` hierarchy is used to represent local tags..
>         that each contain very well defined concepts or small incremental yet
>         related changes.
>
> +[[def_trailer]]trailer::
> +       Key-value metadata.  Trailers are optionally found at the end of
> +       a commit message.  Might be called "footers" or "tags" in other
> +       communities.  See linkgit:git-interpret-trailers[1].
> +
Ack, thanks!

← back to recent threads