		"use strict";

		// Since GitHub mixes all tags into "releases" and can only sort them by tagger time, we must
		// put locks into an earlier time, so that people can still easily find real releases.
		// Luckily, tagger time can be different from the commit time as long as it's annotated.
		// The first Git commit happens on 2005-04-07T22:13Z (see https://github.com/git/git).
		// We set it to be a little after this time to respect Git.
		// The first lock's time will be 2 seconds after this time.
		/*
		Since GitHub mixes all tags into "releases" and can only sort them by tagger time, we must
		put locks into an earlier time, so that people can still easily find real releases.
		Luckily, tagger time can be different from the commit time as long as it's annotated.
		The first Git commit happens on 2005-04-07T22:13Z (see https://github.com/git/git).
		We set it to be a little after this time to respect Git.
		The first lock's time will be 2 seconds after this time.

		Only 3 subcommands can bypass the argument validation, because it's impossible.
		They are "-m", "commit" and "tag". But luckily, on one hand, "git commit -m <message>"
		is obviously safe. On the other hand, when one use "gitlock commit [...]" he must
		be aware that it has the same grammar as "git commit [...]", so it's also safe.
		The same goes for "tag" because "git tag -a -m '' <tagname>" is obviously safe.
		*/

		let TAGGER_TIME_ORIGIN = "2005-04-08T00:00:00Z";
		@@ -172,7 +181,2 @@
		}

		// These are the only 2 commands that bypass the argument validation,
		// because it's impossible. But luckily, on one hand, "git commit -m <message>"
		// is obviously safe. On the other hand, when one use "gitlock commit [...]" he must
		// be aware that it has the same grammar as "git commit [...]", so it's also safe.
		else if (args[0] === "-m") {
		@@ -521,2 +525,15 @@ assert(args.length === 2);
		}
		else if (args[0] === "tag") {
		if (args[1] === undefined) {
		let tagNames = $git.lines(["tag", "-l"]);
		tagNames.forEach(name => {
		if (!name.startsWith("gitlock-")) {
		console.log(name);
		}
		});
		}
		else {
		$git.runWithoutCapture(["tag", "-a", "-m", "", args[1]]);
		}
		}
		else if (args[0] === "config") {
		@@ -523,0 +540,0 @@ if (args.length === 1) {

package.json

		{
		"name": "gitlock",
		"version": "0.2.3",
		"version": "0.3.0",
		"description": "Add a SHA-256 wrapper to increase the security of Git. It can also protect your copyright by adding timestamps from trusted Time Stamping Authority.",
		@@ -5,0 +5,0 @@ "keywords": ["git", "lock"],

README.md

		@@ -153,5 +153,18 @@ GitLock

		### Synopsis 10: log
		### Synopsis 10: remove

		```
		gitlock remove [--last \| --commit \| --all]
		gitlock remove <commit-or-lock>
		```

		Remove locks. If `--all`, it removes all locks in the repo. If `--commit`, it removes all locks in HEAD commit. If `--last`, it removes only the last lock in the `001`, `002` sequence in HEAD commit (`000` won't be removed). The default is `--commit`.

		If you specify a commit or lock, then: If it's a commit or base lock, it will remove this lock (or the lock that matches this commit) and all succeeding locks in the commit chain, without affecting preceding locks. If it's a timestamp / signature lock, it will remove this lock and all succeeding locks in the in-commit chain, without affecting preceding locks.

		You should be very careful in removing locks. Losing an intermediate lock will make a chain broken. There're two types of lock chains: commit chain and in-commit chain. Both are important. Particularly, don't move HEAD to an intermediate commit then `gitlock remove`.

		### Synopsis 11: log

		```
		gitlock log
		@@ -162,15 +175,13 @@ ```

		### Synopsis 11: remove
		### Synopsis 12: tag

		```
		gitlock remove [--last \| --commit \| --all]
		gitlock remove <commit-or-lock>
		gitlock tag <name>
		gitlock tag
		```

		Remove locks. If `--all`, it removes all locks in the repo. If `--commit`, it removes all locks in HEAD commit. If `--last`, it removes only the last lock in the `001`, `002` sequence in HEAD commit (`000` won't be removed). The default is `--commit`.
		Add a simple annotated tag, or show tags (but excluding lock tags) if `<name>` is ommited. When adding a tag, it's similar to `git tag <name>` except that it's for annotated tag, so it's equivalent to `git tag -a -m "" <name>`. Using annotated tags brings the benefit of automatic pushing tags when using `gitlock push`.

		If you specify a commit or lock, then: If it's a commit or base lock, it will remove this lock (or the lock that matches this commit) and all succeeding locks in the commit chain, without affecting preceding locks. If it's a timestamp / signature lock, it will remove this lock and all succeeding locks in the in-commit chain, without affecting preceding locks.
		This command provides an easy way to add an annotated tag with empty message, so we call it "simple annotated" tag. To have messages, you need to use `git tag`.

		You should be very careful in removing locks. Losing an intermediate lock will make a chain broken. There're two types of lock chains: commit chain and in-commit chain. Both are important. Particularly, don't move HEAD to an intermediate commit then `gitlock remove`.

		Configuration
		@@ -218,6 +229,15 @@ =============

		Set the location of root certificates. This is for verifying. `<path>` must be a directory containing certificate files in PEM format. If there's no `<path>`, it will set this config to nothing.
		Set the location of root certificates. This is for verifying. `<path>` must be a directory containing certificate files in PEM (i.e. Base64-encoded) format. If there's no `<path>`, it will set this config to nothing.

		IMPORTANT: You must use `c_rehash` to generate `xxxxxxxx.0` files (where `x` is a hex number, see below), or manually rename the certificate file to this format, before OpenSSL can search the directory. For details see:
		For example, for Comodo timestamps, you can:

		- On Windows 10, click start button, type `certmgr.msc` in the search box and press enter, then export the `UTN-USERFirst-Object` certificate.
		- On Mac OS, open KeyChain, then export the `UTN-USERFirst-Object` certificate.
		- Or download this certificate [here](https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/910/93/
		old-utn-userfirst-object).

		Then rename the file to "`2c3e3f84.0`" (Very important. The filename must be in `xxxxxxxx.0` format).

		You can also use the command `c_rehash` to generate `xxxxxxxx.0` files. For details see:

		[https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html](https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html)
		@@ -228,6 +248,6 @@
		```bash
		the-path-to-c_rehash/c_rehash .
		path-to-c_rehash/c_rehash .
		```

		The generated symlink will be `2c3e3f84.0`.
		The generated symlink will be "`2c3e3f84.0`".

		@@ -308,1 +328,10 @@ ### Synopsis 5: lock-default
		A: It's an interval between timestamping time and pushing time. The purpose is to prevent others from timestamping immediately after you push. If there's no delay, then if someone uses a bot to listen to your Git address, he can modify your copyright info and timestamp at the same second of your timestamp. The timestamp granularity is 1 second, so the delay should be at least 1 second. We set it to 5 seconds.

		Q: Does the SHA-256 lock rely on any SHA-1?

		A: No. If it relies on any SHA-1 then the whole structure will be as weak as SHA-1. For details see `architecture.md`'s FAQ.

		Q: Why so many root certificates are still in SHA-1?

		A: Root certificates are special. System doesn't check root's signature. So it doesn't matter. See [this article](https://blog.qualys.com/ssllabs/2014/09/09/sha1-deprecation-what-you-need-to-
		know).

gitlock - npm Package Compare versions

Improved metrics