Re: GNOME 3.34 in GNU Guix and security
Danny Milosavljevic skribis: > Hello, > > core-updates is still in a pretty bad state. > > [...] > > A short summary of what is at least broken: > > [...] > (2) Source files have been in-place replaced upstream with a lot of packages > (see my bug report about the topic). fldigi has such a problem but can just > be updated. This is easy to see by just building without substitutes--and it > doesn't do anyone any good for me to file individual bug reports for each and > every one of those > [...] Concerning the disappearing source tarballs of older fldigi versions on the official website, it has been fixed on master (65e9f13116edc58836cdbd1da60bfb81a3d58c82), but core-updates hasn't merged that in yet. signature.asc Description: PGP signature
Re: GNOME 3.34 in GNU Guix and security
Hi Danny, > (3) libusb-for-axoloti build failure (guix build axoloti-patcher-next) This has been fixed in 1daedaa8646696783c88553e03035d547fd001ca. > (5) download failed > "https://bioconductor.org/packages/release/bioc/src/contrib/DelayedArray_0.16.1.tar.gz; > 404 "Not Found" This was fixed in f10f2745eb1ec38eae5c41323f31980d2dd1f38c. (These are on the “master” branch.) -- Ricardo
Re: GNOME 3.34 in GNU Guix and security
Hello, core-updates is still in a pretty bad state. I'd be glad to merge Raghav's patches (which he already reworked to be current for core-updates!) to core-updates--but right now, Guix packages don't build BEFORE or after applying these patches to core-updates. Please, let's do something about that. A short summary of what is at least broken: [(1) FTP with IPv6--or with the new patch, some other FTP that don't support EPSV (the latter is a server problem, but the former had been bug in Guix). So I guess that one is fixed.] (2) Source files have been in-place replaced upstream with a lot of packages (see my bug report about the topic). fldigi has such a problem but can just be updated. This is easy to see by just building without substitutes--and it doesn't do anyone any good for me to file individual bug reports for each and every one of those (3) libusb-for-axoloti build failure (guix build axoloti-patcher-next) (4) bug applying patches in sources unpacked from zip files (I just posted patch 47203 to guix-patches) (5) download failed "https://bioconductor.org/packages/release/bioc/src/contrib/DelayedArray_0.16.1.tar.gz; 404 "Not Found" That doesn't mean that those are the only problems. It means I got frustrated and stopped trying, lest I find more problems (which would be easy). My current rebuild command for build-testing the first of Raghav's patches is (from guix refresh -l with some editing--because it didn't work without editing. Sigh): ./pre-inst-env guix build -K --no-substitutes foo2zjs docker localed jnettop raul libinstpatch hdup rdup connman rust-gobject-sys rust-gio rust-glib rust-gio-sys rust-gobject-sys rust-gio-sys rust-glib-sys rust-glib rust-glib-sys rust-gio rust-glib rust-gio 4store mdbtools ncdc american-fuzzy-lop sdcv duperemove libticalcs2 ecl-enchant imposm3 spatialite-tools poly2tri-c gnome-shell-extension-hide-app-icon gnome-shell-extension-topicons-redux tiramisu gnome-shell-extension-paperwm gnome-shell-extension-clipboard-indicator gnome-shell-extension-dash-to-dock gnome-shell-extension-dash-to-panel linkchecker fortune-mod rust-gdk-pixbuf-sys rust-gdk-pixbuf rust-gdk-pixbuf rust-gdk-pixbuf-sys rust-gdk-pixbuf rust-atk rust-atk-sys ddcutil irssi rspamd emacs-mu4e-jump-to-list emacs-mu4e-conversation emacs-helm-mu emacs-mu4e-patch mc bitlbee-discord fna mojoshader-cs glyr remid-lv2 nbd ocaml-lwt-log brlaser igt-gpu-tools pscircle ztoolkit rust-cairo-sys-rs rust-cairo-rs rust-cairo-rs rust-cairo-sys-rs rust-cairo-rs libratbag kaldi-gstreamer-server playerctl python2-pyatspi guile-charting xplanet rust-pango rust-pango-sys rust-pango rust-pango rust-pango-sys font-culmus font-fantasque-sans font-meera-inimai font-linuxlibertine fntsample plymouth python-pygraphviz python2-pygraphviz pynac makefile2graph sigrok-cli ibutils rust-andrew rust-smithay-clipboard mesa-opencl-icd picom rakarrack flamp flrig flwrap tigervnc-client dillo tuxpaint-config infamous-plugins sorcer non-sequencer non-timeline non-mixer alex4 virtualgl celestia tao slim chipmunk aseprite python2-mapnik perceptualdiff megacmd feh sxiv screenfetch ranger eureka git-open privoxy fluxbox xmenu idesk xnotify hsetroot python-django-sortedm2m python-django-simple-math-captcha python-django-override-storage python-django-contrib-comments python-easy-thumbnails python-django-assets python-django-auth-ldap python-django-url-filter python-django-netfields python-django-contact-form python-django-logging-json python-django-rq python-django-debug-toolbar-alchemy patchwork python-django-statici18n font-cozette freedoom mcomix conda visidata gajim-omemo python2-ledgerblue nototools python2-anaconda-client python2-reportlab python2-qrcode libfreenect-examples perl-opengl setbfree xfe gmsh extempore sherlock-lv2 zynaddsubfx dragonfly-reverb ninjas2 helm zam-plugins wolf-shaper patchmatrix wolf-spectrum maim xdriinfo glmark2 insight-toolkit insight-toolkit egl-wayland beignet intel-vaapi-driver libvdpau-va-gl mediasdk libva-utils vulkan-tools swayidle kanshi wlr-randr wl-clipboard wev foot wterm pass-otp pass-git-helper python2-xdo clipmenu libstdc++-doc libstdc++-doc python2-pydot darcs pdf2djvu osm2pgsql postgis netcdf-fortran python-netcdf4 nmoldyn domainfinder mes mes-rb5 python-anytree python2-dulwich python2-graphql-core python-ws4py python-locust python-pykka python-gipc python-pykafka uriparser libxmlplusplus pangomm emacs-w3m emacs-blimp emacs-gif-screencast emacs-image+ tango-icon-theme catimg chafa perl-catalyst-plugin-captcha ecl-ltk emacs-theme-magic skribilo solaar wla-dx keepalived python-symengine alacritty python-pylibmc python2-pylibmc rmlint libabigail python-cffi-documentation emacs-helm-notmuch notmuch-addrlookup-c patches neomutt muchsync afew mpd-mpc ncmpc python-cantools bpython python-robotframework-sshlibrary
Re: GNOME 3.34 in GNU Guix and security
Hi Ricardo! Thanks for the update! Also, then reason GNOME work got messed up is that, in wip-desktop, [1] I was not just working gnome packages, but also its dependencies [2] Work involved not just updates, but also improvements. This kinda complicated the "update stuff" norm. I think that ci.guix.gnu.org should be capable of building your branch. On a note, I have put more work on myself. When I was working on wip-desktop, I made larget commits instead of 'one change per commit'. So after a discussion, I was asked to split them into smaller chunks. So I need to get #42958 out of the way. Excellent! Let me know if there’s anything I can do to assist. Thanks! I will be sending new patch-set to #42958. I will let you know, once I am done. It would be great if you could review and merge them to core-updates or master. Regards, RG. OpenPGP_signature Description: OpenPGP digital signature
Re: GNOME 3.34 in GNU Guix and security
Raghav Gururajan writes: > Hi Ricardo! > >> I don’t know if anyone is working on it right now, though. I was told >> months ago that Raghav Gururajan was working on GNOME upgrades as part >> of the wip-desktop branch, but my occasional questions for a status >> upgrade have gone unanswered. Raghav, please correct me if I’m >> mistaken. It would be good to clarify what is and isn’t the scope of >> wip-desktop. > > wip-desktop consists of some upgrades, plus, lot of improvements to > gnome packages and it's immediate dependencies. About 50% of them not > merged directly in master. When Danny and I, were merging other 50% to > core-updates, core-updates were broken. So we tried to merge few > commits in master, which got reverted due to high re-builds. I was > told by Danny that we can only merge stuff when c-u is back to normal. Thanks for the update! > Since huge time has passed, we need to re-work some commits with > rebasing from master. This gonna require testing via huge re-builds. > Danny is working on setting-up a powerful system to do this work. I think that ci.guix.gnu.org should be capable of building your branch. > Let me speak to Danny and get back to you here. Due to the security > nature of this issue, I am willing to spend this month focusing on > GNOME/wip-desktop. Excellent! Let me know if there’s anything I can do to assist. -- Ricardo
Re: GNOME 3.34 in GNU Guix and security
On Thu, 2021-03-11 at 03:18 -0500, Mark H Weaver wrote: > Hi Léo, Hello! > I appreciate your recent work on Guix security. Thank you for that. Very happy to catch up there as well for my own usage of GNU Guix as well! > Can you please substantiate this? What vulnerabilities do you know > of, > and what makes you think that we can't address them adequately in the > usual ways, without "upgrading GNOME to [the] latest"? I have not yet fully investigated each CVE but there is uncertainty around gnome-shell, gvfs, librsvg, gdk-pixbuf, pango, cairo, if not more. You can use 'guix lint -c cve ' to find out, also look up in NVD individually in case GNU Guix doesnt find it. I am always uneasy relying on CVE only for security patches since I know how much lots of security issues are fixed by developers without issuing any CVE, so to me the best way of keeping up is to always be on latest. > I saw your bug report about our Glib being vulnerable to CVE-2021- > 27218 > and CVE-2021-27219. Thanks very much for bringing that our > attention. > > I'll backport the fixes to our version of Glib. It will actually be > quite easy, given that Ubuntu has already published backports of > the > fixes for Glib 2.56.4 and 2.64.4, which brackets the version in Guix > (2.62.6). I just looked at the diffs between those two patch sets, > and > the differences are quite slight, apart from line number differences. I am really happy you are willing to help! I will have to admit that I am a bit overwhelmed by the amount of work that I have left still. Léo signature.asc Description: This is a digitally signed message part
Re: GNOME 3.34 in GNU Guix and security
Am 11.03.21 um 09:08 schrieb Ricardo Wurmus: Léo Le Bouter writes: I must come to the conclusion that using GNOME 3.34 in GNU Guix right now is just straight out insecure. I would advise we either, get rid of GNOME, backport all individual security patches (they can be numerous..), or upgrade GNOME to latest and keep up over time. I don't think we can afford to spend time backporting security fixes to the numerous GNOME packages with CVEs, not with current resources, it is time-consuming. No, GNOME should be upgraded. I upgraded it twice in the past, and it’s a lot of work, but certainly not impossible. I don’t know if anyone is working on it right now, though. I was told months ago that Raghav Gururajan was working on GNOME upgrades as part of the wip-desktop branch, but my occasional questions for a status upgrade have gone unanswered. Raghav, please correct me if I’m mistaken. It would be good to clarify what is and isn’t the scope of wip-desktop. I tried rebasing wip-gnome3.36 to master. I'm not done yet... But I thinks its easier then merging the wip-desktop branch, because that one is huge and a bit dirty...
Re: GNOME 3.34 in GNU Guix and security
Hi Ricardo! I don’t know if anyone is working on it right now, though. I was told months ago that Raghav Gururajan was working on GNOME upgrades as part of the wip-desktop branch, but my occasional questions for a status upgrade have gone unanswered. Raghav, please correct me if I’m mistaken. It would be good to clarify what is and isn’t the scope of wip-desktop. wip-desktop consists of some upgrades, plus, lot of improvements to gnome packages and it's immediate dependencies. About 50% of them not merged directly in master. When Danny and I, were merging other 50% to core-updates, core-updates were broken. So we tried to merge few commits in master, which got reverted due to high re-builds. I was told by Danny that we can only merge stuff when c-u is back to normal. Since huge time has passed, we need to re-work some commits with rebasing from master. This gonna require testing via huge re-builds. Danny is working on setting-up a powerful system to do this work. Let me speak to Danny and get back to you here. Due to the security nature of this issue, I am willing to spend this month focusing on GNOME/wip-desktop. Regards, RG. OpenPGP_signature Description: OpenPGP digital signature
Re: GNOME 3.34 in GNU Guix and security
Hi Léo,
I appreciate your recent work on Guix security. Thank you for that.
Léo Le Bouter writes:
> I must come to the conclusion that using GNOME 3.34 in GNU Guix right
> now is just straight out insecure. I would advise we either, get rid of
> GNOME, backport all individual security patches (they can be
> numerous..), or upgrade GNOME to latest and keep up over time.
Can you please substantiate this? What vulnerabilities do you know of,
and what makes you think that we can't address them adequately in the
usual ways, without "upgrading GNOME to [the] latest"?
I saw your bug report about our Glib being vulnerable to CVE-2021-27218
and CVE-2021-27219. Thanks very much for bringing that our attention.
> I don't think we can afford to spend time backporting security fixes to
> the numerous GNOME packages with CVEs, not with current resources, it
> is time-consuming.
I'll backport the fixes to our version of Glib. It will actually be
quite easy, given that Ubuntu has already published backports of the
fixes for Glib 2.56.4 and 2.64.4, which brackets the version in Guix
(2.62.6). I just looked at the diffs between those two patch sets, and
the differences are quite slight, apart from line number differences.
Besides CVE-2021-{27218,27219}, do you know of other known security
issues that would justify your claim that "using GNOME 3.34 in GNU Guix
right now is just straight out insecure"?
Thanks,
Mark
Re: GNOME 3.34 in GNU Guix and security
Léo Le Bouter writes: > I must come to the conclusion that using GNOME 3.34 in GNU Guix right > now is just straight out insecure. I would advise we either, get rid of > GNOME, backport all individual security patches (they can be > numerous..), or upgrade GNOME to latest and keep up over time. > > I don't think we can afford to spend time backporting security fixes to > the numerous GNOME packages with CVEs, not with current resources, it > is time-consuming. No, GNOME should be upgraded. I upgraded it twice in the past, and it’s a lot of work, but certainly not impossible. I don’t know if anyone is working on it right now, though. I was told months ago that Raghav Gururajan was working on GNOME upgrades as part of the wip-desktop branch, but my occasional questions for a status upgrade have gone unanswered. Raghav, please correct me if I’m mistaken. It would be good to clarify what is and isn’t the scope of wip-desktop. We™ should upgrade GNOME as soon as possible. It’s been stuck on 3.34 for much too long. -- Ricardo
