[changes]
* Memory management for systems with a large heap (>= 4 GB) was improved
* The version number of plugins now consists of 3 parts
* The plugin "Web Server Defender" added to protects against DoS and account hacking using brute force
* The cookie attribute "SameSite" can now be set. The default value is Lax
* Search bar and ticket views now also support an OR search with the keywords "or", "||" and "|"
* Embedded web pages now also supports the linking (redirect) of web pages. Additional rights management based on "users and groups" memberships
* Generic OpenID Connect (OIDC) authentication provider added
* Azure OpenID Connect (OIDC) authentication provider added
* Sample plugin for Custom OAuth provider added
  
[changes:de]
* Die Speicherverwaltung für Systeme mit einem großen Heap (>= 4 GB) wurde verbessert
* Die Versionsnummer von Plugins besteht nun aus 3 Teilen
* Das Plugin "Web Server Defender" wurde hinzugefügt, um vor DoS und Account-Hacking mit Brute-Force zu schützen
* Das Cookie-Attribut "SameSite" kann nun gesetzt werden. Der Standardwert ist Lax
* Suchleiste und Ticketansichten unterstützen nun auch eine ODER-Suche mit den Schlüsselwörtern "oder", "||" und "|"
* Eingebettete Webseiten unterstützen nun auch die Verlinkung (Redirect) von Webseiten. Zusätzliche Rechteverwaltung auf Basis von "Benutzer- und Gruppen"-Mitgliedschaften
* Generischer OpenID Connect (OIDC) Authentifizierungsanbieter hinzugefügt
* Azure OpenID Connect (OIDC)-Authentifizierungsanbieter hinzugefügt
* Beispiel-Plugin für benutzerdefinierten OAuth-Anbieter hinzugefügt

[bugfixes]
* OAuth authentication (Azure) with Safari browser was not possible
* Permission check for the WebAPI has not worked in connection with the default Windows Authentication
* URL was wrong after signup with any OAuth authentication provider like Azure and if a reverse proxy (like default.aspx for IIS) was used

[bugfixes:de]
* OAuth-Authentifizierung (Azure) mit Safari-Browser war nicht möglich
* Die Berechtigungsprüfung für die WebAPI hat in Verbindung mit der Standard-Windows-Authentifizierung nicht funktioniert
* URL war falsch nach Anmeldung bei einem beliebigen OAuth-Authentifizierungsanbieter wie Azure und wenn ein Reverse-Proxy (wie default.aspx für IIS) verwendet wurde

[security]
* **Jetty version updated because of:**
  * *CVE-2020-27216*
    * In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability
  * *CVE-2020-13956*
    * Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution
  * *CVE-2020-27218*
    * In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request
  * *CVE-2020-27223*
    * In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of &#8220;quality&#8221; (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values
* *Guava version updated to 30.1 because of CVE-2020-8908**
  * A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured
* *Cron-utils updated to version 9.1.3 because of ​https://nvd.nist.gov/vuln/detail/CVE-2020-26238*
* *Security Update for CVE-2020-1967*
  * Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Fixed in OpenSSL 1.1.1g (Affected 1.1.1d-1.1.1f)
* *Security Update for CVE-2021-20328*
  * Specific versions of the Java driver that support client-side field level encryption (CSFLE) fail to perform correct host name verification on the KMS server&#8217;s certificate. This vulnerability in combination with a privileged network position active MITM attack could result in interception of traffic between the Java driver and the KMS service rendering Field Level Encryption ineffective. This issue was discovered during internal testing and affects all versions of the Java driver that support CSFLE. The Java async, Scala, and reactive streams drivers are not impacted. This vulnerability does not impact driver traffic payloads with CSFLE-supported key services originating from applications residing inside the AWS, GCP, and Azure network fabrics due to compensating controls in these environments. This issue does not impact driver workloads that don&#8217;t use Field Level Encryption
  
[security:de]
* **Die kleine Version wurde aktualisiert aufgrund von:**
  * *CVE-2020-27216*
    * In den Eclipse Jetty-Versionen 1.0 bis 9.4.32.v20200930, 10.0.0.alpha1 bis 10.0.0.beta2 und 11.0.0.alpha1 bis 11.0.0.beta2O wird auf Unix-ähnlichen Systemen das temporäre Verzeichnis des Systems von allen Benutzern auf diesem System gemeinsam genutzt. Ein kollokierter Benutzer kann den Prozess der Erstellung eines temporären Unterverzeichnisses in dem gemeinsam genutzten temporären Verzeichnis beobachten und um die Erstellung des temporären Unterverzeichnisses wetteifern. Wenn der Angreifer das Rennen gewinnt, hat er Lese- und Schreibrechte für das Unterverzeichnis, das zum Entpacken von Webanwendungen verwendet wird, einschließlich ihrer WEB-INF/lib jar-Dateien und JSP-Dateien. Wenn aus diesem temporären Verzeichnis heraus Code ausgeführt wird, kann dies zu einer lokalen Schwachstelle führen, die eine Ausweitung der Rechte zur Folge hat
  * *CVE-2020-13956*
    * Apache HttpClient-Versionen vor Version 4.5.13 und 5.0.3 können fehlerhafte Autoritätskomponenten in Anfrage-URIs, die an die Bibliothek als java.net.URI-Objekt übergeben werden, fehlinterpretieren und den falschen Zielhost für die Anfrageausführung auswählen
  * *CVE-2020-27218*
    * In Eclipse Jetty Version 9.4.0.RC0 bis 9.4.34.v20201102, 10.0.0.alpha0 bis 10.0.0.beta2, und 11.0.0.alpha0 bis 11.0.0.beta2, wenn die Aufblähung des GZIP-Anfragekörpers aktiviert ist und Anfragen von verschiedenen Clients auf eine einzige Verbindung gemultiplext werden, und wenn ein Angreifer eine Anfrage mit einem Körper senden kann, der vollständig empfangen, aber nicht von der Anwendung verbraucht wird, dann wird eine nachfolgende Anfrage auf der gleichen Verbindung diesen Körper an seinen Körper vorangestellt sehen. Der Angreifer sieht keine Daten, kann aber Daten in den Body der nachfolgenden Anfrage einfügen
  * *CVE-2020-27223*
    * In Eclipse Jetty 9.4.6.v20170531 bis 9.4.36.v20210114 (einschließlich), 10.0.0 und 11.0.0, wenn Jetty eine Anfrage verarbeitet, die mehrere Accept-Header mit einer großen Anzahl von Qualitätsparametern (d. h. q) enthält, kann der Server aufgrund der hohen CPU-Auslastung bei der Verarbeitung dieser Qualitätswerte in einen Denial-of-Service-Zustand (DoS) eintreten, was zu minutenlanger CPU-Zeit führt, die bei der Verarbeitung dieser Qualitätswerte verbraucht wird
* *Die Guava-Version wurde aufgrund von CVE-2020-8908 auf 30.1 aktualisiert**
  * In allen Versionen von Guava besteht eine Schwachstelle bei der Erstellung von temporären Verzeichnissen, die es einem Angreifer mit Zugriff auf den Rechner ermöglicht, auf Daten in einem temporären Verzeichnis zuzugreifen, das von der Guava-API com.google.common.io.Files.createTempDir() erstellt wurde. Auf unix-ähnlichen Systemen ist das erstellte Verzeichnis standardmäßig für die ganze Welt lesbar (lesbar für einen Angreifer mit Zugriff auf das System). Die betreffende Methode wurde in den Versionen 30.0 und später als @Deprecated markiert und sollte nicht mehr verwendet werden. Android-Entwicklern empfehlen wir, eine von Android bereitgestellte API für temporäre Verzeichnisse zu verwenden, z. B. context.getCacheDir(). Anderen Java-Entwicklern empfehlen wir, auf die Java 7-API java.nio.file.Files.createTempDirectory() umzusteigen, die explizit die Berechtigungen von 700 konfiguriert, oder die Systemeigenschaft java.io.tmpdir der Java-Laufzeitumgebung so zu konfigurieren, dass sie auf einen Speicherort zeigt, dessen Berechtigungen entsprechend konfiguriert sind
* *Cron-utils aktualisiert auf Version 9.1.3 aufgrund von https://nvd.nist.gov/vuln/detail/CVE-2020-26238*
* *Sicherheitsupdate für CVE-2020-1967*
  * Server- oder Client-Anwendungen, die die Funktion SSL_check_chain() während oder nach einem TLS 1.3-Handshake aufrufen, können aufgrund einer NULL-Zeiger-Dereferenz abstÃ?rzen, da die TLS-Erweiterung "signature_algorithms_cert" nicht korrekt behandelt wird. Der Absturz tritt auf, wenn ein ungültiger oder nicht erkannter Signaturalgorithmus von der Gegenstelle empfangen wird. Dies könnte von einer böswilligen Gegenstelle für einen Denial-of-Service-Angriff ausgenutzt werden. OpenSSL Version 1.1.1d, 1.1.1e, und 1.1.1f sind von diesem Problem betroffen. Dieses Problem betraf keine OpenSSL-Versionen vor 1.1.1d. Behoben in OpenSSL 1.1.1g (Betroffen sind 1.1.1d-1.1.1f)
* *Sicherheitsupdate für CVE-2021-20328*
  * Bestimmte Versionen des Java-Treibers, die die clientseitige Verschlüsselung auf Feldebene (CSFLE) unterstützen, führen keine korrekte Überprüfung des Hostnamens auf dem Zertifikat des KMS-Servers durch. Diese Schwachstelle kann in Kombination mit einer privilegierten Netzwerkposition und einem aktiven MITM-Angriff dazu führen, dass der Datenverkehr zwischen dem Java-Treiber und dem KMS-Dienst abgefangen wird, wodurch die Field Level Encryption unwirksam wird. Dieses Problem wurde bei internen Tests entdeckt und betrifft alle Versionen des Java-Treibers, die CSFLE unterstützen. Die Java async-, Scala- und reaktiven Streams-Treiber sind nicht betroffen. Diese Sicherheitsanfälligkeit wirkt sich nicht auf Treiber-Nutzdaten mit CSFLE-unterstützten Schlüsseldiensten aus, die von Anwendungen innerhalb der AWS-, GCP- und Azure-Netzwerkstrukturen stammen, da in diesen Umgebungen kompensierende Kontrollen vorhanden sind. Dieses Problem wirkt sich nicht auf Treiber-Workloads aus, die keine Field Level Encryption verwenden
  