3 ms·

> I get that they were written before git, but not before the advent of version control. git clone https://git.savannah.gnu.org/git/bash.git git clone http

> I get that they were written before git, but not before the advent of version control. git clone https://git.savannah.gnu.org/git/bash.git git clone https://git.savannah.gnu.org/git/coreutils.git Plug the repo name into https://savannah.gnu.org/git/?group=<REPO_NAME> to get a link to browse the repo.

kryptiskt 1y ago
Look at the commit log in the bash repo. What good does it do if it notionally is version controlled if the commits look like this: 2025-07-03 Bash-5.3 distribution sources and documentation bash-5.3 Chet Ramey 896 -103357/+174007
- simoncion 1y ago
  That looks to be the headline for the public release commit. If you'd bothered to look around for a full sixty seconds, you'd have found that the commits tagged with bash-5.3 and bash-5.2 follow that format. Here are the headlines for a couple of fix commits: Bash-5.2 patch 12: fixes for compat mode leaving extglob enabled after command substitution Bash-5.2 patch 1: fix crash with unset arrays in arithmetic contexts It looks like discussion of the patches happens on the mailing list, which is easy to access from the page that brought you to the repo browser.
- oivey 1y ago
  Ahh yes, if only the commit message was better. That would have stopped the xz attack.
  - rcxdude 1y ago
    It's not just the commit message, but the fact that it's a single commit with >100k lines changed (though, if that's just a merge commit, it might be not super unusual for that kind of workflow. Though big merge commits are a good place to hide things in git, given that they can introduce their own changes)
    - simoncion 1y ago
      > It's not just the commit message, but the fact that it's a single commit with >100k lines changed When you diff the `bash-5.3` tag against the `bash-5.3-rc2` tag, the set of changes is reduced by a ton. It's the same story with previous release commits (at least for as far as I care to go back)... there's a "next version" branch that gets tagged with alpha, beta, and rc releases, and then there's a release commit that's made on master with the changes from the "next version" branch, plus some additional changes. Why do they do things this way? I have no idea, but it clearly seems to work for them.
      - yencabulator 1y ago
        Because historically, what's in a release tarball is not what's in the repository. In many cases, the release tarball of an old C/autoconf project has "half-built". Debian has always worked from the release tarballs, and thus if you "just" import Debian packaging into a VCS, you don't necessarily track every upstream commit, just the releases. (Independently importing release tarballs into VCS also worked better in the era of a dozen competing VCSes, without reliable export-import pipelines.)
        simoncion 1y ago
        I think you're either confused, or have attached your comment to the wrong parent? My observations and questions were about the GNU bash git repo and how (and why) the bash maintainers do release branching and tagging. They were not about how the Debian folks handle their packaging.
        yencabulator 1y ago
        Oh yeah. The thread before that talked about Debian packaging.
ottoke 1y ago
This is the upstream source control. The article talks about the Debian packaging source not being in git (on e.g. salsa.debian.org).
- simoncion 1y ago
  Eh, I didn't bother to read TFA. So, it was ambiguous as to whether OP was talking about the projects or Debian's packages of the same. I figured it was more likely that OP was talking about the projects and proceeded accordingly. If that quote's about keeping Debian packaging in source control, I don't really see much benefit for packages like coreutils and bash that generally Just Work(TM) because they're high-quality and well-tested. Sign what you package up so you can detect tampering, but I don't see you really needing anything else.

kryptiskt 1y ago

Look at the commit log in the bash repo. What good does it do if it notionally is version controlled if the commits look like this: 2025-07-03 Bash-5.3 distribution sources and documentation bash-5.3 Chet Ramey 896 -103357/+174007

simoncion 1y ago
That looks to be the headline for the public release commit. If you'd bothered to look around for a full sixty seconds, you'd have found that the commits tagged with bash-5.3 and bash-5.2 follow that format. Here are the headlines for a couple of fix commits: Bash-5.2 patch 12: fixes for compat mode leaving extglob enabled after command substitution Bash-5.2 patch 1: fix crash with unset arrays in arithmetic contexts It looks like discussion of the patches happens on the mailing list, which is easy to access from the page that brought you to the repo browser.
oivey 1y ago
Ahh yes, if only the commit message was better. That would have stopped the xz attack.
- rcxdude 1y ago
  It's not just the commit message, but the fact that it's a single commit with >100k lines changed (though, if that's just a merge commit, it might be not super unusual for that kind of workflow. Though big merge commits are a good place to hide things in git, given that they can introduce their own changes)
  - simoncion 1y ago
    > It's not just the commit message, but the fact that it's a single commit with >100k lines changed When you diff the `bash-5.3` tag against the `bash-5.3-rc2` tag, the set of changes is reduced by a ton. It's the same story with previous release commits (at least for as far as I care to go back)... there's a "next version" branch that gets tagged with alpha, beta, and rc releases, and then there's a release commit that's made on master with the changes from the "next version" branch, plus some additional changes. Why do they do things this way? I have no idea, but it clearly seems to work for them.
    - yencabulator 1y ago
      Because historically, what's in a release tarball is not what's in the repository. In many cases, the release tarball of an old C/autoconf project has "half-built". Debian has always worked from the release tarballs, and thus if you "just" import Debian packaging into a VCS, you don't necessarily track every upstream commit, just the releases. (Independently importing release tarballs into VCS also worked better in the era of a dozen competing VCSes, without reliable export-import pipelines.)
      - simoncion 1y ago
        I think you're either confused, or have attached your comment to the wrong parent? My observations and questions were about the GNU bash git repo and how (and why) the bash maintainers do release branching and tagging. They were not about how the Debian folks handle their packaging.
        yencabulator 1y ago
        Oh yeah. The thread before that talked about Debian packaging.

ottoke 1y ago

This is the upstream source control. The article talks about the Debian packaging source not being in git (on e.g. salsa.debian.org).

simoncion 1y ago
Eh, I didn't bother to read TFA. So, it was ambiguous as to whether OP was talking about the projects or Debian's packages of the same. I figured it was more likely that OP was talking about the projects and proceeded accordingly. If that quote's about keeping Debian packaging in source control, I don't really see much benefit for packages like coreutils and bash that generally Just Work(TM) because they're high-quality and well-tested. Sign what you package up so you can detect tampering, but I don't see you really needing anything else.