Tutte e quattro le implementazioni di `JsonParser` condividono questa falla. L'attacco è ugualmente sfruttabile attraverso ciascuna di esse — che l'input arrivi tramite `InputStream`, `Reader`, `DataInput` o l'API asincrona non bloccante feeder.

**Vettori d'attacco:**

| # | Strategia | Payload esempio | Incremento profondità | Parser interessati |
|---|-----------|----------------|-----------------------|-------------------|
| 1 | Annidamento array | `[[[…]]]` — 1.001 token `[` consecutivi | +1 per `[` | Tutti e quattro |
| 2 | Annidamento oggetto | `{"k":{"k":{…}}}` — 1.001 token `{` consecutivi | +1 per `{` | Tutti e quattro |
| 3 | Annidamento alternato | `[{"k":[{"k":…}]}]` — 1.001 token misti `[`/`{` | +1 per `[` o `{` | Tutti e quattro |

Osservazioni chiave:

- **Annidamento array — overhead minimo:** sono richiesti solo i token `[` e `]`; niente chiavi, valori o spazi bianchi. Un payload di 2.002 byte con 1.001 coppie di parentesi è sufficiente per superare il limite predefinito di 1.000.
- **Annidamento oggetto — pressione heap amplificata:** ogni `{` alloca ulteriormente uno slot chiave `JsonReadContext` oltre al nodo della catena di profondità, aggravando il consumo di memoria a profondità estreme.
- **Annidamento alternato — evasione del Web Application Firewall (WAF):** le difese di pattern-matching che rilevano sequenze ripetute di `[[[` o `{{{` sono cieche all'annidamento a token alternati; il contatore di profondità del parser incrementa allo stesso modo indipendentemente dal tipo di token.
- **Feeder non bloccante — stesso payload, superficie di consegna distinta:** tutte e tre le strategie di annidamento sono ugualmente sfruttabili tramite `NonBlockingJsonParser` e l'API `ByteArrayFeeder`. Il documento può essere consegnato in blocchi arbitrariamente piccoli; `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()` incrementano il contatore di profondità ad ogni token di apertura contesto indipendentemente da come arrivano i byte, accumulando profondità attraverso più chiamate `feedInput()`.

Tutte e tre le strategie di annidamento sono raggiungibili attraverso ciascuna delle quattro implementazioni di `JsonParser`. Con la 2.13.5, il parsing ha successo silenziosamente; con questa correzione, tutti e tre i vettori lanciano `StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)`.

---

### Sonatype-2022-6438 — Lunghezza Token Numerico Illimitata

**Dettagli di sicurezza**

