Show HN: A GitHub Action that creates Trusted Timestamps for your Git repo(github.com)
github.com
Show HN: A GitHub Action that creates Trusted Timestamps for your Git repo
https://github.com/marketplace/actions/timestampit
2 comments
Two questions:
1. What would happen in the event when the private key was leaked? Is there any scenario for invalidating or rotating keys?
2. For verifying the proof file, it seems like the URL for obtaining the signature key[1] is read directly off the proof file[2]. Wouldn’t that allow an attacker to publish proof files that point to their own server, hence allowing the attacker to sign fabricated files and still make them pass the automated validation?
[1]: https://github.com/timestampit/example_clients/blob/cd65e8c8...
[2]: https://github.com/timestampit/example_clients/blob/cd65e8c8...
1. What would happen in the event when the private key was leaked? Is there any scenario for invalidating or rotating keys?
2. For verifying the proof file, it seems like the URL for obtaining the signature key[1] is read directly off the proof file[2]. Wouldn’t that allow an attacker to publish proof files that point to their own server, hence allowing the attacker to sign fabricated files and still make them pass the automated validation?
[1]: https://github.com/timestampit/example_clients/blob/cd65e8c8...
[2]: https://github.com/timestampit/example_clients/blob/cd65e8c8...
Good questions. I suppose both of these issues could solved using standard x.509 certificates, which may be the next step for TimestampIt. I wanted to avoid using certificates to keep things more simple but it does leave open some issues.
To more directly answer your questions:
> 1. What would happen in the event when the private key was leaked? Is there any scenario for invalidating or rotating keys?
Right now there is no good means of invalidating a key. There is key rotation however, and upon key rotation the private key is completely deleted from all places it is stored. So I am doing everything I can to minimize exposure of the private key, but of course nothing is fool proof.
The verification scripts should be extended to verify that the timestamp occurs between the activation and retirement times for the signing key. You can see these times in the keychain: https://github.com/timestampit/keychain/blob/main/keychain.j... / https://timestampit.com/keychain.
> 2. For verifying the proof file, it seems like the URL for obtaining the signature key[1] is read directly off the proof file[2]. Wouldn’t that allow an attacker to publish proof files that point to their own server, hence allowing the attacker to sign fabricated files and still make them pass the automated validation?
This is a good call out. The verification scripts should check that the key-url has a trusted domain on it. I will make those changes soon.
I appreciate you checking out this project!
To more directly answer your questions:
> 1. What would happen in the event when the private key was leaked? Is there any scenario for invalidating or rotating keys?
Right now there is no good means of invalidating a key. There is key rotation however, and upon key rotation the private key is completely deleted from all places it is stored. So I am doing everything I can to minimize exposure of the private key, but of course nothing is fool proof.
The verification scripts should be extended to verify that the timestamp occurs between the activation and retirement times for the signing key. You can see these times in the keychain: https://github.com/timestampit/keychain/blob/main/keychain.j... / https://timestampit.com/keychain.
> 2. For verifying the proof file, it seems like the URL for obtaining the signature key[1] is read directly off the proof file[2]. Wouldn’t that allow an attacker to publish proof files that point to their own server, hence allowing the attacker to sign fabricated files and still make them pass the automated validation?
This is a good call out. The verification scripts should check that the key-url has a trusted domain on it. I will make those changes soon.
I appreciate you checking out this project!
This new GitHub Action makes it very easy to create Trusted Timestamps for any git repo on GitHub, whether it is public or private. These Trusted Timestamps protect your code inventions by proving when the code was actually pushed or merged on GitHub. Unlike regular git commits, they can not be backdated.
https://github.com/timestampit/action_test/tree/trusted_time... is an example repo with this GitHub Action setup. The trusted_timestamps branch contains the Trusted Timestamps for the code on the main branch, as well as a verify_repo_timestamp.sh script for verifying the Trusted Timestamps.
I built TimestampIt! as an exploration of using cryptography to prove what is true. Adding this GitHub Action seemed like a perfect application for Trusted Timestamps, especially for repos that are creating original code.