docs: Remove experimental flags and other minor docs changes

docs/adr/ADR-8_go-transition.md

@@ -1,43 +1,60 @@
-# ADR 8: Transition to golang
+# ADR 8: Transition to Golang
 
 ## Status
 
-Undecided
+Accepted
 
 ## Context
 
-Connaisseur was written in python, mostly because of a preference of language inside the team. This is completely fine and worked for many years, but over the time it became more apparent that other programming languages might be better suited for the task, namely golang. The main reasons for this are:
+Connaisseur was orignally written in Python, mostly because of a preference of language in the team.
+This was completely fine and worked for many years, but over the time it became more apparent that other programming languages might be better suited for the task, namely Golang.
+The main reasons for this are:
 
-- The signature schemes (cosign, notaryv1, notaryv2) are written in golang, which means that they can be directly used in that language. For python, this had to be circumvented by using either a compiled version of the schemes as binaries, which may bloat the image size and are not as easy to use, or writing an own implementation in python. Switching to golang allows for better and probably faster integration of the schemes, giving a broader choice of signature providers to the community.
-- The resulting Connaisseur container will be more secure, as golang is a compiled language, which means that the resulting binary can be run without any interpreter. This has implication on the use of base images, as golang can use distroless images, which are more secure than the python equivalent.
-- Golang is THE kubernetes language. Most of the tools in the ecosystem are written in golang, thus the broader community is a lot more familiar with it. This will make it easier for people to contribute to Connaisseur.
+- The signature schemes (Cosign, Notary, Notation) are written in Golang, which means that they can be directly used in that language.
+For Python, this had to be circumvented by using either a compiled version of the schemes as binaries, which bloat image size and are not as easy to use, or writing an own implementation in Python.
+Switching to Golang allows for better and probably faster integration of the schemes, giving a broader choice of signature providers to the community.
+- The resulting Connaisseur container will be more secure, as Golang is a compiled language, which means that the resulting binary can be run without any interpreter.
+This has implication on the use of base images, as Golang can use scratch images, which are more secure than the Python equivalent bringing OS and runtime.
+- Golang is THE Kubernetes language.
+Most of the tools in the ecosystem are written in Golang, thus the broader community is a lot more familiar with it.
+This will make it easier for people to contribute to Connaisseur.
 
-This ADR discusses whether a transition to golang is worth the effort and how it would play out.
+This ADR discusses whether a transition to Golang is worth the effort and how it would play out.
 
 ## Considered Options
 
-### Option 1: Stay with python
+### Option 1: Stay with Python
 
-No transition will be made. The python code base is kept and continuously developed. Resources can be spend on improving the existing code base and adding new features. Adding new signature schemes will be more difficult, as they either have to be implemented in python, or other workarounds have to be found.
+No transition will be made.
+The Python code base is kept and continuously developed.
+Resources can be spend on improving the existing code base and adding new features.
+Adding new signature schemes will be more difficult, as they either have to be implemented in Python, or other workarounds have to be found.
 
 
-### Option 2: Transition to golang
+### Option 2: Transition to Golang
 
-The python code base is abandoned and a new code base is written in golang. This will allow for easier integration of new signature schemes and a more secure container image. It will also open up the project to the Kubernetes/golang community, while shutting down the python one. The transition will require a lot of work and will take some time
+The Python code base is abandoned and a new code base is written in Golang.
+This will allow for easier integration of new signature schemes and a more secure container image.
+It will also open up the project to the Kubernetes/Golang community, while shutting down the Python one.
+The transition will require a lot of work and will take some time.
 
-We transition to golang, which will require an entirely new code base 😥 This comes
-with all benefits mentioned above, but also with a lot of work. Additionally, the
-knowledge of the language in the team is rather limited at the given time.
+We transition to Golang, which will require an entirely new code base 😥
+This comes with all benefits mentioned above, but also with a lot of work.
+Additionally, the knowledge of the language in the team is rather limited at the time.
 
-There were some efforts by @phbelitz to transition to golang, of which the following
-parts are still missing (compared to the python version):
+There were some efforts by @phbelitz to transition to Golang, of which the following
+parts are still missing (compared to the Python version):
 
-- rekor support for cosign
-- unittests for notaryv1 validator
-- integration tests
-- cicd pipeline
-- documentation
+- Rekor support for Cosign
+- Unit tests for Notary validator
+- Integration tests
+- CICD
+- Documentation
 
-Also none of the golang code was yet reviewed by a second pair of eyes.
+Also none of the Golang code was yet reviewed by a second pair of eyes.
 
 ## Decision Outcome
+
+We develop a Golang version in parallel to continued support of the Python version.
+The Golang version should not be a breaking change to ensure we can use existing tests to keep confidence in the new version.
+Once the Golang version is developed, we switch it with the Python version in a feature release.

docs/adr/ADR-9_multi-pod.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Undecided.
+Undecided
 
 ## Context
 
