¿Cómo manejaría Git una colisión SHA-1 en una gota?


543

Esto probablemente nunca sucedió en el mundo real todavía, y puede que nunca suceda, pero consideremos esto: digamos que tiene un repositorio git, realice una confirmación y tenga mucha mala suerte: uno de los blobs termina teniendo el mismo SHA-1 como otro que ya está en su repositorio. La pregunta es, ¿cómo manejaría Git esto? ¿Simplemente fallar? ¿Encontrar una manera de vincular los dos blobs y verificar cuál se necesita según el contexto?

Es más un desafío para la mente que un problema real, pero el problema me pareció interesante.


76
Una vez que fue un desafío para la mente, ahora es potencialmente un problema real .
Toby

11
@Toby Esta pregunta era sobre un ataque previo a la imagen ; lo que Google demostró es un ataque de colisión , similar pero ligeramente diferente. Puedes leer más sobre la diferencia aquí .
Saheed

@Saheed No veo qué parte de esta pregunta se trata específicamente de un ataque previo a la imagen, ya que la pregunta planteada es solo sobre una colisión en un repositorio git, no sobre explotarlo.
Toby

3
@Toby El desafío para la mente original no se trataba de un ataque (ni preimagen ni colisión) sino de una colisión accidental que es tan insondablemente improbable que no vale la pena considerarlo. Creo que Saheed estaba tratando de decir correctamente que esto todavía no es un problema real. Sin embargo, tiene razón en que el ataque de colisión de Google ha creado potencialmente un problema de seguridad dependiendo de cómo se use Git.
Andrew W. Phillips

Aquí hay una segunda colisión de solo 320 bytes privacylog.blogspot.com/2019/12/the-second-sha-collision.html
William Entriken

Respuestas:


736

Hice un experimento para descubrir exactamente cómo se comportaría Git en este caso. Esto es con la versión 2.7.9 ~ rc0 + next.20151210 (versión Debian). Básicamente, reduje el tamaño del hash de 160 bits a 4 bits aplicando el siguiente diff y reconstruyendo git:

--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
    blk_SHA1_Update(ctx, padlen, 8);

    /* Output hash */
-   for (i = 0; i < 5; i++)
-       put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+       put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+   for (i = 1; i < 5; i++)
+       put_be32(hashout + i * 4, 0);
 }

Luego hice algunas confirmaciones y noté lo siguiente.

  1. Si ya existe un blob con el mismo hash, no recibirá ninguna advertencia en absoluto. Todo parece estar bien, pero cuando empujas, alguien clona o reviertes, perderás la última versión (en línea con lo explicado anteriormente).
  2. Si ya existe un objeto de árbol y crea un blob con el mismo hash: Todo parecerá normal, hasta que intente empujar o alguien clone su repositorio. Entonces verás que el repositorio está corrupto.
  3. Si ya existe un objeto de confirmación y crea un blob con el mismo hash: igual que # 2 - corrupto
  4. Si ya existe un blob y realiza un objeto de confirmación con el mismo hash, fallará al actualizar el "ref".
  5. Si ya existe un blob y crea un objeto de árbol con el mismo hash. Fallará al crear el commit.
  6. Si ya existe un objeto de árbol y usted hace un objeto de confirmación con el mismo hash, fallará al actualizar la "referencia".
  7. Si ya existe un objeto de árbol y usted hace un objeto de árbol con el mismo hash, todo parecerá correcto. Pero cuando se compromete, todo el repositorio hará referencia al árbol incorrecto.
  8. Si ya existe un objeto de confirmación y crea un objeto de confirmación con el mismo hash, todo parecerá correcto. Pero cuando confirma, la confirmación nunca se creará y el puntero HEAD se moverá a una confirmación anterior.
  9. Si ya existe un objeto de confirmación y crea un objeto de árbol con el mismo hash, fallará al crear la confirmación.

Para el n. ° 2, normalmente obtendrá un error como este cuando ejecute "git push":

error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin

o:

error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)

si elimina el archivo y luego ejecuta "git checkout file.txt".

Para # 4 y # 6, generalmente obtendrá un error como este:

error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref

cuando se ejecuta "git commit". En este caso, normalmente puede volver a escribir "git commit", ya que esto creará un nuevo hash (debido a la marca de tiempo modificada)

Para los n. ° 5 y n. ° 9, generalmente obtendrá un error como este:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

cuando se ejecuta "git commit"

Si alguien intenta clonar su repositorio corrupto, normalmente verá algo como:

git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)

Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Lo que me "preocupa" es que en dos casos (2,3) el repositorio se corrompe sin advertencias, y en 3 casos (1,7,8), todo parece estar bien, pero el contenido del repositorio es diferente de lo que espera ser - estar. La clonación o extracción de personas tendrá un contenido diferente al que usted tiene. Los casos 4,5,6 y 9 están bien, ya que se detendrá con un error. Supongo que sería mejor si fallara con un error al menos en todos los casos.


157
Respuesta impresionante: reducir el tamaño del hash para ver cómo se comporta realmente es una gran idea.
Gnurou

44
@Gnurou Estoy de acuerdo y voté esa respuesta en ese momento. ¿Se mencionaron esos casos en la lista de correo de git?
VonC

1
¿Qué tan probable es que esto realmente suceda sin un tamaño reducido de hash?
Mathias Bader

44
Además, ¿cuáles son los planes, si los hay, para pasar a otro algoritmo de hash?
Pete

99
Debe leer: explicaciones de Linus Torval: plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
phil_lgr

238

Respuesta original (2012) (ver shattered.iocolisión SHA1 2017 a continuación)

Esa vieja respuesta (2006) de Linus aún podría ser relevante:

No Si tiene el mismo SHA1, significa que cuando recibamos el objeto del otro extremo, no sobrescribiremos el objeto que ya tenemos.

Entonces, lo que sucede es que si alguna vez vemos una colisión, el objeto "anterior" en cualquier repositorio particular siempre terminará por anularse. Pero tenga en cuenta que "anterior" es obviamente por repositorio, en el sentido de que la red de objetos git genera un DAG que no está completamente ordenado, por lo que los diferentes repositorios estarán de acuerdo sobre lo que es "anterior" en el caso de ascendencia directa, si el el objeto llegó a través de ramas separadas y no directamente relacionadas, obviamente dos repositorios diferentes pueden haber obtenido los dos objetos en un orden diferente.

Sin embargo, la "anulación anterior" es lo que desea desde el punto de vista de la seguridad: recuerde que el modelo git es que debe confiar principalmente en su propio repositorio.
Entonces, si hace un " git pull", los nuevos objetos entrantes son, por definición, menos confiables que los objetos que ya tiene, y como tal sería un error permitir que un nuevo objeto reemplace uno viejo.

Entonces tienes dos casos de colisión:

  • del tipo inadvertido , donde de alguna manera eres muy desafortunado, y dos archivos terminan teniendo el mismo SHA1.
    En ese momento, lo que sucede es que cuando confirma ese archivo (o hace un " git-update-index" para moverlo al índice, pero aún no lo ha confirmado), se calculará el SHA1 de los nuevos contenidos, pero dado que coincide con un objeto antiguo, no se creará un nuevo objeto, y el commit-or-index termina apuntando al objeto antiguo .
    No lo notará de inmediato (ya que el índice coincidirá con el objeto antiguo SHA1, y eso significa que algo como " git diff" usará la copia extraída), pero si alguna vez hace una diferencia a nivel de árbol (o hace un clon o tirar o forzar un pago) de repente notarás que ese archivo ha cambiado a algocompletamente diferente de lo que esperabas.
    Por lo tanto, generalmente notarías este tipo de colisión bastante rápido.
    En noticias relacionadas, la pregunta es qué hacer con la colisión inadvertida.
    En primer lugar, permítanme recordarles a las personas que la colisión inadvertida es realmente muy, muy poco probable, por lo que es muy probable que nunca la veamos en la historia completa. del universo.
    Pero si sucede, no es el fin del mundo: lo más probable es que tenga que hacer es cambiar el archivo que colisionó ligeramente y forzar una nueva confirmación con el contenido modificado (agregue un comentario que diga " /* This line added to avoid collision */") y luego enseñe a git sobre la magia SHA1 que se ha demostrado que es peligrosa.
    Entonces, durante un par de millones de años, tal vez tengamos que agregar uno o dos valores SHA1 "envenenados" a git. Es muy poco probable que sea un problema de mantenimiento;)

  • El tipo de colisión del atacante porque alguien rompió (o fue forzado) SHA1.
    Este es claramente mucho más probable que el tipo inadvertido, pero por definición siempre es un repositorio "remoto". Si el atacante tuviera acceso al repositorio local, tendría formas mucho más fáciles de fastidiarte.
    Entonces, en este caso, la colisión no es un problema : obtendrá un repositorio "malo" que es diferente de lo que pretendía el atacante, pero dado que nunca usará su objeto en colisión, literalmente no es diferente del atacante simplemente no haber encontrado una colisión en absoluto, pero solo usando el objeto que ya tenía (es decir, es 100% equivalente a la colisión "trivial" del archivo idéntico que genera el mismo SHA1).

