|This is the talk page for discussing improvements to the Git article.
This is not a forum for general discussion of the article's subject.
|This article is of interest to the following WikiProjects:|
Threads older than 90 days may be archived by .
Is git's usage of sha1 a problem / a security threat?
Thue proposed to state in the article that git's usage of sha1 "is a problem because SHA-1 is no longer considered secure" and that the source he mentioned "prominently mentioned Git as a possible target for attacks". I don't see how either is the case, especially in regards to his source. If you, Thue, or someone else thinks that the source you used or any other reliable source states this, please discuss it in this section. McGucket (talk) 16:57, 25 February 2017 (UTC)
- The linked PDF mentions Git in the very second paragraph? How is that not prominently saying the SHA-1 compromise could be a problem for Git? Thue (talk) 23:27, 25 February 2017 (UTC)
- It just says that sha1 despite being deprecated (Deprecated for what usage?) is used by git, not that git's usage of it constitutes a problem. A collision of sha1 having been found doesn't mean that git commit or object hashes will now randomly collide and cause problems or that it's even remotely feasible that someone deliberately finds another commit with the same hash as an existing commit. Note that finding a second preimage is much more difficult than finding a collision. McGucket (talk) 23:50, 25 February 2017 (UTC)
- Is there any reliable source which states that there is or anytime soon (up to 2050, maybe) will be a significant risk of a successful second-preimage attack? Quoting a mailing list message which states that "Linus is right, that's an impractical attack." or referring to a paper which found a hash collision (which is a completely different thing as there are literally many orders of magnitude between them, in most cases) doesn't exactly make that appear plausible. McGucket (talk) 18:13, 2 March 2017 (UTC)
- The following response from github seems to indicate that the SHA-1 collision attack can be thwarted - https://blog.github.com/2017-03-20-sha-1-collision-detection-on-github-com/ for collisions being used in the wild to infect others.
- Using SHA-1 for an SSL certificate would not meet best practice in security. However as a developer using SHA-1 as a way to hash an object and produce an almost unique name that is tightly related to the content of the object is not a security issue, but instead is a hashing issue which could cause issues in extreme cases (see github article) but this is true of any non-perfect hashing function (see http://interactivepython.org/runestone/static/pythonds/SortSearch/Hashing.html and https://en.wikipedia.org/wiki/Hash_function). I think the confusion comes in because the hashing function Linus Torvold chose for git was also a cryptography hash, but the purpose of a version control or file system is to share the content - so the source text is visible to all, so unlike a cryptography use where the hash obscures the content, in this case there is nothing being obscured. The article itself mentions this in passing in the security section.
- There are security issues with distributed version control systems, namely how does a user trust what is in a git repository (regardless of whether the user is getting the content from a clean or a corrupt deliberately SHA-1 collision exploited repository). Using software written by someone else requires trust - and unfortunately there are many ways for malicious actors to introduce malware into a source repository. A person using a distributed version control system to download and build software systems would need to inspect / validate that the software generated does not contain malware, I would imagine by running malware detection systems (which are limited and can only identify already known malware exploits). If I can find published articles about open source trust and validation I'll add a reference in the article's security section
The use of platform in the infobox
THe use of platoform attribute in the infobox seems uneeded and also misses a lot of platforms that git runs on and adding all of them would use to much space, I also see no need to state what Processor architectures git runs on. Also, loooking at the Articles of other simular software like GNU Bazaar, Mercurial and BitKeeper do not have the Platform attribute or any mention of what processor architectures the software runs on. --Ioangogo (talk) 11:23, 5 June 2018 (UTC)
I once put a link to an example of something in a WikiPedia article and it was called spam and removed. It was nothing I had any relationship with, I thought it was relevant to the article. Now GitHub is a commercial product, right? GitHub is separate from Git, correct? So why is GitHub in this article yet I can't do the same thing in other articles? I understand the relevance of GitHub to Git but rules are rules. GitHub is listed as a repository in the menu in the right side; that is quite an advertisement. GitHub is listed as a service but no where else in this article is it made clear that GitHub is a commercial product separate from Git. I don't have anything against GitHub; I only resent that my other contribution was called spam as emphatically as it was. Sam Tomato (talk) 20:47, 4 November 2018 (UTC)
Reasoning behind reverting go-git Git implementation edit
Hello everyone, I would like to understand the reasoning behind undoing the contribution of adding go-git implementation of Git in Go as well as the reason why it would be marked as "spam".
It is indeed one of the most popular implementations of Git as shown in the referred URLs, in one of the most popular computer languages nowadays, with many open source contributors from all around the world under different backgrounds. So there's no reason it should not be listed in this article.
If the issue is with one of the references rather than the content itself, let's discuss that specifically on how to improve or fix it, rather than just undoing the full contribution content without detail. Thank you. KDEWolf (talk) 13:49, 19 April 2019 (UTC)
- @KDEWolf: An external link in the article body is almost always considered spam. For details see the Wikipedia policy on external links at Wikipedia:External links. Statements like "one of the most popular open-source implementations of Git" are also usually spam/promotion. If there were multiple independent reliable sources with a reputation for fact checking that actually claim that then it would be acceptable, but a link to a misleading github search (obviously misleading since the primary git-scm.com implementation is not even listed) is not. See Wikipedia:Verifiability, Wikipedia:Reliable sources, and Wikipedia:No original research for further information on these policies. -LiberatorG (talk) 17:57, 19 April 2019 (UTC)
- @LiberatorG: Thanks for the prompt reply with very informative and actionable advice! Given that go-git is cited by the primary implementers at git-scm.com itself, would it be reasonable to:
- (1) remove the external link to the project's GitHub page and keep it plain text
- (2) remove the claim about its popularity: I understand that the primary implementation might be missing, but since libgit2 and Dulwich are listed in the article and are just above & below go-git, the idea was to show that it is popular/notable.
- (3) add the git-scm.com citation to introduce this implementation
- (4) fine tune the citation references to be more neutral
- The final result would be:
- In the end the two examples of usage that were provided to be more akin to the examples provided in the JGit paragraph, that mentions Gerrit, EGit and Ecplise. Also, the article in general has mentions to non-open-source or even commercial references, so I did not consider this a problem. I guess removing one or both of them would make the article edit poorer, but even more neutral.
- @LiberatorG: alright, thanks again for the tip. With this last fix the final result is: