Toutes les quatre implémentations de `JsonParser` partagent cette faille. L'attaque est également exploitable via
n'importe laquelle d'entre elles — que l'entrée arrive via `InputStream`, `Reader`, `DataInput` ou l'API
non-bloquante 'feeder' asynchrone.

**Vecteurs d'attaque :**

| # | Stratégie | Exemple de charge utile | Incrément de profondeur | Analyseurs affectés |
|---|-----------|------------------------|-------------------------|---------------------|
| 1 | Imbrication de tableaux | `[[[…]]]` — 1 001 jetons `[` consécutifs | +1 par `[` | Les quatre |
| 2 | Imbrication d'objets | `{"k":{"k":{…}}}` — 1 001 jetons `{` consécutifs | +1 par `{` | Les quatre |
| 3 | Imbrication alternée | `[{"k":[{"k":…}]}]` — 1 001 jetons `[`/`{` mélangés | +1 par `[` ou `{` | Les quatre |

Observations clés :

- **Imbrication de tableaux — surcharge minimale :** seuls les jetons `[` et `]` sont nécessaires ; aucune clé, valeur ou espace blanc. Une charge utile de 2 002 octets de 1 001 paires de crochets suffit pour dépasser la limite par défaut de 1 000.
- **Imbrication d'objets — pression mémoire amplifiée :** chaque `{` alloue en plus un emplacement de clé `JsonReadContext` en plus du nœud de chaîne de profondeur, ce qui aggrave la consommation mémoire à des profondeurs extrêmes.
- **Imbrication alternée — contournement du pare-feu d'applications Web (WAF) :** les défenses basées sur la reconnaissance de motifs qui détectent les séquences répétées `[[[` ou `{{{` sont aveugles à l'imbrication alternée de jetons ; le compteur de profondeur de l'analyseur s'incrémente à l'identique quel que soit le type de jeton.
- **'Feeder' non-bloquant — même charge utile, surface de livraison distincte :** les trois stratégies d'imbrication sont également exploitables via `NonBlockingJsonParser` et l'API `ByteArrayFeeder`. Le document peut être livré en morceaux arbitrairement petits ; `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()` incrémente le compteur de profondeur à chaque jeton d'ouverture de contexte, quelle que soit la manière dont les octets arrivent, accumulant la profondeur sur plusieurs appels à `feedInput()`.

Les trois stratégies d'imbrication sont accessibles via n'importe laquelle des quatre implémentations de `JsonParser`.
Avec la version 2.13.5, l'analyse réussit silencieusement ; avec cette correction, les trois vecteurs lèvent
`StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)`.

---

### Sonatype-2022-6438 — Longueur illimitée des jetons numériques

**Détails de sécurité**

| Champ | Valeur |
|-------|--------|
| ID Sonatype | [sonatype-2022-6438](https://guide.sonatype.com/vulnerability/sonatype-2022-6438/security-details) |
| Description | jackson-core — Déni de service (DoS) |
| Publié le | 2022-12-07 |
| Source | Sonatype |
| Score CVSS v3.1 | **7.5 HIGH** — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Allocation de ressources sans limites ni régulation |
| Score EPSS | 0% |
| Correctifs en amont | [jackson-core#827](https://github.com/FasterXML/jackson-core/pull/827), [jackson-core#846](https://github.com/FasterXML/jackson-core/pull/846) |

**Méthodes vulnérables (telles qu'identifiées par Sonatype)**

| Méthode | Notes |
|---------|-------|
| `com.fasterxml.jackson.core.base.ParserBase._parseSlowInt(I)V` | Paramètre vulnérable : index 0 |
| `com.fasterxml.jackson.core.base.ParserBase.convertNumberToBigDecimal()V` | |
| `com.fasterxml.jackson.core.base.ParserMinimalBase.getValueAsDouble(D)D` | Paramètre vulnérable : index 0 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDecimal()` | Retourne `BigDecimal` |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDouble(Z)D` | |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsFloat(Z)F` | |

Chacune de ces méthodes traite le tampon de chiffres bruts sans d'abord valider sa longueur. Passer un
jeton numérique suffisamment long déclenche une allocation de tas illimitée et une épuisement du processeur lorsque la JVM
tente d'instancier un `BigInteger` ou un `BigDecimal` à partir du contenu non contraint du tampon.

---

**Cause racine :** Avant la version 2.15.0, `JsonParser` n'imposait aucune limite sur la longueur en octets des jetons entiers, en notation scientifique, à virgule flottante simple ou composée. Lorsqu'un analyseur alloue son `_textBuffer` interne pour accumuler les chiffres, un
attaquant peut fournir un nombre avec des millions de chiffres, ce qui fait croître le tampon sans limite et
finit par épuiser la mémoire de tas.

**Chemins de code vulnérables :**

Il existe deux chemins vulnérables structurellement distincts — l'un partagé par les trois analyseurs synchrones,
et un second chemin indépendant via l'analyseur asynchrone.

**Chemin A — analyseurs synchrones** (trois implémentations, un seul point d'arrivée commun) :```
JsonParser.nextToken()                         // common entry point
  │
  ├─ ReaderBasedJsonParser   ─┐
  ├─ UTF8StreamJsonParser     ├─→ ParserBase.resetInt() / resetFloat()
  └─ UTF8DataInputJsonParser ─┘         │
                                        ▼
                               _textBuffer.contentsAsString()
                               ⚠  no length check — buffer grows without bound

Le parseur non bloquant (asynchrone) représente une surface d'attaque particulièrement notable : il contient ses propres boucles d'accumulation de chiffres dans `_startPositiveNumber`, `_startNegativeNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction` et `_finishFloatExponent` qui définissent `_intLength` / `_fractLength` / `_expLength` directement sans jamais passer par `ParserBase.resetInt()` ou `resetFloat()`. Cela signifie que le correctif du PR #827 en amont (qui ajoutait une validation uniquement dans `ParserBase`) **a laissé `NonBlockingJsonParser` complètement sans protection**. Cela a été découvert lors d'une analyse étendue de la surface d'attaque et corrigé dans cette branche.

**Vecteurs d'attaque :**

| # | Forme du jeton | Exemple de charge utile | `intLen` | `fractLen` | `expLen` | Total | Contrainte |
|---|----------------|-------------------------|----------|------------|----------|-------|------------|
| 1 | Entier | `999…` — 199 999 chiffres consécutifs | 199 999 | 0 | 0 | 199 999 | `validateIntegerLength` |
| 2 | Fraction décimale | `0.999…` — entier à 1 chiffre, fraction à 1 001 chiffres | 1 | 1 001 | 0 | 1 002 | `validateFPLength` |
| 3 | Notation scientifique | `1e999…` — significande à 1 chiffre, exposant à 1 001 chiffres | 1 | 0 | 1 001 | 1 002 | `validateFPLength` |
| 4 | Virgule flottante composée | `0.999…e999…` — fraction à 500 chiffres, exposant à 500 chiffres | 1 | 500 | 500 | 1 001 | `validateFPLength` |

Observations clés :

- **Entier — le signe n'est pas un chiffre :** le `-` initial est exclu de l'accumulation des chiffres ; `-999…` et `999…` produisent des valeurs `intLen` identiques et déclenchent la contrainte au même seuil.
- **Fraction décimale — entier court, fraction illimitée :** la partie entière peut être un seul chiffre (0) tandis que la partie fractionnaire croît sans limite ; le point décimal lui-même est exclu du comptage.
- **Notation scientifique — compacte mais catastrophique :** avec environ 1 004 octets, c'est la charge utile la plus petite et la plus efficace ; elle force l'instanciation d'un `BigDecimal` avec une échelle de ±10^1001, demandant une allocation intermédiaire en tas illimitée malgré la petite taille du jeton.
- **Virgule flottante composée — contournement par division des limites :** avec `fractLen = 500` et `expLen = 500`, aucun composant n'atteint individuellement le seuil des 1 000 chiffres. La vérification unifiée `validateFPLength(intLen + fractLen + expLen)` est la seule défense qui comble cette lacune.
- **Parseur non bloquant — contournement indépendant :** les quatre formes de jetons ci-dessus sont exploitable indépendamment via `NonBlockingJsonParser` via `ByteArrayFeeder`. Contrairement aux parseurs synchrones, `NonBlockingJsonParser` accumule les chiffres dans des boucles privées (`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`) qui écrivent directement `_intLength` / `_fractLength` / `_expLength`, contournant entièrement `ParserBase.resetInt()` et `resetFloat()`. Le PR #827 en amont — qui n'avait modifié que `ParserBase` — a donc laissé ce parseur totalement sans protection, nécessitant six correctifs distincts sur les sites d'appel dans cette correction.

Les quatre formes de jetons et le contournement du parseur non bloquant sont rejetés au moment de la tokenisation — avant que tout `BigDecimal` ou `BigInteger` ne soit construit — par `validateIntegerLength` et `validateFPLength` dans `ParserBase` (parseurs synchrones) et sur six sites d'appel dédiés dans `NonBlockingJsonParser` (parseur asynchrone). Avec la version 2.13.5, les quatre formes de jetons sont acceptées silencieusement ; avec cette correction, chaque parseur lève `StreamConstraintsException: Number length (N) exceeds the maximum length (1000)`.

> **Remarque sur `UTF8DataInputJsonParser` avec des charges utiles volumineuses :** Le parseur DataInput a une limite de tampon interne préexistante de 65 536 octets ([jackson-core#493](https://github.com/FasterXML/jackson-core/issues/493)). Les documents dépassant cette taille (par exemple, charges utiles de 199 999 chiffres ≈ 200 Ko) déclenchent une `ArrayIndexOutOfBoundsException` avant que la contrainte de longueur puisse s'appliquer. La protection de la longueur numérique pour `UTF8DataInputJsonParser` est donc vérifiée avec des charges utiles plus courtes (≤ 1 001 chiffres) où le bogue est encore reproductible.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — Contournement de la contrainte de longueur de document

**Détails de sécurité**

| Champ | Valeur |
|-------|--------|
| ID Snyk | [SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551](https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551) |
| Avis GitHub | [GHSA-2m67-wjpj-xhg9](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-2m67-wjpj-xhg9) |
| Description | Allocation de ressources sans limites ni limitation |
| Divulgué | 2026-04-04 |
| Score CVSS v4.0 | **8.7 ÉLEVÉ** |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Allocation de ressources sans limites ni limitation |
| Versions affectées | [2.8.0, 2.21.2) |
| Correctif amont | jackson-core 2.18.7, 2.21.2 ou supérieur |
| Commits de correction | [74c9ee25](https://github.com/FasterXML/jackson-core/commit/74c9ee25) (3.x), [7ce3622f](https://github.com/FasterXML/jackson-core/commit/7ce3622f) (2.18.x) |

**Cause racine :** Même lorsque `StreamReadConstraints.maxDocumentLength` est configuré, les versions antérieures à 2.18.7 / 2.21.2 n'appliquent pas la limite de longueur du document dans aucun chemin de parseur. Les parseurs bloquants (`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) ne valident jamais le nombre cumulé d'octets lus par rapport à la limite configurée. Le parseur asynchrone (`NonBlockingJsonParser`) manque également de validation dans `feedInput()`. Le `UTF8DataInputJsonParser` n'a aucun mécanisme pour suivre le total d'octets consommés.

Dans jackson-core 2.13.5, `maxDocumentLength` n'existait pas du tout, ce qui signifie qu'il n'y avait aucun moyen de limiter la taille du document. Cette correction introduit le champ `maxDocumentLength` dans `StreamReadConstraints` et l'applique dans tous les chemins de parseur.

**Chemins de parseur vulnérables :**

| Parseur | Chemin | Point d'application |
|---------|--------|---------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | Valide `_currInputProcessed + count` après chaque rechargement du tampon et à la fin du fichier |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | Même motif que `UTF8StreamJsonParser` |
| `NonBlockingJsonParser` | `feedInput()` | Valide `_currInputProcessed + _origBufferLen` après chaque bloc d'entrée |
| `UTF8DataInputJsonParser` | `DataInput` | Échec rapide : lève `StreamConstraintsException` si `maxDocumentLength` est configuré |

**Scénario d'attaque :** Un attaquant envoie un document JSON valide mais surdimensionné (par exemple, une structure profondément imbriquée ou hautement répétitive occupant des gigaoctets) à un service qui a configuré `maxDocumentLength` pour éviter l'épuisement des ressources. Sans application, le parseur traite l'intégralité du document indépendamment de la limite configurée, consommant une mémoire et un CPU illimités.

---

## Impact sur la sécurité

Les quatre vulnérabilités sont exploitables à distance sans authentification :

- Tout service qui analyse du JSON contrôlé par un attaquant via un `JsonParser` (directement ou via Jackson Databind, qui encapsule `jackson-core`) est à risque.
- L'attaque est trivialement constructible — quelques centaines d'octets de JSON suffisent pour déclencher une consommation illimitée de ressources.
- Aucun impact sur la confidentialité ou l'intégrité ; la disponibilité (DoS) est la seule classe d'impact.

---

## Détails de la correction

### Mise à niveau officielle (recommandée)

Mettez à niveau vers **jackson-core 2.15.4** ou toute version stable ultérieure. Toutes les versions 2.15.x et 2.16+ incluent l'API `StreamReadConstraints` avec des valeurs par défaut sûres.```xml
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

Méthodes de validation (appelées par les analyseurs à chaque nouveau jeton) :```java
void validateNestingDepth(int depth) throws StreamConstraintsException;
void validateIntegerLength(int length) throws StreamConstraintsException;
void validateFPLength(int length) throws StreamConstraintsException;
void validateStringLength(int length) throws StreamConstraintsException;
void validateBigIntegerScale(int scale) throws StreamConstraintsException;

Nouvelles méthodes d'assistance `_createChildArrayContext()` et `_createChildObjectContext()` encapsulent la création de contexte
avec une vérification de profondeur :```java
protected JsonReadContext _createChildArrayContext(int line, int col) throws IOException {
    _streamReadConstraints.validateNestingDepth(_parsingContext.getNestingDepth() + 1);
    return _parsingContext.createChildArrayContext(line, col);
}

#### `json/JsonReadContext.java`

Les signatures de `createChildArrayContext()` et `createChildObjectContext()` ont été mises à jour pour propager `throws IOException`.

#### `json/async/NonBlockingJsonParser.java` (Sonatype-2022-6438 seulement)

Il s'agit du correctif supplémentaire principal découvert au-delà du périmètre du PR #827 en amont. Six sites de complétion de nombres qui contournaient `ParserBase.resetInt()` ont été corrigés individuellement :

| Méthode | Validation ajoutée |
|--------|------------------|
| `_startPositiveNumber()` — retour rapide | `validateIntegerLength(_intLength)` |
| `_startNegativeNumber()` — retour rapide | `validateIntegerLength(_intLength)` |
| `_finishNumberIntegralPart()` — retour final | `validateIntegerLength(_intLength)` |
| `_finishToken()` cas `MINOR_NUMBER_INTEGER_DIGITS` | `validateIntegerLength(_intLength)` |
| `_startFloat()` / `_finishFloatFraction()` / `_finishFloatExponent()` retours finaux | `validateFPLength(_intLength + _fractLength + _expLength)` |
| `_finishToken()` cas `MINOR_NUMBER_FRACTION_DIGITS` / `MINOR_NUMBER_EXPONENT_DIGITS` | `validateFPLength(...)` |

Tous les sites sont atteignables : les méthodes de chemin rapide gèrent le cas où le nombre complet est disponible en un seul appel `feedInput()` ; les cas d'état de reprise `MINOR_*` gèrent le cas morcelé où les chiffres arrivent en plusieurs appels. Les deux chemins doivent être protégés.

---

## Couverture de test

### CVE-2025-52999 — Tests de profondeur d'imbrication

| Fichier de test | Méthode de test | Modes d'analyseur | Couvre |
|-----------|-------------|-------------|--------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | flux | Parcours récursif simulant une utilisation réelle de l'application ; confirme `StreamConstraintsException` à la profondeur 1001 (corrigé) et `StackOverflowError` à la profondeur 20 000 (2.13.5) |
| `read/ArrayParsingTest.java` | `testCustomNestingDepthConstraint` | API directe | `StreamReadConstraints.builder().maxNestingDepth(5)` — accesseur, à la limite passe, au-delà de la limite lève une exception |
| `read/ArrayParsingTest.java` | `testObjectNestingDepthLimit` | flux | Objets exactement à la limite 1000 (passent), objets de niveau 1001 lèvent une exception |
| `read/ArrayParsingTest.java` | `testDataInputParserDepthLimit` | `UTF8DataInputJsonParser` | `UTF8DataInputJsonParser` impose une limite de profondeur de niveau 1001 |
| `read/ArrayParsingTest.java` | `testNonBlockingParserDepthLimit` | non-bloquant | `NonBlockingJsonParser` impose une limite de profondeur de niveau 1001 |

### Sonatype-2022-6438 — Tests de longueur numérique

| Fichier de test | Méthode de test | Modes d'analyseur | Couvre |
|-----------|-------------|-------------|--------|
| `read/NumberOverflowTest.java` | `testSonatype_2022_6438` | `ALL_MODES` | Entier à la limite (réussite), entier au-delà de la limite (échec), flottant à la limite (réussite), flottant au-delà de la limite (échec), exposant en notation scientifique à la limite (réussite), exposant au-delà de la limite (échec) — les quatre analyseurs |
| `read/NumberOverflowTest.java` | `testNonBlockingParserNumericLengthLimit` | non-bloquant | `NonBlockingJsonParser` impose la longueur numérique |
| `read/NumberOverflowTest.java` | `testNonBlockingParserExponentLengthLimit` | non-bloquant | `NonBlockingJsonParser` impose la longueur de l'exposant en notation scientifique via `validateFPLength` |
| `read/NumberOverflowTest.java` | `testCustomMaxNumberLengthConstraint` | API directe | `StreamReadConstraints.builder().maxNumberLength(5)` — accesseur, à la limite passe, au-delà lève une exception pour `validateIntegerLength()` et `validateFPLength()`, format du message d'erreur |

> **Clé des modes d'analyseur :**
> - `ALL_STREAMING_MODES` = `UTF8StreamJsonParser` (flux), `UTF8StreamJsonParser` (limité), `ReaderBasedJsonParser`
> - `ALL_MODES` = les trois ci-dessus + `UTF8DataInputJsonParser`
> - `non-bloquant` = `NonBlockingJsonParser` via `ByteArrayFeeder`
> - `flux` = `UTF8StreamJsonParser` (par défaut `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — Tests de longueur de document

| Fichier de test | Méthode de test | Modes d'analyseur | Couvre |
|-----------|-------------|-------------|--------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | L'analyseur `InputStream` impose `maxDocumentLength` — document 20K rejeté avec limite 10K |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | L'analyseur `InputStream` accepte un document dans la limite |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | L'analyseur `Reader` impose `maxDocumentLength` — document 20K rejeté avec limite 10K |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | L'analyseur `Reader` accepte un document dans la limite |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | L'analyseur asynchrone impose `maxDocumentLength` — document 20K rejeté dans `feedInput()` |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | L'analyseur asynchrone accepte un document dans la limite |
| `constraints/LargeDocReadTest.java` | `testDataInputWithDocLengthLimitFails` | `UTF8DataInputJsonParser` | L'analyseur `DataInput` échoue rapidement lorsque `maxDocumentLength` est configuré |
| `constraints/LargeDocReadTest.java` | `testDataInputWithoutDocLengthLimitWorks` | `UTF8DataInputJsonParser` | L'analyseur `DataInput` fonctionne normalement sans `maxDocumentLength` configuré |
| `constraints/LargeDocReadTest.java` | `testDefaultFactoryNoLimit` | `UTF8StreamJsonParser` | La fabrique par défaut (sans limite) accepte les grands documents |

---

## Résultats complets de la suite de tests```
Tests run: 957, Failures: 0, Errors: 0, Skipped: 0

---

## Résultats de validation

### Test de régression contre jackson-core 2.13.5

Les méthodes de test CVE ont été conçues pour **échouer** sur le codebase 2.13.5 et **réussir** sur le build corrigé.

`NumberOverflowTest#testSonatype_2022_6438` contre 2.13.5 :```
FAIL — Sonatype-2022-6438 VULNERABILITY PRESENT: parser returned VALUE_NUMBER_INT
       for a 1001-digit integer — number length limit is not enforced

**Les deux tests sur la version corrigée : RÉUSSI.**

---

## Preuve de concept

### CVE-2025-52999 — Déni de service par profondeur d'imbrication```java
// Build a 1001-level nested array document (just over the limit)
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1001; i++) sb.append('[');
for (int i = 0; i < 1001; i++) sb.append(']');

JsonFactory factory = new JsonFactory();
JsonParser parser = factory.createParser(sb.toString());
try {
    while (parser.nextToken() != null) { }       // ← throws on 1001st '['
    System.err.println("VULNERABLE: no exception thrown");
} catch (StreamConstraintsException e) {
    System.out.println("REMEDIATED: " + e.getMessage());
    // Depth (1001) exceeds the maximum allowed nesting depth (1000)
} finally {
    parser.close();
}

---

## Guide de migration

### Option 1: Mise à niveau vers jackson-core 2.15.4+ (Recommandé)```xml
<!-- Maven -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

<!-- Or with Jackson BOM -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson</groupId>
            <artifactId>jackson-bom</artifactId>
            <version>2.15.4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

### Option 2: Appliquer cette remédiation de sécurité```bash
git clone https://github.com/sassoftware/jackson-core.git
cd jackson-core
git checkout 2.13.5-CVE-2025-52999-sonatype-2022-6438-GHSA-2m67-wjpj-xhg9
./mvnw install -DskipTests

---

## Licence

Sous licence [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0).```
Copyright 2024–2025 The Jackson Authors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.