| Campo | Valore |
|-------|--------|
| Sonatype ID | [sonatype-2022-6438](https://guide.sonatype.com/vulnerability/sonatype-2022-6438/security-details) |
| Descrizione | jackson-core — Negazione del Servizio (DoS) |
| Pubblicato | 2022-12-07 |
| Fonte | Sonatype |
| Punteggio CVSS v3.1 | **7.5 ALTA** — `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) — Assegnazione di Risorse Senza Limiti o Limitazione |
| Punteggio EPSS | 0% |
| PR di correzione upstream | [jackson-core#827](https://github.com/FasterXML/jackson-core/pull/827), [jackson-core#846](https://github.com/FasterXML/jackson-core/pull/846) |

**Metodi vulnerabili (come identificati da Sonatype)**

| Metodo | Note |
|--------|------|
| `com.fasterxml.jackson.core.base.ParserBase._parseSlowInt(I)V` | Parametro vulnerabile: indice 0 |
| `com.fasterxml.jackson.core.base.ParserBase.convertNumberToBigDecimal()V` | |
| `com.fasterxml.jackson.core.base.ParserMinimalBase.getValueAsDouble(D)D` | Parametro vulnerabile: indice 0 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDecimal()` | Restituisce `BigDecimal` |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDouble(Z)D` | |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsFloat(Z)F` | |

Ciascuno di questi metodi elabora il buffer di cifre grezze senza prima validarne la lunghezza. Passare un token numerico sufficientemente lungo innesca allocazione heap illimitata ed esaurimento della CPU quando la JVM tenta di istanziare un `BigInteger` o `BigDecimal` dal contenuto del buffer non vincolato.

---

**Causa principale:** Prima della 2.15.0, `JsonParser` non imponeva alcun limite sulla lunghezza in byte dei token interi, in notazione scientifica, a virgola mobile semplici o composti. Quando un parser alloca il suo `_textBuffer` interno per accumulare cifre, un attaccante può fornire un numero con milioni di cifre, causando la crescita illimitata del buffer e portando infine all'esaurimento della memoria heap.

**Percorsi di codice vulnerabili:**

Esistono due percorsi vulnerabili strutturalmente distinti — uno condiviso dai tre parser sincroni, e un secondo percorso indipendente attraverso il parser asincrono.

**Path A — parser sincroni** (tre implementazioni, un sink condiviso):```
JsonParser.nextToken()                         // common entry point
  │
  ├─ ReaderBasedJsonParser   ─┐
  ├─ UTF8StreamJsonParser     ├─→ ParserBase.resetInt() / resetFloat()
  └─ UTF8DataInputJsonParser ─┘         │
                                        ▼
                               _textBuffer.contentsAsString()
                               ⚠  no length check — buffer grows without bound

Il parser non bloccante (asincrono) è una superficie d'attacco particolarmente degna di nota: contiene i propri
cicli di accumulo di cifre in `_startPositiveNumber`, `_startNegativeNumber`,
`_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction` e `_finishFloatExponent`
che impostano `_intLength` / `_fractLength` / `_expLength` direttamente senza passare mai attraverso
`ParserBase.resetInt()` o `resetFloat()`. Ciò significa che la correzione a monte della PR #827 (che ha aggiunto
la validazione solo a `ParserBase`) **ha lasciato `NonBlockingJsonParser` completamente non protetto**.
Questa scoperta è stata fatta durante un'analisi estesa della superficie d'attacco e corretta in questo branch.

**Vettori d'attacco:**

| # | Forma del token | Esempio di payload | `intLen` | `fractLen` | `expLen` | Totale | Vincolo |
|---|----------------|-------------------|----------|------------|----------|--------|---------|
| 1 | Intero | `999…` — 199.999 cifre consecutive | 199.999 | 0 | 0 | 199.999 | `validateIntegerLength` |
| 2 | Frazione decimale | `0.999…` — intero a 1 cifra, frazione a 1.001 cifre | 1 | 1.001 | 0 | 1.002 | `validateFPLength` |
| 3 | Notazione scientifica | `1e999…` — significando a 1 cifra, esponente a 1.001 cifre | 1 | 0 | 1.001 | 1.002 | `validateFPLength` |
| 4 | Virgola mobile composta | `0.999…e999…` — frazione a 500 cifre, esponente a 500 cifre | 1 | 500 | 500 | 1.001 | `validateFPLength` |

Osservazioni chiave:

- **Intero — il segno non è una cifra:** il `-` iniziale è escluso dall'accumulo di cifre; `-999…` e `999…` producono valori identici di `intLen` e attivano il vincolo alla stessa soglia.
- **Frazione decimale — intero corto, frazione illimitata:** la parte intera può essere una singola cifra (0) mentre la parte frazionaria cresce senza limite; il punto decimale stesso è escluso dal conteggio.
- **Notazione scientifica — compatta ma catastrofica:** a circa 1.004 byte è il payload efficace più piccolo; forza l'istanziazione di un `BigDecimal` con scala ±10^1001, richiedendo un'allocazione intermedia di heap illimitata nonostante la piccola dimensione del token.
- **Virgola mobile composta — elusione del limite suddiviso:** con `fractLen = 500` e `expLen = 500`, nessun componente raggiunge individualmente la soglia di 1.000 cifre. Il controllo unificato `validateFPLength(intLen + fractLen + expLen)` è l'unica difesa che chiude questa falla.
- **Parser non bloccante — bypass indipendente:** tutte e quattro le forme di token sopra sono sfruttabili indipendentemente attraverso `NonBlockingJsonParser` tramite `ByteArrayFeeder`. A differenza dei parser sincroni, `NonBlockingJsonParser` accumula cifre in cicli privati (`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`) che scrivono `_intLength` / `_fractLength` / `_expLength` direttamente, bypassando completamente `ParserBase.resetInt()` e `resetFloat()`. La PR #827 a monte — che ha modificato solo `ParserBase` — ha quindi lasciato questo parser completamente non protetto, richiedendo sei patch indipendenti nei siti di chiamata in questa correzione.

Tutte e quattro le forme di token e il bypass non bloccante vengono rifiutati al momento della tokenizzazione — prima che qualsiasi `BigDecimal` o `BigInteger`
venga costruito — da `validateIntegerLength` e `validateFPLength` in `ParserBase` (parser sincroni)
e in sei siti di chiamata dedicati in `NonBlockingJsonParser` (parser asincrono). Con 2.13.5, tutte e quattro le forme di token vengono accettate silenziosamente; con questa correzione, ogni parser lancia
`StreamConstraintsException: Number length (N) exceeds the maximum length (1000)`.

> **Nota su `UTF8DataInputJsonParser` con payload grandi:** Il parser DataInput ha un
> limite interno del buffer preesistente di 65.536 byte ([jackson-core#493](https://github.com/FasterXML/jackson-core/issues/493)).
> I documenti che superano questa dimensione (ad es., payload PoC da 199.999 cifre ≈ 200 KB) attivano
> un `ArrayIndexOutOfBoundsException` prima che il vincolo di lunghezza possa scattare. La protezione
> della lunghezza numerica per `UTF8DataInputJsonParser` è quindi verificata con payload più brevi
> (≤ 1.001 cifre) dove il bug è ancora riproducibile.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — Bypass del vincolo di lunghezza del documento

**Dettagli di sicurezza**

| Campo | Valore |
|-------|--------|
| ID Snyk | [SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551](https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551) |
| Advisory GitHub | [GHSA-2m67-wjpj-xhg9](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-2m67-wjpj-xhg9) |
| Descrizione | Allocazione di risorse senza limiti o limitazione |
| Divulgato | 2026-04-04 |
| Punteggio CVSS v4.0 | **8.7 ALTA** |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Allocazione di risorse senza limiti o limitazione |
| Versioni affette | [2.8.0, 2.21.2) |
| Correzione a monte | jackson-core 2.18.7, 2.21.2 o superiore |
| Commit di correzione | [74c9ee25](https://github.com/FasterXML/jackson-core/commit/74c9ee25) (3.x), [7ce3622f](https://github.com/FasterXML/jackson-core/commit/7ce3622f) (2.18.x) |

**Causa principale:** Anche quando `StreamReadConstraints.maxDocumentLength` è configurato, le versioni precedenti
alla 2.18.7 / 2.21.2 non impongono il limite di lunghezza del documento in nessun percorso del parser. I parser bloccanti
(`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) non convalidano mai i byte cumulativi letti rispetto al
limite configurato. Il parser asincrono (`NonBlockingJsonParser`) manca similmente di validazione in
`feedInput()`. `UTF8DataInputJsonParser` non ha alcun meccanismo per tracciare i byte totali consumati.

