From patchwork Tue Feb 2 16:19:04 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062147 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58D3FC433DB for ; Tue, 2 Feb 2021 16:27:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2475A64F78 for ; Tue, 2 Feb 2021 16:27:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236254AbhBBQ1d (ORCPT ); Tue, 2 Feb 2021 11:27:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235081AbhBBQWg (ORCPT ); Tue, 2 Feb 2021 11:22:36 -0500 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC465C061224 for ; Tue, 2 Feb 2021 08:19:14 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id c12so21097477wrc.7 for ; Tue, 02 Feb 2021 08:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=s3tQLLw1VoeIVYOBcePa6Zg6m/eYJaaMoocRslAdv9M=; b=MWpCpy2P+CUrEpWK4r2//UcdGmqVypk7c+AvI2qI610wsUVEAjnf5ApM0okEJBYqTW C+48y5b7nPJ6C3EoHxAFIEfVHBj124Rxg7L91aDguO2o9Jzj3Gy1ezn2LIswVfyvzhD6 AURh8I/CnShNVfEVM4sBBShUIKgScAANsFCHU6d4P2oraQUqdRuA7YQ3juvFIUqW5Tif sf/UJIiaiEPt3GITj6Rbv8+8so0V27jik/yWNcIeDrQvuv3PZim07NCRZ9sCUIkMEP9B Z1uZCGwP/5+7P/OoaKHGaS3p5YbK/g0ZfWhlCk2KFg3GsAuxmpiUe8g695N0RK+JLKPS 6Fvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=s3tQLLw1VoeIVYOBcePa6Zg6m/eYJaaMoocRslAdv9M=; b=Nm7jMgHF+QXL3vbINkpHqvgxJ6cRpYD03dDPQT2nwPd2HcSc+rQi2Y1RSeEtYigPUS 8cZb457BW6dtKvPAIbIh0CNuIWw2L9VEY4ayYOO5c+lrwTrwrX+7VbQKVumc0uEz/868 sxMIVI2Sj1ohnLoCq1WUK+dDQnJ82QbX2zHamK+EMDcgQZINQNejOBf21LO8cOej9ANx W64te0WidxSD09vH6/+9hKNCFkippK0IJcD2FRthkXSRDhKGKHW4Q/RslW828Nyey35z dfvexKFuPTVTEvJUCYcCAn8O0k42EADPRI6ihqfBQL76dUxRBQmyDs1J+Npteu7NW27w BwMw== X-Gm-Message-State: AOAM533j+Ejgpven8GlMhz1+p4bEqkViCkgeEjPvHN/CpJyHKwXDReEa z5+ytpXdBKnJZiai5K98uFwe5Eppwfk= X-Google-Smtp-Source: ABdhPJzr1TvhCecsHKEpBr7UpQf74T9EQceB1IR0d61SmhKtVyBZjKrxOySVmLbHTAaIxSCYOC4u7g== X-Received: by 2002:a5d:6b45:: with SMTP id x5mr23735668wrw.415.1612282753166; Tue, 02 Feb 2021 08:19:13 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id n5sm3677106wmq.7.2021.02.02.08.19.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:11 -0800 (PST) Message-Id: In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:04 +0000 Subject: [PATCH v2 1/6] doc hash-function-transition: fix asciidoc output Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Asciidoc requires lists to start with an empty line and uses different characters for indentation levels ("-", "*", "**", ...). For special symbols like a dash "--" has to be used and there is no double arrow "<->", so a left and right arrow "<-->" has to be combined for that. Lastly for verbatim output a newline followed by an indentation has to be used. Fix asciidoc output for lists, special characters and verbatim text while retaining the readabilty of the original text file. Signed-off-by: Thomas Ackermann --- .../technical/hash-function-transition.txt | 81 +++++++++++-------- 1 file changed, 46 insertions(+), 35 deletions(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 6fd20ebbc25..4b04829d537 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -94,7 +94,7 @@ Overview -------- We introduce a new repository format extension. Repositories with this extension enabled use SHA-256 instead of SHA-1 to name their objects. -This affects both object names and object content --- both the names +This affects both object names and object content -- both the names of objects and all references to other objects within an object are switched to the new hash function. @@ -191,21 +191,21 @@ hash functions. They have the following format (all integers are in network byte order): - A header appears at the beginning and consists of the following: - - The 4-byte pack index signature: '\377t0c' - - 4-byte version number: 3 - - 4-byte length of the header section, including the signature and + * The 4-byte pack index signature: '\377t0c' + * 4-byte version number: 3 + * 4-byte length of the header section, including the signature and version number - - 4-byte number of objects contained in the pack - - 4-byte number of object formats in this pack index: 2 - - For each object format: - - 4-byte format identifier (e.g., 'sha1' for SHA-1) - - 4-byte length in bytes of shortened object names. This is the + * 4-byte number of objects contained in the pack + * 4-byte number of object formats in this pack index: 2 + * For each object format: + ** 4-byte format identifier (e.g., 'sha1' for SHA-1) + ** 4-byte length in bytes of shortened object names. This is the shortest possible length needed to make names in the shortened object name table unambiguous. - - 4-byte integer, recording where tables relating to this format + ** 4-byte integer, recording where tables relating to this format are stored in this index file, as an offset from the beginning. - - 4-byte offset to the trailer from the beginning of this file. - - Zero or more additional key/value pairs (4-byte key, 4-byte + * 4-byte offset to the trailer from the beginning of this file. + * Zero or more additional key/value pairs (4-byte key, 4-byte value). Only one key is supported: 'PSRC'. See the "Loose objects and unreachable objects" section for supported values and how this is used. All other keys are reserved. Readers must ignore @@ -213,37 +213,36 @@ network byte order): - Zero or more NUL bytes. This can optionally be used to improve the alignment of the full object name table below. - Tables for the first object format: - - A sorted table of shortened object names. These are prefixes of + * A sorted table of shortened object names. These are prefixes of the names of all objects in this pack file, packed together without offset values to reduce the cache footprint of the binary search for a specific object name. - - A table of full object names in pack order. This allows resolving + * A table of full object names in pack order. This allows resolving a reference to "the nth object in the pack file" (from a reachability bitmap or from the next table of another object format) to its object name. - - A table of 4-byte values mapping object name order to pack order. + * A table of 4-byte values mapping object name order to pack order. For an object in the table of sorted shortened object names, the value at the corresponding index in this table is the index in the previous table for that same object. - This can be used to look up the object in reachability bitmaps or to look up its name in another object format. - - A table of 4-byte CRC32 values of the packed object data, in the + * A table of 4-byte CRC32 values of the packed object data, in the order that the objects appear in the pack file. This is to allow compressed data to be copied directly from pack to pack during repacking without undetected data corruption. - - A table of 4-byte offset values. For an object in the table of + * A table of 4-byte offset values. For an object in the table of sorted shortened object names, the value at the corresponding index in this table indicates where that object can be found in the pack file. These are usually 31-bit pack file offsets, but large offsets are encoded as an index into the next table with the most significant bit set. - - A table of 8-byte offset entries (empty for pack files less than + * A table of 8-byte offset entries (empty for pack files less than 2 GiB). Pack files are organized with heavily used objects toward the front, so most object references should not need to refer to this table. @@ -252,10 +251,10 @@ network byte order): up to and not including the table of CRC32 values. - Zero or more NUL bytes. - The trailer consists of the following: - - A copy of the 20-byte SHA-256 checksum at the end of the + * A copy of the 20-byte SHA-256 checksum at the end of the corresponding packfile. - - 20-byte SHA-256 checksum of all of the above. + * 20-byte SHA-256 checksum of all of the above. Loose object index ~~~~~~~~~~~~~~~~~~ @@ -350,8 +349,8 @@ the following steps: they will be discarded.) 3. convert to sha256: open a new (sha256) packfile. Read the topologically sorted list just generated. For each object, inflate its - sha1-content, convert to sha256-content, and write it to the sha256 - pack. Record the new sha1<->sha256 mapping entry for use in the idx. + SHA-1 content, convert to SHA-256 content, and write it to the SHA-256 + pack. Record the new SHA-1<-->SHA-256 mapping entry for use in the idx. 4. sort: reorder entries in the new pack to match the order of objects in the pack the server generated and include blobs. Write a sha256 idx file @@ -391,6 +390,7 @@ existing "gpgsig" field. Its signed payload is the sha256-content of the commit object with any "gpgsig" and "gpgsig-sha256" fields removed. This means commits can be signed + 1. using SHA-1 only, as in existing signed commit objects 2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig fields. @@ -408,6 +408,7 @@ sha256-content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP SIGNATURE-----" delimited in-body signature removed. This means tags can be signed + 1. using SHA-1 only, as in existing signed tag objects 2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body signature. @@ -598,7 +599,7 @@ The user can also explicitly specify which format to use for a particular revision specifier and for output, overriding the mode. For example: -git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} + git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} Choice of Hash -------------- @@ -636,6 +637,7 @@ We choose SHA-256. Transition plan --------------- Some initial steps can be implemented independently of one another: + - adding a hash function API (vtable) - teaching fsck to tolerate the gpgsig-sha256 field - excluding gpgsig-* from the fields copied by "git commit --amend" @@ -647,9 +649,9 @@ Some initial steps can be implemented independently of one another: - introducing index v3 - adding support for the PSRC field and safer object pruning - The first user-visible change is the introduction of the objectFormat extension (without compatObjectFormat). This requires: + - teaching fsck about this mode of operation - using the hash function API (vtable) when computing object names - signing objects and verifying signatures @@ -657,6 +659,7 @@ extension (without compatObjectFormat). This requires: repository Next comes introduction of compatObjectFormat: + - implementing the loose-object-idx - translating object names between object formats - translating object content between object formats @@ -669,6 +672,7 @@ Next comes introduction of compatObjectFormat: "Object names on the command line" above) The next step is supporting fetches and pushes to SHA-1 repositories: + - allow pushes to a repository using the compat format - generate a topologically sorted list of the SHA-1 names of fetched objects @@ -734,6 +738,7 @@ Using hash functions in parallel Objects newly created would be addressed by the new hash, but inside such an object (e.g. commit) it is still possible to address objects using the old hash function. + * You cannot trust its history (needed for bisectability) in the future without further work * Maintenance burden as the number of supported hash functions grows @@ -749,6 +754,7 @@ sha1-content based signatures. In other words, a single signature was used to attest to the object content using both hash functions. This had some advantages: + * Using one signature instead of two speeds up the signing process. * Having one signed payload with both hashes allows the signer to attest to the sha1-name and sha256-name referring to the same object. @@ -756,6 +762,7 @@ content using both hash functions. This had some advantages: to be detected quickly using current versions of git. However, it also came with disadvantages: + * Verifying a signed object requires access to the sha1-names of all objects it references, even after the transition is complete and translation table is no longer needed for anything else. To support @@ -782,16 +789,17 @@ Document History bmwill@google.com, jonathantanmy@google.com, jrnieder@gmail.com, sbeller@google.com -Initial version sent to -http://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com +* Initial version sent to http://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com 2017-03-03 jrnieder@gmail.com Incorporated suggestions from jonathantanmy and sbeller: + * describe purpose of signed objects with each hash type * redefine signed object verification using object content under the first hash function 2017-03-06 jrnieder@gmail.com + * Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2] * Make sha3-based signatures a separate field, avoiding the need for "hash" and "nohash" fields (thanks to peff[3]). @@ -805,6 +813,7 @@ Incorporated suggestions from jonathantanmy and sbeller: especially Junio). 2017-09-27 jrnieder@gmail.com, sbeller@google.com + * use placeholder NewHash instead of SHA3-256 * describe criteria for picking a hash function. * include a transition plan (thanks especially to Brandon Williams @@ -816,12 +825,14 @@ Incorporated suggestions from jonathantanmy and sbeller: Later history: - See the history of this file in git.git for the history of subsequent - edits. This document history is no longer being maintained as it - would now be superfluous to the commit log +* See the history of this file in git.git for the history of subsequent + edits. This document history is no longer being maintained as it + would now be superfluous to the commit log + +References: -[1] http://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ -[2] http://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ -[3] http://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ -[4] http://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net -[5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/ + [1] http://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ + [2] http://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ + [3] http://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ + [4] http://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net + [5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/ From patchwork Tue Feb 2 16:19:05 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062151 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75D59C43331 for ; Tue, 2 Feb 2021 16:28:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A7DD64E9B for ; Tue, 2 Feb 2021 16:28:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236398AbhBBQ1l (ORCPT ); Tue, 2 Feb 2021 11:27:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236298AbhBBQWs (ORCPT ); Tue, 2 Feb 2021 11:22:48 -0500 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A23CC061225 for ; Tue, 2 Feb 2021 08:19:16 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id b3so2967894wrj.5 for ; Tue, 02 Feb 2021 08:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=2dao6OMT3vJpBhdQEs6QMZnm69uKurFMOI3bhJiNuvc=; b=el9/AyvzigukQkEcRQO5kOO0jvNACuWac4PfX5OU0gKIqCm2XEVKC14xZ3zZTDWkre u4YZWzQrDN8JAY7ZYpI1VbYuzbYpHXExbOzCpCgpwe3EzwtZ7bUMD6GceVdcPpkfIwXO yzJqReYpEziFPZPq3K/pe9gNDCnGbQsDMrTM476iyBGVy4Uc57eYxUVhKxsk3J2Jnd5t g/FR0sRbGNTSeqxMNM6n44kzwnPtbMJq7xum8BvuKRRtOibIqTfD/RImoIsos18qi3rY fHO4dfJCV+Cx+8iD6cGL0RRutUg7gxkqtT4kzD+BfV5jsJmXa3xjQjIGiqsTPk5bOB6D kV2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=2dao6OMT3vJpBhdQEs6QMZnm69uKurFMOI3bhJiNuvc=; b=TLyG1hJpnCmzJ3cVOOdTryb80JqsaLdlimpol8ENhN6nxMH3rupgNi2+zieOkKpe+6 rjfITtyvV985b5qdvP+UrM6tWknla1TqPxaJ0gGtYwwCDB2EX/7rdaA+SEhv9TkHMQ5L mS5SROwtHi0pAG1iNDHDuF1nVLnQ0eIDgp1QeebZrWvwzBSYrLF9MGWM6TSNv5BMo3Wq bpAK1cvC+uf71Oj7NDsc92PcxVkm3piX+NSOqMDIBT0E652UBqonOBVS9iKHku+e6eXg 4wWgNlqqDUFhrzd0PHqYhretBtk/OYQHznphAdbp3NwVcOCO7mMTM91HUPQCC5criehk xwlw== X-Gm-Message-State: AOAM533M5UpVViWKn1LyPIcoZyavop9co/3o4FVdm7+VSq9FZOSBvFwl LlSZrBoLgoouISxNsyInvPgdtfIqWt8= X-Google-Smtp-Source: ABdhPJwqxPBv2mvfofw4M2SrZaCs+9l0GBtY9EXYjo3p1H6J5HOilUss3DJ/zoGF18uzb5KnTT4z8g== X-Received: by 2002:a5d:4e4c:: with SMTP id r12mr24563022wrt.354.1612282754573; Tue, 02 Feb 2021 08:19:14 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id q9sm4389426wme.18.2021.02.02.08.19.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:13 -0800 (PST) Message-Id: <681ce4129dc35b6a61aac0dbd1b9b9d638a2b78d.1612282749.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:05 +0000 Subject: [PATCH v2 2/6] doc hash-function-transition: use SHA-1 and SHA-256 consistently Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Use SHA-1 and SHA-256 instead of sha1 and sha256 when referring to the hash type. Signed-off-by: Thomas Ackermann --- .../technical/hash-function-transition.txt | 122 +++++++++--------- 1 file changed, 61 insertions(+), 61 deletions(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 4b04829d537..51acf2c10b7 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -107,7 +107,7 @@ mapping to allow naming objects using either their SHA-1 and SHA-256 names interchangeably. "git cat-file" and "git hash-object" gain options to display an object -in its sha1 form and write an object given its sha1 form. This +in its SHA-1 form and write an object given its SHA-1 form. This requires all objects referenced by that object to be present in the object database so that they can be named using the appropriate name (using the bidirectional hash mapping). @@ -115,7 +115,7 @@ object database so that they can be named using the appropriate name Fetches from a SHA-1 based server convert the fetched objects into SHA-256 form and record the mapping in the bidirectional mapping table (see below for details). Pushes to a SHA-1 based server convert the -objects being pushed into sha1 form so the server does not have to be +objects being pushed into SHA-1 form so the server does not have to be aware of the hash function the client is using. Detailed Design @@ -151,38 +151,38 @@ repository extensions. Object names ~~~~~~~~~~~~ -Objects can be named by their 40 hexadecimal digit sha1-name or 64 -hexadecimal digit sha256-name, plus names derived from those (see +Objects can be named by their 40 hexadecimal digit SHA-1 name or 64 +hexadecimal digit SHA-256 name, plus names derived from those (see gitrevisions(7)). -The sha1-name of an object is the SHA-1 of the concatenation of its -type, length, a nul byte, and the object's sha1-content. This is the +The SHA-1 name of an object is the SHA-1 of the concatenation of its +type, length, a nul byte, and the object's SHA-1 content. This is the traditional used in Git to name objects. -The sha256-name of an object is the SHA-256 of the concatenation of its -type, length, a nul byte, and the object's sha256-content. +The SHA-256 name of an object is the SHA-256 of the concatenation of its +type, length, a nul byte, and the object's SHA-256 content. Object format ~~~~~~~~~~~~~ The content as a byte sequence of a tag, commit, or tree object named -by sha1 and sha256 differ because an object named by sha256-name refers to -other objects by their sha256-names and an object named by sha1-name -refers to other objects by their sha1-names. +by SHA-1 and SHA-256 differ because an object named by SHA-256 name refers to +other objects by their SHA-256 names and an object named by SHA-1 name +refers to other objects by their SHA-1 names. -The sha256-content of an object is the same as its sha1-content, except -that objects referenced by the object are named using their sha256-names -instead of sha1-names. Because a blob object does not refer to any -other object, its sha1-content and sha256-content are the same. +The SHA-256-content of an object is the same as its SHA-1 content, except +that objects referenced by the object are named using their SHA-256 names +instead of SHA-1 names. Because a blob object does not refer to any +other object, its SHA-1 content and SHA-256 content are the same. -The format allows round-trip conversion between sha256-content and -sha1-content. +The format allows round-trip conversion between SHA-256 content and +SHA-1 content. Object storage ~~~~~~~~~~~~~~ Loose objects use zlib compression and packed objects use the packed format described in Documentation/technical/pack-format.txt, just like -today. The content that is compressed and stored uses sha256-content -instead of sha1-content. +today. The content that is compressed and stored uses SHA-256 content +instead of SHA-1 content. Pack index ~~~~~~~~~~ @@ -287,18 +287,18 @@ To remove entries (e.g. in "git pack-refs" or "git-prune"): Translation table ~~~~~~~~~~~~~~~~~ -The index files support a bidirectional mapping between sha1-names -and sha256-names. The lookup proceeds similarly to ordinary object -lookups. For example, to convert a sha1-name to a sha256-name: +The index files support a bidirectional mapping between SHA-1 names +and SHA-256 names. The lookup proceeds similarly to ordinary object +lookups. For example, to convert a SHA-1 name to a SHA-256 name: 1. Look for the object in idx files. If a match is present in the - idx's sorted list of truncated sha1-names, then: - a. Read the corresponding entry in the sha1-name order to pack + idx's sorted list of truncated SHA-1 names, then: + a. Read the corresponding entry in the SHA-1 name order to pack name order mapping. - b. Read the corresponding entry in the full sha1-name table to + b. Read the corresponding entry in the full SHA-1 name table to verify we found the right object. If it is, then - c. Read the corresponding entry in the full sha256-name table. - That is the object's sha256-name. + c. Read the corresponding entry in the full SHA-256 name table. + That is the object's SHA-256 name. 2. Check for a loose object. Read lines from loose-object-idx until we find a match. @@ -312,10 +312,10 @@ Since all operations that make new objects (e.g., "git commit") add the new objects to the corresponding index, this mapping is possible for all objects in the object store. -Reading an object's sha1-content -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The sha1-content of an object can be read by converting all sha256-names -its sha256-content references to sha1-names using the translation table. +Reading an object's SHA-1 content +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The SHA-1 content of an object can be read by converting all SHA-256 names +its SHA-256 content references to SHA-1 names using the translation table. Fetch ~~~~~ @@ -338,7 +338,7 @@ the following steps: 1. index-pack: inflate each object in the packfile and compute its SHA-1. Objects can contain deltas in OBJ_REF_DELTA format against objects the client has locally. These objects can be looked up - using the translation table and their sha1-content read as + using the translation table and their SHA-1 content read as described above to resolve the deltas. 2. topological sort: starting at the "want"s from the negotiation phase, walk through objects in the pack and emit a list of them, @@ -347,12 +347,12 @@ the following steps: (This list only contains objects reachable from the "wants". If the pack from the server contained additional extraneous objects, then they will be discarded.) -3. convert to sha256: open a new (sha256) packfile. Read the topologically +3. convert to SHA-256: open a new SHA-256 packfile. Read the topologically sorted list just generated. For each object, inflate its SHA-1 content, convert to SHA-256 content, and write it to the SHA-256 pack. Record the new SHA-1<-->SHA-256 mapping entry for use in the idx. 4. sort: reorder entries in the new pack to match the order of objects - in the pack the server generated and include blobs. Write a sha256 idx + in the pack the server generated and include blobs. Write a SHA-256 idx file 5. clean up: remove the SHA-1 based pack file, index, and topologically sorted list obtained from the server in steps 1 @@ -377,16 +377,16 @@ experimenting to get this to perform well. Push ~~~~ Push is simpler than fetch because the objects referenced by the -pushed objects are already in the translation table. The sha1-content +pushed objects are already in the translation table. The SHA-1 content of each object being pushed can be read as described in the "Reading -an object's sha1-content" section to generate the pack written by git +an object's SHA-1 content" section to generate the pack written by git send-pack. Signed Commits ~~~~~~~~~~~~~~ We add a new field "gpgsig-sha256" to the commit object format to allow signing commits without relying on SHA-1. It is similar to the -existing "gpgsig" field. Its signed payload is the sha256-content of the +existing "gpgsig" field. Its signed payload is the SHA-256 content of the commit object with any "gpgsig" and "gpgsig-sha256" fields removed. This means commits can be signed @@ -404,7 +404,7 @@ Signed Tags ~~~~~~~~~~~ We add a new field "gpgsig-sha256" to the tag object format to allow signing tags without relying on SHA-1. Its signed payload is the -sha256-content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP +SHA-256 content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP SIGNATURE-----" delimited in-body signature removed. This means tags can be signed @@ -416,11 +416,11 @@ This means tags can be signed Mergetag embedding ~~~~~~~~~~~~~~~~~~ -The mergetag field in the sha1-content of a commit contains the -sha1-content of a tag that was merged by that commit. +The mergetag field in the SHA-1 content of a commit contains the +SHA-1 content of a tag that was merged by that commit. -The mergetag field in the sha256-content of the same commit contains the -sha256-content of the same tag. +The mergetag field in the SHA-256 content of the same commit contains the +SHA-256 content of the same tag. Submodules ~~~~~~~~~~ @@ -495,7 +495,7 @@ Caveats ------- Invalid objects ~~~~~~~~~~~~~~~ -The conversion from sha1-content to sha256-content retains any +The conversion from SHA-1 content to SHA-256 content retains any brokenness in the original object (e.g., tree entry modes encoded with leading 0, tree objects whose paths are not sorted correctly, and commit objects without an author or committer). This is a deliberate @@ -514,15 +514,15 @@ allow lifting this restriction. Alternates ~~~~~~~~~~ -For the same reason, a sha256 repository cannot borrow objects from a -sha1 repository using objects/info/alternates or +For the same reason, a SHA-256 repository cannot borrow objects from a +SHA-1 repository using objects/info/alternates or $GIT_ALTERNATE_OBJECT_REPOSITORIES. git notes ~~~~~~~~~ -The "git notes" tool annotates objects using their sha1-name as key. +The "git notes" tool annotates objects using their SHA-1 name as key. This design does not describe a way to migrate notes trees to use -sha256-names. That migration is expected to happen separately (for +SHA-256 names. That migration is expected to happen separately (for example using a file at the root of the notes tree to describe which hash it uses). @@ -556,7 +556,7 @@ unclear: Git 2.12 -Does this mean Git v2.12.0 is the commit with sha1-name +Does this mean Git v2.12.0 is the commit with SHA-1 name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7? @@ -676,7 +676,7 @@ The next step is supporting fetches and pushes to SHA-1 repositories: - allow pushes to a repository using the compat format - generate a topologically sorted list of the SHA-1 names of fetched objects -- convert the fetched packfile to sha256 format and generate an idx +- convert the fetched packfile to SHA-256 format and generate an idx file - re-sort to match the order of objects in the fetched packfile @@ -748,38 +748,38 @@ using the old hash function. Signed objects with multiple hashes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Instead of introducing the gpgsig-sha256 field in commit and tag objects -for sha256-content based signatures, an earlier version of this design -added "hash sha256 " fields to strengthen the existing -sha1-content based signatures. +for SHA-256 content based signatures, an earlier version of this design +added "hash sha256 " fields to strengthen the existing +SHA-1 content based signatures. In other words, a single signature was used to attest to the object content using both hash functions. This had some advantages: * Using one signature instead of two speeds up the signing process. * Having one signed payload with both hashes allows the signer to - attest to the sha1-name and sha256-name referring to the same object. + attest to the SHA-1 name and SHA-256 name referring to the same object. * All users consume the same signature. Broken signatures are likely to be detected quickly using current versions of git. However, it also came with disadvantages: -* Verifying a signed object requires access to the sha1-names of all +* Verifying a signed object requires access to the SHA-1 names of all objects it references, even after the transition is complete and translation table is no longer needed for anything else. To support - this, the design added fields such as "hash sha1 tree " - and "hash sha1 parent " to the sha256-content of a signed + this, the design added fields such as "hash sha1 tree " + and "hash sha1 parent " to the SHA-256 content of a signed commit, complicating the conversion process. -* Allowing signed objects without a sha1 (for after the transition is +* Allowing signed objects without a SHA-1 (for after the transition is complete) complicated the design further, requiring a "nohash sha1" - field to suppress including "hash sha1" fields in the sha256-content + field to suppress including "hash sha1" fields in the SHA-256 content and signed payload. Lazily populated translation table ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some of the work of building the translation table could be deferred to push time, but that would significantly complicate and slow down pushes. -Calculating the sha1-name at object creation time at the same time it is -being streamed to disk and having its sha256-name calculated should be +Calculating the SHA-1 name at object creation time at the same time it is +being streamed to disk and having its SHA-256 name calculated should be an acceptable cost. Document History @@ -801,7 +801,7 @@ Incorporated suggestions from jonathantanmy and sbeller: 2017-03-06 jrnieder@gmail.com * Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2] -* Make sha3-based signatures a separate field, avoiding the need for +* Make SHA3-based signatures a separate field, avoiding the need for "hash" and "nohash" fields (thanks to peff[3]). * Add a sorting phase to fetch (thanks to Junio for noticing the need for this). From patchwork Tue Feb 2 16:19:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062149 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51D7FC4332E for ; Tue, 2 Feb 2021 16:28:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3266964F77 for ; Tue, 2 Feb 2021 16:28:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236313AbhBBQ1i (ORCPT ); Tue, 2 Feb 2021 11:27:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236299AbhBBQWs (ORCPT ); Tue, 2 Feb 2021 11:22:48 -0500 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B6B9C061226 for ; Tue, 2 Feb 2021 08:19:17 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id e15so2830479wme.0 for ; Tue, 02 Feb 2021 08:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=/DncVgEztJPVuz6mC6hrgF0RNBiotUg00UdzjEdkN0g=; b=qVU73IJf3q0MEpeVwMcjWqb87R7llM2c/MUGmIl0kcd2ZvcH2hhY8aZxkPO6qxiqQh jTj5usLBLZPezO1OhZ+EVPb3Zmye956BsSEJJAGEhIFIW01BgU/zlTOc8y+DqWFB4R4P DZb7QpMXDuy1tyyv5XrNKVjCEL+ZOAlVJuLixtkjFBBqQS3SfM8u1xrP9Zyyi3cUqlpu g06366NE6AJFvoBvEgE7xxvvZx1QWfgRW8gIdrAdlGdsQPb2SnXqFIga1QwYpoik00EB 64/V7Y+pEE9W6+679Hlb3DCABkG3aajFExrGxgoR9yqOsRBWvrE9tw8oq2R6uAiHewE0 oPsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=/DncVgEztJPVuz6mC6hrgF0RNBiotUg00UdzjEdkN0g=; b=s86h7POJtLjSgccl1LB6LkD2o9+8zXHJ0Xl+ECs1uR9Hvj1BOQBIPhJu+Bb5EHe65M zcgH9TPjddqt+L5fzHUp7h9WqpE6BmFY1QnXVsux7lzXCjBIIZVvlKVnVkWRHNI/SikI ZRB7EmDL16y5oiozrftqHhoXEUo5n2MkKkLjVehMW+h8UqOAMpQv3OrBNrzV3R/ZeV9o vA16xgJzT6htSJPUiGdS/I4T/01xMGZA/51vjOnulopvb59H5JjkYIr4TrGGx6qGlRdq rB63dBFYmymbPSE9NtGVRta34KYoGgx9QSIfq9sjvPmEb1XflsgOGtJZKEKuNyXZfxmT hd5g== X-Gm-Message-State: AOAM5306zAoHMBSRLNJvte/S2Twz2AWUwdd7PH/sMEGXL+uimQRtzFaS qSDTOhAC0pvUOa/eYSXwhiG51n+9sdk= X-Google-Smtp-Source: ABdhPJxmUkvuAF0CJwUAM5LCuwXWSsDh+Ev0/P5nVDn1v2TJcHFmIK4iPiVGC5eXvcz89tFUP5POsQ== X-Received: by 2002:a1c:9648:: with SMTP id y69mr4301804wmd.40.1612282755725; Tue, 02 Feb 2021 08:19:15 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id t8sm3526269wmq.36.2021.02.02.08.19.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:15 -0800 (PST) Message-Id: <4f622fffcc5d42ff202c7de530a7805d41cd32bb.1612282749.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:06 +0000 Subject: [PATCH v2 3/6] doc hash-function-transition: use upper case consistently Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Use upper case consistently in Document History. Signed-off-by: Thomas Ackermann --- .../technical/hash-function-transition.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 51acf2c10b7..2eba25cf87c 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -794,8 +794,8 @@ sbeller@google.com 2017-03-03 jrnieder@gmail.com Incorporated suggestions from jonathantanmy and sbeller: -* describe purpose of signed objects with each hash type -* redefine signed object verification using object content under the +* Describe purpose of signed objects with each hash type +* Redefine signed object verification using object content under the first hash function 2017-03-06 jrnieder@gmail.com @@ -814,13 +814,13 @@ Incorporated suggestions from jonathantanmy and sbeller: 2017-09-27 jrnieder@gmail.com, sbeller@google.com -* use placeholder NewHash instead of SHA3-256 -* describe criteria for picking a hash function. -* include a transition plan (thanks especially to Brandon Williams +* Use placeholder NewHash instead of SHA3-256 +* Describe criteria for picking a hash function. +* Include a transition plan (thanks especially to Brandon Williams for fleshing these ideas out) -* define the translation table (thanks, Shawn Pearce[5], Jonathan +* Define the translation table (thanks, Shawn Pearce[5], Jonathan Tan, and Masaya Suzuki) -* avoid loose object overhead by packing more aggressively in +* Avoid loose object overhead by packing more aggressively in "git gc --auto" Later history: From patchwork Tue Feb 2 16:19:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062129 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF4CFC433E6 for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8419E64F70 for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236233AbhBBQZZ (ORCPT ); Tue, 2 Feb 2021 11:25:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236303AbhBBQWv (ORCPT ); Tue, 2 Feb 2021 11:22:51 -0500 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DC92C0611C0 for ; Tue, 2 Feb 2021 08:19:18 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id a1so21106596wrq.6 for ; Tue, 02 Feb 2021 08:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=EZ4RHWZVjAkBYM+91aqMFDJy3L3W3Or4L2fRZltk7IY=; b=kdjzhLzPl2XnTs5i7aC2ZPK/sQSda6naW4Dn+9FTjLjU2FGj+u9ANtskaeB9fqdkuN dd+jhza1GQsZ54VRg7Cwh0WNC+UWcmhmI39hZvNAc60bMXYOr0k4sW5XDSSIQuN3Wh2d K05nML0+PC60vVf8sERt2XShzqnPyKm5ZqBoo8u0WLQZnDa5XNx40Mg4panDPbc/BFNI i4hA7IfmzZA8qgNKn6o8h9mawfJUcE2wdVq2MTI+aTN0DL+YFhm/wtfvnJ0pvFk+cdtH dqfmlraiSHPPydMnHGnVBgMZQJOY6HuryTYCJuH0fQIthGXpgcebALFehcRez2C7Xasr ZS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=EZ4RHWZVjAkBYM+91aqMFDJy3L3W3Or4L2fRZltk7IY=; b=aJMvPETDPMuhNVJ61KJyQWAOMiEhYO4vSZBxiK7TwDtC6Z2XJBbiZlkpvLfPHVG4HA GEye12coOvs0CjzjuhlI/u7OyQUSEKzHzs+aKkQ2MCZEk9uxKjX8QGfyzzggk7myLkCw ttoYXVrRziOFOXAa9mVEKMs4UuWpYgSCI3qUm1E2KHl+n0h3a0vjgSGUvxw6CV+QG6pD PnJEtL0uZSFSTvjn0avzQp5Uwd7gdS4YMW58un9FdFtfg1CHDFDeIGuDGQ4TOSDfqrZ0 K63rQbZ4PcmzXNwWDY15lo3ZNHTTNgNABt/E++epNdZS6RXyKN4viztnbGQFYiJqfp1M Qmng== X-Gm-Message-State: AOAM533p/zichuCt1pjxQE/nrlmHbfka171sKV0y3nRtH7VAYl36+SpU kaJdgl4jAc+Ji+B3lhERxHWazmS6CzQ= X-Google-Smtp-Source: ABdhPJyxve+qfdhA/zSkCOkX6r+OYr7r0cps8Wn8OthkXDYTa3/AXCw3NjHYdwys9+mFT6J1aqOI2g== X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr12802311wrx.328.1612282756849; Tue, 02 Feb 2021 08:19:16 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id y24sm3741006wmi.47.2021.02.02.08.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:16 -0800 (PST) Message-Id: <58295cadffe5e91786da45909b87b280e1f15147.1612282749.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:07 +0000 Subject: [PATCH v2 4/6] doc hash-function-transition: fix incomplete sentence Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Signed-off-by: Thomas Ackermann --- Documentation/technical/hash-function-transition.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 2eba25cf87c..86b09ea0f21 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -315,7 +315,7 @@ for all objects in the object store. Reading an object's SHA-1 content ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The SHA-1 content of an object can be read by converting all SHA-256 names -its SHA-256 content references to SHA-1 names using the translation table. +of its SHA-256 content references to SHA-1 names using the translation table. Fetch ~~~~~ From patchwork Tue Feb 2 16:19:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062125 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A5E6C433DB for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 173F664F72 for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236363AbhBBQZE (ORCPT ); Tue, 2 Feb 2021 11:25:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236302AbhBBQWv (ORCPT ); Tue, 2 Feb 2021 11:22:51 -0500 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88CF3C0611C1 for ; Tue, 2 Feb 2021 08:19:19 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id l12so21105745wry.2 for ; Tue, 02 Feb 2021 08:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=ykrjwuOhfmXvFJgFxOpKYuTOaMIy6qr02qTqRxa/ZC0=; b=Y8aAs5TD/CvDKETkZDH72OkOWW4NMb+ejbhFeVpRkDGlGazpn4iAEdwL7ZitzeslgC 9GWVLPfO9iUEdrRTmBOE5gOhb3d24+PLyC2dhLc932Ao84TGGfAvFENAxlJBYhXOqriw NUS0G+h15KNjvW03pjh2aLTTHqsYY1f1BQ5xAyW6B6KHNbD/tsVFQZB3eKtqkxZg+qkO DO0giV0s2lJoKEnjhaYUgxr0zf3G/YQ6CgrfmLO+WKYcpAk2/qMqCoDadc+Jzkmk6iIg uaH2QRqH+qTWsISSEAEXW3ncARDgiwVJTSnxwtj16tBiNd9fV2vHkj61po8WrXD2r7ve Q4JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=ykrjwuOhfmXvFJgFxOpKYuTOaMIy6qr02qTqRxa/ZC0=; b=c1W/2GaTT1ENvveql47tzJapzeaZJ2yyZ5dkdi3L2wViXVelrav1x4RH54AVVDZ02G A+uGcJafjTq1oxtsA8LQ8w3ObnF4+fwz7oHLt5a+G5bcuyfpX2rd60I9DZwBjzd3Br8E V5FkzN2Pvc6Eg8eI9LCWrJPweWfEgyCER2axiLqwP2nQokD4p9WAwOljgTPxOkDE4gdV bCiieQjO9O97tk8XftuzhYRWVhWI+nPB4TxzI6t8xUiS7Ev09iqnPJlz1NHyFg5gqIJD oHSs9KFPkOSHjDzag2BIwcxZJ5+L0X8v92ytX+0XBYAwog3NlLqSf8fJHiR77HLmZoyA Lt4g== X-Gm-Message-State: AOAM533+oFexgjDAuLnZ4krwWZxia3NpxG+A4KnBuuvD2zVEI7iiu3fB jdh13XTUTFZwTHt9C1dtdk6DSjuojaQ= X-Google-Smtp-Source: ABdhPJzpOGu0FMr26T16KL1wFKKKDtEo49HYXs0+LiqtJNGrd/UH0Sz7aqs4BmiTejVEKHcxffhh5A== X-Received: by 2002:a5d:6546:: with SMTP id z6mr24980514wrv.125.1612282757988; Tue, 02 Feb 2021 08:19:17 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id n6sm3661869wmi.23.2021.02.02.08.19.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:17 -0800 (PST) Message-Id: <711a37969b6f51922c12555534d9c4634cde6021.1612282749.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:08 +0000 Subject: [PATCH v2 5/6] doc hash-function-transition: move rationale upwards Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Move rationale for new hash function to beginning of document so that it appears before the concrete move to SHA-256 is described. Remove details about SHA-1 weaknesses. Instead add references to the details of how the new hash function was chosen. Signed-off-by: Thomas Ackermann --- .../technical/hash-function-transition.txt | 62 +++++-------------- 1 file changed, 16 insertions(+), 46 deletions(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 86b09ea0f21..475f2f501a6 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -27,22 +27,12 @@ advantages: methods have a short reliable string that can be used to reliably address stored content. -Over time some flaws in SHA-1 have been discovered by security -researchers. On 23 February 2017 the SHAttered attack -(https://shattered.io) demonstrated a practical SHA-1 hash collision. +Over time some flaws in SHA-1 have been discovered by security researchers. Git v2.13.0 and later subsequently moved to a hardened SHA-1 -implementation by default, which isn't vulnerable to the SHAttered -attack. +implementation by default, but SHA-1 is still believed to be weak. -Thus Git has in effect already migrated to a new hash that isn't SHA-1 -and doesn't share its vulnerabilities, its new hash function just -happens to produce exactly the same output for all known inputs, -except two PDFs published by the SHAttered researchers, and the new -implementation (written by those researchers) claims to detect future -cryptanalytic collision attacks. - -Regardless, it's considered prudent to move past any variant of SHA-1 +Thus it's considered prudent to move past any variant of SHA-1 to a new hash. There's no guarantee that future attacks on SHA-1 won't be published in the future, and those attacks may not have viable mitigations. @@ -57,6 +47,19 @@ SHA-1 still possesses the other properties such as fast object lookup and safe error checking, but other hash functions are equally suitable that are believed to be cryptographically secure. +Choice of Hash +-------------- +There were several contenders for a successor hash to SHA-1, including +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256. + +In late 2018 the project picked SHA-256 as its successor hash. + +See 0ed8d8da374 (doc hash-function-transition: pick SHA-256 as +NewHash, 2018-08-04) and numerous mailing list threads at the time, +particularly the one starting at +https://lore.kernel.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/ +for more information. + Goals ----- 1. The transition to SHA-256 can be done one local repository at a time. @@ -601,39 +604,6 @@ example: git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} -Choice of Hash --------------- -In early 2005, around the time that Git was written, Xiaoyun Wang, -Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1 -collisions in 2^69 operations. In August they published details. -Luckily, no practical demonstrations of a collision in full SHA-1 were -published until 10 years later, in 2017. - -Git v2.13.0 and later subsequently moved to a hardened SHA-1 -implementation by default that mitigates the SHAttered attack, but -SHA-1 is still believed to be weak. - -The hash to replace this hardened SHA-1 should be stronger than SHA-1 -was: we would like it to be trustworthy and useful in practice for at -least 10 years. - -Some other relevant properties: - -1. A 256-bit hash (long enough to match common security practice; not - excessively long to hurt performance and disk usage). - -2. High quality implementations should be widely available (e.g., in - OpenSSL and Apple CommonCrypto). - -3. The hash function's properties should match Git's needs (e.g. Git - requires collision and 2nd preimage resistance and does not require - length extension resistance). - -4. As a tiebreaker, the hash should be fast to compute (fortunately - many contenders are faster than SHA-1). - -We choose SHA-256. - Transition plan --------------- Some initial steps can be implemented independently of one another: From patchwork Tue Feb 2 16:19:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Ackermann X-Patchwork-Id: 12062127 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A90EC433E0 for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65B0D64F77 for ; Tue, 2 Feb 2021 16:25:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233546AbhBBQZP (ORCPT ); Tue, 2 Feb 2021 11:25:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236307AbhBBQW4 (ORCPT ); Tue, 2 Feb 2021 11:22:56 -0500 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82A02C0611C2 for ; Tue, 2 Feb 2021 08:19:20 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id l12so1956962wmq.2 for ; Tue, 02 Feb 2021 08:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=OlGDqfHJfMcZpZUqydihqUUw8xk/hGiogY19dE95aKU=; b=deS8O8wUCDtm04d70IPvAIumkPa95qQWWy7b0xL60PtmnHQ6QHQXkIbIhZszusV0iN 2mS5+xgqlRDPEX5Y0iPeJft6KC4yWIX6FrND2PW2bm3s1Js23pmq+4f4mB9ilOs8+bgd +UrGqaG49paDuGRN/7ff/6iYlDWtqFN8LBBiFaSPfV2RruCCPTFvcNrrzi2GO8q6N4HT AdQUGy4bqZrod2WOXRBTLrgBF0Ascu4QfO4VtlhPt4CS6HeY60CEQ0qTU2FXkKEZjnE5 vr+6AAxbmxufRggxKJlvgNC6CWygLqL09/pv5Cc6Z5Ryhjy2y+zy9VQghkBLrji+fO66 DXZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=OlGDqfHJfMcZpZUqydihqUUw8xk/hGiogY19dE95aKU=; b=P8Q3Dhd83VvQc+WIu43Okhm6WcnxFtoHOIOnSrnRBrnn3Lmxn7ZBf2tg5/FLeKKm// re0sedpFHMP4pbINhWB0REhnsdV6nw+GKdxJuCQ3f7jGe9ej3moV0jjjjWRgE+l6gd3v r6AOQ1cUq0x8gAAnqYphIfsBJLLxnpgA9yHNs8Ixh1cJ3KhI3QvQ4fgCuhUCGUQ51Vrk RS0Srak0vorP56DxtePtHeRAagHrk61n4PI8tnmK5w/ZCWQwz0EP4UdJeRxi5S8fAwQ9 lDl3mxUOSCpH/M9gdFyhPsTWeXONbrrFS0wYD7bd3iGBVajZQ3UjQdX5QtyUBOthBQQa lu/Q== X-Gm-Message-State: AOAM531ZjytmBlXqJvdEu0o73yTS0CzK9qtvcHF7nef/E/7UvbhXQLYj AiQ7q4ASxHHsh4yOMGqUTZbFMKNE2sg= X-Google-Smtp-Source: ABdhPJyAPbqnrtnC1+4FelSfKht+OruFJhiLWdJgEkzp+7qhNOlRG+j5O4cRD/tDkdjNztRSuTcjKg== X-Received: by 2002:a1c:6384:: with SMTP id x126mr4418761wmb.52.1612282759080; Tue, 02 Feb 2021 08:19:19 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id l2sm3754245wmq.17.2021.02.02.08.19.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 08:19:18 -0800 (PST) Message-Id: In-Reply-To: References: Date: Tue, 02 Feb 2021 16:19:09 +0000 Subject: [PATCH v2 6/6] doc: use https links Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Junio C Hamano , =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Thomas Ackermann , Thomas Ackermann Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Thomas Ackermann From: Thomas Ackermann Use only https links for lore.kernel.org. Signed-off-by: Thomas Ackermann --- Documentation/technical/hash-function-transition.txt | 10 +++++----- t/t0021-conversion.sh | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 475f2f501a6..e7e6bd95ff9 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -759,7 +759,7 @@ Document History bmwill@google.com, jonathantanmy@google.com, jrnieder@gmail.com, sbeller@google.com -* Initial version sent to http://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com +* Initial version sent to https://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com 2017-03-03 jrnieder@gmail.com Incorporated suggestions from jonathantanmy and sbeller: @@ -801,8 +801,8 @@ Later history: References: - [1] http://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ - [2] http://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ - [3] http://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ - [4] http://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net + [1] https://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ + [2] https://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ + [3] https://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ + [4] https://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net [5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/ diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh index e4c4de5c745..e828ee964c1 100755 --- a/t/t0021-conversion.sh +++ b/t/t0021-conversion.sh @@ -34,7 +34,7 @@ filter_git () { # Compare two files and ensure that `clean` and `smudge` respectively are # called at least once if specified in the `expect` file. The actual # invocation count is not relevant because their number can vary. -# c.f. http://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ +# c.f. https://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ test_cmp_count () { expect=$1 actual=$2 @@ -49,7 +49,7 @@ test_cmp_count () { # Compare two files but exclude all `clean` invocations because Git can # call `clean` zero or more times. -# c.f. http://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ +# c.f. https://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ test_cmp_exclude_clean () { expect=$1 actual=$2