Autofixture: ¿Debemos mantener nuestra clave de señal en secreto?

Creado en 2 abr. 2017  ·  8Comentarios  ·  Fuente: AutoFixture/AutoFixture

Anteriormente @ploeh mantenía en secreto la clave de firma de todas las asambleas. Me gustaría discutir si realmente tiene sentido.

Si revisamos otros ayudantes de prueba populares, encontraremos que todos ellos tienen una clave pública abierta:

  1. xunit: la clave está abierta .
  2. nunit - la llave está abierta .
  3. NSubstitute: la llave está abierta .
  4. Moq: la tecla está abierta .
  5. FakeItEasy: la llave está abierta .
  6. FluentAssertions: la tecla está abierta .

No veo demasiado sentido mantener cerrada la tecla AF y creo que también podemos agregarla al repositorio. De hecho, firmar permite probar la identidad de la asamblea, pero no creo que lo exijamos estrictamente. Nuestros días NuGet se utiliza para distribuir paquetes, en lugar de sitios de terceros donde la identidad sí importa.

Si publicamos la clave en el repositorio, eso tendrá muchos beneficios:

  1. Será más fácil generar NuGet con ensamblados firmados por CI.
  2. Será más fácil para las personas hacer sus propios ensamblajes AutoFixture y probar si resuelve un problema en particular. Considere el siguiente escenario:
1. You found some bug in AF. You download source code locally and fix it.
2. Now you have AF assemblies with fixed bug and you want to test whether it helped.

Here is where the issues start. If you assemblies are unsigned, you cannot simply put the modified assemblies to the local NuGet cache - project will not compile. Rather, you need to update all your projects to target to a new assembly - just for a simple test. The things become even worse when that is the core `AutoFixture` assembly, as other depending libraries (like `AutoFixture.xunit` or `AutoFixture.NSubstitute`) will need to be updated as well.

If we ship signing key issue will be solved.

  1. No necesitas guardar un secreto más :)

En cuanto a @ploeh , parece que no tenía razones sólidas para mantenerlo en secreto.

Personalmente, votaría con ambas manos para abrir la llave y simplificar la vida de todos.
Chicos ( @moodmosaic , @adamchester , @ecampidoglio , @klimisa), ¿qué opinan de esto?

question

Todos 8 comentarios

👍 para abrir la llave.

: +1: No veo ninguna razón para no abrirlo. ¿Cómo se preocupa? Dudo que alguien lo haga.

Abra la clave y mantenga los privilegios de nuget.org en secreto.

El domingo 2 de abril de 2017 a las 14:16 Alexander Batishchev [email protected]
escribió:

No veo ninguna razón para no abrirlo. ¿Cómo se preocupa? Dudo que alguien lo haga.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/AutoFixture/AutoFixture/issues/746#issuecomment-291000103 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAwCvwwhRzzUb9d3jVblzyxrpqrWyUsJks5rr9fkgaJpZM4Mw2Pq
.

Aunque encuentro interesante el tema de discusión, no tengo opinión. Votar neutral en eso.

@ecampidoglio y @adamchester ¿Podrían agregar sus opiniones aquí también?
Actualmente estoy trabajando en CI para tener versiones iniciales de v4 y simplificar el procedimiento de lanzamiento en sí. Necesito la clave de señalización en CI, así que necesito esta decisión.

Creo que tiene sentido abrirlo, especialmente considerando el segundo punto mencionado en este comentario .
Además, en estos días la autenticidad está garantizada por la cuenta NuGet que publica el paquete, lo que ciertamente no fue el caso durante los primeros días de AutoFixture.

Entonces, claro, puede continuar y enviar las claves al repositorio en lo que a mí respecta. 👍

👍 para abrirlo

Gracias, de acuerdo :)

¿Fue útil esta página
0 / 5 - 0 calificaciones