SoylentNews is people
SoylentNews
The open source Git project has just released Git 2.13.0, with features and bugfixes from over 65 contributors. Before we dig into the new features, we have a brief security announcement.
For those running their own Git hosting server, Git 2.13 fixes a vulnerability in the git shell program in which an untrusted Git user can potentially run shell commands on a remote host. This only affects you if you're running a hosting server and have specifically configured git shell. If none of that makes sense to you, you're probably fine. See this announcement for more details. As neither GitHub.com nor GitHub Enterprise uses git shell, both are unaffected.
Phew. With that out of the way, let's get on to the fun stuff.
[...] You may have heard that researchers recently found the first collision in SHA-1, the hash function Git uses to identify objects. Their techniques may eventually be used to conduct collision-based attacks against Git users. Fortunately those same researchers also provided a way to detect content that is trying to exploit this technique to create collisions. In March, GitHub.com began using that implementation to prevent it being used as a potential platform for conducting collision attacks.
Git 2.13 ships with similar changes, and will detect and reject any objects that show signs of being part of a collision attack. The collision-detecting SHA-1 implementation is now the default. The code is included with Git, so there's no need to install any additional dependencies. Note that this implementation is slower than the alternatives, but in practice this has a negligible effect on the overall time of most Git operations (because Git spends only a small portion of its time computing SHA-1 hashes in the first place).
In other collision detection news, efforts have continued to develop a transition plan and to prepare the code base for handling new hash functions, which will eventually allow the use of stronger hash algorithms in Git.
What version of git, if any, are you running?
(Score: -1, Troll) by Anonymous Coward on Thursday May 11 2017, @04:04PM (8 children)
"GIT", the overly complex CM system created by hipster dufuses.
(Score: 0) by Anonymous Coward on Thursday May 11 2017, @04:15PM
Hey, fuck you, Git Torvalds is GenX.
(Score: 4, Funny) by ikanreed on Thursday May 11 2017, @04:39PM
You're right, of course, we should all go back to SVN and let every tree conflict be the cause of 1 to 3 suicides.
(Score: 3, Insightful) by mth on Thursday May 11 2017, @04:41PM (3 children)
Git is complex, but is it overly complex? I don't know of any other CM system that can handle projects with the number of contributors of the Linux kernel and is significantly easier to use. I've heard people say Mercurial is easier to learn, but it's not all that different from Git in my opinion.
You could argue Git is unnecessarily complex for small-scale projects, which is true if you'd have to learn Git for that purpose. But if you already know Git, it's easier to use that also for simple projects than to learn a second tool.
(Score: 3, Informative) by Anonymous Coward on Thursday May 11 2017, @04:51PM
Git is absolutely fantastic for because now when I want to contribute to an open source project I don't need to diff a patch and mail it to a list where my patch will be summarily ignored. Instead I can open a pull request on Github where my pull request will be summarily ignored. Git makes the completely nonexistent community so much better at ignoring contributors!
(Score: -1, Troll) by Anonymous Coward on Thursday May 11 2017, @09:49PM
(Score: 3, Interesting) by MadTinfoilHatter on Friday May 12 2017, @07:55AM
I've heard people say Mercurial is easier to learn, but it's not all that different from Git in my opinion.
In my opinion git is easily the best version control system currently out there. I've done backend development and low level support for a Big Corporation's(tm) version control system which supported git, mercurial and svn. Git caused by far the least headaches, despite that ~70% of the repositories were git, (about 20% svn and 10% hg) Mercurial OTOH was a constant PITA. It had all kinds of weird version compatibility issues, performance issues (both network and system resources) and issues that just made it difficult to work with.
One issue I remember in particular was that for some time we coudn't get mercurial to work over ssh for users who had read-only-privileges. The reason was that mercurial doesn't tell anything about what it intends to do prior to doing it when talking to the server. The suggestion for solving the problem that mercurial had was to let the client do whatever it wanted to, but then have a post-commit-hook (mercurial called it something else, but functionally the same thing) check what the operation was, and roll it back if it was a write operation. :-/ I had to write a small wrapper program that placed itself between the client and the mercurial process, doing a "MITM" of sorts on the mercurial protocol. If any write operations were attempted it would throw an error message and kill the connection.
TL;DR: From a sysadmin's point of view mercurial is a toy version of git.
(Score: 2) by SDRefugee on Thursday May 11 2017, @08:38PM
Bet you don't have the balls to call Linus a "hipster dufus" and NOT hide as an AC...
America should be proud of Edward Snowden, the hero, whether they know it or not..
(Score: 2) by Wootery on Friday May 12 2017, @08:12AM
Come on now, you can't get a respectable version-control flame-war going unless you name your preferred alternative.