ra...@openmailbox.org skribis: > A bad package could sneakily replace a core system library with, for > example, insecure crypto code. So I think it is something that should > be dealt with.
That’s really out of the threat model. The problem here is the installation of an evil package in the first place, not the shadowing. > I had a look at past discussions on this: > > * https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00437.html > * https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00106.html > * https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00213.html > * https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00668.html > > one idea was a whitelist to reduce the amount of errors displayed. > > I've made a list of the collisions I see on my system: > > * [gnome] /share/icons/hicolor/icon-theme.cache > * [gnome] /lib/gio/modules/giomodule.cache > * [gnome] /share/glib-2.0/schemas/gschemas.compiled > * [gnome] /bin/gtk-update-icon-cache # because there are 2 versions of > gtk > * [python] /bin/coverage > * [python] /bin/.coverage3-wrap-01 > * [python] /bin/py.test-3.4 > * [python] /bin/.py.test-wrap-01 > * [python] /bin/.py.test-3.4-wrap-01 > > A suggestion I have for helping reduce this is there could be a post > install phase in gtk build system to delete those specific .cache > files. There could also be a similar one in those python libraries. > > Do people agree that this is a potential problem? If so I could > attempt to add such an phase. Or maybe there are other solutions that > would solve this better? These warnings are definitely a problem, but they’re a user interface problem. For GNOME/GLib cache files, I think the solution may be to generate them at profile-creation time. I’ve never seen the pytest collisions before, so I can’t tell. Ricardo also suggested that ‘guix package’ should warn about or error out when propagated inputs conflict with each other, or conflict with explicitly-installed packages. I think we should do that. Ludo’.
