Point in case: 16.04 TLS is still on 2.7.4 but it is fully patched and secure.
Indeed if I check with "apt-get show git", the package is on version 2.11.0-2, and then I have to browse to the package web page at https://packages.ubuntu.com/zesty/git and click on the changelog and finally I get to the update information, which clearly contains the text, "SECURITY UPDATE: Arbitrary code execution on clients through malicious ssh URLs."
So it was patched as expected, it just wasn't easy for me to see that without going through a few extra steps.
/usr/share/doc/git/changelog.Debian.gz
It means that one group of developers is busy improving and fixing packages, and another different group is cherry-picking commits in order to maintain the illusion of stability (as mentioned above).
That second group has to duplicate all the testing work done by the first group, and additionally ensure that there are no new problems introduced.
It's very vulnerable to human error and adds a lot of unnecessary work.
The example you gave is specifically about a client application of git that wasn't updated to work with the current version of git - probably because of some twisted logic that they didn't have to worry about it until some future date.
Imagine you had a daily backup script that uses git to commit and push to a remote server perhaps managed by someone else. You then upgrade to the latest and greatest version of git to try to patch this vulnerability, and surprise, your backup script fails! Hope you weren't planning on spending the rest of the day getting the guys running the git server to implement a workaround, who might have already left for the weekend, leaving you with no backups or having to manually try to fix your git to work with that server again.
I see it differently. Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.
From the point of view of many server administrators, using the latest versions of everything is inherently risky. What they want to use is a stable, solid version that has all the latest security fixes.
It's unlikely that these opposing viewpoints will ever be reconciled.
Some cases will slip through sometimes, but over a couple of releases these should be gone.
>> Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.
Do you have stats for that?
Semantic versioning was supposed to be the fix for that, but as Rich Hickey has pointed out, that is also broken.
Everyone is their own server admin these days. We all want "a stable, solid version that has all the latest security fixes" but it's difficult accept that that might be impossible.
https://bugs.kde.org/show_bug.cgi?id=382911
it is a duplicate of
https://bugs.kde.org/show_bug.cgi?id=378854
which is fixed by https://cgit.kde.org/konversation.git/commit/?id=783dc0f595e...
but upstream for some reason does not think this is important enough to tag and bag into a release.
as much hate as Fedora gets, rdieter has taken the time to backport the changes that we need in Fedora.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c3e2138...
Ideally, we'd rather see upstream release this fix but we've all read https://news.ycombinator.com/item?id=14051106 and I don't want to be too impatient with software that upstream has graciously provided for free (in both senses of the word!)
I guess my point is backporting might make sense if there are small changes we can make to enhance release. However, I agree that there is too much duplication of effort going on.
And, I'm not too surprised, KDE has a broken development and maintenance process. I'm sure they think they're doing a great job - but that's because they don't even see or receive most bug reports.
KDE actually fixed the bug but it hasn't gone to a tagged release after two months. Maybe they think this small change doesn't warrant a release? I asked if KDE neon can pick it up but they (understandably) seem to see this as feature creep. KDE applications means something different for the neon folks (only the things they ship with neon from what I understand).
I agree. I have no doubt we are all trying to do our best. =)