threads / discuss / 63946

Signing commits and tags differently

Subject: Signing commits and tags differently

## tl;dr

2 messages between Aug 12, 2025 and Aug 12, 2025.

replies: 1people: 2as markdown or json

Andrea Pappacoda· Aug 12, 2025, 15:18 UTC · lore
Hi all!

I would like to configure Git to automatically sign commits using SSH keys, while using OpenPGP when creating signed tags. As far as I can tell, this isn't currently possible.

What I was thinking about were a couple of options like commit.gpg.format and tag.gpg.format, as we already have commit.gpgSign and tag.gpgSign. Of course, differently namespaced options like gpg.tag.format would work too.

What do you think? Does this make any sense to you? Let me know!
Bye :)
P.S. please keep me CC'd; I'm not subscribed
brian m. carlson· Aug 12, 2025, 21:16 UTC · re: Andrea Pappacoda · lore

Re: Signing commits and tags differently

On 2025-08-12 at 15:18:19, Andrea Pappacoda wrote:
> Hi all!
Hi,
> I would like to configure Git to automatically sign commits using SSH keys,
> while using OpenPGP when creating signed tags. As far as I can tell, this
> isn't currently possible.

I agree this isn't possible with the default commands, although you could solve with with an alias (such as `alias.signed-tag="!f() { git -c gpg.format=openpgp tag "$@"; };f"`).

I'm interested to hear more about your use case for this split, since it's the first time I've heard about someone wanting to do this.

Show 5 quoted lines
> What I was thinking about were a couple of options like commit.gpg.format
> and tag.gpg.format, as we already have commit.gpgSign and tag.gpgSign. Of
> course, differently namespaced options like gpg.tag.format would work too.
> 
> What do you think? Does this make any sense to you? Let me know!

I don't have a strong opinion about adding this feature or not (especially since I don't know about your use case), but I think if this feature were implemented we'd need to have the format options default to the current config option to not regress functionality for existing users.

There's also the issue that this makes verification more difficult. After all, you sign the data once, but presumably the data is verified many times by many different users (or software acting on their behalf, such as a forge). That means that we'd either need to autodetect the signature and invoke the right tool (which we may already do) or every individual user would need to have the appropriate configuration set up for both.

Again, no strong opinions here, just thoughts about what an implementation might look like.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

← back to recent threads