Trailers Containing Underscore or Dot Characters

Trailers Containing Underscore or Dot Characters

[ふじを]

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]

Re: Trailers Containing Underscore or Dot Characters

[Christian Couder]

Hi,

On Wed, Nov 13, 2024 at 8:40 AM ふじを <ffjlabo@gmail.com> wrote:
>
> 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.

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

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

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

Re: Trailers Containing Underscore or Dot Characters

[Junio C Hamano]

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.

Re: Trailers Containing Underscore or Dot Characters

[Patrick Steinhardt]

On Thu, Nov 14, 2024 at 07:31:20AM +0900, Junio C Hamano wrote:
> 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

[PATCH] Documentation/glossary: describe "trailer"

[kristofferhaugsbakk]

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

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

[Junio C Hamano]

kristofferhaugsbakk@fastmail.com writes:

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

Re: Trailers Containing Underscore or Dot Characters

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

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

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

[Christian Couder]

On Sun, Nov 17, 2024 at 8:34 PM <kristofferhaugsbakk@fastmail.com> wrote:
>
>     • 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!