@matheusbsbs / matheus-bagliano / commits / 0ed8d8da37

doc hash-function-transition: pick SHA-256 as NewHash

From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256, K12, and so on are all believed to have similar security properties. All are good options from a security point of view. SHA-256 has a number of advantages: * It has been around for a while, is widely used, and is supported by just about every single crypto library (OpenSSL, mbedTLS, CryptoNG, SecureTransport, etc). * When you compare against SHA1DC, most vectorized SHA-256 implementations are indeed faster, even without acceleration. * If we're doing signatures with OpenPGP (or even, I suppose, CMS), we're going to be using SHA-2, so it doesn't make sense to have our security depend on two separate algorithms when either one of them alone could break the security when we could just depend on one. So SHA-256 it is. Update the hash-function-transition design doc to say so. After this patch, there are no remaining instances of the string "NewHash", except for an unrelated use from 2008 as a variable name in t/t9700/test.pl. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Dan Shumow <danshu@microsoft.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jonathan Nieder committed Aug 4, 2018 at 01:52 UTC 0ed8d8da374f648764758f13038ca93af87ab800

1 file changed +98 -98

Documentation/technical/hash-function-transition.txt

+98 -98

@@ -59,14 +59,11 @@ that are believed to be cryptographically secure.

60 Goals

61 -----

62 -Where NewHash is a strong 256-bit hash function to replace SHA-1 (see

63 -"Selection of a New Hash", below):

64 -

65 -1. The transition to NewHash can be done one local repository at a time.

62 +1. The transition to SHA-256 can be done one local repository at a time.

63 a. Requiring no action by any other party.

67 - b. A NewHash repository can communicate with SHA-1 Git servers

64 + b. A SHA-256 repository can communicate with SHA-1 Git servers

65 (push/fetch).

69 - c. Users can use SHA-1 and NewHash identifiers for objects

66 + c. Users can use SHA-1 and SHA-256 identifiers for objects

67 interchangeably (see "Object names on the command line", below).

68 d. New signed objects make use of a stronger hash function than

69 SHA-1 for their security guarantees.

