6 ms·

Just a note for everyone on Ubuntu, the fixed version for Ubuntu 16.04 is git v2.7.4-0ubuntu1.2 [0]. [0]: https://people.canonical.com/~ubuntu-security/cve/201

Just a note for everyone on Ubuntu, the fixed version for Ubuntu 16.04 is git v2.7.4-0ubuntu1.2 [0]. [0]: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-1000117.html https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...

lotsoflumens 9y ago
Does anybody understand Ubuntu releases? The update this morning for Ubuntu 17.04 installs git 2.11.0 .. NOT the patched 2.11.3 NOR the latest 2.14.1 Why isn't Ubuntu fully up to date?
- radarsat1 9y ago
  Came here to ask the same thing, running 17.04. I just did an update && dist-upgrade, still have git-2.11.0. Edit: The package is actually 2.11.0-2 which contains the security patch.
  - pawadu 9y ago
    This question is brought up every time this happens. Ubuntu uses stable (old) versions and does not upgrade to latest (unstable) releases very often. However, they do back port and apply security patches to these old versions. Point in case: 16.04 TLS is still on 2.7.4 but it is fully patched and secure.
    - lotsoflumens 9y ago
      This practice is seriously bad. 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.
      - 0x0 9y ago
        It's better to have a competent "second group" do the backport job rather than every single user of a distro having their rug pulled out under them every time they patch. New versions of software can quickly break your environment. For example, https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 . If you have to re-test every script and web service to ensure compatibility with the daily churn of vulnerability fixes you would get nothing done and you could almost never be sure your service is stable.
        lotsoflumens 9y ago
        I agree, this is a problem, but it's not being solved by this practice. 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.
        0x0 9y ago
        It's an example of how things break if you upgrade to new versions of software. If you avoid going to new versions of software, and instead just backport the essential security fixes, there will be much fewer surprises like this. 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.
        lotsoflumens 9y ago
        Well then, I guess with that line of reasoning we should just turn off the computers and go live in the woods. There's obviously too much risk in doing anything.
    - radarsat1 9y ago
      Yes, you're right. I was expecting to see the update by checking "git --version" and seeing 2.11.0-1 or something like that, but it's not visible that way. 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 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.
      - masterleep 9y ago
        Try "apt changelog git" on the box.
        eikenberry 9y ago
        Or you can read the changelog on the filesystem at... /usr/share/doc/git/changelog.Debian.gz
- CiPHPerCoder 9y ago
  They backport patches and lie about the version number, to maintain the illusion of stability. It really pisses off the PHP community. https://github.com/ircmaxell/password_compat/issues/90 https://github.com/ircmaxell/password_compat/issues/90
  - cperciva 9y ago
    I can't speak for Ubuntu, but when I was FreeBSD Security Officer we would regularly backport patches because importing an entire new release would regularly break existing functionality or even add new security vulnerabilities. It annoyed the heck out of vulnerability scanning tools, but I decided that giving users a system which didn't randomly break when they applied security patches was far more important.
    - CiPHPerCoder 9y ago
      That was years ago, IIRC. PHP has gotten better about "no BC breaks in patch versions" over the years, but the Debian/Ubuntu teams still insist on making people effectively run e.g. 7.1.8 while the version indicator says 7.1.1. It makes feature detection a nightmare.
      - rlpb 9y ago
        Ubuntu developer here. Huh? No, we don't. Can you provide a more specific and current example to make sure I don't misunderstand you? For example, the current package for Ubuntu 16.04 LTS is 7.0.22-0ubuntu0.16.04.1. How does this mismatch 7.0.22 from the PHP upstream project?
        CiPHPerCoder 9y ago
        Okay, maybe Ubuntu stopped being stupid and only Debian is still guilty of this? This used to be a huge problem. I've since convinced [most PHP devs I talk to] to stop using distro-provided packages, in favor of deb.sury.org.
- piquadrat 9y ago
  The version is actually 2.11.0-2ubuntu0.2, with the fix backported, as can be seen in the changelog: http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.11.0-2ubuntu0.2/changelog http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_... It's somewhat confusing if you run `git --version` and it reports back 2.11.0, despite being fully patched against this vulnerability.
  - lotsoflumens 9y ago
    Thanks for the info! I've added the git-core PPA now which installs 2.14.1 . I just don't understand this screwing with version numbers and not being on the latest code.
    - richardwhiuk 9y ago
      The point of having stables releases is that you have a consistent set of versions of packages including git, otherwise how is it stable?
      - lotsoflumens 9y ago
        Yes, it makes a lot of sense to ignore the real world and pretend that software will always be stable.
        0x0 9y ago
        Why don't you just run Debian Sid then? You'll get new packages every day and get all the fun of chasing changing features all the time :D
- 0x0 9y ago
  Almost all linux distros that use the concept of a "release" will stay on the version numbers they originally released for. Security fixes are backported but no other functionality is imported, thereby keeping the feature set fixed to the version numbers in the original release. If you are maintaining or developing any kind of server and services where you need an uptime guarantee above 0%, you will appreciate this. Otherwise you will need staff on standby 24/7 being ready to develop fixes for breaking backwards compatibility changes. Imagine if you had to deal with funky errors like these every minute of the day - https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 For Ubuntu, you should follow their "usn" security notices and you would stay informed: https://usn.ubuntu.com/usn/ https://usn.ubuntu.com/usn/ For Debian, likewise there is a "debian-security-announce" mailing list https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/ Also for Debian, you can check up on the status for known vulnerabilities on their security tracker. For example, for this particular git exploit, you could look up https://security-tracker.debian.org/tracker/CVE-2017-8386 https://security-tracker.debian.org/tracker/CVE-2017-8386

