Resumen

  • En el commit público fijado 3c2068477eb38ebbbe70039ee6e1b7b004fc69cd, una elección nueva obtiene ALL como modo predeterminado de recuperación de enlaces, sin importar su tipo; ONLY_BR y NONE siguen disponibles.
  • La misma dirección, normalizada, activa tres búsquedas independientes: votantes, contactos de organizaciones miembro y contactos de apoyo a postulaciones. Cada una puede reenviar su propio enlace tokenizado.
  • La respuesta indistinguible y el tope de diez coincidencias por clase reducen exposición. Un recibo privado debería demostrar por qué cada poder seguía vigente, cómo se entregó y cuándo expiró, se usó o se anuló.

Hay tres maneras de leer un correo en este sistema. Puede ser un dato de entrega para quien figura en el padrón. Puede ser el contacto mediante el cual una organización ejerce la facultad de postular. O puede pertenecer a quien debe confirmar el apoyo de una nominación. La ortografía de la dirección no revela cuál de esas funciones está en juego.

El repositorio elections-open-source de LACNIC sí lo revela. El panel de recuperación convierte la dirección a minúsculas y consulta, por separado, UserVoter.mail, Organization.membershipContactEmail y SupportNomination.supportingContactEmail. Después clasifica los envíos como enlace de voto, de postulación o de apoyo. Esa separación es una buena noticia: el diseño no confunde las tablas.

La decisión llamativa aparece un paso antes. Al construir una elección, el modelo llama a defaultForElectionType. La función recibe un tipo, pero siempre devuelve ALL. Los ensayos esperan ALL para una elección nueva de Directorio. La guía pública confirma el alcance: en esta distribución, toda elección nueva comienza en ALL, independientemente del tipo. Un administrador puede seleccionar ONLY_BR o NONE.

No hay aquí evidencia de que una elección real de LACNIC utilice ese commit ni ese valor. Tampoco hay una prueba de recuperación ejecutada, una dirección observada o un token examinado. La fotografía pertenece al código público. Su interés está en una cuestión de control: una configuración general nace antes de que quede constancia pública de por qué encaja con el mandato concreto.

Recuperar participación también recupera poder

La pérdida de un mensaje es una causa absurda de exclusión. El correo inicial puede caer en spam, quedar en un teléfono antiguo o desaparecer bajo miles de notificaciones. Una herramienta que reenvía el enlace permite que un problema de entrega no se convierta en un problema de representación. Desactivar toda recuperación tendría su propio coste de legitimidad.

Por eso ALL no debe tratarse como sinónimo de inseguridad. Puede ser un valor elegido para favorecer acceso uniforme, disminuir intervención manual y evitar que un tipo de elección reciba peor soporte que otro. El código permite reducir ese alcance. La pregunta no es si la recuperación debe existir, sino qué evidencia deja cuando vuelve a poner una capacidad en circulación.

Un enlace de voto no es una simple página de información. La ruta posterior comprueba calendario, estado y token, pero la posesión del enlace es una parte del acceso. Lo mismo ocurre con una URL de postulación o apoyo. Reenviar el enlace no crea el derecho original; hace posible ejercerlo otra vez desde el canal registrado.

Ese derecho proviene de lugares distintos. El padrón habilita al votante. La relación de membresía y el contacto designado habilitan a la organización. El flujo de nominación crea la solicitud de apoyo. Si una única bandeja recibe las tres cosas, la coincidencia puede ser totalmente correcta. Lo que debe sobrevivir es la prueba de cada origen.

ALL mide alcance, no justificación

El enum ofrece tres estados. NONE apaga la función. ONLY_BR filtra por Brasil, aunque el campo usado depende del objeto: país del votante, país de la organización o país de la organización que emitió la nominación. ALL elimina ese filtro. Son instrucciones de ejecución, no una taxonomía de riesgo.

Las elecciones de Directorio, Comisión Fiscal, Comisión Electoral, moderación del PDP, ASO AC e IANA Review Committee no son intercambiables. Sus electores, candidatos, órganos de control y normas pueden variar. Una misma política de recuperación puede ser adecuada para todas. Pero esa equivalencia debería ser el resultado de una revisión documentada, no una inferencia a partir de que el software arrancó.

La diferencia importa después. Si un auditor ve ALL, necesita saber si alguien lo aprobó, si llegó por herencia o si se mantuvo provisionalmente mientras otro canal no funcionaba. El valor almacenado no contiene esa procedencia. Una captura de pantalla tampoco. Hace falta una identidad de configuración y un acto de aceptación.

El tiempo suma otra capa. La recuperación solo se muestra cuando la elección no está cerrada y el modo no es NONE. La landing pública debe estar habilitada y haber alcanzado N_1. Según la guía, la recuperación no tiene un calendario propio. Toma prestada la vida de la elección y de su página pública.

Los enlaces recuperados sí encuentran reglas posteriores. El voto depende de su periodo. La postulación, el apoyo y las tareas del candidato tienen ventanas y estados distintos. Por eso un correo puesto en cola no basta para describir el resultado. El enlace puede llegar tarde y estar bloqueado; puede corresponder a una acción ya realizada; o puede continuar vigente. La evidencia debe unir el reenvío con la compuerta final.

Treinta posibilidades no son treinta autorizaciones

El código fija MAX_LINKS_BY_TYPE en diez. Lanza tres búsquedas con ese máximo. En consecuencia, una petición puede procesar hasta diez coincidencias de votantes, diez de organizaciones y diez de apoyos. El número no afirma que se enviarán treinta mensajes: puede haber menos coincidencias, tokens vacíos o fallos. Tampoco prueba que un individuo controle treinta facultades.

