Las cuatro implementaciones de `JsonParser` comparten esta falla. El ataque es igualmente explotable a través
de cualquiera de ellas — ya sea que la entrada llegue mediante `InputStream`, `Reader`, `DataInput` o la API
asíncrona de alimentador no bloqueante.

**Vectores de ataque:**

| # | Estrategia | Ejemplo de carga útil | Incremento de profundidad | Analizadores afectados |
|---|----------|----------------|-----------------|------------------|
| 1 | Anidamiento de arrays | `[[[…]]]` — 1001 tokens `[` consecutivos | +1 por `[` | Las cuatro |
| 2 | Anidamiento de objetos | `{"k":{"k":{…}}}` — 1001 tokens `{` consecutivos | +1 por `{` | Las cuatro |
| 3 | Anidamiento alternado | `[{"k":[{"k":…}]}]` — 1001 tokens mixtos `[`/`{` | +1 por `[` o `{` | Las cuatro |

Observaciones clave:

- **Anidamiento de arrays — sobrecarga mínima:** solo se requieren tokens `[` y `]`; no hay claves, valores ni espacios en blanco. Una carga útil de 2002 bytes con 1001 pares de corchetes es suficiente para superar el límite predeterminado de 1000.
- **Anidamiento de objetos — presión de heap amplificada:** cada `{` asigna además una ranura de clave `JsonReadContext` sobre el nodo de la cadena de profundidad, lo que agrava el consumo de memoria en profundidades extremas.
- **Anidamiento alternado — evasión del firewall de aplicaciones web (WAF):** las defensas de coincidencia de patrones que detectan secuencias repetidas `[[[` o `{{{` son ciegas al anidamiento de tokens alternados; el contador de profundidad del analizador se incrementa de forma idéntica independientemente del tipo de token.
- **Alimentador no bloqueante — misma carga útil, superficie de entrega distinta:** las tres estrategias de anidamiento son igualmente explotables mediante `NonBlockingJsonParser` y la API `ByteArrayFeeder`. El documento puede entregarse en fragmentos arbitrariamente pequeños; `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()` incrementan el contador de profundidad en cada token de apertura de contexto, independientemente de cómo lleguen los bytes, acumulando profundidad a lo largo de múltiples llamadas a `feedInput()`.

Las tres estrategias de anidamiento son alcanzables a través de cualquiera de las cuatro implementaciones de `JsonParser`.
Con 2.13.5, el análisis se completa silenciosamente; con esta remediación, los tres vectores lanzan
`StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)`.

---

### Sonatype-2022-6438 — Longitud sin límite de tokens numéricos

**Detalles de seguridad**

