Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Lack of immediate access to GenericArray to view associated functions and trait impls leads to confusion and annoyance.

Abierto
  • ¿Algo no está bien?
#575 13 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
rust
Área
cryptography

Línea de trabajo

Comienza revisando cómo aes-gcm y aes-gcm-siv exponen Nonce y cómo se utiliza GenericArray; después, lee la discusión del issue para conocer la dirección acordada de la API. Se considera terminado cuando los maintainers eligen y documentan un enfoque —volver a exportar GenericArray, añadir un wrapper u otro diseño— y abordan la compatibilidad y la documentación orientada al usuario.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

It's understandable that aes-gcm and aes-gcm-siv use generic_array's GenericArray's for the Nonce type. What's less understandable though is why this is left an opaque type and not either a wrapper with its own documentation of its methods custom to the uses of ges-gcm* or that GenericArray is not re-exported both for convenience as well as documentation. As a new user, I was really confused by the fact that I could not access the documentation for the underlying type to see what associated functions/methods it supports or even how to get one besides converting from a slice (as is demonstrated by the top-level crate documentation). Not everyone knows the generic_array crate and knows what GenericArray is and I had to look through the source to find the implementations of what I thought were a private type but turned out to be an import that is used on the front end by the user despite not only not being re-exported but there being no mention in the top-level crate documentation where this type comes from.

I would personally prefer turning Nonce into a newtype custom wrapper but I understand that this can be an issue due to the fact that it fundamentally introduces breaking changes.

The second best option is to simply re-export GenericArray. After all, aes-gcm-siv re-exports the entire aead crate just like aes-gcm which also re-exports aes in addition. I think this is by far the most uncontroversial option but the seemingly random re-export seems for some reason distasteful, I propose a third proposal:

This one is a compromise between the last two: create a new type called something like NonceWrapper that does exactly what I mentioned in the first proposal and then impl From for Nonce, unwrapping it. One could then have replace all instances of taking a Nonce type with impl Into. I can't see any breakage that would come of this but obviously it would still work even without the function refactors, just less convenient.

I would be willing to make a PR if and when a solution is agreed upon. I would love to hear others' thoughts.

Lenguaje dominante
Rust
Estrellas
961
Forks
200
Merge medio
2 h 50 min
PR fusionados (30 d)
3

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RustCrypto/AEADs

Todos los issues de RustCrypto/AEADs

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.