In jackson-core 2.13.5, `maxDocumentLength` non esisteva affatto, il che significa che non c'era modo di
limitare la dimensione del documento. Questa correzione introduce il campo `maxDocumentLength` in
`StreamReadConstraints` e lo impone in tutti i percorsi del parser.

**Percorsi di parser vulnerabili:**

| Parser | Percorso | Punto di imposizione |
|--------|----------|----------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | Convalida `_currInputProcessed + count` dopo ogni ricarica del buffer e all'EOF |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | Stesso schema di `UTF8StreamJsonParser` |
| `NonBlockingJsonParser` | `feedInput()` | Convalida `_currInputProcessed + _origBufferLen` dopo ogni blocco di input |
| `UTF8DataInputJsonParser` | `DataInput` | Fail-fast: lancia `StreamConstraintsException` se `maxDocumentLength` è configurato |

**Scenario d'attacco:** Un attaccante invia un documento JSON valido ma di dimensioni eccessive (ad es., una struttura
profondamente annidata o altamente ripetitiva che si estende per gigabyte) a un servizio che ha configurato
`maxDocumentLength` per prevenire l'esaurimento delle risorse. Senza imposizione, il parser elabora l'intero
documento indipendentemente dal limite configurato, consumando memoria e CPU illimitate.

---

