ready for new release; docs update.

This commit is contained in:
2021-12-13 00:18:36 -05:00
parent 55e740793a
commit df86089517
3 changed files with 174 additions and 78 deletions

60
doc.go
View File

@@ -43,13 +43,13 @@ SecretService Concepts
For reference:
- A Service allows one to operate on/with Session objects.
- A Service allows one to retrieve and operate on/with Session and Collection objects.
- A Session allows one to operate on/with Collection objects.
- A Session allows one to operate on/with Item objects (e.g. parsing/decoding/decrypting them).
- A Collection allows one to operate on/with Item objects.
- A Collection allows one to retrieve and operate on/with Item objects.
- An Item allows one to operate on/with Secrets.
- An Item allows one to retrieve and operate on/with Secret objects.
(Secrets are considered "terminating objects" in this model, and contain actual secret value(s) and metadata).
@@ -59,44 +59,30 @@ So the object hierarchy in THEORY looks kind of like this:
Service
├─ Session "A"
├─ Collection "A.1"
│ │ ├─ Item "A.1.a"
│ │ ├─ Secret "A_1_a_I"
│ │ │ └─ Secret "A_1_a_II"
│ │ └─ Item "A.1.b"
│ ├─ Secret "A_1_b_I"
│ └─ Secret "A_1_b_II"
│ └─ Collection "A.2"
│ ├─ Item "A.2.a"
│ │ ├─ Secret "A_2_a_I"
─ Secret "A_2_a_II"
└─ Item "A.2.b"
│ ├─ Secret "A_2_b_I"
─ Secret "A_2_b_II"
└─ Session "B"
├─ Collection "B.1"
│ ├─ Item "B.1.a"
│ │ ├─ Secret "B_1_a_I"
│ │ └─ Secret "B_1_a_II"
│ └─ Item "B.1.b"
│ ├─ Secret "B_1_b_I"
│ └─ Secret "B_1_b_II"
└─ Collection "B.2"#
├─ Item "B.2.a"
│ ├─ Secret "B_2_a_I"
│ └─ Secret "B_2_a_II"
└─ Item "B.2.b"
├─ Secret "B_2_b_I"
└─ Secret "B_2_b_II"
├─ Session "B"
├─ Collection "A"
├─ Item "A.1"
│ │ ─ Secret "A_1_a"
│ │ └─ Secret "A_1_b"
└─ Item "A.2"
─ Secret "A_2_a"
└─ Secret "A_2_b"
└─ Collection "B"
├─ Item "B.1"
─ Secret "B_1_a"
│ └─ Secret "B_1_b"
└─ Item "B.2"
─ Secret "B_2_a"
└─ Secret "B_2_b"
And so on.
In PRACTICE, however, most users will only have two Session types
(a default "system" one and a temporary one that may or may not exist, running in memory for the current login session)
and a single Collection, named "login" (and aliased to "default", usually).
In PRACTICE, however, most users will only have two Collection items
(a default "system" one named "login", which usually is unlocked upon login,
and a temporary one that may or may not exist, running in memory for the current login session named `session`).
Usage
Full documentation can be found via inline documentation.
Additionally, use either https://pkg.go.dev/r00t2.io/gosecret or https://pkg.go.dev/golang.org/x/tools/cmd/godoc (or `go doc`) in the source root.
*/
package libsecret
package gosecret