¿Por qué Github necesita ofrecer una característica de firma GPG?

Question

¿Por qué Github necesita ofrecer una característica de firma GPG?

#1 de Benoit Esnard (4 votos)
#2 de LvB (2 votos)
#3 de Peter Green (1 votos)

-1

Github ofrece a los usuarios firmar su trabajo usando GPG. Supongo que me falta el panorama general, aunque ¿cómo pueden las personas tener sus claves SSH o sus credenciales y no sus claves GPG? ¿No está seguro de qué tipo de capa agrega sobre la conexión ssh normal?

¿Cómo ayuda esto a lograr su objetivo?

Use las claves GPG para firmar su trabajo localmente y verificar el trabajo de colaboradores de confianza.

Por qué el nombre de usuario autenticado + el inicio de sesión de la contraseña, el intercambio de claves SSH con github no es suficiente para evitar masquerade y implementar la autorización?

Editar:

De hecho, si ves el comentario de Davorak :

Puedes usar la api de github para identificar quién hizo un compromiso:

Actualmente el evento en cuestión está en la página 3, así que puedes usar:    enlace

Iré a otras páginas a medida que aparezcan nuevos eventos.

(ver la salida al final)

A mi me parece que se trata de un exceso de ingeniería y de malas prácticas, porque todas las personas que no configuran un GPG todavía están en "riesgo".

Eso es lo que Linus tiene para decir .

{
    "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"
  },

digital-signature gnupg git github

pregunta 0x90 13.03.2018 - 15:54

fuente

3 respuestas

4

Dado que git está descentralizado, cualquiera puede falsificar un compromiso y falsificar la fuente del compromiso, incluso si no tiene sus credenciales.

Es realmente tan fácil como:

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

Firmar un compromiso le permite a su autor probar su autenticidad.

respondido por el Benoit Esnard 13.03.2018 - 15:58

fuente

1

Lo primero es lo primero, esto no es una característica "github", es una característica git.

Git es un sistema de control de versiones distribuido diseñado para permitir la colaboración ad-hoc. Un repositorio "principal" es simplemente una cuestión de convención y uso, no un aspecto central de git. El resultado es que el seguimiento del historial del repositorio principal no es una parte fundamental de git.

Existe algo llamado "reflog" que rastrea el historial de un repositorio, pero está pensado más como una herramienta de recuperación de desastres que como un registro histórico a largo plazo. Solo se puede acceder a él de forma local, no se copia a los clientes, está deshabilitado de forma predeterminada para los repositorios vacíos y por defecto a un tiempo de caducidad relativamente corto.

La información del autor habitual en un git commit no identifica de manera confiable quién creó el commit o cuándo. Cualquiera puede crear un compromiso con cualquier información de autoría. Esto puede ocurrir maliciosamente, pero también puede ocurrir inocentemente, por ejemplo, como resultado del uso de herramientas de importación para convertir otros sistemas de control de versiones a git o como resultado de la rebasación.

Entonces, si queremos identificar de manera confiable quién creó un compromiso, necesitamos otro mecanismo. Una que funciona en un entorno distribuido, GPG cumple con los requisitos.

Volviendo a github.

Simplemente bloqueando las subidas de confirmaciones donde la información del autor no coincide con la identidad del impulsor destruiría gran parte de la utilidad githubs. Haría imposible mantener el historial al cargar las horquillas de proyectos alojados en otros lugares. Haría imposible mantener el historial cuando se usa github como un espejo mientras se tienen los proyectos principales en otros lugares. Haría imposible un rebase.

Entonces, en github como con git en general, la información del autor no identifica de manera confiable quién creó el compromiso. Un mecanismo para hacerlo es deseable y git ya tiene un mecahnismo de firma de gpg. ¿Por qué github reinventar la rueda ?!

respondido por el Peter Green 13.03.2018 - 18:50

fuente

Lea otras preguntas en las etiquetas digital-signature gnupg git github

¿Tiene sentido restringir el uso de Metasploit en los exámenes de pruebas de penetración? [cerrado] ayúdame a eliminar las contraseñas

score 2 · Accepted Answer

GPG se utiliza para verificar el código en el repositorio (p. ej., puede verificar quién lo hizo después). SSH se trata de conectividad (por ejemplo, a quién se le permite acceder al repositorio).

Por lo tanto, al utilizar la clave GPG (que podría estar en una SMARTCARD), puede realizar una confirmación / etiqueta / liberación auténtica que otras personas puedan validar de su parte como fuente canónica.

Este compromiso tendrá todas las cosas normales (nombre de usuario de texto plano y correo electrónico que cualquier cliente puede configurar de forma gratuita) y un cryptohash que solo se validará con la clave pública del firmante.

Esto también funciona en diferentes servidores / clientes. Entonces, si alguien importa el proyecto en Gitlab, las claves GPG (y la verificación) aún funcionan.

El punto de uso de las claves (ssh para el acceso y GPG para la autenticidad) es proporcionar confianza acerca de ese código: proviene de una fuente válida (conexión de clave SSH) y es de una entidad válida (persona que lo firmó con GPG clave).