La cuestión del uso de SHA-256 se menciona regularmente, pero no se actúa por ahora (2012).
Nota: a partir de 2018 y Git 2.19 , el código se está refactorizando para usar SHA-256.


Nota (Humor): puede forzar una confirmación a un prefijo SHA1 particular , con el proyecto gitbrute de Brad Fitzpatrick ( bradfitz) .

gitbrute brute-force un par de marcas de tiempo de autor + committer de modo que el git commit resultante tenga el prefijo deseado.

Ejemplo: https://github.com/bradfitz/deadbeef


Daniel Dinnyes señala en los comentarios a 7.1 Git Tools - Revision Selection , que incluye:

Existe una mayor probabilidad de que todos los miembros de su equipo de programación sean atacados y asesinados por lobos en incidentes no relacionados en la misma noche.


Incluso el más reciente (febrero de 2017) shattered.iodemostró la posibilidad de forjar una colisión SHA1:
(vea mucho más en mi respuesta por separado , incluida la publicación de Google+ de Linus Torvalds)

  • a / todavía requiere más de 9,223,372,036,854,775,808 cálculos SHA1. Esto tomó la potencia de procesamiento equivalente a 6.500 años de cálculos de CPU única y 110 años de cálculos de GPU única.
  • b / forjaría un archivo (con el mismo SHA1), pero con la restricción adicional de su contenido y tamaño produciría el SHA1 idéntico (una colisión en el contenido solo no es suficiente): vea " ¿Cómo se calcula el hash git? ") : un blob SHA1 se calcula en función del contenido y el tamaño .

Consulte " Duración de las funciones hash criptográficas " de Valerie Anita Aurora para obtener más información.
En esa página, ella nota:

Google pasó 6500 años de CPU y 110 años de GPU para convencer a todos de que debemos dejar de usar SHA-1 para aplicaciones críticas de seguridad.
También porque era genial

Vea más en mi respuesta separada a continuación .


25
giro: sigue siendo el mismo después de agregar /* This line added to avoid collision */: D puedes ganar la lotería dos veces: P
Janus Troelsen

44
@JanusTroelsen seguro, pero todavía es una lotería, ¿no? ;) (como se menciona en esta breve nota sobre SHA1 )
VonC

66
@VonC con respecto a esa referencia : es un estallido de una epidemia mundial de hombres lobo, aniquilando a toda la humanidad y resultando en la espantosa muerte de todos mis desarrolladores en la misma noche, a pesar de que se distribuyeron geográficamente, ¿considerado un incidente no relacionado? Por supuesto, suponiendo que sucediera en luna llena, obviamente. Ahora, tal escenario cambiaría las cosas. ¡Incluso pensar en eso es una locura! ¡Eso está en una escala de probabilidad completamente diferente! Eso significaría que debemos ... ¡DEJEN DE USAR GIT! ¡¡¡AHORA!!! TODOS RUUUUUN !!!!!!!
Daniel Dinnyes

2
Tenga en cuenta que el gitbrute no fuerza un SHA1 en particular, sino solo un prefijo (es decir, una subparte del SHA1 completo). Forzar un SHA1 completo (es decir, con un prefijo de la longitud completa de la clave) probablemente tomará "demasiado tiempo".
mb14

