.net - condiciones - Mejores prácticas para firmar ensamblajes con múltiples proyectos y desarrolladores
condiciones c# (3)
Estoy buscando recomendaciones y mejores prácticas para aplicar conjuntos firmados en una organización con más de 30 desarrolladores, más de 20 soluciones y más de 60 proyectos. Estamos utilizando Visual Studio Team System 2008 y TFS.
Aunque crear una clave y firmar el ensamblaje es un procedimiento muy sencillo y directo, me preocupa cómo lo manejamos de la mejor manera.
Mis pensamientos hasta ahora:
- Cada solución, que normalmente tiene entre 3 y 20 proyectos, tendrá un solo archivo de clave .pfx ubicado en la carpeta raíz de la solución.
- Cada solución tendrá una contraseña segura única para la clave.
¿Encontraremos algún problema con ese enfoque?
Algunas otras ideas:
- Utilice el mismo archivo clave para todos los proyectos en todas las soluciones. ¿Esto nos facilitará las cosas? ¿Es una mala idea? ¿Es incluso posible?
- ¿Debería cada proyecto tener su propia clave única? ¿Por qué por qué no?
Cualquier aportación, buenas / malas experiencias y recomendaciones son bienvenidas. :)
Actualmente utilizamos la misma clave segura (.SNK) para cada proyecto en nuestra solución. Dependiendo de su proyecto es cómo administra las diferentes claves para cada proyecto.
Si desea una mayor seguridad, supongo que podría recrear la clave para cada proyecto, pero será una pesadilla para administrar. Recuerde que al final del día, el SNK solo muestra que el código proviene de su compañía, y evita que se alteren los ensamblajes, no es una característica de seguridad interna enorme.
Para eso, debe limitar su control de código fuente y considerar el uso de un servidor de compilación, etc., si no confía / no quiere que los desarrolladores creen el código.
En el pasado, he usado una sola clave para múltiples soluciones y proyectos de manera muy efectiva. Es un enfoque simple que garantiza que solo las personas con acceso al archivo de clave privada puedan publicar una compilación que pase la verificación de nombre seguro.
Nota: Para usar el archivo de clave única, fue más fácil agregar el archivo como un enlace a cada proyecto.
La única desventaja que veo es que tener el archivo de clave disponible para sus desarrolladores significa que no es tan privado como debería ser. Idealmente, la menor cantidad de personas posible (por ejemplo, solo el proceso de construcción) debe tener acceso / conocer la contraseña.
El enfoque de un solo archivo mantiene la administración de las claves simple (solo hay una) al tiempo que permite los beneficios de una asignación de nombres sólida.
También puede mantener la clave de nombre seguro en una carpeta en el nivel raíz, en el mismo nivel que todas las carpetas de proyectos. Cuando elige este archivo en las propiedades del proyecto -> pestaña de firma, el archivo de clave se copia en la carpeta del proyecto. Eliminar este archivo. Abra el archivo .csproj en el bloc de notas. Busque la siguiente etiqueta mykey.snk Edite manualmente la ruta del archivo clave, asegúrese de especificar una ruta relativa desde la carpeta del proyecto. Guarda el archivo. Ahora abre las propiedades del proyecto en visual studio. Puede ver la ruta actualizada para indicar la ubicación correcta.