From 08e51df5978be2cf5c2105af8dc170d57ed53a0b Mon Sep 17 00:00:00 2001
From: Hussam Moammar <hussam.moammar@informatik.hs-fulda.de>
Date: Sat, 15 Feb 2025 18:36:57 +0100
Subject: [PATCH] Edit Woche 11.md

---
 Woche 11.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 55 insertions(+), 3 deletions(-)

diff --git a/Woche 11.md b/Woche 11.md
index 3992b04..2106b6d 100644
--- a/Woche 11.md	
+++ b/Woche 11.md	
@@ -124,8 +124,60 @@ Untersuchen Sie die verschiedenen Notationen zur Spezifizierung von Versionsanfo
 - **Caret (^)**
 - **Platzhalter (*)**
 
-### Hinweise:
-- Achten Sie darauf, die Szenarien klar zu begründen.
-- Diskutieren Sie potenzielle Risiken und Nutzen jeder Notation basierend auf Ihren Beispielen.
+## Antwort
+
+### **Aufgabe 1: Analyse eines Vorfalls mit Paketmanagern**  
+
+#### **1. Problemquelle**  
+**Vorfalldetails:** "event-stream"-Backdoor (2018) in npm  
+- Ein Open-Source-Maintainer übergab die Kontrolle eines npm-Pakets an einen neuen Entwickler.  
+- Dieser fügte eine bösartige Abhängigkeit hinzu, die Bitcoin-Wallets ausspähte.  
+
+#### **2. Auswirkungen und Folgen**  
+- **Unmittelbar:** Zahlreiche Projekte nutzten "event-stream" und wurden kompromittiert.  
+- **Langfristig:** Vertrauensprobleme in Open-Source-Community, Diskussion über Paketübernahmen.  
+
+#### **3. Ursache und Schwachstellen**  
+- Keine Prüfung bei Übergabe des Pakets an einen neuen Maintainer.  
+- Fehlende Sicherheitsmechanismen in npm zur Detektion schädlicher Updates.  
+
+#### **4. Reaktionen und Lösungen**  
+- npm verbesserte Richtlinien für Paket-Transfers.  
+- Unternehmen implementierten strengere Abhängigkeitsprüfungen (z. B. Lockfiles & Audits).  
+- Empfehlung: Signierte Pakete und Abhängigkeitsüberwachung mit Tools wie Snyk.  
+
+---
+
+### **Aufgabe 2: Untersuchung von Semantic Versioning**  
+
+#### **1. Exakte Version (`1.2.3`)**  
+**Szenario:** Ein Unternehmen benötigt eine getestete, stabile Version.  
+**Vorteil:** Keine unerwarteten Änderungen.  
+**Nachteil:** Keine Updates für Bugfixes oder Security-Patches.  
+
+#### **2. Bereichsoperatoren (`>=1.2.0 <2.0.0`)**  
+**Szenario:** Ein Framework unterstützt alle `1.x`-Versionen, aber nicht `2.0.0`.  
+**Vorteil:** Flexibilität für Patch- und Minor-Updates.  
+**Nachteil:** Major-Updates ausgeschlossen, potenzielle Sicherheitslücken.  
+
+#### **3. Intervall-Notation (`[1.2.0,2.0.0)`)**  
+**Szenario:** Eine API-Bibliothek garantiert Kompatibilität für `1.2.0` bis `2.0.0`.  
+**Vorteil:** Strikte Kontrolle über erlaubte Versionen.  
+**Nachteil:** Umständlicher als `>=` und `<`.  
+
+#### **4. Tilde `~1.2.3`**  
+**Szenario:** Ein Projekt benötigt `1.2.x`, aber nicht `1.3.0`.  
+**Vorteil:** Erlaubt nur Bugfix-Updates (`1.2.4`, `1.2.5`).  
+**Nachteil:** Keine neuen Features (z. B. `1.3.0` bleibt ausgeschlossen).  
+
+#### **5. Caret `^1.2.3`**  
+**Szenario:** Eine Bibliothek akzeptiert Updates innerhalb der gleichen Major-Version (`1.x`).  
+**Vorteil:** Sicherheits- und Feature-Updates (`1.3.0`, `1.4.0` erlaubt).  
+**Nachteil:** Potenziell inkompatible Änderungen in Minor-Releases.  
+
+#### **6. Platzhalter `1.*`**  
+**Szenario:** Ein System soll immer die neueste `1.x`-Version erhalten.  
+**Vorteil:** Maximale Flexibilität.  
+**Nachteil:** Keine Kontrolle über neue Minor-Releases, potenzielle Breaking-Changes.  
 
 ---
\ No newline at end of file
-- 
GitLab