2
@JanusTroelsen Entonces agregarías:/* This line added to avoid collision of the avoid collision line */
smg

42

De acuerdo con Pro Git :

Si sucede que confirma un objeto que tiene el mismo valor SHA-1 que un objeto anterior en su repositorio, Git verá el objeto anterior que ya está en su base de datos de Git y asumirá que ya está escrito. Si intenta revisar ese objeto nuevamente en algún momento, siempre obtendrá los datos del primer objeto.

Por lo tanto, no fallaría, pero tampoco salvaría su nuevo objeto.
No sé cómo se vería eso en la línea de comando, pero eso ciertamente sería confuso.

Un poco más abajo, esa misma referencia intenta ilustrar la probabilidad de tal colisión:

Aquí hay un ejemplo para darle una idea de lo que se necesitaría para obtener una colisión SHA-1. Si todos los 6.500 millones de humanos en la Tierra estuvieran programando, y cada segundo, cada uno produjera código que fuera equivalente al historial completo del kernel de Linux (1 millón de objetos Git) y lo empujara a un enorme repositorio Git, tomaría 5 años hasta ese repositorio contenía suficientes objetos para tener una probabilidad del 50% de una sola colisión de objetos SHA-1. Existe una mayor probabilidad de que todos los miembros de su equipo de programación sean atacados y asesinados por lobos en incidentes no relacionados en la misma noche.


44
Me gustaría ver la fuente de los números en la última oración ;-)
Joachim Sauer

17
@Jasper: ese enlace es una buena documentación, pero no contiene estadísticas sobre la probabilidad de que cada miembro de un equipo sea atacado y asesinado por lobos en incidentes no relacionados en la misma noche.
Joachim Sauer

55
@Jasper: Bueno, tal como lo leí, el texto literalmente afirma que la probabilidad de que 6.500 millones de miembros del equipo sean asesinados por lobos en la misma noche es superior al 50%. Pero mi principal objeción a su declaración es que tal evento tiene que ser un fenómeno en todo el mundo; Es inconcebible que esto pueda ocurrir debido a incidentes no relacionados. ;)
Keith Robertson

55
@KeithRobertson Estoy bastante seguro de que la publicación habla de la posibilidad de que todos los miembros de su equipo real sean comidos en comparación con la posibilidad de una colisión hash si todos en el mundo produjeran cantidades de código insanas, junto con el tiempo que les lleva en esas circunstancias llegar a un 50% de posibilidades de colisión (es decir, el incidente de los lobos no involucró a todo el mundo y el 50% estaba separado de los lobos). Sin embargo, entendiste el punto, si tal evento es inconcebible, también debería ser una colisión git hash. (Por supuesto, uno es (casi) puramente basado en el azar y el otro no, pero aún así.)
Jasper


23

Para agregar a mi respuesta anterior de 2012 , ahora hay (febrero de 2017, cinco años después), un ejemplo de colisión SHA-1 real con shattered.io , donde puede crear dos archivos PDF en colisión: obtener un SHA- 1 firma digital en el primer archivo PDF que también se puede abusar como una firma válida en el segundo archivo PDF.
Consulte también " A las puertas de la muerte durante años, la función SHA1 ampliamente utilizada ahora está muerta ", y esta ilustración .

Actualización 26 de febrero: Linus confirmó los siguientes puntos en una publicación de Google+ :

(1) Primero, el cielo no se está cayendo. Hay una gran diferencia entre usar un hash criptográfico para cosas como la firma de seguridad y usar uno para generar un "identificador de contenido" para un sistema direccionable por contenido como git.

(2) En segundo lugar, la naturaleza de este ataque SHA1 en particular significa que en realidad es bastante fácil mitigarlo, y ya se han publicado dos conjuntos de parches para esa mitigación.

(3) Y finalmente, en realidad hay una transición razonablemente sencilla a otro hash que no romperá el mundo, o incluso los viejos repositorios de git.

Con respecto a esa transición, vea el Q1 2018 Git 2.16 agregando una estructura que representa el algoritmo hash. La implementación de esa transición ha comenzado.