| Campo | Valor |
|-------|-------|
| ID de Sonatype | [sonatype-2022-6438](https://guide.sonatype.com/vulnerability/sonatype-2022-6438/security-details) |
| Descripción | jackson-core — Denegación de servicio (DoS) |
| Publicado | 2022-12-07 |
| Fuente | Sonatype |
| Puntuación 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) — Asignación de recursos sin límites ni limitaciones |
| Puntuación EPSS | 0% |
| PRs de corrección upstream | [jackson-core#827](https://github.com/FasterXML/jackson-core/pull/827), [jackson-core#846](https://github.com/FasterXML/jackson-core/pull/846) |

**Métodos vulnerables (según lo identificado por Sonatype)**

| Método | Notas |
|--------|-------|
| `com.fasterxml.jackson.core.base.ParserBase._parseSlowInt(I)V` | Parámetro vulnerable: índice 0 |
| `com.fasterxml.jackson.core.base.ParserBase.convertNumberToBigDecimal()V` | |
| `com.fasterxml.jackson.core.base.ParserMinimalBase.getValueAsDouble(D)D` | Parámetro vulnerable: índice 0 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDecimal()` | Devuelve `BigDecimal` |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDouble(Z)D` | |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsFloat(Z)F` | |

Cada uno de estos métodos procesa el búfer de dígitos en bruto sin validar primero su longitud. Pasar un
token numérico suficientemente largo desencadena una asignación de heap sin límite y agotamiento de CPU cuando la JVM
intenta instanciar un `BigInteger` o `BigDecimal` a partir del contenido no restringido del búfer.

---

**Causa raíz:** Antes de 2.15.0, `JsonParser` no imponía ningún límite en la longitud en bytes de los tokens de enteros, notación científica, punto flotante simple o punto flotante compuesto. Cuando un analizador asigna su `_textBuffer` interno para acumular dígitos, un
atacante puede proporcionar un número con millones de dígitos, lo que hace que el búfer crezca sin límite y
finalmente agote la memoria heap.

**Rutas de código vulnerables:**

Existen dos rutas vulnerables estructuralmente distintas — una compartida por los tres analizadores síncronos,
y una segunda ruta independiente a través del analizador asíncrono.

**Ruta A — analizadores síncronos** (tres implementaciones, un sumidero compartido):```
JsonParser.nextToken()                         // common entry point
  │
  ├─ ReaderBasedJsonParser   ─┐
  ├─ UTF8StreamJsonParser     ├─→ ParserBase.resetInt() / resetFloat()
  └─ UTF8DataInputJsonParser ─┘         │
                                        ▼
                               _textBuffer.contentsAsString()
                               ⚠  no length check — buffer grows without bound

El analizador no bloqueante (asíncrono) es una superficie de ataque particularmente notable: contiene sus propios
bucles de acumulación de dígitos en `_startPositiveNumber`, `_startNegativeNumber`,
`_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction` y `_finishFloatExponent`
que establecen `_intLength` / `_fractLength` / `_expLength` directamente sin pasar nunca por
`ParserBase.resetInt()` o `resetFloat()`. Esto significa que la corrección del PR #827 de upstream (que añadió
validación solo a `ParserBase`) **dejó `NonBlockingJsonParser` completamente desprotegido**.
Esto se descubrió durante un análisis ampliado de la superficie de ataque y se remedió en esta rama.

**Vectores de ataque:**

| # | Forma del token | Ejemplo de carga útil | `intLen` | `fractLen` | `expLen` | Total | Restricción |
|---|------------|----------------|----------|------------|----------|-------|------------|
| 1 | Entero | `999…` — 199,999 dígitos consecutivos | 199,999 | 0 | 0 | 199,999 | `validateIntegerLength` |
| 2 | Fracción decimal | `0.999…` — entero de 1 dígito, fracción de 1,001 dígitos | 1 | 1,001 | 0 | 1,002 | `validateFPLength` |
| 3 | Notación científica | `1e999…` — significando de 1 dígito, exponente de 1,001 dígitos | 1 | 0 | 1,001 | 1,002 | `validateFPLength` |
| 4 | Punto flotante compuesto | `0.999…e999…` — fracción de 500 dígitos, exponente de 500 dígitos | 1 | 500 | 500 | 1,001 | `validateFPLength` |

Observaciones clave:

- **Entero — el carácter de signo no es un dígito:** el `-` inicial se excluye de la acumulación de dígitos; `-999…` y `999…` producen valores `intLen` idénticos y activan la restricción en el mismo umbral.
- **Fracción decimal — entero corto, fracción ilimitada:** la parte entera puede ser un único dígito (0) mientras que la parte fraccionaria crece sin límite; el punto decimal en sí se excluye del recuento.
- **Notación científica — compacta pero catastrófica:** con aproximadamente 1,004 bytes es la carga útil efectiva más pequeña; fuerza la instanciación de un `BigDecimal` con escala ±10^1001, exigiendo una asignación de heap intermedia sin límites a pesar del pequeño tamaño del token.
- **Punto flotante compuesto — evasión del límite dividido:** con `fractLen = 500` y `expLen = 500`, ningún componente alcanza individualmente el umbral de 1,000 dígitos. La verificación unificada `validateFPLength(intLen + fractLen + expLen)` es la única defensa que cierra esta brecha.
- **Analizador no bloqueante — derivación independiente:** las cuatro formas de token anteriores son explotables de forma independiente a través de `NonBlockingJsonParser` mediante `ByteArrayFeeder`. A diferencia de los analizadores síncronos, `NonBlockingJsonParser` acumula dígitos en bucles privados (`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`) que escriben `_intLength` / `_fractLength` / `_expLength` directamente, omitiendo por completo `ParserBase.resetInt()` y `resetFloat()`. El PR #827 de upstream — que solo modificó `ParserBase` — dejó, por tanto, este analizador totalmente desprotegido, requiriendo seis parches independientes en los puntos de llamada en esta remediación.

