2012-08-22 15 views
12

Sperimentando con git, ho installato Gitlab per un repository self-hosted e sembra fantastico.Can Gitlab/Gitolite applica nome utente/email corretto

L'unica cosa che mi infastidisce è che sembra che chiunque possa eseguire commit come chiunque altro (es: spoofing un commit).

vale a dire: io ho il mio setup utenti in Gitlab con accesso a chiave pubblica

  • Utente1
  • Utente2

Ora solo gli utenti possono spingere - con le loro chiavi SSH private - ma sembra non c'è nulla che si fermi Utente2 tweaking loro gitconfig per impegnarsi sotto il nome di Utente1 e spingendo su?

La storia in gitlab e git -show mostra la committer come qualsiasi testo gitconfig del Utente1 era. Voglio che Gitlab stampi il nome utente associato alla chiave ssh in push nella cronologia, quindi so quale chiave ssh è stata usata per spingere.

Lo scenario è che il repository verrebbe utilizzato in un ambiente di team e sembra solo prudente non consentire commit di spoofing.

Ho letto e capisco che in genere si può cambiare il flusso di lavoro per avere un repository benedetto e avere solo committer fidati che possono spingere a questo - ma a questo punto mentre sto imparando git voglio rimanere in un ambiente più centralizzato/Flusso di lavoro di tipo SVN.

È possibile utilizzare i ganci?

C'è una risposta similar question per la gitosi ma anche quella che sembra applicare solo il committer proviene da un intervallo di utenti che non interrompe User1 spoofing come Utente2 - per quanto posso dire.

PS: Forse sto facendo la domanda sbagliata - c'è un modo in gitlab per scoprire quale chiave ssh (e quindi utente reale) è stata utilizzata per inserire il codice nel repository? Non sembra così da quello che posso trovare.

risposta

4

Aggiornamento 2015

Poiché questa menzione discussione, GitLab Enterprise ha tra i suoi ganci git associati a un progetto un modo per controllare le email:

Vai al progetto Impostazioni -> ganci git e verificare la convalida di email dell'autore.

Qualsiasi messaggio di posta elettronica che non corrisponde a un utente conosciuto viene rifiutato.


risposta Originale (2012)

Un modo parziale per ottenere un controllo ID utente è quello di rendere gitolite (che si basa su gitlab) respinge la spinta se almeno uno dei commit spinto non è commesso da quello che lo spinge.

Quando si preme, si è autenticati (in base al nome della chiave pubblica registrata da Gitolite o in un altro modo come una connessione LDAP).
È possibile aggiungere un hook pre-receive che verificherà tutti i nuovi commit e cercare almeno uno impegnato con il nome corretto (ovvero l'id dell'utente che preme detti commit).
Vedere questo pre-receive hook come esempio.

+0

Ho provato questo e quasi funziona, ma ottengo un valore strano per $ GL_USER. L'hook viene eseguito ma gli errori con "_remote: nessun commit trovato con nome_lastname_gmail_com_1345598530 come nome del committer_". Non so da dove provenisse quell'ultima stringa di numeri: qualche cosa interna di gitlab? Gitlab non sembra supportare altro che [i loro web hook] (https://github.com/gitlabhq/gitlabhq/issues/476) quindi forse questo non funzionerà per Gitlab? – fiat

+0

dopo qualche altro scavo, il valore $ GL_USER di _firstname_lastname_gmail_com_1345598530_ è la colonna identificativa della tabella 'keys' nel database gitlab che memorizza le chiavi utente ssh. Sembra essere generato automaticamente e non impostabile dall'interfaccia utente. – fiat

+0

@fiat Confermo: 'GL_USER' è impostato con il nome della chiave pubblica, indicato da Gitlab in questo modo, e registrato da gitolite. – VonC

Problemi correlati