[PATCH] gnu: git: Update to 2.39.2 [fixes CVE-2023-22490 & CVE-2023-23946].

Hi,

On ven., 17 févr. 2023 at 18:04, Greg Hogan <code@greghogan.com> wrote:

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:

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

I have tried to replace the plain ’git’ or ’git-minimal’ by

’git-minimal/pinned’ for some packages. It does not change much.

Hum, we are not very reactive. :-)

Cheers,

simon

Hi,

I'd ask ‘why can we not simply graft this’ but…

Simon Tournier ???

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:

------

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

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.

--

Thanks,

Maxim

On Fri, Mar 3, 2023, at 22:39, Maxim Cournoyer wrote:

`guix refresh -l git git-minimal` shows only hundreds of rebuilds. Am I missing something?

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

`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,

--

Josselin Poiret

On Sat, Mar 4, 2023, at 05:30, Josselin Poiret wrote:

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 ???

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

Whoops, you're right, I completely ignored that. I agree with you and

Tobias about pushing to master immediately then!

Best,

--

Josselin Poiret

Hi,

On Fri, 3 Mar 2023 at 22:57, Leo Famulari <leo@famulari.name> 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.

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:

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.

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.

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.

Leo Famulari <leo@famulari.name> writes:

Currently the limit is 200 builds per system.

Contributions are very welcome, there's no documentation yet.

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.

Hi Leo,

On Sun, 5 Mar 2023 at 19:46, Leo Famulari <leo@famulari.name> wrote:

Ah thanks! I always forgot that limit. :-) I mean, since it says

"not yet processed", I still think the limit is higher. ;-) Anyway.

Indeed. Just to note that the last update of Git was by commit:

and all was fine...

...but it was not with the previous,

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.

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:

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.

--

Thanks,

Maxim

On Fri, Feb 17, 2023 at 06:04:02PM +0000, Greg Hogan wrote:

Thank you! Pushed as a0d22c41989e529859c813fb64a78250bde76991

Some more discussion on the subject on #guix IRC:

Hi Leo,

On Mon, 06 Mar 2023 at 12:23, Leo Famulari <leo@famulari.name> wrote:

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