Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to specify a timestamp server #47

Open
onovotny opened this issue Dec 15, 2018 · 26 comments

Comments

Projects
None yet
4 participants
@onovotny
Copy link

commented Dec 15, 2018

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?

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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.

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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?

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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?

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

@bufferoverflow

This comment has been minimized.

Copy link

commented Dec 17, 2018

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

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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.

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

@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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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.

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

@onovotny

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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

@onovotny

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

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.

@onovotny

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

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.

@mastahyeti

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

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 😦

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.