git/Documentation/technical/hash-function-transition.txt, branch v2.30.2

docs: fix step in transition plan

2020-08-14T01:09:55Z

One of the required steps for the objectFormat extension is to implement the loose object index. However, without support for compatObjectFormat, we don't even know if the loose object index is needed, so it makes sense to move that step to the compatObjectFormat section. Do so. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'jk/lore-is-the-archive'

2019-12-06T23:09:23Z

Doc update for the mailing list archiving and nntp service. * jk/lore-is-the-archive: doc: replace public-inbox links with lore.kernel.org doc: recommend lore.kernel.org over public-inbox.org

doc: replace public-inbox links with lore.kernel.org

2019-11-30T17:12:26Z

Since we're now recommending lore.kernel.org (and because the public-inbox.org domain might eventually go away), let's update our internal references to use it, too. That future-proofs our references, and sets the example we want people to follow. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Documentation: fix a bunch of typos, both old and new

2019-11-07T04:42:00Z

Reported-by: Jens Schleusener Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

doc: fix repeated words

2019-08-12T00:40:07Z

Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran "git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases where words were duplicated, e.g. "the the", and in most cases removed one of the repeated words. There were many false positives by this grep command, including deliberate repeated words like "really really" or valid uses of "that that" which I left alone, of course. I also did not correct any of the legitimate, accidentally repeated words in old RelNotes. Signed-off-by: Mark Rushakoff Acked-by: Jeff King Signed-off-by: Junio C Hamano

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

2018-08-07T14:40:43Z

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 Acked-by: Linus Torvalds Acked-by: brian m. carlson Acked-by: Johannes Schindelin Acked-by: Dan Shumow Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

doc hash-function-transition: note the lack of a changelog

2018-07-25T21:29:55Z

The changelog embedded in the document pre-dates the addition of the document to git.git (it used to be a Google Doc), so it only goes up to 752414ae43 ("technical doc: add a design doc for hash function transition", 2017-09-27). Since then I made some small edits to it, which would have been worthy of including in this changelog (but weren't). Instead of amending it to include these, just note that future changes will be noted in the log. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

doc hash-function-transition: clarify what SHAttered means

2018-03-28T02:08:31Z

Attempt to clarify what the SHAttered attack means in practice for Git. The previous version of the text made no mention whatsoever of Git already having a mitigation for this specific attack, which the SHAttered researchers claim will detect cryptanalytic collision attacks. I may have gotten some of the nuances wrong, but as far as I know this new text accurately summarizes the current situation with SHA-1 in git. I.e. git doesn't really use SHA-1 anymore, it uses Hardened-SHA-1 (they just so happen to produce the same outputs 99.99999999999...% of the time). Thus the previous text was incorrect in asserting that: [...]As a result [of SHAttered], SHA-1 cannot be considered cryptographically secure any more[...] That's not the case. We have a mitigation against SHAttered, *however* we consider it prudent to move to work towards a NewHash should future vulnerabilities in either SHA-1 or Hardened-SHA-1 emerge. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

doc hash-function-transition: clarify how older gits die on NewHash

2018-03-28T02:07:51Z

Change the "Repository format extension" to accurately describe what happens with different versions of Git when they encounter NewHash repositories, instead of only saying what happens with versions v2.7.0 and later. See ab9cb76f66 ("Repository format version check.", 2005-11-25) and 00a09d57eb ("introduce "extensions" form of core.repositoryformatversion", 2015-06-23) for the relevant changes to the setup code where these variables are checked. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

technical doc: add a design doc for hash function transition

2017-09-28T10:37:52Z

This document describes what a transition to a new hash function for Git would look like. Add it to Documentation/technical/ as the plan of record so that future changes can be recorded as patches. Also-by: Brandon Williams Also-by: Jonathan Tan Also-by: Stefan Beller Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano