How to specify a timestamp server

[clairernovotny]

The utility supports a timestamp parameter, but it's not clear how to specify it in the git configuration so that it's used.

How do we specify the timestamp server to use?

[btoews]

There is no way to tell Git what arguments to pass to smimesign. You have two options for making smimesign use a timestamp server when used with Git. The first would be to create a shell script that wraps smimesign and adds additional arguments. You would then tell Git to use this wrapper script for signing instead of having it call smimesign directly. The second option is to specify a default timestamp server when compiling smimesign.

smimesign/main.go

Lines 20 to 22 in 6eb0038

	// default timestamp authority URL. This can be set at build time by running
	// go build -ldflags "-X main.defaultTSA=${https://whatever}"
	defaultTSA = ""

In the long run, I'd like to add a smimesign --install command that creates a wrapper script for the smimesign binary, installs it on the user's path, and configures Git to use it.

[clairernovotny]

Would it be possible to have the tool check an environment variable? I'd really like to avoid having to build the tool bespoke to hard-code it.

[btoews]

That could be added if it were useful. Is there a way to get Git to set an environment variable based on the Git config, or would the idea be to have a variable that you set in your bash profile?

[clairernovotny]

Given that timestamp servers don't generally care about the user or the signing cert, I'd be okay with having it set for my profile all-up.

It could also use a .smimesignconfig file in my profile directory as that could give you more flexibility later if you need additional configuration.

Like that config file could have a mapping of email addresses to thumbprints in case there's multiple email addresses with each having multiple matching certs available.

[btoews]

I'd like to avoid going down the path of a separate config file for this tool, though maybe that isn't reasonable. What are your thoughts on installing a wrapper script on the PATH that adds arguments?

[clairernovotny]

Where would that wrapper script go; would that directory be easily user-editable?

[clairernovotny]

Also, does git ignore extra sections? You could potentially piggyback on the user's profile-wide gitconfig file and add a config section in it.

[btoews]

Where would that wrapper script go; would that directory be easily user-editable?

I'm not sure. Maybe running smimesign --install --include-certs=-3 --timestamp-authority= http://timestamp.digicert.com would create a ~/bin/smimesign-wrapped like

#!/bin/sh

smimesign --include-certs=-3 --timestamp-authority= http://timestamp.digicert.com "$@"

and then run git config --local gpg.program smimesign-wrapped. I'm not sure if there's a more appropriate directory.

Also, does git ignore extra sections? You could potentially piggyback on the user's profile-wide gitconfig file and add a config section in it.

Git should ignore extra sections. I can ask around to see how terrible this would be.

[bufferoverflow]

I think this is also relevant for gpg signed commits.
@henning-schild What do you think about it?

[btoews]

Definitely an issue for gpgsm too. It would be nice to be able to specify --include-certs for that tool also.

[bufferoverflow]

... sounds like something to fix upstream, not with wrappers...

[btoews]

Yeah. I agree that adding another Git config entry to specifying additional signing tool arguments would be ideal. I don't have time to work on this right now and have forgotten the Git syntax for emailing patches, unfortunately.

[henning-schild]

Let us stick to the topic. I think that git does not actually support RFC3161 timestamps, hence there will not be an argument to the gpg.XXX.program to use it. Whatever smimesign invents to make it work, the official git-supported tools (gpg and gpgsm) will not understand it. So i guess having that feature in just one non-official tool is not a good idea. In fact it should be marked as such.

The second thing --include-certs, i am not sure what that is supposed to do.

[clairernovotny]

@henning-schild For gpgsm, do they ignore certificate validity periods? How do they assess valid signatures (or do they accept anything)? Is it worth having a discussion around having gpgsm support timestamps?

[henning-schild]

Like that config file could have a mapping of email addresses to thumbprints in case there's multiple email addresses with each having multiple matching certs available.

For verification whether a signature is valid, that should not matter at all. For signing you have to tell git which key to use. And if we are talking about trust, that is outside the scope of verification and could potentially be relevant for smimesign. Or it should be offloaded to the Windows/Mac key/cert store.
On Linux you keep your trust in your configuration of gpg(sm), but for git and its signingtool it is just about signature and authenticity.