El límite evita que una dirección ampliamente reutilizada provoque un recorrido sin fin. Es una defensa de disponibilidad. No es un límite de autoridad. Para esto último habría que demostrar que cada fila seguía siendo válida, que el correo era todavía el canal designado y que la capacidad no había terminado.

El formulario evita mostrar el resultado. Si no hay fallo operacional, responde siempre con el mismo texto, encuentre o no encuentre registros. Esta decisión protege frente a la enumeración. Una persona externa no puede probar desde la pantalla que una dirección figura en el padrón.

El sistema, sin embargo, envía a la dirección guardada los enlaces que encuentre. La persona que controla esa bandeja puede aprender las clases por los mensajes recibidos. Eso es inherente al canal lateral. La respuesta uniforme protege al registro frente al solicitante; el recibo de autoridad protege al proceso frente a una entrega desactualizada o ambigua. Son controles complementarios.

El panel también distingue el error operacional. Cuenta coincidencias y colas; si una clase encuentra registros pero no consigue poner ningún mensaje en cola, marca fallo. Esa comprobación es valiosa. Aun así, “en cola” no significa “entregado”, y “entregado” no significa “ejercido por el principal correcto”.

El CAPTCHA es una condición, no una constante

La ruta de validación usa reCAPTCHA solo cuando se cumplen tres hechos: la recuperación está activa, un parámetro global permite mostrar CAPTCHA y existe una dataSiteKey. Si falta cualquiera, el formulario continúa sin esa verificación. La fuente no dice cuál es la configuración de una elección desplegada.

Por tanto, no se puede escribir honestamente que LACNIC carece de CAPTCHA ni que lo aplica siempre. Lo que sí puede afirmarse es que la protección es configurable y que el modo ALL no implica por sí solo su activación. Un recibo debería conservar la decisión efectiva por elección y por versión.

Las guías externas ayudan a ordenar la evidencia. OWASP aconseja, para recuperación de contraseñas, respuestas uniformes, tiempos comparables, limitación por cuenta o CAPTCHA y tokens aleatorios, de un solo uso y con vencimiento. NIST SP 800-63B establece, en su propio ámbito de identidad digital, que los métodos alternativos de recuperación deben basarse en análisis de riesgo documentado y que los eventos de recuperación generan notificaciones. Estas reglas no gobiernan elecciones de LACNIC, y un enlace de voto no es un reset de contraseña. Sirven para recordar que el canal de recuperación merece controles autónomos.

El material revisado no prueba la entropía de los tokens, su rotación, expiración o revocación; tampoco prueba entrega, custodia de la bandeja ni límites efectivos fuera del máximo de resultados. Es posible que otros módulos o la operación aporten esas garantías. El silencio de los archivos capturados no autoriza a inventar una vulnerabilidad.

Código abierto sin identidad de despliegue

La página institucional de LACNIC explica que el sistema electoral es de código abierto y puede ser auditado. La publicación permite una observación excepcionalmente precisa. Se puede seguir la dirección hasta tres consultas, ver qué enlaces salen de ellas y confirmar el valor predeterminado con pruebas automatizadas.

El commit de compatibilidad del 11 de septiembre de 2026 actualiza bibliotecas del servidor y mantiene el ensayo que espera ALL. El commit de cabeza, unos minutos después, añade cobertura para archivos subidos almacenados en disco. Ambos sirven para fechar la muestra. Ninguno enlaza por sí solo una elección pública con ese binario.

Ese límite protege el rigor. Este artículo no sostiene que el código sea el despliegue de producción, que ALL esté activo, que el CAPTCHA esté apagado o que haya ocurrido un incidente. Tampoco repite una pieza anterior sobre un correo situado en el camino de una consulta GET autenticada. Aquí el correo no selecciona un informe: solicita el reenvío de tres clases de capacidad.

La transparencia ganaría fuerza con una declaración agregada por elección: versión revisada, modo efectivo, clases recuperables, ventana, controles automatizados y autoridad que aceptó el ajuste. No es necesario publicar correos, tokens, direcciones IP o actos individuales.

Un recibo privado con salida pública mínima

El primer bloque del recibo uniría la elección, el build y la configuración. Nombraría el tipo de elección, el reglamento aplicable, el modo y su procedencia: heredado o elegido expresamente. Registraría quién revisó el valor y cuándo.

El segundo preservaría la clase de autoridad. Votante, organización postulante y contacto de apoyo deben conservar referencias separadas. Una clave opaca puede apuntar a la fila correspondiente sin copiar datos personales. La prueba incluiría el estado de la fila y la ventana del acto en el momento de la petición.

El tercero seguiría el token. ¿Se reenvió un enlace existente o se creó otro? ¿Cuál era su generación y vencimiento? ¿El anterior quedó inválido? ¿El enlace terminó usado, expirado, revocado o sustituido? La cola, la entrega y el uso ocuparían campos distintos.

El cuarto cerraría el poder. Cuando termina la votación o se resuelve una postulación, el enlace no debería conservar capacidad de decisión. Si mantiene una vista histórica, el recibo debe marcarla como solo lectura. La clausura general de la elección no tiene por qué ser el único evento terminal.

La proyección pública mostraría apenas la versión, el modo, las clases, las fechas, el estado de controles antiabuso, la política de invalidación y cifras agregadas con supresión para grupos pequeños. El detalle sensible permanecería protegido conforme a la política de privacidad.

La recuperación seguirá siendo útil. La diferencia es que dejará de presentar la entrega como si fuera el mandato. El correo puede devolver un enlace perdido; solo el registro de autoridad puede explicar por qué su destinatario aún tenía derecho a usarlo.

Fuentes