Remove v2 from documentation (Fraunhofer-AISEC#661)

Co-authored-by: Florian Wendland <[email protected]>

docs/Codyze/index.md

@@ -13,8 +13,7 @@ description: >
 !!! info
 
     Codyze is currently being redesigned.
-    The legacy version of Codyze, in the following called __Codyze v2__, will be maintained for the foreseeable future.
-    Differences between the redesigned version, called __Codyze v3__, and __Codyze v2__ will be explicitly stated in this documentation.
+    For the documentation for the legacy version of Codyze, please look [here](https://github.com/Fraunhofer-AISEC/codyze/tree/v2.3.0/docs).
 
 Security is hard and implementing it correctly is even harder. Luckily, there are well-established and battle-proven libraries available that do the heavy lifting of security functions such as authentication, logging or encryption. But even when using these libraries in application code, developers run the risk of making subtle errors which may undermine the security of their application. This is where Codyze helps. By integrating it into an IDE or CI pipeline, developers can analyze their source code while programming and check if they are using libraries in a correct or in an insecure way.
 
@@ -35,9 +34,9 @@ Codyze is based on a "Code Property Graph", which represents the source code as
 
 Codyze checks source code for the correct usage of libraries. It is an addition to generic static analysis tools such as Sonarqube, Frama-C, or the Checker Framework and specifically verifies that libraries are used as originally intended by their developers. 
 
-**Library developers** write rules for their library in a simple domain specific language, called *MARK*.
+**Library developers** write rules for their library in specification languages supported by Codyze.
 
-**Developers** verify their code against rules of modelled libraries using Codyze - either as an IDE-plugin or as a CI module.
+**Developers** verify their code against rules of modelled libraries using Codyze.
 
 **Integrators** of open source components may want to verify these components using the automated analysis of Codyze or by manually searching the code for critical patterns.
 

docs/Codyze/why-v3.md

@@ -6,15 +6,15 @@ no_list: true
 description: >
   Differences between Codyze v3 and Codyze v2
 ---
-The goal of Codyze v3 is to make Codyze more maintainable and easier extendable.
-This introduced a lot of changes compared to Codyze v2.
+The goal of the redesign is to make Codyze more maintainable and easier extendable.
+This introduced a lot of changes compared to the legacy version.
 
 The core functionalities of Codyze were separated from the executable part which makes it possible to use Codyze as a library.
 
 We introduced the concept of Executors which are responsible for evaluating rules of a specific specification language.
-Through Executors, Codyze is no longer limited to MARK rules as long as there is an Executor for the specification language of your choosing.
+Through Executors, Codyze can verify rules written in different specification languages and utilize their advantages as long as there is an Executor for them.
 
-With Codyze v3 we're also working on a new specification language that improves upon MARK.
+We are also working on a new specification language Coko which comes inbuilt with Codyze.
 
-Additionally, we reworked the organisation of code in Codyze to be able to handle multiple projects with their own configurations with only one Codyze instance. 
+Additionally, we reworked the organisation of code in Codyze to be able to handle multiple projects with their own configurations with only one Codyze instance.
 This, for example, allows switching between projects in an IDE without losing the context of any analysis and should better support LSP mode.

docs/Getting Started/cli.md

@@ -13,22 +13,12 @@ description: >
 
 When running in command line interface (CLI) mode, Codyze can be used to automatically check a code base against a set of MARK rules.
 Below are short exemplary calls to start codyze in command line interface mode.
-`./` refers to the top-level directory of the repository. However, for the Gradle arguments `./` refers to the directory of the project (`codyze-v2` for Codyze v2 and `codyze-v3/codyze` for Codyze v3).
+`./` refers to the top-level directory of the repository. However, for the Gradle arguments `./` refers to the directory of the project which is `codyze-cli`.
 
-### Codyze v2
 ```shell
-./gradlew :codyze-v2:run --args="-c -s <sourcepath> -m ./mark -o <outputpath>"
+./gradlew :codyze-cli:run --args="analyze -s <sourcepath> --spec <specpath> -o <outputpath>"
 ```
-`-c` enters command line mode. It will parse all files given by the `-s` argument, analyze them against the MARK policies given by `-m`, and write the findings in SARIF format to the file given by `-o`. 
-If `-` is given as the output name, the results will be dumped to stdout.
-
-
-
-### Codyze v3
-```shell
-./gradlew :codyze-v3:codyze:run --args="analyze -s <sourcepath> --spec ./mark -o <outputpath>"
-```
-`analyze` enters command line mode. `--spec` is the replacement for `-m` since Codyze v3 enables verifying rules from different specification languages. The findings are written in SARIF format to the file given by `-o`.
+`analyze` enters command line mode. It will parse all files given by the `-s` argument. With `--spec` you can specify the files which contain the policies you want Codyze to verify. The findings are written in SARIF format to the file given by `-o`.
 
 
 ## CI/CD Integration
@@ -66,18 +56,11 @@ jobs:
 The repository contains examples which you can use to test Codyze. 
 Below are the commands to call Codyze on these examples.
 
-```shell title="Codyze v2"
-./gradlew :codyze-v2:run --args="-c -s ../examples/botan/blockciphers/Prudkovskiy.Qt_LockBox/crypto.cpp -m ../examples/botan/MARK"
-```
-
-```shell title="Codyze v3"
-./gradlew :codyze-v3:codyze:run --args="analyze -s ../../examples/botan/blockciphers/Prudkovskiy.Qt_LockBox/crypto.cpp --spec ../../examples/botan/MARK"
+```shell
+./gradlew :codyze-cli:run --args="analyze -s ../codyze-specification-languages/coko/coko-dsl/src/test/resources/java/Main.java --spec ../codyze-specification-languages/coko/coko-dsl/src/test/resources/model.codyze.kts --spec ../codyze-specification-languages/coko/coko-dsl/src/test/resources/javaimpl.codyze.kts"
 ```
 
-You might notice that the Gradle task will fail.
-The reason is that Codyze returns `1` if there is any negative finding and will only return `0` if no rule was violated.
+You will see the result printed to the console.
+The spec files contain a single rule which checks that every change to a database is logged.
+The sample Java file adheres to the rule so there should be no issues in the result.
 
-The findings are located in the file `findings.sarif` in the respective project directories.
-Looking into the findings, there are two passes for the rule `WrongBlockCipher`, which means that the correct algorithm `AES` was used for the block ciphers in line 16 and 22.
-There are also two open findings for the rule `BadKeyLength` since the key length was not explicitly set.
-The last open finding is for the rule `WrongUseOfBotan_CipherMode`.