Errores al verificar y al manejar los fallos

Un patrón frecuente al migrar: «si la apertura nueva falla, probamos con la vieja, por compatibilidad». Parece prudente y es lo contrario: un sobre que falla la verificación es justo el que no hay que abrir, y el respaldo lo abre por el camino sin etiqueta. La versión del sobre debe decidirse por un campo del propio formato, no por intento y error tras un fallo.

Abre abrir-con-respaldo.txt y mira qué ocurre cuando la etiqueta no coincide.

Para corregir un hallazgo hay que nombrar el punto exacto del código donde ocurre, no «el módulo». El respaldo vive en una función concreta, y esa función es la que se cambia: la que elige la versión por el campo del sobre y no vuelve atrás tras un fallo.

Si el servicio contesta «relleno incorrecto» en un caso y «firma de integridad incorrecta» en otro, el que envía sobres inválidos aprende cuál de las dos comprobaciones falló. Esa diferencia, repetida, es información útil para quien quiera sondear el servicio. La respuesta al exterior debe ser la misma y genérica; el detalle va al registro interno, sin incluir texto descifrado ni claves.

Compara las respuestas de hoy con la propuesta de respuestas-de-error.txt.

Con ficheros grandes se descifra por trozos. En un modo autenticado la etiqueta cubre todo el fichero y se comprueba al final; si el código escribe, indexa o envía cada trozo según llega, ya procesó datos que quizá no eran legítimos cuando la verificación falla. La regla: no usar nada de lo descifrado hasta que la etiqueta haya pasado, o cifrar el fichero en trozos pequeños, cada uno con su propia etiqueta.

El mejor seguro contra todo lo anterior es una prueba que altere un sobre y exija que se rechace. Si no existe, nadie se entera cuando un cambio posterior rompe la verificación. La política del módulo pide esa prueba; el resultado de la suite dice cuál falta.