From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CEIyBl1tFmLALwAAgWs5BA (envelope-from ) for ; Wed, 23 Feb 2022 18:22:37 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id EEG6A11tFmL8ZgEA9RJhRA (envelope-from ) for ; Wed, 23 Feb 2022 18:22:37 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A3EB224FE9 for ; Wed, 23 Feb 2022 18:22:36 +0100 (CET) Received: from localhost ([::1]:45294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMvLW-0003tU-PC for larch@yhetil.org; Wed, 23 Feb 2022 12:22:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvK2-0003A7-8z for bug-guix@gnu.org; Wed, 23 Feb 2022 12:21:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMvK1-0003El-VD for bug-guix@gnu.org; Wed, 23 Feb 2022 12:21:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMvK1-0004Z3-R6 for bug-guix@gnu.org; Wed, 23 Feb 2022 12:21:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#54129: =?UTF-8?Q?Guix=E2=80=99s?= environment variables can break the host system Resent-From: Tirifto Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 23 Feb 2022 17:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 54129 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 54129@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164563685817524 (code B ref -1); Wed, 23 Feb 2022 17:21:01 +0000 Received: (at submit) by debbugs.gnu.org; 23 Feb 2022 17:20:58 +0000 Received: from localhost ([127.0.0.1]:46391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMvJx-0004Ya-LB for submit@debbugs.gnu.org; Wed, 23 Feb 2022 12:20:58 -0500 Received: from lists.gnu.org ([209.51.188.17]:34430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMvJv-0004YN-B0 for submit@debbugs.gnu.org; Wed, 23 Feb 2022 12:20:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvJv-0002wr-58 for bug-guix@gnu.org; Wed, 23 Feb 2022 12:20:55 -0500 Received: from mout02.posteo.de ([185.67.36.66]:49731) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvJr-0003Bp-Vx for bug-guix@gnu.org; Wed, 23 Feb 2022 12:20:54 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4A359240103 for ; Wed, 23 Feb 2022 18:20:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.cz; s=2017; t=1645636848; bh=vi6XzKccYIkKSWtDsaQ3M89c2WSyZ3lX52yrjTbBkB0=; h=Date:From:To:Subject:From; b=CvIU1/Oj9A5svwSUg7Sg4EMFdf5A19yE9stR0PPWsYUZtil9D8543gbaEtqiA/ajo nwCtPvKRhb+aQBFZZreVpm0UuXJX63CskheI0pE9Bl9wlvesx056BZbMTkRSRiMZUS bCDH0GGmaV9iWEi3YiW3I9+lRCztp+yjHidj/rPMPEAeK5aJFAhKQrBUhLrx2pjcXR hKn4gLbIQppZ8sVRq0QSJlZiQIFw1gKo8/xRYRzKvynZ3PDfoG1s8DeqJ413sAFVrm 7AG2/llkVci7o+WTtlyWSF4A441ntrCCgYb8n0HYiGkFJl23qv63yTDLqRw8n5fAAL t+4sp6ka/cMmQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4K3jVR3XBhz9rxD for ; Wed, 23 Feb 2022 18:20:47 +0100 (CET) Date: Wed, 23 Feb 2022 17:20:46 +0000 From: Tirifto Message-ID: <20220223182046.553d9176@Jado> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=tirifto@posteo.cz; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1645636956; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=a4GwIHvy9Gy0OoyQHjdDAM5r+fXMSigzYWMXlY0qRuA=; b=ROEzt/CtVC44AHuKkX7/uq2OufOGOW2Sa5sXyJI6K6Vx2T/GvtoKs5nS0woeEEiRFsCXAp 0hjj83Gbi3/7YUFm8do5/oZiEu+mfTOz0yvdAJt1ebZPFM+mH+Te7NdUtJwWcUc8YXWvpt dhRDCK3XX6Rh/C5ixwpqhJCjkAc5TuTnDi20ABGbw6T0Se1fGgloRiK0X7+EIbIZUTqu8A lcT6hrm+M30j8lDtAaP3ancBNxuVPD0XPWQ/Gy1u0j2Ob6BWflTBjO73jmbBOhNa1jYlXv eRZRcetgEl9NdpQ5ymF96Pr0DteB2/dL2N0fGqhEHB9RBgZtFKglpZI8BwNZaA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1645636956; a=rsa-sha256; cv=none; b=iWwB7VKu2nNj3wItR7h5jHGdyo6V/FE6/uUJhFipHLAC/MuqonbrxpMTAK8i+sD8w5XcEj 6SQI1LCSsC1p75TPFF5PgMtNO5CYMtatzZir1gtpIIzounESUEJyIlSowy0LBMunTNnu7B X+/VQuk3G2w4OMuUl7XkStWVRLTbtMGXVLJu5VHbn069GsCg/FlQNZYCFxp5hPNpir2gUC SP964CNEz5dxsgpsgF6j8QZK3saVTNRhkzpVys5uMPeVsbae600B48Z3yY2YiYIBJIS/1O +78MMufNc9FMpk6zUym5/Tru6xnR/D6IkcHR0VjTwGbkMGmCv7NIYhmtywDdhg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=posteo.cz header.s=2017 header.b="CvIU1/Oj"; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.cz (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.93 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=posteo.cz header.s=2017 header.b="CvIU1/Oj"; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.cz (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: A3EB224FE9 X-Spam-Score: -2.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: nuKfrTbW9pXM Hello! Over some time using Guix as an additional package manager in different environments on Parabola and Trisquel, I have repeatedly run into issues where something broke in the host system because of an environment variable set by Guix. #### Example 1 Usually this concerned $XDG_DATA_DIRS. The problem with this variable stems from the XDG Base Directory Specification [1], which says that: > If $XDG_DATA_DIRS is either not set or empty, a value equal to > /usr/local/share/:/usr/share/ should be used. =46rom what I=E2=80=99ve heard from others, some environments automatically s= et this variable; others, however, do not set the variable, instead having the system fall back to the value shown above. I have observed the latter behaviour in GNOME=C2=A03 and Window=C2=A0Maker. Guix currently prepends its own paths to the existing value, which works fine when there *is* an existing value. When there is no value and the system is relying on the fall-back, Guix sets the value to its own paths only. This means the local, non-guix applications will no longer look for the data in =E2=80=98/usr/local/share/=E2=80=99 or =E2=80= =98/usr/share/=E2=80=99, where they are stored, and will break, possibly condemning the user to resort to the command line. #### Example 2 Just now I tried to clone a git repository. Git is installed on the host system and is not found in my Guix profile. Yet the cloning has failed with the following message: > fatal: unable to access > 'https://framagit.org/peppercarrot/webcomics.git/': server > certificate verification failed. CAfile: > /home/tirifto/.guix-profile/etc/ssl/certs/ca-certificates.crt > CRLfile: none All I had to do was to unset $GIT_SSL_CAINFO, apparently set by Guix, and everything worked again. #### Comment I suppose problems like this cannot always be prevented automagically. But whenever that happens to be the case, perhaps the possibility of them happening could be exposed to the user in a more prominent way? I can deal with the two issues mentioned above with ease, since: 1. I know environment variables exist and parts of the system rely on them for stuff. 2. I know that Guix sets its own environment variables and modifies existing ones. 3. When something breaks, it either points me to a Guix-related path, or I remember by myself to check if Guix has changed something relevant. But the first time I had a problem with $XDG_DATA_DIRS, it took me a while to find the cause. I imagine that right now, running Guix is very much a conscious decision made by users who are at least somewhat comfortable with the command line and the internal workings of their system, so this does not present an insurmountable problem for them. But it might for other types of users (who might become more common in the future, I suppose). As one hypothetical solution, would it be possible for Guix to include default values in its paths if it=E2=80=99s running on a host system and th= ere are no values set, but it is known that fallback values may be used? I have no idea how practical this would be on the Guix side of things. Alternatively, perhaps the more ubiquitous variables could be given a mention or their own section in the manual, so that the user will know to set values for them when setting Guix up? Perhaps something similar could be done for individual packages which set some variables, with the user being informed about their use on installation, should they wish to set their values or note them for reference in case of issues in the future? Perhaps this is less of a technical bug and more of a design issue, but this seemed like the best place to bring it up nevertheless. Sorry if that is not the case! Best of wishes // Tirifto [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html