Perché Github deve offrire una funzione di firma GPG?

-1

Github offre agli utenti di firmare il loro lavoro utilizzando GPG. Immagino di perdere l'immagine più grande, anche se come possono le persone avere le tue chiavi SSH o le tue credenziali e non le tue chiavi GPG. Non sei sicuro di quale tipo di layer aggiunga alla normale connessione ssh?

In che modo questo aiuta a raggiungere il loro obiettivo:

Use GPG keys to sign your work locally and verify work from trusted collaborators.

Perché il login utente / password autenticato, le chiavi SSH scambiate con github non sono sufficienti per impedire mascherarsi e implementare l'autorizzazione?

Modifica

Infatti, se vedi il commento Davorak :

You can use github's api to identify out who pushed a commit:

Currently the event in question is on page 3 so you can use: https://api.github.com/repos/amoffat/masquerade/events?page=3

It i will roll to further pages as new events come in.

(vedi l'output alla fine)

Per me sembra un'eccessiva ingegnerizzazione e una cattiva pratica, perché tutte le persone che non impostano un GPG sono ancora a "rischio".

Questo è ciò che Linus deve dire .

{
    "id": "3030685599",
    "type": "PushEvent",
    "actor": {
      "id": 259113,
      "login": "amoffat",
      "gravatar_id": "",
      "url": "https://api.github.com/users/amoffat",
      "avatar_url": "https://avatars.githubusercontent.com/u/259113?"
    },
    "repo": {
      "id": 40194425,
      "name": "amoffat/masquerade",
      "url": "https://api.github.com/repos/amoffat/masquerade"
    },
    "payload": {
      "push_id": 747582733,
      "size": 1,
      "distinct_size": 1,
      "ref": "refs/heads/master",
      "head": "9b0562595cc479ac8696110cb0a2d33f8f2b7d29",
      "before": "2ff8c2e08b0be167a6794a1a03b7a41f0c459141",
      "commits": [
        {
          "sha": "9b0562595cc479ac8696110cb0a2d33f8f2b7d29",
          "author": {
            "email": "[email protected]",
            "name": "Linus Torvalds"
          },
          "message": "Enjoy!",
          "distinct": true,
          "url": "https://api.github.com/repos/amoffat/masquerade/commits/9b0562595cc479ac8696110cb0a2d33f8f2b7d29"
        }
      ]
    },
    "public": true,
    "created_at": "2015-08-04T18:44:26Z"
  },
    
posta 0x90 13.03.2018 - 15:54
fonte

3 risposte

2

GPG viene utilizzato per verificare il codice nel repository (ad es. puoi controllare chi lo ha fatto in seguito). SSH riguarda la connettività (ad es. Chi è autorizzato ad accedere al repository).

Quindi usando la chiave GPG (che potrebbe essere su una SMARTCARD) puoi fare un commit / tag / release autentico che altre persone possono validare da te come fonte canonica.

Questo commit avrà tutte le cose normali (nome utente ed e-mail in chiaro che possono essere impostati da qualsiasi client) e un criptohash che verrà validato solo contro la chiave pubblica del firmatario.

Funziona anche su diversi client / server. Quindi se qualcuno importa il progetto in Gitlab, le chiavi GPG (e la verifica) funzionano ancora.

Il punto di utilizzo dei tasti (ssh per l'accesso e GPG per l'autenticità) è quello di fornire attendibilità su quel codice: proviene da un'origine valida (connessione chiave SSH) e proviene da un'entità valida (persona che l'ha firmata con il GPG chiave).

    
risposta data 13.03.2018 - 16:03
fonte
4

Dato che git è decentralizzato, chiunque può falsificare un commit e falsificare la fonte del commit, anche se non hanno le tue credenziali.

È davvero facile come:

git commit --author "Name <[email protected]>"

La firma di un commit consente all'autore di dimostrare la sua autenticità.

    
risposta data 13.03.2018 - 15:58
fonte
1

Prima di tutto questa non è una funzione "github", è una funzionalità git.

Git è un sistema di controllo delle versioni distribuito progettato per consentire una collaborazione ad hoc. Un repository "principale" è semplicemente una questione di convenzione e utilizzo, non un aspetto fondamentale di git. Il risultato è che tracciare la cronologia del repository principale non è una parte fondamentale di git.

Esiste qualcosa chiamato "reflog" che traccia la cronologia di un repository ma è inteso più come uno strumento di disaster recovery che come un record storico a lungo termine. Può essere consultato solo localmente, non viene copiato sui client, è disabilitato per impostazione predefinita per i repository nudi e il valore predefinito è un tempo di scadenza molto breve.

Le informazioni regolari dell'autore in un commit git non identificano in modo imparziale chi ha creato il commit o quando. Chiunque può creare un commit con qualsiasi informazione sull'autore. Questo può accadere maliziosamente, ma può anche accadere in modo innocente, ad esempio come risultato dell'utilizzo di strumenti di importazione per convertire altri sistemi di controllo della versione in git o in seguito a una ridefinizione.

Quindi, se vogliamo identificare in modo affidabile chi ha creato un commit, abbiamo bisogno di un altro meccanismo. Uno che funziona in un ambiente distribuito, GPG si adatta al conto.

Torna a github.

Il semplice blocco dei caricamenti di commit in cui le informazioni dell'autore non corrispondevano all'identità dello spacciatore avrebbe distrutto gran parte dell'utilità di githubs. Renderebbe impossibile mantenere la cronologia durante il caricamento di fork di progetti ospitati altrove. Renderebbe impossibile mantenere la cronologia quando si usa github come specchio mentre si sta eseguendo il repository principale altrove. Renderebbe impossibile rebase.

Quindi su github come con git in generale le informazioni dell'autore non identificano in modo affidabile chi ha creato il commit. Un meccanismo per farlo è auspicabile e git ha già un mecahnismo di firma gpg. Perché dovrebbe github reinventare la ruota?!

    
risposta data 13.03.2018 - 18:50
fonte

Leggi altre domande sui tag