2012-08-22 11 views
12

Experimentando con git, configuré Gitlab para un repositorio autocapturado y se ve muy bien.Can Gitlab/Gitolite impone el nombre de usuario/correo electrónico correcto

Lo que me molesta es que parece que cualquiera puede hacer commits como cualquier otra persona (es decir: spoof a commit).

es decir: Tengo mi configuración de usuarios en Gitlab con acceso a la clave pública

  • Usuario1
  • Usuario2

Ahora sólo aquellos usuarios pueden empujar - utilizando sus claves SSH privadas - pero parece no hay nada que se detenga User2 ajustando su gitconfig para confirmar bajo el nombre de User1 y empujando hacia arriba?

La historia en gitlab y git -demostrar muestra el confirmador como cualquier texto gitconfig del Usuario1 era. Quiero que Gitlab estampare el nombre de usuario asociado con la tecla ssh que empuja en la historia, así sabré de quién se usó la tecla ssh para presionar.

El escenario es que el repositorio se usaría en un entorno de equipo y parece prudente no permitir confirmaciones falsificadas.

He leído un poco y entiendo que, por lo general, uno puede cambiar el flujo de trabajo para tener un repositorio bendecido y solo tener confiables que puedan presionar para eso, pero en esta etapa mientras aprendo git, quiero permanecer en un lugar más centralizado/Flujo de trabajo tipo SVN.

¿Es posible utilizar ganchos?

Hay un similar question respondido por gitosis, pero incluso eso parece hacer que el committer sea de una gama de usuarios que no detiene User1 spoofing como User2, por lo que yo sé.

PD: Tal vez estoy haciendo la pregunta incorrecta: ¿hay alguna manera en gitlab para descubrir qué clave ssh (y por lo tanto, usuario real) se utilizó para insertar el código en el repositorio? No parece así por lo que puedo encontrar.

Respuesta

4

Actualización 2015

Como esta mención hilo, GitLab empresa tiene entre sus ganchos git asociados a un proyecto de una manera de controlar los correos electrónicos:

Ir a Ajustes del proyecto -> ganchos Git y comprobar la validación de correo electrónico del autor

Se rechaza cualquier correo electrónico que no coincida con un usuario conocido.


Respuesta original (2012)

Una manera parcial para lograr el control de identificador de usuario es hacer gitolite (que se basa en gitlab) rechazar el empuje si al menos una de las confirmaciones empujados no está comprometido por el que lo empuja.

Al presionar, está autenticado (ya sea en función del nombre de la clave pública registrada por Gitolite, o de otra manera, como una conexión LDAP).
Puede agregar un gancho pre-receive que verificará todas las confirmaciones nuevas y buscará al menos una confirmada por el nombre correcto (es decir, la identificación del usuario que presiona dichas confirmaciones).
Vea esto pre-receive hook como ejemplo.

+0

Intenté esto y casi funciona pero obtengo un valor extraño para $ GL_USER. El gancho se ejecuta pero los errores con "_remote: no se encontró confirmación con firstname_lastname_gmail_com_1345598530 como committer name_". No sé de dónde vino esa última serie de números, ¿alguna cosa interna de Gitlab? Gitlab no parece ser compatible con nada más que [sus ganchos web] (https://github.com/gitlabhq/gitlabhq/issues/476) así que quizás esto no funcione para Gitlab? – fiat

+0

después de excavar más, el valor $ GL_USER de _firstname_lastname_gmail_com_1345598530_ es la columna de identificador de la tabla 'keys' en la base de datos gitlab que almacena las claves de usuario de ssh. Parece ser autogenerado y no configurable desde la interfaz de usuario. – fiat

+0

@fiat Confirmo: 'GL_USER' se establece con el nombre de la clave pública, nombrada por Gitlab de esa manera, y registrada por gitolite. – VonC

Cuestiones relacionadas