platform-samples
opentimestamps-client
platform-samples | opentimestamps-client | |
---|---|---|
3 | 2 | |
1,858 | 283 | |
0.3% | 0.0% | |
7.2 | 2.6 | |
5 days ago | about 2 months ago | |
Shell | Python | |
Creative Commons Zero v1.0 Universal | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
platform-samples
-
Signing Git Commits with Your SSH Key
> Note that signing commits doesn't bar bad actors from pushing unsigned commits with forged identities.
This would need to be coupled with a "reject unsigned commits" policy on push. For example - https://docs.gitlab.com/ee/user/project/repository/push_rule...
And note that the caveats that it has would require the person to log in to gitlab to not need to push (by using the webIDE instead) which leaves an audit trail there.
Similar functionality can be crafted with a pre-receive commit hook - https://docs.github.com/en/[email protected]/admin/polic...
An example of such a hook - https://github.com/github/platform-samples/blob/master/pre-r...
-
Strange use case and was wondering if this is possible
I want to write a function in node.js(typescript) so I can access a public remote Github repo for example: "https://github.com/github/platform-samples" then lists the folders/directories in json output and eventually download/copy one specific folder
- is this the standard way to write pom ?
opentimestamps-client
-
📑 MiniBolt resources 📚 List of the MiniBolt core/bonus guides + latest versions
OpenTimeStamp-client v0.7.1 (Released: 26th August 2022) - https://github.com/opentimestamps/opentimestamps-client/releases
-
Signing Git Commits with Your SSH Key
if you sign your commits, you should also consider timestamping your commits. I use OpenTimestamps for this. Docs and some rationale here: https://github.com/opentimestamps/opentimestamps-client/blob...
from the doc:
> My signing keys (e.g. blog or Qubes code signing keys) do not have expiration dates. This is not laziness. There is a fundamental problem with using an expiration date on keys used for code signing (e.g. git tag -s), because it is unclear what the outcome should be when one verifies some old code (written and signed when the key was still valid) in the future when the key has already expired?
> Naturally we would like the old code, written and signed when the key was still valid, to continue to verify fine also in the future, after the key expires (and the developer passed away, perhaps). However, it is very problematic to prevent the attacker from creating falsified code pretending to be an old one.
What are some alternatives?
smimesign - An S/MIME signing utility for use with Git
rebalance-lnd - A script that can be used to balance lightning channels of a lnd node