A partir de Git 2.19 (Q3 2018) , Git eligió SHA-256 como NewHash y está en el proceso de integrarlo al código (lo que significa que SHA1 sigue siendo el predeterminado (Q2 2019, Git 2.21), pero SHA2 será el sucesor)


Respuesta original (25 de febrero) Pero:

Joey Hess prueba esos pdf en un repositorio de Git y encontró :

Eso incluye dos archivos con el mismo SHA y tamaño, que obtienen diferentes blobs gracias a la forma en que git antepone el encabezado al contenido.

joey@darkstar:~/tmp/supercollider>sha1sum  bad.pdf good.pdf 
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65    bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1    good.pdf

Si bien agregar datos idénticos a estos archivos en colisión genera otras colisiones, los datos anteriores no lo hacen.

Entonces, el vector principal de ataque (forjar un commit) sería :

  • Generar un objeto de confirmación regular;
  • use todo el objeto commit + NUL como el prefijo elegido, y
  • use el ataque de colisión de prefijo idéntico para generar los objetos buenos / malos colisionantes.
  • ... y esto es inútil porque los objetos de confirmación buenos y malos todavía apuntan al mismo árbol.

Además, ya puede detectar ataques de colisión criptoanalíticos contra SHA-1 presente en cada archivo con cr-marcstevens/sha1collisiondetection

Agregar un cheque similar en Git en sí mismo tendría un costo de cálculo .

Al cambiar el hash, Linux comenta :

El tamaño del hash y la elección del algoritmo hash son cuestiones independientes.
Lo que probablemente haría es cambiar a un hash de 256 bits, usarlo internamente y en la base de datos nativa de git y, de forma predeterminada, solo mostrar el hash como una cadena hexadecimal de 40 caracteres (algo así como cómo abreviamos las cosas en muchas situaciones)
De esa manera, las herramientas alrededor de git ni siquiera ven el cambio a menos que se lo pase en algún " --full-hash" argumento especial (o " --abbrev=64" o lo que sea - el valor predeterminado es que abreviamos a 40).

Aún así, un plan de transición (de SHA1 a otra función hash) aún sería complejo , pero se estudiaría activamente.
Una convert-to-object_idcampaña está en progreso :


Actualización 20 de marzo: GitHub detalla un posible ataque y su protección :

A los nombres SHA-1 se les puede asignar confianza a través de varios mecanismos. Por ejemplo, Git le permite firmar criptográficamente una confirmación o etiqueta. Al hacerlo, solo se firma el objeto commit o tag, que a su vez apunta a otros objetos que contienen los datos reales del archivo utilizando sus nombres SHA-1. Una colisión en esos objetos podría producir una firma que parece válida, pero que apunta a datos diferentes de los que pretendía el firmante. En tal ataque, el firmante solo ve la mitad de la colisión, y la víctima ve la otra mitad.

Proteccion:

El reciente ataque utiliza técnicas especiales para explotar las debilidades en el algoritmo SHA-1 que encuentran una colisión en mucho menos tiempo. Estas técnicas dejan un patrón en los bytes que se puede detectar al calcular el SHA-1 de cualquier mitad de un par colisionante.

GitHub.com ahora realiza esta detección para cada SHA-1 que calcula, y aborta la operación si hay evidencia de que el objeto es la mitad de un par colisionante. Eso evita que los atacantes usen GitHub para convencer a un proyecto de que acepte la mitad "inocente" de su colisión, así como evitar que alojen la mitad maliciosa.

Ver " sha1collisiondetection" por Marc Stevens


Nuevamente, con Q1 2018 Git 2.16 agregando una estructura que representa el algoritmo hash, ha comenzado la implementación de una transición a un nuevo hash.
Como se mencionó anteriormente, el nuevo Hash compatible será SHA-256 .


La colisión: 1. El intento fue crear una colisión, que no ocurriera por coincidencia. 2. Del informe PDF: en total, el esfuerzo computacional gastado es equivalente a 2 ^ 63.1 compresiones SHA-1 y tomó aproximadamente 6.500 años de CPU y 100 años de GPU . 3. Aunque deberíamos pasar de MD5 y SHA-1, en general están bien para usos únicos de archivos.
zaph

