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.

[henning-schild]

@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?

I do not know, and i guess the following: Signature made with the cert within its period, should be valid forever, unless the cert gets revoked ... which might shorten the time or make all invalid. And gpgsm probably just takes the current time of the machine, so i guess one could create a valid signature with an expired ... revoked cert.

[btoews]

The inability to verify old signatures from expired GPG key or X.509 certificates is a huge deficiency of signing Git commits/tags currently. Adding RFC3161 timestamps, especially since they are supported by S/MIME, is a big usability improvement.

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

Gpgsm includes the entire certificate chain (except for the root) in each signature. This is about 5KB for my DigiCert certificate, but could easily be ten times that size when dealing with the US federal government's CAs. My understanding is that this added bloat is likely to cause significant performance issues for large repositories. If it can be assumed that verifiers know how to reconstruct the chain, it would be very beneficial to not include it in every signature.

More generally though, my point here was that user's might want to customize other aspects of Git signing by passing additional arguments to the signing tool.

[btoews]

And gpgsm probably just takes the current time of the machine, so i guess one could create a valid signature with an expired ... revoked cert.

Yes. This is a big problem for gpg and gpgsm.

[henning-schild]

I guess the whole timestamp story is again a story of trust and not of authenticity. You would not want to distrust a whole repo because the key of the maintainer got revoked some day, you would need to trust the (new) maintainer to not merge commits signed with the revoked key anymore.
So the easy answer is that it is outside the scope of the git signing-/verification-tool. And my gut feeling is that smimesign will get it wrong without involving git and gnupg upstream.

[clairernovotny]

I would argue that it's about authenticity and that timestamps help verify that the key was used before it was expired or revoked. That should not need to be a manual process, relying on a maintainer to check that. Without a timestamp, how can you be sure of authenticity? IMO, timestamps have nothing to do with trust.

I agree though that this should be involving git upstream.

[btoews]

Smimesign isn't exactly reinventing the wheel. Timestamps are explicitly designed to work with CMS. See Appendix A of RFC3161.

[clairernovotny]

@mastahyeti Agreed. I'm suggesting that the Git ecosystem needs to embrace timestamps all-up.

[clairernovotny]

Bump, any movement here?

There's two issues:

1. It seems like the Git ecosystem needs to have a discussion around timestamps. This would affect both GPG and S/MIME as even with GPG, how would you know if a signed commit is valid if a key is revoked or expired? Local computer time is untrustworthy.
2. If there's a easy way to get it working with smimesign

[btoews]

No movement. Sorry. My current thinking is to have smimesign use the Git config for storing some options. That will take some effort to implement though. I can't make promises about when I'll get around to it. In the meantime, I'd recommend using a script that wraps smimesign as discussed above.

[clairernovotny]

My attempts at that failed (to work correctly on Windows). If you could maybe provide that, it'd help. You can see my failed attempts here: https://github.com/onovotny/MSBuildSdkExtras/commits/test

The last one is when I finally built smimesign from source and specified the defaultTSA (which was painful since it also required GCC in the path, something to add to the readme...).

I couldn't figure out how to display the full signature with timestamp though; the GitHub UI doesn't show the timestamp either.

[btoews]

My attempts at that failed (to work correctly on Windows). If you could maybe provide that, it'd help. You can see my failed attempts here: https://github.com/onovotny/MSBuildSdkExtras/commits/test

I just created a wrapped.cmd file in a Windows VM with the following contents

@echo off
smimesign.exe --timestamp-authority http://timestamp.digicert.com %*

I put this file in a directory on my %PATH% and then did git config --global gpg.program wrapped.cmd. My commits are now signed with smimesign and include a timestamp.

I couldn't figure out how to display the full signature with timestamp though; the GitHub UI doesn't show the timestamp either.

Unfortunately, github.com support for timestamp verification is currently blocked on ruby/openssl#204 😦

[bufferoverflow]

@mastahyeti Great to see the TSA functionality landed within ruby openssl!

I was thinking about the config ui for this, I think it should be git config --global gpg.x509.tsa http://timestamp.digicert.com

My ~/.gitconfig looks then like this:

[gpg "x509"]
	program = smimesign
	tsa = http://timestamp.digicert.com

@henning-schild Is there a best practice for optional configs or should e.g. tsa be added to the allowed configs with doc somehow?

[henning-schild]

As far as i know gpg(sm) does not support tsa and git does not either. So it would be a config key for smimesign, maybe better kept in a separate configfile.
I do not know whether "plugins" are allowed to define their own values and where those should go.

[bufferoverflow]

Other git-related tools may and do use their own variables. When inventing new variables for use in your own tool, make sure their names do not conflict with those that are used by Git itself and other popular tools, and describe them in your documentation.

The use of the config key gpg.x509.tsa is possible according to the git documentation, see https://git-scm.com/docs/git-config#_variables

[henning-schild]

I would go for gpg.x509.smimesign-tsa or smimesign.tsa, just to avoid a possible future collision.

[bufferoverflow]

@mastahyeti Simplify developers life by providing such an option recognized by smimesign would be cool. What do you think?

[btoews]

Yes. I'm definitely in favor of adding the ability to read a TSA option from the git config. I'd like to work on this as well as adding support to GitHub.com. Given other, competing priorities though, I haven't had a chance yet and I'm not sure when I will.