Verified_repositories/README.md

# Personal verified repositories

This repositories has two aims:
- as [the web of trust](https://en.wikipedia.org/wiki/Web_of_trust), people trusting me can trust the repositories states that I verified
- serve as a personal memo to keep track of personal verified states of repositories that *I use* and briefly comment as far as I know their legitimacy

Note that by repository state I mean the actual state of a repository at a given commit id, so marking a repository at a given commit as verified doesn't mean that previous commits were also verified. Only the resulting state at the given commit id was verified.

The current trust level is defined as looking legitimate, I don't guarantee that to the best of my knowledge there isn't any security vulnerability.

Meta-informations related to a git, such as dependencies (not the legitimate aspect but the verified one), issues, pull requests..., aren't verified yet but may be in the future, if so it would be precised as such.

Default template:

```json
{
    // Mandatory: git state hash verified.
    "commit": "0123456789abcdef0123456789abcdef01234567",
    // Optional (default: "VERIFIED"): xor of following flags (written as `FLAG_0 | FLAG_1 | ... | FLAG_N`):
    // - `VERIFIED_ONLY_OWN_COMMITS`: means that the whole git state wasn't verified but the verifier commits were verified (note that using this flag for repositories that aren't managed by the verifier requires verifier commits to be signed and to precise the fingerprint of his public key in this `README.md` for instance)
    // - `CLOSED_SOURCE_DEPENDENCY`
    // - `UNVERIFIED_INITIAL_COMMIT`
    "status": "VERIFIED",
    // Optional (default: ""): verifier comment concerning the git state verified
    "comment": ""
}
```
Add `README.md` 2023-01-31 23:43:23 +01:00			`# Personal verified repositories`

			`This repositories has two aims:`
			`- as [the web of trust](https://en.wikipedia.org/wiki/Web_of_trust), people trusting me can trust the repositories states that I verified`
Precise the current trust level target in `README.md` I thought about adding the following convention: > Current convention is such that if a folder exists but just contains `.gitkeep`, it means that everything that could fall into this folder and isn't existing is considered as verified. This would be useful for personal git users, but it's an edge case and would anyway need to precise an overwhole git user gits hash to confirm a statement at a given gits state. So let's keep the same convention for every git. 2023-02-01 00:38:24 +01:00			`- serve as a personal memo to keep track of personal verified states of repositories that I use and briefly comment as far as I know their legitimacy`

Precise the notion of repository state in `README.md` 2023-02-01 00:44:53 +01:00			`Note that by repository state I mean the actual state of a repository at a given commit id, so marking a repository at a given commit as verified doesn't mean that previous commits were also verified. Only the resulting state at the given commit id was verified.`

Precise the current trust level target in `README.md` I thought about adding the following convention: > Current convention is such that if a folder exists but just contains `.gitkeep`, it means that everything that could fall into this folder and isn't existing is considered as verified. This would be useful for personal git users, but it's an edge case and would anyway need to precise an overwhole git user gits hash to confirm a statement at a given gits state. So let's keep the same convention for every git. 2023-02-01 00:38:24 +01:00			`The current trust level is defined as looking legitimate, I don't guarantee that to the best of my knowledge there isn't any security vulnerability.`

			`Meta-informations related to a git, such as dependencies (not the legitimate aspect but the verified one), issues, pull requests..., aren't verified yet but may be in the future, if so it would be precised as such.`
Add default template to `README.md` introducing `status` and `comment` optional fields 2023-02-01 01:20:48 +01:00
			`Default template:`

			```json
			`{`
			`// Mandatory: git state hash verified.`
			`"commit": "0123456789abcdef0123456789abcdef01234567",`
			// Optional (default: "VERIFIED"): xor of following flags (written as `FLAG_0 \| FLAG_1 \| ... \| FLAG_N`):
Add a description to `VERIFIED_ONLY_OWN_COMMITS` `status` flag in `README.md` template Note that here I talk about commits and not git state. I don't even know if talking about global commits diff like a git state diff make sense as commits happening between the first and last known to date verifier can contain commits from other users. 2023-02-01 01:48:20 +01:00			// - `VERIFIED_ONLY_OWN_COMMITS`: means that the whole git state wasn't verified but the verifier commits were verified (note that using this flag for repositories that aren't managed by the verifier requires verifier commits to be signed and to precise the fingerprint of his public key in this `README.md` for instance)
Add default template to `README.md` introducing `status` and `comment` optional fields 2023-02-01 01:20:48 +01:00			// - `CLOSED_SOURCE_DEPENDENCY`
			// - `UNVERIFIED_INITIAL_COMMIT`
			`"status": "VERIFIED",`
			`// Optional (default: ""): verifier comment concerning the git state verified`
			`"comment": ""`
			`}`
			```