Vale la pena señalar que WebKit revisó los PDF en colisión para una prueba. Rompió su infraestructura espejo git-svn: bugs.webkit.org/show_bug.cgi?id=168774#c24
dahlbyk

1
@dahlbyk Vale la pena señalar de hecho ... en eso lo anoté en la respuesta (el enlace detrás de "Tiene algún problema git-svnaunque" se refiere a él, aunque indirectamente)
VonC

1
@Mr_and_Mrs_D no, todavía no falla con un error. Está en curso un gran parche que luego ayudará a facilitar la detección de colisión: marc.info/?l=git&m=148987267504882&w=2
VonC

1
@Mr_and_Mrs_D VER edición 4 en stackoverflow.com/posts/42450327/revisions : falla ahora, al menos cuando se actualiza a GitHub.
VonC

6

Creo que los criptógrafos lo celebrarían.

Cita del artículo de Wikipedia sobre SHA-1 :

En febrero de 2005, se anunció un ataque de Xiaoyun Wang, Yiqun Lisa Yin y Hongbo Yu. Los ataques pueden encontrar colisiones en la versión completa de SHA-1, lo que requiere menos de 2 ^ 69 operaciones. (Una búsqueda de fuerza bruta requeriría 2 ^ 80 operaciones).


77
El punto es que se ha encontrado una falla en SHA1 y que esto fue más o menos cuando se introdujo Git. Además, la probabilidad es no lineal. El hecho de que juegue a la lotería durante cincuenta años no significa que tenga más posibilidades de ganar. Solo tienes la misma oportunidad cada vez. La persona que juega por primera vez aún puede ganar.
0xC0000022L

Este es solo un ataque que encuentra colisión, lo que significa que puede encontrar ytal que h(x) == h (y) `, que es una amenaza grave para datos arbitrarios como certificados SSL, sin embargo, esto no afecta a Git, que sería vulnerable a un segundo ataque previo a la imagen, lo que significa que teniendo el mensaje xse puede modificar el mensaje x'que h(x) == h(x'). Entonces este ataque no debilita a Git. Además, Git no ha elegido SHA-1 por razones de seguridad.
Hauleth

Ahora se ha encontrado una colisión, solo que no molesta a Git directamente todavía. stackoverflow.com/questions/42433126/…
Willem Hengeveld

2 ^ 69 son aproximadamente 600 operaciones Exa. Ocho años después, la súper computadora SaturnV de Nvidia actualizada con su A100 puede hacer 4.6 ExaOPS, por lo que podría resolver esto en un poco más de 2 minutos, o hacer un ataque de fuerza bruta en unos pocos días.
qdin

6

Hay varios modelos de ataque diferentes para hashes como SHA-1, pero el que generalmente se discute es la búsqueda de colisiones, incluida la herramienta HashClash de Marc Stevens .

"A partir de 2012, el ataque más eficiente contra SHA-1 es considerado por Marc Stevens [34] con un costo estimado de $ 2.77M para romper un valor de hash único al alquilar la potencia de la CPU de los servidores en la nube".

Como la gente señaló, podría forzar una colisión de hash con git, pero hacerlo no sobrescribirá los objetos existentes en otro repositorio. Me imagino que incluso git push -f --no-thinno sobrescribirá los objetos existentes, pero no estoy 100% seguro.

Dicho esto, si piratea un repositorio remoto, entonces podría convertir su objeto falso en el más antiguo allí , posiblemente incrustando código pirateado en un proyecto de código abierto en github o similar. Si fue cuidadoso, entonces podría presentar una versión pirateada que los nuevos usuarios descargaron.

Sin embargo, sospecho que muchas cosas que los desarrolladores del proyecto podrían hacer podrían exponer o destruir accidentalmente su truco multimillonario. En particular, eso es una gran cantidad de dinero por el desagüe si algún desarrollador, a quien no hackeaste, alguna vez ejecuta lo mencionado git push --no-thindespués de modificar los archivos afectados, a veces incluso sin la --no-thindependencia.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.