About collision encountered arbitrarily choosing ...

About collision encountered arbitrarily choosing ...

[rain1]

I was just thinking about the warnings you get after installing 
packages:

warning: collision encountered
warning: arbitrarily choosing

because there are a lot of them and they generally don't matter or cause 
problems I have learned to ignore them.. but I just spotted this 
collision today:

/gnu/store/...-lsh-2.1/share/man/man8/sftp-server.8.gz
/gnu/store/...-openssh-7.2p2/share/man/man8/sftp-server.8.gz

That's only a man page substitution but really any package can shadow 
any file with 50% chance (can probably make it 100% by setting up the 
hash to come lexically first, not sure).

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.

-------------------------------------------

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?

Re: About collision encountered arbitrarily choosing ...

[Ludovic Courtès]

rain1@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’.