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: 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.