## Impatto sulla sicurezza

Tutte e quattro le vulnerabilità sono sfruttabili da remoto senza autenticazione:

- Qualsiasi servizio che analizza JSON controllato dall'attaccante tramite un `JsonParser` (direttamente o attraverso
  Jackson Databind, che avvolge `jackson-core`) è a rischio.
- L'attacco è banale da costruire — poche centinaia di byte di JSON sono sufficienti per innescare
  un consumo illimitato di risorse.
- Nessun impatto sulla riservatezza o sull'integrità; la disponibilità (DoS) è l'unica classe di impatto.

---

## Dettagli della correzione

### Aggiornamento ufficiale (Raccomandato)

Aggiornare a **jackson-core 2.15.4** o qualsiasi release stabile successiva. Tutte le release 2.15.x e 2.16+
includono l'API `StreamReadConstraints` con valori predefiniti sicuri.```xml
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

Metodi di validazione (chiamati dai parser su ogni nuovo token):```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;

Nuovi metodi helper `_createChildArrayContext()` e `_createChildObjectContext()` racchiudono la creazione del contesto con un controllo di profondità:```java
protected JsonReadContext _createChildArrayContext(int line, int col) throws IOException {
    _streamReadConstraints.validateNestingDepth(_parsingContext.getNestingDepth() + 1);
    return _parsingContext.createChildArrayContext(line, col);
}

#### `json/JsonReadContext.java`

`createChildArrayContext()` e `createChildObjectContext()` firme aggiornate per propagare
`throws IOException`.

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

Questo è il principale fix aggiuntivo scoperto al di là dell'ambito della PR #827 upstream. Sei
siti di completamento numerico che bypassavano `ParserBase.resetInt()` sono stati remediati
individualmente:

| Metodo | Validazione aggiunta |
|--------|----------------------|
| `_startPositiveNumber()` — fast-path return | `validateIntegerLength(_intLength)` |
| `_startNegativeNumber()` — fast-path return | `validateIntegerLength(_intLength)` |
| `_finishNumberIntegralPart()` — final return | `validateIntegerLength(_intLength)` |
| `_finishToken()` case `MINOR_NUMBER_INTEGER_DIGITS` | `validateIntegerLength(_intLength)` |
| `_startFloat()` / `_finishFloatFraction()` / `_finishFloatExponent()` final returns | `validateFPLength(_intLength + _fractLength + _expLength)` |
| `_finishToken()` cases `MINOR_NUMBER_FRACTION_DIGITS` / `MINOR_NUMBER_EXPONENT_DIGITS` | `validateFPLength(...)` |

Tutti i siti sono raggiungibili: i metodi fast-path gestiscono il caso in cui il numero
completo è disponibile in una singola chiamata `feedInput()`; i casi di stato di ripresa
`MINOR_*` gestiscono il caso frammentato in cui le cifre del numero arrivano attraverso
chiamate multiple. Entrambi i percorsi devono essere protetti.

---

## Copertura dei test

### CVE-2025-52999 — Test della profondità di annidamento

| File di test | Metodo di test | Modalità parser | Copertura |
|--------------|----------------|-----------------|-----------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | stream | Traversal ricorsivo simulando l'uso reale dell'app; conferma `StreamConstraintsException` alla profondità 1001 (riparato) e `StackOverflowError` alla profondità 20.000 (2.13.5) |
| `read/ArrayParsingTest.java` | `testCustomNestingDepthConstraint` | direct API | `StreamReadConstraints.builder().maxNestingDepth(5)` — accessor, passaggio al limite, superamento del limite lancia eccezione |
| `read/ArrayParsingTest.java` | `testObjectNestingDepthLimit` | stream | Oggetti esattamente al limite 1000 (passaggio), oggetti al livello 1001 lanciano eccezione |
| `read/ArrayParsingTest.java` | `testDataInputParserDepthLimit` | `UTF8DataInputJsonParser` | `UTF8DataInputJsonParser` impone il limite di profondità di 1001 livelli |
| `read/ArrayParsingTest.java` | `testNonBlockingParserDepthLimit` | non-blocking | `NonBlockingJsonParser` impone il limite di profondità di 1001 livelli |

