From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: About collision encountered arbitrarily choosing ... Date: Sun, 27 Mar 2016 23:30:07 +0200 Message-ID: <87poufwqw0.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akIGD-0000Rl-F0 for guix-devel@gnu.org; Sun, 27 Mar 2016 17:30:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akIGA-0003Jb-1f for guix-devel@gnu.org; Sun, 27 Mar 2016 17:30:13 -0400 In-Reply-To: (rain1@openmailbox.org's message of "Sun, 27 Mar 2016 19:58:15 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: rain1@openmailbox.org Cc: guix-devel@gnu.org 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=E2=80=99s 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=E2=80=99re a user interfa= ce problem. For GNOME/GLib cache files, I think the solution may be to generate them at profile-creation time. I=E2=80=99ve never seen the pytest collisions before, so I can=E2=80=99t te= ll. Ricardo also suggested that =E2=80=98guix package=E2=80=99 should warn abou= t or error out when propagated inputs conflict with each other, or conflict with explicitly-installed packages. I think we should do that. Ludo=E2=80=99.