@@ -79,7 +76,7 @@ Where NewHash is a strong 256-bit hash function to replace SHA-1 (see

77 Non-Goals

78 ---------

82 -1. Add NewHash support to Git protocol. This is valuable and the

79 +1. Add SHA-256 support to Git protocol. This is valuable and the

80 logical next step but it is out of scope for this initial design.

81 2. Transparently improving the security of existing SHA-1 signed

82 objects.

@@ -87,26 +84,26 @@ Non-Goals

84 repository.

85 4. Taking the opportunity to fix other bugs in Git's formats and

86 protocols.

90 -5. Shallow clones and fetches into a NewHash repository. (This will

91 - change when we add NewHash support to Git protocol.)

92 -6. Skip fetching some submodules of a project into a NewHash

93 - repository. (This also depends on NewHash support in Git

87 +5. Shallow clones and fetches into a SHA-256 repository. (This will

88 + change when we add SHA-256 support to Git protocol.)

89 +6. Skip fetching some submodules of a project into a SHA-256

90 + repository. (This also depends on SHA-256 support in Git

91 protocol.)

93 Overview

94 --------

95 We introduce a new repository format extension. Repositories with this

99 -extension enabled use NewHash instead of SHA-1 to name their objects.

96 +extension enabled use SHA-256 instead of SHA-1 to name their objects.

97 This affects both object names and object content --- both the names

98 of objects and all references to other objects within an object are

99 switched to the new hash function.

100

104 -NewHash repositories cannot be read by older versions of Git.

101 +SHA-256 repositories cannot be read by older versions of Git.

102

106 -Alongside the packfile, a NewHash repository stores a bidirectional

107 -mapping between NewHash and SHA-1 object names. The mapping is generated

103 +Alongside the packfile, a SHA-256 repository stores a bidirectional

104 +mapping between SHA-256 and SHA-1 object names. The mapping is generated

105 locally and can be verified using "git fsck". Object lookups use this

109 -mapping to allow naming objects using either their SHA-1 and NewHash names

106 +mapping to allow naming objects using either their SHA-1 and SHA-256 names

107 interchangeably.

108

109 "git cat-file" and "git hash-object" gain options to display an object

@@ -116,7 +113,7 @@ object database so that they can be named using the appropriate name

113 (using the bidirectional hash mapping).

114

115 Fetches from a SHA-1 based server convert the fetched objects into

119 -NewHash form and record the mapping in the bidirectional mapping table

116 +SHA-256 form and record the mapping in the bidirectional mapping table

117 (see below for details). Pushes to a SHA-1 based server convert the

118 objects being pushed into sha1 form so the server does not have to be

119 aware of the hash function the client is using.

@@ -125,19 +122,19 @@ Detailed Design

122 ---------------

123 Repository format extension

124 ~~~~~~~~~~~~~~~~~~~~~~~~~~~

128 -A NewHash repository uses repository format version `1` (see

125 +A SHA-256 repository uses repository format version `1` (see

126 Documentation/technical/repository-version.txt) with extensions

127 `objectFormat` and `compatObjectFormat`:

128

129 [core]

130 repositoryFormatVersion = 1

131 [extensions]

135 - objectFormat = newhash

132 + objectFormat = sha256

133 compatObjectFormat = sha1

134

135 The combination of setting `core.repositoryFormatVersion=1` and

136 populating `extensions.*` ensures that all versions of Git later than

140 -`v0.99.9l` will die instead of trying to operate on the NewHash

137 +`v0.99.9l` will die instead of trying to operate on the SHA-256

138 repository, instead producing an error message.

139

140 # Between v0.99.9l and v2.7.0

@@ -155,36 +152,36 @@ repository extensions.

152 Object names

153 ~~~~~~~~~~~~

154 Objects can be named by their 40 hexadecimal digit sha1-name or 64

158 -hexadecimal digit newhash-name, plus names derived from those (see

155 +hexadecimal digit sha256-name, plus names derived from those (see

156 gitrevisions(7)).

157

158 The sha1-name of an object is the SHA-1 of the concatenation of its

159 type, length, a nul byte, and the object's sha1-content. This is the

160 traditional <sha1> used in Git to name objects.

161

165 -The newhash-name of an object is the NewHash of the concatenation of its

166 -type, length, a nul byte, and the object's newhash-content.

162 +The sha256-name of an object is the SHA-256 of the concatenation of its

163 +type, length, a nul byte, and the object's sha256-content.

164

165 Object format

166 ~~~~~~~~~~~~~

167 The content as a byte sequence of a tag, commit, or tree object named

171 -by sha1 and newhash differ because an object named by newhash-name refers to

172 -other objects by their newhash-names and an object named by sha1-name

168 +by sha1 and sha256 differ because an object named by sha256-name refers to

169 +other objects by their sha256-names and an object named by sha1-name

170 refers to other objects by their sha1-names.

171

175 -The newhash-content of an object is the same as its sha1-content, except

176 -that objects referenced by the object are named using their newhash-names

172 +The sha256-content of an object is the same as its sha1-content, except

173 +that objects referenced by the object are named using their sha256-names

174 instead of sha1-names. Because a blob object does not refer to any

178 -other object, its sha1-content and newhash-content are the same.

175 +other object, its sha1-content and sha256-content are the same.

176

180 -The format allows round-trip conversion between newhash-content and

177 +The format allows round-trip conversion between sha256-content and

178 sha1-content.

179

180 Object storage

181 ~~~~~~~~~~~~~~

182 Loose objects use zlib compression and packed objects use the packed

183 format described in Documentation/technical/pack-format.txt, just like

187 -today. The content that is compressed and stored uses newhash-content

184 +today. The content that is compressed and stored uses sha256-content

185 instead of sha1-content.

186

187 Pack index

@@ -255,10 +252,10 @@ network byte order):

252 up to and not including the table of CRC32 values.

253 - Zero or more NUL bytes.

254 - The trailer consists of the following:

258 - - A copy of the 20-byte NewHash checksum at the end of the

255 + - A copy of the 20-byte SHA-256 checksum at the end of the

256 corresponding packfile.

257

261 - - 20-byte NewHash checksum of all of the above.

258 + - 20-byte SHA-256 checksum of all of the above.

259

260 Loose object index

261 ~~~~~~~~~~~~~~~~~~

@@ -266,7 +263,7 @@ A new file $GIT_OBJECT_DIR/loose-object-idx contains information about

263 all loose objects. Its format is

264

265 # loose-object-idx

269 - (newhash-name SP sha1-name LF)*

266 + (sha256-name SP sha1-name LF)*

267

268 where the object names are in hexadecimal format. The file is not

269 sorted.

@@ -292,8 +289,8 @@ To remove entries (e.g. in "git pack-refs" or "git-prune"):

289 Translation table

290 ~~~~~~~~~~~~~~~~~

291 The index files support a bidirectional mapping between sha1-names

295 -and newhash-names. The lookup proceeds similarly to ordinary object

296 -lookups. For example, to convert a sha1-name to a newhash-name:

292 +and sha256-names. The lookup proceeds similarly to ordinary object

293 +lookups. For example, to convert a sha1-name to a sha256-name:

294

295 1. Look for the object in idx files. If a match is present in the

296 idx's sorted list of truncated sha1-names, then:

@@ -301,8 +298,8 @@ lookups. For example, to convert a sha1-name to a newhash-name:

298 name order mapping.

299 b. Read the corresponding entry in the full sha1-name table to

300 verify we found the right object. If it is, then

304 - c. Read the corresponding entry in the full newhash-name table.

305 - That is the object's newhash-name.

301 + c. Read the corresponding entry in the full sha256-name table.

302 + That is the object's sha256-name.

303 2. Check for a loose object. Read lines from loose-object-idx until

304 we find a match.

305

@@ -318,25 +315,25 @@ for all objects in the object store.

315

316 Reading an object's sha1-content

317 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

321 -The sha1-content of an object can be read by converting all newhash-names

322 -its newhash-content references to sha1-names using the translation table.

318 +The sha1-content of an object can be read by converting all sha256-names

319 +its sha256-content references to sha1-names using the translation table.

320

321 Fetch

322 ~~~~~

323 Fetching from a SHA-1 based server requires translating between SHA-1

327 -and NewHash based representations on the fly.

324 +and SHA-256 based representations on the fly.

325

326 SHA-1s named in the ref advertisement that are present on the client

330 -can be translated to NewHash and looked up as local objects using the

327 +can be translated to SHA-256 and looked up as local objects using the

328 translation table.

329

330 Negotiation proceeds as today. Any "have"s generated locally are

331 converted to SHA-1 before being sent to the server, and SHA-1s

335 -mentioned by the server are converted to NewHash when looking them up

332 +mentioned by the server are converted to SHA-256 when looking them up

333 locally.

334

335 After negotiation, the server sends a packfile containing the

339 -requested objects. We convert the packfile to NewHash format using

336 +requested objects. We convert the packfile to SHA-256 format using

337 the following steps:

338

339 1. index-pack: inflate each object in the packfile and compute its

@@ -351,12 +348,12 @@ the following steps:

348 (This list only contains objects reachable from the "wants". If the

349 pack from the server contained additional extraneous objects, then

350 they will be discarded.)

354 -3. convert to newhash: open a new (newhash) packfile. Read the topologically

351 +3. convert to sha256: open a new (sha256) packfile. Read the topologically

352 sorted list just generated. For each object, inflate its

356 - sha1-content, convert to newhash-content, and write it to the newhash

357 - pack. Record the new sha1<->newhash mapping entry for use in the idx.

353 + sha1-content, convert to sha256-content, and write it to the sha256

354 + pack. Record the new sha1<->sha256 mapping entry for use in the idx.

355 4. sort: reorder entries in the new pack to match the order of objects

359 - in the pack the server generated and include blobs. Write a newhash idx

356 + in the pack the server generated and include blobs. Write a sha256 idx

357 file

358 5. clean up: remove the SHA-1 based pack file, index, and

359 topologically sorted list obtained from the server in steps 1

@@ -388,16 +385,16 @@ send-pack.

385

386 Signed Commits

387 ~~~~~~~~~~~~~~

391 -We add a new field "gpgsig-newhash" to the commit object format to allow

388 +We add a new field "gpgsig-sha256" to the commit object format to allow

389 signing commits without relying on SHA-1. It is similar to the

393 -existing "gpgsig" field. Its signed payload is the newhash-content of the

394 -commit object with any "gpgsig" and "gpgsig-newhash" fields removed.

390 +existing "gpgsig" field. Its signed payload is the sha256-content of the

391 +commit object with any "gpgsig" and "gpgsig-sha256" fields removed.

392

393 This means commits can be signed

394 1. using SHA-1 only, as in existing signed commit objects

398 -2. using both SHA-1 and NewHash, by using both gpgsig-newhash and gpgsig

395 +2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig

396 fields.

400 -3. using only NewHash, by only using the gpgsig-newhash field.

397 +3. using only SHA-256, by only using the gpgsig-sha256 field.

398

399 Old versions of "git verify-commit" can verify the gpgsig signature in

400 cases (1) and (2) without modifications and view case (3) as an

@@ -405,24 +402,24 @@ ordinary unsigned commit.

402

403 Signed Tags

404 ~~~~~~~~~~~

408 -We add a new field "gpgsig-newhash" to the tag object format to allow

405 +We add a new field "gpgsig-sha256" to the tag object format to allow

406 signing tags without relying on SHA-1. Its signed payload is the

410 -newhash-content of the tag with its gpgsig-newhash field and "-----BEGIN PGP

407 +sha256-content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP

408 SIGNATURE-----" delimited in-body signature removed.

409

410 This means tags can be signed

411 1. using SHA-1 only, as in existing signed tag objects

415 -2. using both SHA-1 and NewHash, by using gpgsig-newhash and an in-body

412 +2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body

413 signature.

417 -3. using only NewHash, by only using the gpgsig-newhash field.

414 +3. using only SHA-256, by only using the gpgsig-sha256 field.

415

416 Mergetag embedding

417 ~~~~~~~~~~~~~~~~~~

418 The mergetag field in the sha1-content of a commit contains the

419 sha1-content of a tag that was merged by that commit.

420

424 -The mergetag field in the newhash-content of the same commit contains the

425 -newhash-content of the same tag.

421 +The mergetag field in the sha256-content of the same commit contains the

422 +sha256-content of the same tag.

423

424 Submodules

425 ~~~~~~~~~~

@@ -497,7 +494,7 @@ Caveats

494 -------

495 Invalid objects

496 ~~~~~~~~~~~~~~~

500 -The conversion from sha1-content to newhash-content retains any

497 +The conversion from sha1-content to sha256-content retains any

498 brokenness in the original object (e.g., tree entry modes encoded with

499 leading 0, tree objects whose paths are not sorted correctly, and

500 commit objects without an author or committer). This is a deliberate

@@ -516,7 +513,7 @@ allow lifting this restriction.

513

514 Alternates

515 ~~~~~~~~~~

519 -For the same reason, a newhash repository cannot borrow objects from a

516 +For the same reason, a sha256 repository cannot borrow objects from a

517 sha1 repository using objects/info/alternates or

518 $GIT_ALTERNATE_OBJECT_REPOSITORIES.

519

@@ -524,20 +521,20 @@ git notes

521 ~~~~~~~~~

522 The "git notes" tool annotates objects using their sha1-name as key.

523 This design does not describe a way to migrate notes trees to use

527 -newhash-names. That migration is expected to happen separately (for

524 +sha256-names. That migration is expected to happen separately (for

525 example using a file at the root of the notes tree to describe which

526 hash it uses).

527

528 Server-side cost

529 ~~~~~~~~~~~~~~~~

533 -Until Git protocol gains NewHash support, using NewHash based storage

530 +Until Git protocol gains SHA-256 support, using SHA-256 based storage

531 on public-facing Git servers is strongly discouraged. Once Git

535 -protocol gains NewHash support, NewHash based servers are likely not

532 +protocol gains SHA-256 support, SHA-256 based servers are likely not

533 to support SHA-1 compatibility, to avoid what may be a very expensive

534 hash reencode during clone and to encourage peers to modernize.

535

536 The design described here allows fetches by SHA-1 clients of a

540 -personal NewHash repository because it's not much more difficult than

537 +personal SHA-256 repository because it's not much more difficult than

538 allowing pushes from that repository. This support needs to be guarded

539 by a configuration option --- servers like git.kernel.org that serve a

540 large number of clients would not be expected to bear that cost.

@@ -547,7 +544,7 @@ Meaning of signatures

544 The signed payload for signed commits and tags does not explicitly

545 name the hash used to identify objects. If some day Git adopts a new

546 hash function with the same length as the current SHA-1 (40

550 -hexadecimal digit) or NewHash (64 hexadecimal digit) objects then the

547 +hexadecimal digit) or SHA-256 (64 hexadecimal digit) objects then the

548 intent behind the PGP signed payload in an object signature is

549 unclear:

550

@@ -562,7 +559,7 @@ Does this mean Git v2.12.0 is the commit with sha1-name

559 e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with

560 new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7?

561

565 -Fortunately NewHash and SHA-1 have different lengths. If Git starts

562 +Fortunately SHA-256 and SHA-1 have different lengths. If Git starts

563 using another hash with the same length to name objects, then it will

564 need to change the format of signed payloads using that hash to

565 address this issue.

@@ -574,24 +571,24 @@ supports four different modes of operation:

571

572 1. ("dark launch") Treat object names input by the user as SHA-1 and

573 convert any object names written to output to SHA-1, but store

577 - objects using NewHash. This allows users to test the code with no

574 + objects using SHA-256. This allows users to test the code with no

575 visible behavior change except for performance. This allows

576 allows running even tests that assume the SHA-1 hash function, to

577 sanity-check the behavior of the new mode.

578

582 - 2. ("early transition") Allow both SHA-1 and NewHash object names in

579 + 2. ("early transition") Allow both SHA-1 and SHA-256 object names in

580 input. Any object names written to output use SHA-1. This allows

581 users to continue to make use of SHA-1 to communicate with peers

582 (e.g. by email) that have not migrated yet and prepares for mode 3.

583

587 - 3. ("late transition") Allow both SHA-1 and NewHash object names in

588 - input. Any object names written to output use NewHash. In this

584 + 3. ("late transition") Allow both SHA-1 and SHA-256 object names in

585 + input. Any object names written to output use SHA-256. In this

586 mode, users are using a more secure object naming method by

587 default. The disruption is minimal as long as most of their peers

588 are in mode 2 or mode 3.

589

590 4. ("post-transition") Treat object names input by the user as

594 - NewHash and write output using NewHash. This is safer than mode 3

591 + SHA-256 and write output using SHA-256. This is safer than mode 3

592 because there is less risk that input is incorrectly interpreted

593 using the wrong hash function.

594

@@ -601,27 +598,31 @@ The user can also explicitly specify which format to use for a

598 particular revision specifier and for output, overriding the mode. For

599 example:

600

604 -git --output-format=sha1 log abac87a^{sha1}..f787cac^{newhash}

601 +git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}

602

606 -Selection of a New Hash

607 ------------------------

603 +Choice of Hash

604 +--------------

605 In early 2005, around the time that Git was written, Xiaoyun Wang,

606 Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1

607 collisions in 2^69 operations. In August they published details.

608 Luckily, no practical demonstrations of a collision in full SHA-1 were

609 published until 10 years later, in 2017.

610

614 -The hash function NewHash to replace SHA-1 should be stronger than

615 -SHA-1 was: we would like it to be trustworthy and useful in practice

616 -for at least 10 years.

611 +Git v2.13.0 and later subsequently moved to a hardened SHA-1

612 +implementation by default that mitigates the SHAttered attack, but

613 +SHA-1 is still believed to be weak.

614 +

615 +The hash to replace this hardened SHA-1 should be stronger than SHA-1

616 +was: we would like it to be trustworthy and useful in practice for at

617 +least 10 years.

618

619 Some other relevant properties:

620

621 1. A 256-bit hash (long enough to match common security practice; not

622 excessively long to hurt performance and disk usage).

623

623 -2. High quality implementations should be widely available (e.g. in

624 - OpenSSL).

624 +2. High quality implementations should be widely available (e.g., in

625 + OpenSSL and Apple CommonCrypto).

626

627 3. The hash function's properties should match Git's needs (e.g. Git

628 requires collision and 2nd preimage resistance and does not require

@@ -630,14 +631,13 @@ Some other relevant properties:

631 4. As a tiebreaker, the hash should be fast to compute (fortunately

632 many contenders are faster than SHA-1).

633

633 -Some hashes under consideration are SHA-256, SHA-512/256, SHA-256x16,

634 -K12, and BLAKE2bp-256.

634 +We choose SHA-256.

635

636 Transition plan

637 ---------------

638 Some initial steps can be implemented independently of one another:

639 - adding a hash function API (vtable)

640 -- teaching fsck to tolerate the gpgsig-newhash field

640 +- teaching fsck to tolerate the gpgsig-sha256 field

641 - excluding gpgsig-* from the fields copied by "git commit --amend"

642 - annotating tests that depend on SHA-1 values with a SHA1 test

643 prerequisite

@@ -664,7 +664,7 @@ Next comes introduction of compatObjectFormat:

664 - adding appropriate index entries when adding a new object to the

665 object store

666 - --output-format option

667 -- ^{sha1} and ^{newhash} revision notation

667 +- ^{sha1} and ^{sha256} revision notation

668 - configuration to specify default input and output format (see

669 "Object names on the command line" above)

670

@@ -672,7 +672,7 @@ The next step is supporting fetches and pushes to SHA-1 repositories:

672 - allow pushes to a repository using the compat format

673 - generate a topologically sorted list of the SHA-1 names of fetched

674 objects

675 -- convert the fetched packfile to newhash format and generate an idx

675 +- convert the fetched packfile to sha256 format and generate an idx

676 file

677 - re-sort to match the order of objects in the fetched packfile

678

@@ -680,30 +680,30 @@ The infrastructure supporting fetch also allows converting an existing

680 repository. In converted repositories and new clones, end users can

681 gain support for the new hash function without any visible change in

682 behavior (see "dark launch" in the "Object names on the command line"

683 -section). In particular this allows users to verify NewHash signatures

683 +section). In particular this allows users to verify SHA-256 signatures

684 on objects in the repository, and it should ensure the transition code

685 is stable in production in preparation for using it more widely.

686

687 Over time projects would encourage their users to adopt the "early

688 transition" and then "late transition" modes to take advantage of the

689 -new, more futureproof NewHash object names.

689 +new, more futureproof SHA-256 object names.

690

691 When objectFormat and compatObjectFormat are both set, commands

692 -generating signatures would generate both SHA-1 and NewHash signatures

692 +generating signatures would generate both SHA-1 and SHA-256 signatures

693 by default to support both new and old users.

694

695 -In projects using NewHash heavily, users could be encouraged to adopt

695 +In projects using SHA-256 heavily, users could be encouraged to adopt

696 the "post-transition" mode to avoid accidentally making implicit use

697 of SHA-1 object names.

698

699 Once a critical mass of users have upgraded to a version of Git that

700 -can verify NewHash signatures and have converted their existing

700 +can verify SHA-256 signatures and have converted their existing

701 repositories to support verifying them, we can add support for a

702 -setting to generate only NewHash signatures. This is expected to be at

702 +setting to generate only SHA-256 signatures. This is expected to be at

703 least a year later.

704

705 That is also a good moment to advertise the ability to convert

706 -repositories to use NewHash only, stripping out all SHA-1 related

706 +repositories to use SHA-256 only, stripping out all SHA-1 related

707 metadata. This improves performance by eliminating translation

708 overhead and security by avoiding the possibility of accidentally

709 relying on the safety of SHA-1.

@@ -742,16 +742,16 @@ using the old hash function.

742

743 Signed objects with multiple hashes

744 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

745 -Instead of introducing the gpgsig-newhash field in commit and tag objects

746 -for newhash-content based signatures, an earlier version of this design

747 -added "hash newhash <newhash-name>" fields to strengthen the existing

745 +Instead of introducing the gpgsig-sha256 field in commit and tag objects

746 +for sha256-content based signatures, an earlier version of this design

747 +added "hash sha256 <sha256-name>" fields to strengthen the existing

748 sha1-content based signatures.

749

750 In other words, a single signature was used to attest to the object

751 content using both hash functions. This had some advantages:

752 * Using one signature instead of two speeds up the signing process.

753 * Having one signed payload with both hashes allows the signer to

754 - attest to the sha1-name and newhash-name referring to the same object.

754 + attest to the sha1-name and sha256-name referring to the same object.

755 * All users consume the same signature. Broken signatures are likely

756 to be detected quickly using current versions of git.

757

@@ -760,11 +760,11 @@ However, it also came with disadvantages:

760 objects it references, even after the transition is complete and

761 translation table is no longer needed for anything else. To support

762 this, the design added fields such as "hash sha1 tree <sha1-name>"

763 - and "hash sha1 parent <sha1-name>" to the newhash-content of a signed

763 + and "hash sha1 parent <sha1-name>" to the sha256-content of a signed

764 commit, complicating the conversion process.

765 * Allowing signed objects without a sha1 (for after the transition is

766 complete) complicated the design further, requiring a "nohash sha1"

767 - field to suppress including "hash sha1" fields in the newhash-content

767 + field to suppress including "hash sha1" fields in the sha256-content

768 and signed payload.

769

770 Lazily populated translation table

@@ -772,7 +772,7 @@ Lazily populated translation table

772 Some of the work of building the translation table could be deferred to

773 push time, but that would significantly complicate and slow down pushes.

774 Calculating the sha1-name at object creation time at the same time it is

775 -being streamed to disk and having its newhash-name calculated should be

775 +being streamed to disk and having its sha256-name calculated should be

776 an acceptable cost.

777

778 Document History