Step one in making a new repo is disabling Dependabot. Automate intentionally or get pwned your choice.
Also, is automated version bumps really such a good thing? Many times I have wasted hours tracking down a bug that was introduced by bumping library. Sometimes only the patch version of the library is different so it shouldn't be breaking anything... but it does! It is so much better to update intentionally, test, deploy. Though this does assume you have a modest number of dependencies which pretty much excludes any kind of server-side javascript project.
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.
> 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.
One of Rails most under appreciated features is testing. Basically everything you can do in Rails has a way to write an automated test for it. Having good tests is a way to keep momentum as the project grows in complexity.
I love Rails. Every investment I've made in learning it has yielded returns for years. Everytime I learn a new JS framework, its obsolete two years later.
Also, is automated version bumps really such a good thing? Many times I have wasted hours tracking down a bug that was introduced by bumping library. Sometimes only the patch version of the library is different so it shouldn't be breaking anything... but it does! It is so much better to update intentionally, test, deploy. Though this does assume you have a modest number of dependencies which pretty much excludes any kind of server-side javascript project.