Las cuatro formas de token y la derivación no bloqueante se rechazan en el momento de la tokenización — antes de que se construya cualquier `BigDecimal` o `BigInteger`
— mediante `validateIntegerLength` y `validateFPLength` en `ParserBase` (analizadores síncronos)
y en seis puntos de llamada dedicados en `NonBlockingJsonParser` (analizador asíncrono). Con 2.13.5, las cuatro formas de token se aceptan silenciosamente; con esta remediación, cada analizador lanza
`StreamConstraintsException: Number length (N) exceeds the maximum length (1000)`.

> **Nota sobre `UTF8DataInputJsonParser` con cargas útiles grandes:** El analizador DataInput tiene un
> límite de búfer interno preexistente de 65 536 bytes ([jackson-core#493](https://github.com/FasterXML/jackson-core/issues/493)).
> Los documentos que superan este tamaño (p. ej., cargas útiles PoC de 199,999 dígitos ≈ 200 KB) provocan una
> `ArrayIndexOutOfBoundsException` antes de que la restricción de longitud pueda activarse. La protección
> de longitud numérica para `UTF8DataInputJsonParser` se verifica, por lo tanto, con cargas útiles más cortas
> (≤ 1,001 dígitos) donde el error aún es reproducible.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — Evasión de la restricción de longitud del documento

**Detalles de seguridad**

| Campo | Valor |
|-------|-------|
| ID de Snyk | [SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551](https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551) |
| Aviso de GitHub | [GHSA-2m67-wjpj-xhg9](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-2m67-wjpj-xhg9) |
| Descripción | Asignación de recursos sin límites ni control |
| Divulgado | 2026-04-04 |
| Puntuación CVSS v4.0 | **8.7 ALTO** |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Asignación de recursos sin límites ni control |
| Versiones afectadas | [2.8.0, 2.21.2) |
| Corrección upstream | jackson-core 2.18.7, 2.21.2 o superior |
| Commits de la corrección | [74c9ee25](https://github.com/FasterXML/jackson-core/commit/74c9ee25) (3.x), [7ce3622f](https://github.com/FasterXML/jackson-core/commit/7ce3622f) (2.18.x) |

**Causa raíz:** Incluso cuando `StreamReadConstraints.maxDocumentLength` está configurado, las versiones anteriores a
2.18.7 / 2.21.2 no aplican el límite de longitud del documento en ninguna ruta del analizador. Los analizadores bloqueantes
(`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) nunca validan los bytes acumulados leídos contra el
límite configurado. El analizador asíncrono (`NonBlockingJsonParser`) carece igualmente de validación en
`feedInput()`. El `UTF8DataInputJsonParser` no tiene ningún mecanismo para rastrear el total de bytes consumidos.

En jackson-core 2.13.5, `maxDocumentLength` no existía en absoluto, lo que significa que no había forma de
restringir el tamaño del documento. Esta remediación introduce el campo `maxDocumentLength` en
`StreamReadConstraints` y lo aplica en todas las rutas del analizador.

**Rutas de analizador vulnerables:**

| Analizador | Ruta | Punto de aplicación |
|--------|------|-------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | Valida `_currInputProcessed + count` después de cada recarga del búfer y al final del flujo (EOF) |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | Mismo patrón que `UTF8StreamJsonParser` |
| `NonBlockingJsonParser` | `feedInput()` | Valida `_currInputProcessed + _origBufferLen` después de cada fragmento de entrada |
| `UTF8DataInputJsonParser` | `DataInput` | Fail-fast: lanza `StreamConstraintsException` si `maxDocumentLength` está configurado |

**Escenario de ataque:** Un atacante envía un documento JSON válido pero de tamaño excesivo (por ejemplo, una estructura
profundamente anidada o altamente repetitiva que abarca gigabytes) a un servicio que ha configurado
`maxDocumentLength` para evitar el agotamiento de recursos. Sin la aplicación, el analizador procesa el
documento completo independientemente del límite configurado, consumiendo memoria y CPU sin límites.

---

## Impacto de seguridad

Las cuatro vulnerabilidades son explotables de forma remota sin requerir autenticación:

- Cualquier servicio que analice JSON controlado por el atacante mediante un `JsonParser` (directamente o a través de
  Jackson Databind, que envuelve `jackson-core`) está en riesgo.
- El ataque es trivialmente construible — unos pocos cientos de bytes de JSON son suficientes para desencadenar
  un consumo ilimitado de recursos.
- No hay impacto en la confidencialidad ni en la integridad; la disponibilidad (DoS) es la única clase de impacto.

---

## Detalles de la remediación

### Actualización oficial (recomendada)

Actualice a **jackson-core 2.15.4** o a cualquier versión estable posterior. Todas las versiones 2.15.x y 2.16+ incluyen
la API `StreamReadConstraints` con valores predeterminados seguros.```xml
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

Métodos de validación (llamados por los analizadores en cada nuevo 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;

Nuevos métodos auxiliares `_createChildArrayContext()` y `_createChildObjectContext()` envuelven la creación
de contexto con una verificación de profundidad:```java
protected JsonReadContext _createChildArrayContext(int line, int col) throws IOException {
    _streamReadConstraints.validateNestingDepth(_parsingContext.getNestingDepth() + 1);
    return _parsingContext.createChildArrayContext(line, col);
}

#### `json/JsonReadContext.java`

Las firmas de `createChildArrayContext()` y `createChildObjectContext()` se actualizaron para propagar
`throws IOException`.

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

Este es el principal arreglo adicional descubierto más allá del alcance del PR #827 original. Seis
puntos de finalización de números que omitían `ParserBase.resetInt()` fueron corregidos individualmente:

| Método | Validación añadida |
|--------|------------------|
| `_startPositiveNumber()` — retorno de ruta rápida | `validateIntegerLength(_intLength)` |
| `_startNegativeNumber()` — retorno de ruta rápida | `validateIntegerLength(_intLength)` |
| `_finishNumberIntegralPart()` — retorno final | `validateIntegerLength(_intLength)` |
| `_finishToken()` caso `MINOR_NUMBER_INTEGER_DIGITS` | `validateIntegerLength(_intLength)` |
| `_startFloat()` / `_finishFloatFraction()` / `_finishFloatExponent()` retornos finales | `validateFPLength(_intLength + _fractLength + _expLength)` |
| `_finishToken()` casos `MINOR_NUMBER_FRACTION_DIGITS` / `MINOR_NUMBER_EXPONENT_DIGITS` | `validateFPLength(...)` |

Todos los puntos son alcanzables: los métodos de ruta rápida manejan el caso en que el número completo está
disponible en una sola llamada a `feedInput()`; los casos de estado de reanudación `MINOR_*` manejan el caso
fragmentado en que los dígitos del número llegan en múltiples llamadas. Ambas rutas deben estar protegidas.

---

## Cobertura de pruebas

### CVE-2025-52999 — Pruebas de profundidad de anidamiento

| Archivo de prueba | Método de prueba | Modos de parser | Cubre |
|-----------|-------------|-------------|--------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | stream | Recorrido recursivo que simula el uso real de la aplicación; confirma `StreamConstraintsException` en profundidad 1001 (corregido) y `StackOverflowError` en profundidad 20,000 (2.13.5) |
| `read/ArrayParsingTest.java` | `testCustomNestingDepthConstraint` | API directa | `StreamReadConstraints.builder().maxNestingDepth(5)` — accesor, pasa en el límite, lanza excepción por encima del límite |
| `read/ArrayParsingTest.java` | `testObjectNestingDepthLimit` | stream | Objetos exactamente en el límite 1000 (pasan), objetos de nivel 1001 lanzan una excepción |
| `read/ArrayParsingTest.java` | `testDataInputParserDepthLimit` | `UTF8DataInputJsonParser` | `UTF8DataInputJsonParser` aplica el límite de profundidad de 1001 niveles |
| `read/ArrayParsingTest.java` | `testNonBlockingParserDepthLimit` | non-blocking | `NonBlockingJsonParser` aplica el límite de profundidad de 1001 niveles |

### Sonatype-2022-6438 — Pruebas de longitud numérica

| Archivo de prueba | Método de prueba | Modos de parser | Cubre |
|-----------|-------------|-------------|--------|
| `read/NumberOverflowTest.java` | `testSonatype_2022_6438` | `ALL_MODES` | Entero en el límite (pasa), entero por encima del límite (falla), flotante en el límite (pasa), flotante por encima del límite (falla), exponente de notación científica en el límite (pasa), exponente por encima del límite (falla) — los cuatro parsers |
| `read/NumberOverflowTest.java` | `testNonBlockingParserNumericLengthLimit` | non-blocking | `NonBlockingJsonParser` aplica la longitud numérica |
| `read/NumberOverflowTest.java` | `testNonBlockingParserExponentLengthLimit` | non-blocking | `NonBlockingJsonParser` aplica la longitud del exponente de notación científica mediante `validateFPLength` |
| `read/NumberOverflowTest.java` | `testCustomMaxNumberLengthConstraint` | API directa | `StreamReadConstraints.builder().maxNumberLength(5)` — accesor, pasa en el límite, lanza excepción por encima del límite tanto para `validateIntegerLength()` como para `validateFPLength()`, formato del mensaje de error |

> **Leyenda de modos de parser:**
> - `ALL_STREAMING_MODES` = `UTF8StreamJsonParser` (stream), `UTF8StreamJsonParser` (throttled), `ReaderBasedJsonParser`
> - `ALL_MODES` = los tres anteriores + `UTF8DataInputJsonParser`
> - `non-blocking` = `NonBlockingJsonParser` mediante `ByteArrayFeeder`
> - `stream` = `UTF8StreamJsonParser` (por defecto, `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — Pruebas de longitud de documento

| Archivo de prueba | Método de prueba | Modos de parser | Cubre |
|-----------|-------------|-------------|--------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | El parser InputStream aplica `maxDocumentLength` — documento de 20K rechazado con límite de 10K |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | El parser InputStream acepta el documento dentro del límite |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | El parser Reader aplica `maxDocumentLength` — documento de 20K rechazado con límite de 10K |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | El parser Reader acepta el documento dentro del límite |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | El parser asíncrono aplica `maxDocumentLength` — documento de 20K rechazado en `feedInput()` |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | El parser asíncrono acepta el documento dentro del límite |
| `constraints/LargeDocReadTest.java` | `testDataInputWithDocLengthLimitFails` | `UTF8DataInputJsonParser` | El parser DataInput falla rápidamente cuando se configura `maxDocumentLength` |
| `constraints/LargeDocReadTest.java` | `testDataInputWithoutDocLengthLimitWorks` | `UTF8DataInputJsonParser` | El parser DataInput funciona normalmente sin `maxDocumentLength` configurado |
| `constraints/LargeDocReadTest.java` | `testDefaultFactoryNoLimit` | `UTF8StreamJsonParser` | La factory por defecto (sin límite) acepta documentos grandes |

---

## Resultados completos de la suite de pruebas```
Tests run: 957, Failures: 0, Errors: 0, Skipped: 0

---

## Resultados de Validación

### Prueba de Regresión Contra jackson-core 2.13.5

Los métodos de prueba del CVE fueron diseñados para **fallar** en el código de 2.13.5 y
**pasar** en la compilación corregida.

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

**Ambas pruebas en la compilación corregida: PASS.**

---

## Prueba de concepto

### CVE-2025-52999 — DoS por profundidad de anidamiento```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();
}

---

## Guía de migración

### Opción 1: Actualizar a jackson-core 2.15.4+ (Recomendado)```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>

### Opción 2: Aplicar esta corrección de seguridad```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

---

## Licencia

Licenciado bajo la [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.