lotsoflumens 9y ago

Does anybody understand Ubuntu releases? The update this morning for Ubuntu 17.04 installs git 2.11.0 .. NOT the patched 2.11.3 NOR the latest 2.14.1 Why isn't Ubuntu fully up to date?

radarsat1 9y ago
Came here to ask the same thing, running 17.04. I just did an update && dist-upgrade, still have git-2.11.0. Edit: The package is actually 2.11.0-2 which contains the security patch.
- pawadu 9y ago
  This question is brought up every time this happens. Ubuntu uses stable (old) versions and does not upgrade to latest (unstable) releases very often. However, they do back port and apply security patches to these old versions. Point in case: 16.04 TLS is still on 2.7.4 but it is fully patched and secure.
  - lotsoflumens 9y ago
    This practice is seriously bad. 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.
    - 0x0 9y ago
      It's better to have a competent "second group" do the backport job rather than every single user of a distro having their rug pulled out under them every time they patch. New versions of software can quickly break your environment. For example, https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 . If you have to re-test every script and web service to ensure compatibility with the daily churn of vulnerability fixes you would get nothing done and you could almost never be sure your service is stable.
      - lotsoflumens 9y ago
        I agree, this is a problem, but it's not being solved by this practice. 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.
        0x0 9y ago
        It's an example of how things break if you upgrade to new versions of software. If you avoid going to new versions of software, and instead just backport the essential security fixes, there will be much fewer surprises like this. 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.
        lotsoflumens 9y ago
        Well then, I guess with that line of reasoning we should just turn off the computers and go live in the woods. There's obviously too much risk in doing anything.
  - radarsat1 9y ago
    Yes, you're right. I was expecting to see the update by checking "git --version" and seeing 2.11.0-1 or something like that, but it's not visible that way. 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 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.
    - masterleep 9y ago
      Try "apt changelog git" on the box.
      - eikenberry 9y ago
        Or you can read the changelog on the filesystem at... /usr/share/doc/git/changelog.Debian.gz
CiPHPerCoder 9y ago
They backport patches and lie about the version number, to maintain the illusion of stability. It really pisses off the PHP community. https://github.com/ircmaxell/password_compat/issues/90 https://github.com/ircmaxell/password_compat/issues/90
- cperciva 9y ago
  I can't speak for Ubuntu, but when I was FreeBSD Security Officer we would regularly backport patches because importing an entire new release would regularly break existing functionality or even add new security vulnerabilities. It annoyed the heck out of vulnerability scanning tools, but I decided that giving users a system which didn't randomly break when they applied security patches was far more important.
  - CiPHPerCoder 9y ago
    That was years ago, IIRC. PHP has gotten better about "no BC breaks in patch versions" over the years, but the Debian/Ubuntu teams still insist on making people effectively run e.g. 7.1.8 while the version indicator says 7.1.1. It makes feature detection a nightmare.
    - rlpb 9y ago
      Ubuntu developer here. Huh? No, we don't. Can you provide a more specific and current example to make sure I don't misunderstand you? For example, the current package for Ubuntu 16.04 LTS is 7.0.22-0ubuntu0.16.04.1. How does this mismatch 7.0.22 from the PHP upstream project?
      - CiPHPerCoder 9y ago
        Okay, maybe Ubuntu stopped being stupid and only Debian is still guilty of this? This used to be a huge problem. I've since convinced [most PHP devs I talk to] to stop using distro-provided packages, in favor of deb.sury.org.
piquadrat 9y ago
The version is actually 2.11.0-2ubuntu0.2, with the fix backported, as can be seen in the changelog: http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.11.0-2ubuntu0.2/changelog http://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_... It's somewhat confusing if you run `git --version` and it reports back 2.11.0, despite being fully patched against this vulnerability.
- lotsoflumens 9y ago
  Thanks for the info! I've added the git-core PPA now which installs 2.14.1 . I just don't understand this screwing with version numbers and not being on the latest code.
  - richardwhiuk 9y ago
    The point of having stables releases is that you have a consistent set of versions of packages including git, otherwise how is it stable?
    - lotsoflumens 9y ago
      Yes, it makes a lot of sense to ignore the real world and pretend that software will always be stable.
      - 0x0 9y ago
        Why don't you just run Debian Sid then? You'll get new packages every day and get all the fun of chasing changing features all the time :D
0x0 9y ago
Almost all linux distros that use the concept of a "release" will stay on the version numbers they originally released for. Security fixes are backported but no other functionality is imported, thereby keeping the feature set fixed to the version numbers in the original release. If you are maintaining or developing any kind of server and services where you need an uptime guarantee above 0%, you will appreciate this. Otherwise you will need staff on standby 24/7 being ready to develop fixes for breaking backwards compatibility changes. Imagine if you had to deal with funky errors like these every minute of the day - https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 For Ubuntu, you should follow their "usn" security notices and you would stay informed: https://usn.ubuntu.com/usn/ https://usn.ubuntu.com/usn/ For Debian, likewise there is a "debian-security-announce" mailing list https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/ Also for Debian, you can check up on the status for known vulnerabilities on their security tracker. For example, for this particular git exploit, you could look up https://security-tracker.debian.org/tracker/CVE-2017-8386 https://security-tracker.debian.org/tracker/CVE-2017-8386