threads / discuss / 58837

git tag -l --format results into a malloc fatal error, if tag is signed.

Subject: git tag -l --format results into a malloc fatal error, if tag is signed.

## tl;dr

3 messages between Nov 22, 2022 and Nov 23, 2022.

replies: 2people: 3as markdown or json

Jan-Otto Kröpke· Nov 22, 2022, 08:01 UTC · lore

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue) Create a signed git tag signed by a SSH key and run this command (orginally executed by goreleaser). % git -c log.showSignature=false tag -l --format='%(contents:body)' v4.2.2

What did you expect to happen? (Expected behavior) Command executed successfully

What happened instead? (Actual behavior) % git -c log.showSignature=false tag -l --format='%(contents:body)' v4.2.2 fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes)

What's different between what you expected and what actually happened? See above

Anything else you want to add:

Reference repository: https://github.com/jkroepke/helm-secrets

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.38.1 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64 compiler info: clang: 14.0.0 (clang-1400.0.29.102) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh

[Enabled Hooks]

René Scharfe· Nov 22, 2022, 17:48 UTC · re: Jan-Otto Kröpke · lore

Re: git tag -l --format results into a malloc fatal error, if tag is signed.

Am 22.11.22 um 09:01 schrieb Jan-Otto Kröpke:

Show 15 quoted lines

> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> Create a signed git tag signed by a SSH key and run this command
> (orginally executed by goreleaser).
> % git -c log.showSignature=false tag -l --format='%(contents:body)' v4.2.2
>
> What did you expect to happen? (Expected behavior)
> Command executed successfully
>
> What happened instead? (Actual behavior)
> % git -c log.showSignature=false tag -l --format='%(contents:body)' v4.2.2
> fatal: Out of memory, malloc failed (tried to allocate
> 18446744073709551323 bytes)

Fixed by b01e1c7ef0 (ref-filter: fix parsing of signatures without blank lines, 2022-11-02). It hasn't made it into a release, yet, but I would expect it to be included in an upcoming version 2.38.2. Discussion: https://lore.kernel.org/git/Y2IfT0UFJ7H%2FmHMz@coredump.intra.peff.net/.

Show 30 quoted lines

>
>
> What's different between what you expected and what actually happened?
> See above
>
> Anything else you want to add:
>
> Reference repository: https://github.com/jkroepke/helm-secrets
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.38.1
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54
> PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
> compiler info: clang: 14.0.0 (clang-1400.0.29.102)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /bin/zsh
>
>
> [Enabled Hooks]

Junio C Hamano· Nov 23, 2022, 00:20 UTC · re: René Scharfe · lore

Re: git tag -l --format results into a malloc fatal error, if tag is signed.

René Scharfe <l.s.r@web.de> writes:

> Fixed by b01e1c7ef0 (ref-filter: fix parsing of signatures without blank
> lines, 2022-11-02).  It hasn't made it into a release, yet, but I would
> expect it to be included in an upcoming version 2.38.2.

I am fairly certain it would be in 2.39 but probably not 2.38 maintenance track, as b01e1c7ef0 seems to have been applied without considering that it is a maint-worthy material.