# PVProg Exercise 2

## Aufgabe 1

### Crash Fault
- https://github.com/signalapp/Signal-Android/commit/e9ae439b70ed8e807df090d97c2cd798c612e09e
Signal crashes when opening group with many unread messages due to out of bounds error

- https://github.com/signalapp/Signal-Android/commit/7fc9876b1ea88ff1893ef627d1ecf0d2c2913508
An exception gets thrown in a `finally` block, which makes Signal crash when doing a backup restore.

### Omission Fault

### Timing Fault
- https://github.com/hpi-swa-teaching/IMAPClient/issues/114#issuecomment-509009253
Feature would have been too slow, so it was decided to not implement it.
- https://github.com/hpi-swa-teaching/IMAPClient/pull/316
IMAP client that did not wait long enough for the servers response.

### Computation Fault
- https://github.com/troeger/fuzzed/pull/124
The image that the Docker Daemon produces is not deterministic.

### Byzantine Fault
- https://github.com/signalapp/Signal-Android/commit/b8c42fa57ea0825d428f7e9e68d0475ece27e3c3

- https://github.com/osmhpi/fuzzed/commit/e44474eb881b4a9cd5c622b8978a3e070e00c1e6

###

## Aufgabe 2
- Code Review
- Automated Testing & linting (to avoid unreadable code leading to hard-to-find bugs)
- Manual Quality Assurance by testing workflows

## Aufgabe 3

- Anstelle von Fehlerwahrscheinlichkeit/Fehlerrate wäre auch die "Mean time to failure/occurrence" als Metrik denkbar.
- Bei vielen Ereignissen ergibt diese Metrik nicht besonders viel Sinn. Quantifizierbar ist diese z.B. für RAID failure (Data loss) oder Power outage.
- Wir haben sowohl Hardware Faults als auch Software Faults in das Modell einfließen lassen.

## Aufgabe 4
- Redundanz
- mehrere Backend Server: verhindern Ausfall des Backend Service
- mehrere Frontend Server: verhindern Ausfall des Frontend Service
- redundantes Postgres Setup mit Failover: verhindert Ausfall des Datenbank Services
- Software/Hardware fault model
- Scalability
- mehrere Backend Server: verhindern Überlastung
- Software fault model
- Recovery
- Docker erkennt fehlerhaften Container, startet neu
- Software fault model

## Aufgabe 5
- Wir könnten manuell (trigger mechanism) zur Laufzeit (injection time) per Anfragen an die Frontend/Backend services (injection level) erzeugen und so das System unter Last testen.
- Wir könnten manuell (trigger mechanism) vor einem Neustart, d.h. pre-execution (injection time) einen ungültigen API key für einen OAuth Provider konfigurieren (injection level) um das Verhalten des Systems unter fehlerhafter Konfiguration zu untersuchen.

## Aufgabe 6

### Availability
Wird besser, da Container üblicherweise mit Health Checks ausgestattet werden und so automatisiert im Falle eines Ausfalls neugestartet werden, was die Ausfallzeit nur verringern kann.

### Reliability
Ändert sich nicht, da Fehler immernoch genauso auftreten (es sei denn, Fehlerursachen sind durch die veränderte Umwelt entfernt worden).

### Safety
Im besten Fall erschweren Container das Ausnutzen von Sicherheitslücken innerhalb einer darin ausgeführten Anwendung durch Ausbruch aus dem Container. Die inhärente Safety der Anwendung ohne Bezug auf die ausführende Umgebung jedoch bleibt unverändert.

### Confidentiality
Wird verbessert, da Prozesse in Container (üblicherweise) dahingehend isoliert sind, dass sie nur beschränkt Einfluss auf Prozesse außerhalb des Containers nehmen können.

### Integrity
Könnte besser werden, da ein Orchestrator durch eingebaute Health Checks einen ungültigen / ungesunden Zustand erkennen und den entsprechenden Container neustarten kann.

### Maintainability
Ja, da das Setup durch Image Versionierung der Container stabiler gegenüber Dependency Updates wird.