Cuando la notarización rechaza
El informe de rechazo es específico y útil: cómo se lee, las cinco causas frecuentes, y cómo se evita el ciclo de esperar para descubrir un fallo evitable.
Las cinco causas
Las tres primeras son casi todos los casos, y las tres se detectan localmente sin enviar nada.
Detectarlas antes de enviar
Las cuatro juntas son un guion de treinta líneas y convierten el ciclo de «enviar, esperar, leer, arreglar, repetir» en «comprobar en tres segundos, arreglar, enviar una vez».
Y merecen estar en la construcción automática, antes del envío, para que un fallo no consuma la espera.
Leer el informe
Cuando aun así rechacen, tres cosas que ayudan:
- El informe viene con una ruta dentro del paquete, y esa ruta identifica el fichero exacto.
- Puede haber varios problemas a la vez: arreglar solo el primero y reenviar es perder otra espera. Léelo entero.
- Y el mismo informe se puede volver a consultar con el identificador del envío, así que no hace falta guardarlo si se pierde.
El caso raro que merece conocerse
Además de las cinco, hay un rechazo que confunde: que el servicio detecte algo en un binario ajeno que empaquetaste.
Ocurre cuando un acompañante del nivel 46.1 contiene algo que el análisis marca. No significa necesariamente que sea dañino —hay falsos positivos— y significa que no puedes distribuirlo así.
Las salidas: usar otra compilación de esa herramienta, no empaquetarla —nivel 45.5— o sustituirla. Y es una razón más para verificar el origen de los binarios ajenos que metes en algo que firmas con tu identidad, que era el consejo del nivel 46.3.