### Sonatype-2022-6438 — Test della lunghezza numerica

| File di test | Metodo di test | Modalità parser | Copertura |
|--------------|----------------|-----------------|-----------|
| `read/NumberOverflowTest.java` | `testSonatype_2022_6438` | `ALL_MODES` | Intero al limite (passaggio), intero oltre il limite (fallimento), float al limite (passaggio), float oltre il limite (fallimento), esponente in notazione scientifica al limite (passaggio), esponente oltre il limite (fallimento) — tutti e quattro i parser |
| `read/NumberOverflowTest.java` | `testNonBlockingParserNumericLengthLimit` | non-blocking | `NonBlockingJsonParser` impone la lunghezza numerica |
| `read/NumberOverflowTest.java` | `testNonBlockingParserExponentLengthLimit` | non-blocking | `NonBlockingJsonParser` impone la lunghezza dell'esponente in notazione scientifica tramite `validateFPLength` |
| `read/NumberOverflowTest.java` | `testCustomMaxNumberLengthConstraint` | direct API | `StreamReadConstraints.builder().maxNumberLength(5)` — accessor, passaggio al limite, superamento del limite lancia eccezione per entrambi `validateIntegerLength()` e `validateFPLength()`, formato del messaggio di errore |

> **Legenda delle modalità parser:**
> - `ALL_STREAMING_MODES` = `UTF8StreamJsonParser` (stream), `UTF8StreamJsonParser` (throttled), `ReaderBasedJsonParser`
> - `ALL_MODES` = le tre precedenti + `UTF8DataInputJsonParser`
> - `non-blocking` = `NonBlockingJsonParser` tramite `ByteArrayFeeder`
> - `stream` = `UTF8StreamJsonParser` (predefinito `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — Test della lunghezza del documento

| File di test | Metodo di test | Modalità parser | Copertura |
|--------------|----------------|-----------------|-----------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | Il parser InputStream impone `maxDocumentLength` — documento 20K rifiutato con limite 10K |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | Il parser InputStream accetta documento entro il limite |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | Il parser Reader impone `maxDocumentLength` — documento 20K rifiutato con limite 10K |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | Il parser Reader accetta documento entro il limite |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | Il parser asincrono impone `maxDocumentLength` — documento 20K rifiutato in `feedInput()` |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | Il parser asincrono accetta documento entro il limite |
| `constraints/LargeDocReadTest.java` | `testDataInputWithDocLengthLimitFails` | `UTF8DataInputJsonParser` | Il parser DataInput fallisce rapidamente quando `maxDocumentLength` è configurato |
| `constraints/LargeDocReadTest.java` | `testDataInputWithoutDocLengthLimitWorks` | `UTF8DataInputJsonParser` | Il parser DataInput funziona normalmente senza `maxDocumentLength` configurato |
| `constraints/LargeDocReadTest.java` | `testDefaultFactoryNoLimit` | `UTF8StreamJsonParser` | La factory predefinita (nessun limite) accetta documenti grandi |

---

## Risultati completi della suite di test```
Tests run: 957, Failures: 0, Errors: 0, Skipped: 0

---

## Risultati di convalida

### Test di regressione contro jackson-core 2.13.5

I metodi di test CVE sono stati progettati per **fallire** sul codebase 2.13.5 e **passare** sulla build corretta.

**`NumberOverflowTest#testSonatype_2022_6438`** contro 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

**Entrambi i test sulla build corretta: PASS.**

---

## Prova di concetto

### CVE-2025-52999 — Profondità di annidamento DoS```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();
}

---

## Guida alla migrazione

### Opzione 1: Aggiornamento a jackson-core 2.15.4+ (Consigliato)```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>

### Opzione 2: Applica questa correzione di sicurezza```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

---

## Licenza

Concesso in licenza ai sensi della [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.