| Message ID | 20230217180402.29401-1-code@greghogan.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#61583] gnu: git: Update to 2.39.2 [fixes CVE-2023-22490 & CVE-2023-23946]. | expand |
Hi,
On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote:
> * gnu/packages/version-control.scm (git): Update to 2.39.2.
As noticed previously for an update of Git, this implies a lot of
rebuilds because git-minimal inherits from git.
Well, I am checking if git-minimal is used only for the tests by some of
the packages.
For sure, it is a concern since it is a security fixes.
Cheers,
simon
Hi, CC: core team On Mon, 20 Feb 2023 at 12:44, Simon Tournier <zimon.toutoune@gmail.com> wrote: > On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote: >> * gnu/packages/version-control.scm (git): Update to 2.39.2. > > As noticed previously for an update of Git, this implies a lot of > rebuilds because git-minimal inherits from git. Well, I locally rebuilt all and maybe a couple of packages break. The rebuild is intensive and I do not know if such update should to master or core-updates and/or use some grafts. For instance, QA is still saying nothing after 12 days. https://qa.guix.gnu.org/issue/61583 > Well, I am checking if git-minimal is used only for the tests by some of > the packages. I have tried to replace the plain ’git’ or ’git-minimal’ by ’git-minimal/pinned’ for some packages. It does not change much. > For sure, it is a concern since it is a security fixes. Hum, we are not very reactive. :-) Cheers, simon
Hi, I'd ask ‘why can we not simply graft this’ but… Simon Tournier 写道： >> As noticed previously for an update of Git, this implies a lot >> of >> rebuilds because git-minimal inherits from git. > > Well, I locally rebuilt all and maybe a couple of packages > break. The > rebuild is intensive and I do not know if such update should to > master > or core-updates and/or use some grafts. Packages that built with .1 break with .2? That's not a very semantic versioning :-/ What broke? Then I can test just those. Kind regards, T G-R
On Mon, Feb 20, 2023 at 12:44:23PM +0100, Simon Tournier wrote: > On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote: > > * gnu/packages/version-control.scm (git): Update to 2.39.2. > > As noticed previously for an update of Git, this implies a lot of > rebuilds because git-minimal inherits from git. ------ $ guix refresh -l git-minimal Building the following 43 packages would ensure 69 dependent packages are rebuilt: r-biocpkgtools@1.16.0 r-biocthis@1.8.1 r-biocworkflowtools@1.24.0 r-golem@0.3.5 r-megadepth@1.8.0 r-chromunity@0.0.1-1.09fce8b r-rnaseqdtu@2.0-1.5bee1e7 r-spectre@0.5.5-1.f6648ab r-battenberg@2.2.9 r-chemometricswithr@0.1.13 r-adapr@2.0.0 r-activpal@0.1.3 rust-git2-6@0.6.11 rust-git2@0.15.0 rust-git2@0.13.24 rust-git2@0.11.0 rust-git2@0.14.4 rust-git2@0.9.1 emacs-libgit@0.0.1-1.ab1a53a nuspell@3.1.2 kicad-doc@7.0.0 musescore@4.0.1 python-oslosphinx@4.18.0 conan@1.50.0 python-jupytext@1.14.1 snakemake@7.7.0 vorta@0.8.7 clipper@2.0.1 gnome@42.4 mate@1.24.1 r-prereg@0.6.0 python-ipython-documentation@8.2.0 python-numpy-documentation@1.21.6 nototools@0.2.16 python-clorm@1.4.1 python-telingo@2.1.1 python-screenkey@1.4 mbed-tools@7.53.0 snakemake@6.15.5 emacs-ghq@0.1.2 pre-commit@2.20.0 gitless@0.8.8 vlang@0.2.4 ------ That's not a significant number of packages. Overall, git and git-minimal will cause more than 300 rebuilds, but not too many for the current state of the build farm. Concretely, why can't we push this to master immediately?
Hi Simon, Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi, > > CC: core team > > On Mon, 20 Feb 2023 at 12:44, Simon Tournier <zimon.toutoune@gmail.com> wrote: > >> On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote: > >>> * gnu/packages/version-control.scm (git): Update to 2.39.2. >> >> As noticed previously for an update of Git, this implies a lot of >> rebuilds because git-minimal inherits from git. > > Well, I locally rebuilt all and maybe a couple of packages break. The > rebuild is intensive and I do not know if such update should to master > or core-updates and/or use some grafts. > > For instance, QA is still saying nothing after 12 days. > > https://qa.guix.gnu.org/issue/61583 > > >> Well, I am checking if git-minimal is used only for the tests by some of >> the packages. > > I have tried to replace the plain ’git’ or ’git-minimal’ by > ’git-minimal/pinned’ for some packages. It does not change much. > > >> For sure, it is a concern since it is a security fixes. > > Hum, we are not very reactive. :-) I think the number of rebuilt packages is in the thousands, so that's a core-updates change. On master it should be grafted instead, if that's possible.
On Fri, Mar 3, 2023, at 22:39, Maxim Cournoyer wrote: > Hi Simon, > > Simon Tournier <zimon.toutoune@gmail.com> writes: > >> Hi, >> >> CC: core team >> >> On Mon, 20 Feb 2023 at 12:44, Simon Tournier <zimon.toutoune@gmail.com> wrote: >> >>> On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote: >> >>>> * gnu/packages/version-control.scm (git): Update to 2.39.2. >>> >>> As noticed previously for an update of Git, this implies a lot of >>> rebuilds because git-minimal inherits from git. >> >> Well, I locally rebuilt all and maybe a couple of packages break. The >> rebuild is intensive and I do not know if such update should to master >> or core-updates and/or use some grafts. >> >> For instance, QA is still saying nothing after 12 days. >> >> https://qa.guix.gnu.org/issue/61583 >> >> >>> Well, I am checking if git-minimal is used only for the tests by some of >>> the packages. >> >> I have tried to replace the plain ’git’ or ’git-minimal’ by >> ’git-minimal/pinned’ for some packages. It does not change much. >> >> >>> For sure, it is a concern since it is a security fixes. >> >> Hum, we are not very reactive. :-) > > I think the number of rebuilt packages is in the thousands, so that's a > core-updates change. On master it should be grafted instead, if that's > possible. `guix refresh -l git git-minimal` shows only hundreds of rebuilds. Am I missing something?
Hi Leo, Leo Famulari <leo@famulari.name> writes: > That's not a significant number of packages. > > Overall, git and git-minimal will cause more than 300 rebuilds, but not > too many for the current state of the build farm. > > Concretely, why can't we push this to master immediately? `guix refresh` is not great for core packages: it only detects things that depend on other packages through inputs. Here though, git is used indirectly by git-fetch origins, and would affect the dependency graph a lot more. I think this should be grafted to avoid too many rebuilds, and ungrafted on core-updates (maybe now, maybe after the big core-updates merge). Best,
On Sat, Mar 4, 2023, at 05:30, Josselin Poiret wrote: > Hi Leo, > > Leo Famulari <leo@famulari.name> writes: > >> That's not a significant number of packages. >> >> Overall, git and git-minimal will cause more than 300 rebuilds, but not >> too many for the current state of the build farm. >> >> Concretely, why can't we push this to master immediately? > > `guix refresh` is not great for core packages: it only detects things > that depend on other packages through inputs. Here though, git is used > indirectly by git-fetch origins, and would affect the dependency graph a > lot more. I think this should be grafted to avoid too many rebuilds, > and ungrafted on core-updates (maybe now, maybe after the big > core-updates merge). Changing the Git package shouldn't affect fixed-output derivations that fetch from Git. If they do, that's a recent and very serious bug. Git is a security critical package that we've always updated freely. I'm AFK, only have my phone today . But, please try updating Git and check if the fixed-output source derivations change. Leo
Leo Famulari 写道： > I'm AFK, only have my phone today . But, please try updating Git > and check if the fixed-output source derivations change. …and if not, shall we agree to push this? (It's a yes from me, dog.) Kind regards, T G-R
Hi Leo,
"Leo Famulari" <leo@famulari.name> writes:
> Changing the Git package shouldn't affect fixed-output derivations that fetch from Git. If they do, that's a recent and very serious bug.
Whoops, you're right, I completely ignored that. I agree with you and
Tobias about pushing to master immediately then!
Best,
Hi, On Fri, 3 Mar 2023 at 22:57, Leo Famulari <leo@famulari.name> wrote: > Overall, git and git-minimal will cause more than 300 rebuilds, but not > too many for the current state of the build farm. I get 546 dependent packages for git + git-minimal which need to be re-built. And some are really expensive -- that what I meant by "a lot of rebuilds". :-) Well, I do not know if there is an issue with QA or it is just really expensive but the process is still pending, if I read correctly <https://qa.guix.gnu.org/issue/61583>. > Concretely, why can't we push this to master immediately? Somehow the guarantee that none of these 546 would not be broken by the update. ;-) Anyway, I had locally built them -- it took 3-4 days on my machine, IIRC -- and I do not remember any "big" breakage, maybe a couple of packages -- even maybe not since some are already broken. However, I did not carefully tracked my process thinking to come back later -- well, I ran "guix gc" in the mean for checking stuff with SWH coverage thinking that QA would have finished. I do not have an opinion where or whether to push. Cheers, simon
On Sat, Mar 04, 2023 at 07:52:04PM +0100, Simon Tournier wrote: > I get 546 dependent packages for git + git-minimal which need to be > re-built. And some are really expensive -- that what I meant by "a > lot of rebuilds". :-) > > Well, I do not know if there is an issue with QA or it is just really > expensive but the process is still pending, if I read correctly > <https://qa.guix.gnu.org/issue/61583>. At the Guix Days, it was said that there is a limit to how many builds the QA server will perform for a change. I don't recall the number, but maybe 300 builds per change? So, if a change causes too many rebuilds, the QA server will not perform the builds. Aside: Chris, I'd be happy to add a FAQ page to the QA server that answers this type of question. Let me know if I've missed that one already exists. For the Berlin server, I don't think that 546 builds is too many, at least for Intel systems. > > Concretely, why can't we push this to master immediately? > > Somehow the guarantee that none of these 546 would not be broken by > the update. ;-) It's certainly possible that something breaks. But we can do a simple test by trying to update our profiles and Guix System installations, and checking that our tools still work. I think it's okay to cause a little breakage in order to deploy important security updates.
Leo Famulari <leo@famulari.name> writes: > On Sat, Mar 04, 2023 at 07:52:04PM +0100, Simon Tournier wrote: >> I get 546 dependent packages for git + git-minimal which need to be >> re-built. And some are really expensive -- that what I meant by "a >> lot of rebuilds". :-) >> >> Well, I do not know if there is an issue with QA or it is just really >> expensive but the process is still pending, if I read correctly >> <https://qa.guix.gnu.org/issue/61583>. > > At the Guix Days, it was said that there is a limit to how many builds > the QA server will perform for a change. I don't recall the number, but > maybe 300 builds per change? So, if a change causes too many rebuilds, > the QA server will not perform the builds. Currently the limit is 200 builds per system. https://git.cbaines.net/guix/qa-frontpage/tree/guix-qa-frontpage/manage-builds.scm#n99 > Aside: Chris, I'd be happy to add a FAQ page to the QA server that > answers this type of question. Let me know if I've missed that one > already exists. Contributions are very welcome, there's no documentation yet. >> > Concretely, why can't we push this to master immediately? >> >> Somehow the guarantee that none of these 546 would not be broken by >> the update. ;-) > > It's certainly possible that something breaks. But we can do a simple > test by trying to update our profiles and Guix System installations, and > checking that our tools still work. I think it's okay to cause a little > breakage in order to deploy important security updates. The backlog of revisions to be processed by data.qa.guix.gnu.org is being processed faster now, so hopefully the impact of this change will be visible there shortly.
> "Leo Famulari" <leo@famulari.name> writes: > > Changing the Git package shouldn't affect fixed-output derivations that fetch from Git. If they do, that's a recent and very serious bug. Now I have confused myself and I'm unsure. I stepped away from Guix for a while and forgot a lot of the intimate knowledge I had on this subject. I checked, and this patch does change the derivation of packages fetching from Git, although the output is identical. So, I am confused about if this will cause >10k rebuilds or not. Here's how I checked, first by calculating derivations and outputs on the master branch, and then after applying the patch: ------ $ git rev-parse --abbrev-ref HEAD master $ git rev-parse HEAD cedf97ed6ee4eba8c39bfe6cc0efe33fcb977ccf $ ./pre-inst-env guix build --no-grafts corefreq -d /gnu/store/78lhq407x6sjlf3k7jh16ph1pff1y2nw-corefreq-1.95.2.drv $ ./pre-inst-env guix build --no-grafts corefreq /gnu/store/vva0xljihzmpf4ddbihr168f2ymkh2k0-corefreq-1.95.2-linux-module /gnu/store/qkwah5gnfqh293i36byhc00cd6xb3jml-corefreq-1.95.2 ------ Apply the patch: ------ $ git checkout contrib-security-git Switched to branch 'contrib-security-git' $ git log --oneline | head -n1 faeb52692d gnu: git: Update to 2.39.2 [fixes CVE-2023-22490 & CVE-2023-23946]. $ ./pre-inst-env guix build --no-grafts corefreq -d /gnu/store/sw5942gj4f5lm9i9zn6bwj7f0q0dlf7a-corefreq-1.95.2.drv $ ./pre-inst-env guix build --no-grafts corefreq /gnu/store/vva0xljihzmpf4ddbihr168f2ymkh2k0-corefreq-1.95.2-linux-module /gnu/store/qkwah5gnfqh293i36byhc00cd6xb3jml-corefreq-1.95.2 ------ The package derivation changed, but not the output. I'm looking for guidance on how to interpret these results.
Hi Leo, On Sun, 5 Mar 2023 at 19:46, Leo Famulari <leo@famulari.name> wrote: > At the Guix Days, it was said that there is a limit to how many builds > the QA server will perform for a change. I don't recall the number, but > maybe 300 builds per change? So, if a change causes too many rebuilds, > the QA server will not perform the builds. Ah thanks! I always forgot that limit. :-) I mean, since it says "not yet processed", I still think the limit is higher. ;-) Anyway. > For the Berlin server, I don't think that 546 builds is too many, at > least for Intel systems. Indeed. Just to note that the last update of Git was by commit: --8<---------------cut here---------------start------------->8--- 51f8a7aced70b7f79037bd99019dddaea07ced25 Author: Tobias Geerinckx-Rice <me@tobias.gr> AuthorDate: Sun Jan 15 01:00:03 2023 +0100 Commit: Tobias Geerinckx-Rice <me@tobias.gr> CommitDate: Sun Jan 15 01:00:08 2023 +0100 gnu: git: Update to 2.39.1 [fixes CVE-2022-41903 & CVE-2022-23521]. * gnu/packages/version-control.scm (git): Update to 2.39.1. Reported by HexMachina in #guix. --8<---------------cut here---------------end--------------->8--- and all was fine... > > Somehow the guarantee that none of these 546 would not be broken by > > the update. ;-) > > It's certainly possible that something breaks. But we can do a simple > test by trying to update our profiles and Guix System installations, and > checking that our tools still work. I think it's okay to cause a little > breakage in order to deploy important security updates. ...but it was not with the previous, --8<---------------cut here---------------start------------->8--- 83ede5a02e1fc531d912eb92eb0a22a4b897997c Author: Greg Hogan <code@greghogan.com> AuthorDate: Wed Oct 19 20:13:15 2022 +0000 Commit: Ludovic Courtès <ludo@gnu.org> CommitDate: Tue Nov 8 14:06:00 2022 +0100 gnu: git: Update to 2.38.1. Fixes CVE-2022-39253 and CVE-2022-39260. * gnu/packages/version-control.scm (git): Update to 2.38.1. Co-authored-by: Ludovic Courtès <ludo@gnu.org> --8<---------------cut here---------------end--------------->8--- which had broken part of the Julia ecosystem; now the same problem cannot arise for Julia. Who knows for the others? Anyway, I did this rebuild and I did not noticed large breaks. > > > Concretely, why can't we push this to master immediately? Since we agree it is fine for master, feel free to push. :-) Cheers, simon
Hi, Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> writes: > Leo Famulari 写道： >> I'm AFK, only have my phone today . But, please try updating Git and >> check if the fixed-output source derivations change. > > …and if not, shall we agree to push this? (It's a yes from me, dog.) > > Kind regards, As long as it doesn't touch git-minimal/fixed, we should be OK, otherwise it causes thousands of rebuilds (see the revert of 8a9bf794e184934e1432f25f4954117d4b46f655, where I got bitten by this). I don't recall why it causes so many rebuilds.
On Fri, Feb 17, 2023 at 06:04:02PM +0000, Greg Hogan wrote:
> * gnu/packages/version-control.scm (git): Update to 2.39.2.
Thank you! Pushed as a0d22c41989e529859c813fb64a78250bde76991
Some more discussion on the subject on #guix IRC:
http://logs.guix.gnu.org/guix/2023-03-06.log#175418
Hi Leo, On Mon, 06 Mar 2023 at 12:23, Leo Famulari <leo@famulari.name> wrote: > Some more discussion on the subject on #guix IRC: > > http://logs.guix.gnu.org/guix/2023-03-06.log#175418 There is mentioned git-minimal/fixed and git-minimal/pinned. + git-minimal/fixed = grafted + git-minimal/pinned = that does not change Basically, the aim of git-minimal/pinned is to avoid “world rebuild” when updating git-minimal. It is mainly used by some tests and it is safe to make few upgrades. See more details here: https://issues.guix.gnu.org/issue/61078 or the discussion starting here: https://issues.guix.gnu.org/issue/60042#msgid-c811d75e30752a591d9777368672dbdf801675b4 Cheers, simon
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm index 5de344e549..88df2c2aeb 100644 --- a/gnu/packages/version-control.scm +++ b/gnu/packages/version-control.scm @@ -225,14 +225,14 @@ (define git-cross-configure-flags (define-public git (package (name "git") - (version "2.39.1") + (version "2.39.2") (source (origin (method url-fetch) (uri (string-append "mirror://kernel.org/software/scm/git/git-" version ".tar.xz")) (sha256 (base32 - "0qf1wly7zagg23svpv533va5v213y7y3lfw76ldkf35k8w48m8s0")))) + "1mpjvhyw8mv2q941xny4d0gw3mb6b4bqaqbh73jd8b1v6zqpaps7")))) (build-system gnu-build-system) (native-inputs `(("native-perl" ,perl) @@ -252,7 +252,7 @@ (define-public git version ".tar.xz")) (sha256 (base32 - "0xf7ki90xw77nvmnkw50xaivyfi8jddfq0h8crzi7m9zjs7aa8mm")))) + "09cva868qb4705s884dzvbwkm78jlw4q8m6xj7nd7cwxy2i2ff8b")))) ;; For subtree documentation. ("asciidoc" ,asciidoc) ("docbook-xsl" ,docbook-xsl)