@@ -74,4 +74,4 @@ One pod for web server+validation and one pod for caching.
 ## Decision Outcome
 
 - We like the idea, but it's a huge change with significant attached effort
-- Let's consider a POC
+- Let's consider a PoC

docs/basics.md

@@ -427,7 +427,7 @@ There is two rules that should remain intact in some form in order to not brick
 | `validator` | `default` | - | Name of a validator in the `validators` list. If not provided, the validator with name `default` is used if it exists. |
 | `with` | - | - | Additional parameters to use for a validator. See more specifics in [validator section](validators/README.md). |
 |`with.trustRoot`| `default` | - | Name of a trust root, which is specified within the referenced validator. If not provided, the trust root with name `default` is used if it exists. |
-|`with.mode`| `mutate` | - | Mode of operation which specifies whether or not image references should be mutated after successfull image validation. If set to `mutate`, Connaisseur operates regularly. If set to `insecureValidateOnly`, Connaisseur will not mutate the digests of image references after successfully validating them. |
+|`with.mode`| `mutate` | - | Mode of operation which specifies whether or not image references should be mutated after successful image validation. If set to `mutate`, Connaisseur operates mutates image references to include digests. If set to `insecureValidateOnly`, Connaisseur will not mutate the digests. This leaves the risk of a malicious registry serving a different image under the signed tag. |
 
 #### Example
 

docs/features/automatic_child_approval.md

@@ -1,9 +1,5 @@
 # Automatic Child Approval
 
-!!! warning
-    This is currently an experimental feature that might become unstable over time.
-    As such, it is not part of our semantic versioning guarantees and we take the liberty to adjust or remove it with any version at any time without incrementing MAJOR or MINOR.
-
 Per default, Connaisseur uses *automatic child approval* by which the child of a Kubernetes resource is automatically admitted without re-verification of the signature in order to avoid duplicate validation and handle inconsistencies with the image policy.
 This behavior can be configured or even disabled.
 

docs/migrating_to_version_3.md

@@ -9,7 +9,7 @@ Read on for the list of most interesting changes.
 
 0. Read the [Major changes](#major-changes) and [API changes](#api-changes) sections to get an overview of what's new
 1. Run `python3 scripts/upgrade_to_version_3.py`
-2. Check the diff of your `charts/connaisseur/values.yaml` and make sure everything is as expected
+2. Check the diff of your `helm/values.yaml` and make sure everything is as expected
 3. Run `make upgrade` or alternatively `helm upgrade connaisseur helm -n <your-namespace> --wait`
 4. Enjoy the new version :tada: :crossed_fingers:
 
@@ -20,7 +20,7 @@ Read on for the list of most interesting changes.
     If all your Cosign signature artifacts are already part of Rekor's default transparency log (or part of your configured Rekor host) or you don't use Cosign, this is not breaking for you.
 - [Changes](#api-changes) to the Helm `values.yaml` file
     - :boom: This is a breaking change as we touched quite a bunch of configuration keys to make the configuration API more consistent and more intuitive
-    - :robot: We've prepared a [script](https://github.com/sse-secure-systems/connaisseur/blob/master/scripts/upgrade_to_version_3.py) that migrates your existing Connaisseur configuration to the new format. Limitation: It won't migrate your comments :cry: Simply run `python3 scripts/upgrade_to_version_3.py` and your `charts/connaisseur/values.yaml` will be updated (and we'll store a backup of your previous config in `charts/connaisseur/values.yaml.old`)
+    - :robot: We've prepared a [script](https://github.com/sse-secure-systems/connaisseur/blob/master/scripts/upgrade_to_version_3.py) that migrates your existing Connaisseur configuration to the new format. Limitation: It won't migrate your comments :cry: Simply run `python3 scripts/upgrade_to_version_3.py` and your `helm/values.yaml` will be updated (and we'll store a backup of your previous config in `helm/values.yaml.old`)
 
 ## Minor changes
 

docs/validators/sigstore_cosign.md

@@ -245,17 +245,13 @@ Most other KMS will require credentials for authentication that must be provided
 Such environment variables can be injected into Connaisseur via `deployment.envs` in `charts/connaisseur/values.yaml`, e.g.:
 
 ```yaml title="charts/connaisseur/values.yaml"
-  envs: 
+  envs:
     VAULT_ADDR: myvault.com
     VAULT_TOKEN: secrettoken
 ```
 
 ### Multi-signature verification
 
-!!! warning
-    This is currently an experimental feature that might be unstable over time.
-    As such, it is not part of our semantic versioning guarantees and we take the liberty to adjust or remove it with any version at any time without incrementing MAJOR or MINOR.
-
 Connaisseur can verify multiple signatures for a single image.
 It is possible to configure a threshold number and specific set of required valid signatures.
 This allows to implement several advanced use cases (and policies):