Re: Search alerts and Watch issue on mumi

[Arun Isaac]

> Or, subscribe to all issues in which you participated
> in—submitter:"Arun Isaac" (replace my name with yours, of course)—and
> never worry about people not Ccing you correctly.

Small correction. This query should be author:"Arun Isaac".
submitter:"Arun Isaac" only gives you issues which you created.

Cheers!

Re: bug#76428: [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>>   ld.so.cache
>>   search-paths.d
>> GUIX_XDG_DATA_DIRS
>> GUIX_GIO_EXTRA_MODULES
>> GUIX_GTK4_PATH
>
> I don’t think the “GUIX_” prefix is really justified in the proposal.

Sure.  There are 2 reasons, one is to avoid broke foreign systems (
GUIX_GIO_EXTRA_MODULES, GUIX_GTK4_PATH), another is about priority
(GUIX_XDG_*) I'll explain later.

>
> There’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow
> that this can be generalized to every search path environment variable.
>
> For example, the XDG_ variables are honored by a lot of software, not
> just GLib- or Qt-based software, and it’s unrealistic to patch them all.
> It’s also undesirable: generally speaking, we want to stay as close to
> upstream as possible so that documentation, tutorials, and scripts found
> elsewhere also work on Guix.

Yes, we introduced GUIX_PYTHONPATH, GUIX_GTK* to avoid ABI
incompatibility problems between different programs from foreign systems
and Guix systems.  But XDG_DATA_DIRS, as it's designed for shareable
data files, won't have ABI incompatibility problems, and we rely on it
for a foreign desktop launch to find applications (via desktop files),
fonts installed from Guix.

So do we need 'GUIX_XDG_*'?  Well, In 'wrap-program' we can specifiy how
the wrapped environment variables are going to be combined with the
system level variables in 3 positions: prefix, suffix or = (exact).  The
priority between wrapped and system level variables influence the
robustness of programs.

For plugins which might have ABI problems, we'll use 'prefix', so a
wrapped program always load the correct ones (eg: qtbase) first, and
hopefully they can ignore the possible incompatible ones (eg: a qt
theme plugin) with reduced functions but still works.

Or for not real search paths which only support a single directory or
file, we'll use '=' (eg: SSL_CERT_FILE).

But for XDG_DATA_DIRS and XDG_CONFIG_DIRS, we'll want to use 'suffix',
so that the shared combined data (icons, mime databases) will be used
instead of a seperated incomplete ones.  Also it allow user to customize
them as usually, or 'guix home' or 'guix system' to custom them at
profile level.

In the specified search-paths.d implementation, for simplify reason, the
envs from search-paths.d files are always used in 'prefix' way.  For '='
cases, we could patch it to a real search path (eg:
GUIX_GDK_PIXBUF_MODULE_FILES), or hardcode it (eg:
QTWEBENGINEPROCESS_PATH #75966).  For 'suffix' cases, it uses 2
variables, that's prefer XDG_DATA_DIRS (set by profile or foreign
system) over GUIX_XDG_DATA_DIRS (set by search-paths.d, not leaking).

>
>> ## Find the location of the current executable
>>
>> To find its search path configuration files when an executable is running,
>> we can first find the location of the executable.  Conveniently, Linux
>> provides a pseudo-file `/proc/self/exe` for this exact purpose, which works
>> well for ELF executables.   But for an interpreter script, `/proc/self/exe`
>> would return the file name of its interpreter instead of the script, so
>> we patch interpreters to set 2 environment variables:
>>
>>   - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter
>>   - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script
>
> We won’t patch every interpreter out there, that’s not reasonable.

Yes, python should be the most, also we can avoid patching and still use
'wrap-program' for them.

>
> These two variables could also have unexpected consequences since an
> attacker could override them to cause confusion.

The check (current /prof/self-exe == GUIX_INTERPRETER_FILE) done in the
client side should prevent the attack or confusion, if the interpreter
haven't changed then there should be no way to modify
GUIX_MAIN_SCRIPT_FILE set by the interpreter.


> [...]
>
> I’m concerned about the cost of maintaining these patches.  Again, the
> ld.so patch (for glibc) sets a precedent, but this part of glibc changes
> relatively rarely, and it’s just one patch; what if we have to maintain
> ten such patches in big and changing libraries like GLib and Qt?

I'm totally fine with reject the implementation due to maintaince
burden.  I could polish the patches later for easier review and decide
they are reasonable or not.

>
> Overall, I think I’d be reassured if we reduced the scope a little bit:
> don’t insist on the “GUIX_” prefix, focus on GTK and Qt applications.

Okay, I'll send GUIX_GIO_EXTRA_MODULES as a seperated patch later.  For
'GUIX_XDG_DATA_DIRS' and 'GUIX_XDG_CONFIG_DIRS', do you think the
current implementation plan (GUIX_ ones only used by search-paths.d,
only XDG_DATA_* still set by profile and visible, use 2 variables due to
simplify reason) fine?

Thank you!

Re: GNU & Guix

[Tobias Geerinckx-Rice]

Yo,

On 2 April 2025 15:34:36 UTC, Caleb Herbert  wrote:
>Hi, signer of Document!

Wat.  I attached no signature/document/whatsoever.  What was it?

(Whenever I *want* K-9 and GPG to play nicely, they won't!)

Anyway, it meant nothing and I presume you were able to read my message just 
fine.

>Pardon my inflammatory remarks.

Gladly, if those were the last :-)

I don't want you to feel ignored or not be taken seriously.  Lashing out only 
alienates those who did respond, and affirms the very same popular ‘GNU’ 
stereotypes to which I'm sure you object.  Don't stereotype your ‘opponents’ in 
turn.

Enemies of GNU lurk not on these lists.  Enemies of GNU don't care about its 
(mis)management.  Enemies of GNU don't use a weird, slow package manager that 
won't run their Steam games and they are all the poorer for it.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: Applying Patches for Review

[Cayetano Santos]

>sam. 29 mars 2025 at 16:10, Noé Lopez  wrote:

> Gabriel Santos  writes:

> Another way I know of is to download the mailbox from the issue’s
> debbugs page and apply it with “git am”.

As an alternative, you have

   https://yhetil.org/guix-patches/

From here, you can download the full thread as mbox, individual messages, etc.

As a third possibility to apply a patch, you have the b4 utility

b4 shazam messageID

C.


signature.asc
Description: PGP signature

How is security managed in Guix? Should there be a team?

[Nicolas Graves]

Hi Guix!

I think one of the things where Guix could be better is security /
ensuring CVEs are fixed quickly.

In 76819 I developped some missing functionality in the CVE linter, so
that it will be easier to get proper missing libraries.

A few ideas/questions to advance on that :
- there are still a lot of linted CVEs for toolchains (former go
  versions etc) that users should in principle not be exposed to.
  Should we handle or ignore those?
- Maybe having a team or a responsible person for this is a good idea.
- A good practice could be to setup a daily job to get notified of all
  CVEs, so that we can quickly handle them.

-- 
Best regards,
Nicolas Graves

Re: How is security managed in Guix? Should there be a team?

[Development of GNU Guix and the GNU System distribution.]

Nicolas Graves  writes:

> Hi Guix!
>
> I think one of the things where Guix could be better is security /
> ensuring CVEs are fixed quickly.
>
> In 76819 I developped some missing functionality in the CVE linter, so
> that it will be easier to get proper missing libraries.
>
> A few ideas/questions to advance on that :
> - there are still a lot of linted CVEs for toolchains (former go
>   versions etc) that users should in principle not be exposed to.
>   Should we handle or ignore those?
> - Maybe having a team or a responsible person for this is a good idea.
> - A good practice could be to setup a daily job to get notified of all
>   CVEs, so that we can quickly handle them.

Yes, most distributions have a special security point of contact that is
not publicly archived, to discuss ways to resolve responsible disclosure
vulnerabilities for example.  Seeing some progress on this has been one
blocker for me to increase dependence on Guix for production systems.
The process doesn't have to work perfect (I don't think anyone would
suggest Debian/Fedora/Ubuntu/RHEL/etc handle security bugs perfect
either), but one important step is for the process to exist.

/Simon


signature.asc
Description: PGP signature

Re: Slow guix pull? (was Re: Please don't leave GNU)

[45mg]

45mg <45mg.wri...@gmail.com> writes:

> The initial `git pull` part can be surprisingly slow, though. And it's
> not always a network thing. For example, every single time I run `guix
> pull` it appears to do nothing for like 2 minutes, and then the progress
> bars display as it pulls the entire repo instead of using a cached
> checkout, which takes forever.
>
> It's probably a bug with the caching; I pull from a local authenticated
> fork, which can't be too common, so it makes sense that this hasn't been
> caught before. I haven't had time to properly debug it yet (deleting the
> cache does not help).

Ok, small update: I decided to spend a little time trying to debug it.
It looks like it's a libgit2 issue, not a Guix issue.

Specifically, `update-cached-checkout` in (guix git) calls libgit2's
`git_remote_fetch` (via the guile-git `remote-fetch` binding). I tested
this function on the cached clone [1] and it's /extremely/ slow.

This has been reported upstream:
https://github.com/libgit2/libgit2/issues/5271

[1]
(remote-fetch (remote-lookup 
   (repository-open "~/.cache/guix/checkouts/cachename") 
   "origin")
  #:fetch-options (make-default-fetch-options
   #:verify-certificate? #t))

Re: How is security managed in Guix? Should there be a team?

[Development of GNU Guix and the GNU System distribution.]

Hello,

(CCing some more security people)

On Fri, Apr 04, 2025 at 05:51 PM, Simon Josefsson via \"Development of GNU Guix 
and the GNU System distribution.\" wrote:

> Nicolas Graves  writes:
>
>> Hi Guix!
>>
>> I think one of the things where Guix could be better is security /
>> ensuring CVEs are fixed quickly.
>>
>> In 76819 I developped some missing functionality in the CVE linter, so
>> that it will be easier to get proper missing libraries.
>>
>> A few ideas/questions to advance on that :
>> - there are still a lot of linted CVEs for toolchains (former go
>>   versions etc) that users should in principle not be exposed to.
>>   Should we handle or ignore those?

I think we should definitely handle all CVEs, as best we can. Toolchain
updates will be slower unfortunately, but we have grafts we can do of
course (already too many).

>> - Maybe having a team or a responsible person for this is a good
>> idea.

Do you mean for package-level CVEs and the like? We do have a
security-team:  (linked from the
About menu on the Guix homepage).

Admittedly, we could use more people and rotate out, with some set terms.
It has been mentioned before but not done. I'm on the team and we could
do better. Some things take a while (though I think we have been pretty
good about Guix-specific issues in the recent past), though generally it
is quite low traffic. Prioritizing package updates to do CVEs can and
should be done by us all though.

>> - A good practice could be to setup a daily job to get notified of all
>>   CVEs, so that we can quickly handle them.
>

That does sound helpful, though also running `guix lint` on any
submission or review of a patch should catch CVEs as well. A set
job/notification sounds helpful.

Perhaps you also meant a public security list for things like speedier
review of patches with "security-updates" or CVEs listed? I'm not sure
if we want that together or not with a private list for undisclosed
vulnerabilities, but for sure a way to ping some extra people for such
(public) security updates would be great. Presumably we can leverage
what is done for CCing teams to look for those keywords and CC security?
I try to keep an eye open when I can but that is no substitute.

> Yes, most distributions have a special security point of contact that is
> not publicly archived, to discuss ways to resolve responsible disclosure
> vulnerabilities for example.  Seeing some progress on this has been one
> blocker for me to increase dependence on Guix for production systems.
> The process doesn't have to work perfect (I don't think anyone would
> suggest Debian/Fedora/Ubuntu/RHEL/etc handle security bugs perfect
> either), but one important step is for the process to exist.
>
> /Simon

Simon, do you mean there has or has not been progress? As I noted above,
we do have a private security list for such things though the vast
majority of CVEs tend to be for older packages we have that need to be
updated. Issues specific to Guix do get emailed out and posted on the
website when they are fixed/disclosed.

Oh, while I'm here: we need to ungraft! I would like some sort of
cadence for this, perhaps:

1. Any graft immediately has an ungraft patch applied to, say,
"ungrafting-branch" or some branch focused on that.

2. This is built and merged every month (?) or once a certain number of
ungrafts/package rebuilds are needed (insert favorite arbitrary number),
whichever comes first.

Maybe this needs a proper GCD? I think we could just try something as
this is more basic build management than a change to the project,
because right now we keep falling behind and easily spend more time
grafting than building on user systems.

John

Re: How is security managed in Guix? Should there be a team?

[Leo Famulari]

The guix-security mailing list is meant to be a private messaging system for 
embargoed (i.e. secret) security reports. Everything else should be handled in 
public.

Leo

On Fri, Apr 4, 2025, at 12:21, John Kehayias wrote:
> Hello,
>
> (CCing some more security people)
>
> On Fri, Apr 04, 2025 at 05:51 PM, Simon Josefsson via \"Development of 
> GNU Guix and the GNU System distribution.\" wrote:
>
>> Nicolas Graves  writes:
>>
>>> Hi Guix!
>>>
>>> I think one of the things where Guix could be better is security /
>>> ensuring CVEs are fixed quickly.
>>>
>>> In 76819 I developped some missing functionality in the CVE linter, so
>>> that it will be easier to get proper missing libraries.
>>>
>>> A few ideas/questions to advance on that :
>>> - there are still a lot of linted CVEs for toolchains (former go
>>>   versions etc) that users should in principle not be exposed to.
>>>   Should we handle or ignore those?
>
> I think we should definitely handle all CVEs, as best we can. Toolchain
> updates will be slower unfortunately, but we have grafts we can do of
> course (already too many).
>
>>> - Maybe having a team or a responsible person for this is a good
>>> idea.
>
> Do you mean for package-level CVEs and the like? We do have a
> security-team:  (linked from the
> About menu on the Guix homepage).
>
> Admittedly, we could use more people and rotate out, with some set terms.
> It has been mentioned before but not done. I'm on the team and we could
> do better. Some things take a while (though I think we have been pretty
> good about Guix-specific issues in the recent past), though generally it
> is quite low traffic. Prioritizing package updates to do CVEs can and
> should be done by us all though.
>
>>> - A good practice could be to setup a daily job to get notified of all
>>>   CVEs, so that we can quickly handle them.
>>
>
> That does sound helpful, though also running `guix lint` on any
> submission or review of a patch should catch CVEs as well. A set
> job/notification sounds helpful.
>
> Perhaps you also meant a public security list for things like speedier
> review of patches with "security-updates" or CVEs listed? I'm not sure
> if we want that together or not with a private list for undisclosed
> vulnerabilities, but for sure a way to ping some extra people for such
> (public) security updates would be great. Presumably we can leverage
> what is done for CCing teams to look for those keywords and CC security?
> I try to keep an eye open when I can but that is no substitute.
>
>> Yes, most distributions have a special security point of contact that is
>> not publicly archived, to discuss ways to resolve responsible disclosure
>> vulnerabilities for example.  Seeing some progress on this has been one
>> blocker for me to increase dependence on Guix for production systems.
>> The process doesn't have to work perfect (I don't think anyone would
>> suggest Debian/Fedora/Ubuntu/RHEL/etc handle security bugs perfect
>> either), but one important step is for the process to exist.
>>
>> /Simon
>
> Simon, do you mean there has or has not been progress? As I noted above,
> we do have a private security list for such things though the vast
> majority of CVEs tend to be for older packages we have that need to be
> updated. Issues specific to Guix do get emailed out and posted on the
> website when they are fixed/disclosed.
>
> Oh, while I'm here: we need to ungraft! I would like some sort of
> cadence for this, perhaps:
>
> 1. Any graft immediately has an ungraft patch applied to, say,
> "ungrafting-branch" or some branch focused on that.
>
> 2. This is built and merged every month (?) or once a certain number of
> ungrafts/package rebuilds are needed (insert favorite arbitrary number),
> whichever comes first.
>
> Maybe this needs a proper GCD? I think we could just try something as
> this is more basic build management than a change to the project,
> because right now we keep falling behind and easily spend more time
> grafting than building on user systems.
>
> John

Re: “Build daemon drops its privileges” 👈 blog post

[Ludovic Courtès]

Simon Josefsson  skribis:

> Not invalidating my questions, but maybe some additional insight:
> Reading the guix-install.sh make me believe that one part of my issues
> could be due to:
>
> [ FAIL ] Init system could not be detected.
>
> Several things from guix-install.sh are not run properly in my GitLab
> runner instance.

Oh yes, it won’t install the unprivileged daemon in that case.

> I see two ways forward:
>
> 1) Guix-install.sh is enhanced to support installation of Guix in
> containers that lack normal init systems.  Is this something you want to
> support?  I think you should test guix-install.sh in common containers
> like Debian/PureOS, Ubuntu/Trisquel, Fedora, Alma/Rocky Linux,
> ArchLinux, Alpine, etc and make sure Guix ends up being installed
> correctly.

Yes, I think we should support it.  It’s basically a single-user
installation; no need to all the systemd magic, we can just run
guix-daemon directly without creating a separate user account or
anything.

Any idea how we could detect a single-user container installation?

Anyway, the installation steps are simple here:

  cd /
  tar xf /path/to/guix-binary.tar.xz
  /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon &

And I think that’s it.

Ludo’.

Re: Next period? (was Re: [GCD] Set search paths without program wrappers)

[宋文武]

Simon Tournier  writes:

> Almost one month is over.  For the record, the discussion happens here:
>
> [bug#76428] [GCD PATCH] 
> 003-set-search-paths-without-program-wrappers: Submit.
> iyzsong--- via Guix-patches via 
> Thu, 20 Feb 2025 12:08:23 +0800
> id:20250220040827.4127-1-iyzs...@envs.net
> https://issues.guix.gnu.org/76428
> 
> https://issues.guix.gnu.org/msgid/20250220040827.4127-1-iyzs...@envs.net
> https://yhetil.org/guix/20250220040827.4127-1-iyzs...@envs.net
>
> Do we need more discussions?  It remains at maximum almost one month.
> Else, if the discussion is stalling and a consensus is emerging, maybe
> we could start soon the Deliberation Period.  WDYT?
>

Hi, thanks for the notice, I think so.
I merged it into main, and will send the deliberating announce to
info-guix some minutes later.

Re: Search alerts and Watch issue on mumi

[Gabriel Santos]

>PS: I would appreciate if some CSS-proficient person helped out with
>https://issues.guix.gnu.org/77513
>

I gave it a quick look and removing this line:

mumi.css 1970:2
> line-height: var(--line-height);

Brought "Projects" to the same height as "Search Alert".

-- 
Gabriel Santos

Re: Search alerts and Watch issue on mumi

[Cayetano Santos]

>ven. 04 avril 2025 at 20:07, Arun Isaac  wrote:

> Hi all,
>
> mumi has two exciting new features—search alerts and watch issue. Now,
> you can subscribe to any issue or search query using your feed reader.

Love it. Really. Thanks a lot for all those improvements to mumi, which
is getting more and more useful with time.

> # Search alerts from public inbox
>
> I recently found out that public inbox has similar search alert feeds.

Each has its benefits and drawbacks. As for searches, for example, we have:

https://issues.guix.gnu.org/help#search
https://yhetil.org/guix-patches/_/text/help

which are kind of complementary.

> I would definitely recommend that to anyone who wants to subscribe to only
> a subset of guix-devel conversation, and not the full mailing list.

And not only guix devel, as yhetil includes several mail lists, 
https://yhetil.org.

> # Atom feeds under the hood
>
> Search alerts and issue watching are all powered by Atom feeds under the
> hood. Atom is a web standard.

Free, open and distributed, I must say (emacs people, give elfeed a try).

Thanks again,

C.


signature.asc
Description: PGP signature

Re: How is security managed in Guix? Should there be a team?

[Development of GNU Guix and the GNU System distribution.]

John Kehayias via "Development of GNU Guix and the GNU System
distribution."  writes:

>> Yes, most distributions have a special security point of contact that is
>> not publicly archived, to discuss ways to resolve responsible disclosure
>> vulnerabilities for example.  Seeing some progress on this has been one
>> blocker for me to increase dependence on Guix for production systems.
>> The process doesn't have to work perfect (I don't think anyone would
>> suggest Debian/Fedora/Ubuntu/RHEL/etc handle security bugs perfect
>> either), but one important step is for the process to exist.
>
> Simon, do you mean there has or has not been progress? As I noted above,
> we do have a private security list for such things though the vast
> majority of CVEs tend to be for older packages we have that need to be
> updated. Issues specific to Guix do get emailed out and posted on the
> website when they are fixed/disclosed.

I was seriously out of date with my comment, and I apologize for making
it appear like Guix doesn't have the processes and even a well written
document on exactly what I was looking for:

https://guix.gnu.org/en/security/

However, if I still may make a suggestions (or perhaps rhetorically ask
a question), what I think is still lacking is the kind of security
announcements like Debian and Ubuntu has:

https://lists.debian.org/debian-security-announce/2025/threads.html
https://lists.ubuntu.com/archives/ubuntu-security-announce/2025-April/thread.html

These are regular day-to-day security announcements, which seems more
light-weight than the more Guix-specific security advisories:

https://guix.gnu.org/en/blog/tags/security-advisory/

I think a Guix security team have at least two different tasks:

1) Answer privately about any security coordination needed, especially
about Guix-specific problems.

2) Work on updating packages in Guix with known security issues, wether
publicly or not.

Comparing with Debian, that security team also works to actually publish
updates of packages when external events happen.  For example, comparing
with the debian-security-announce list, who is tasked with noticing and
making a package update of the 'atop' tool for this problem?

https://www.openwall.com/lists/oss-security/2025/03/29/1

For me, I would like to see a distribution I use for production use to
have a track record of say 1 year of publicly acknowledging and
announcing fixes to various world events around it.  Otherwise it feels
quite opaque to trust it, how am I to know if very common security
problems are patched or not?  Of course, for each and every particular
issue, I can research the Guix git history.  But that's not what I am
looking for: instead I'd like to see some continous mailing list or RSS
flow with security fixes that a Guix security team is monitoring and
applying.

I am now waiting for another link to some already existing guix.gnu.org
webpage that make my request feel very embarrassing :)

/Simon


signature.asc
Description: PGP signature

Search alerts and Watch issue on mumi

[Arun Isaac]

Hi all,

mumi has two exciting new features—search alerts and watch issue. Now,
you can subscribe to any issue or search query using your feed reader.

# Watch issues

Subscribe to a specific issue. Look for a "Watch Issue" link in the
top-right corner on the navbar of issue pages. You will get something
like https://issues.guix.gnu.org/issue/77407?format=atom . You can
subscribe to that feed on your feed reader and get all emails coming in
to that issue.

This lets you follow an issue without having to participate in it. And,
you never have to worry about people forgetting to Cc you correctly via
email.

# Search alerts

Even cooler, you can also subscribe to search queries. You put in any
search query at https://issues.guix.gnu.org , and you will find a
"Search Alert" link in the top-right corner on the navbar. You will get
something like
https://issues.guix.gnu.org/search-alert?query=tag%3Ateam-emacs&package=guix
You can subscribe to this feed in your feed reader, and you will get all
emails from issues matching your search queries.

This lets you easily subscribe to the subset of guix issues you are
interested in without having to subscribe to the full firehose. Maybe
you want to only subscribe to the Emacs team—find the search alert feed
for "tag:team-emacs". Or, subscribe to all issues in which you
participated in—submitter:"Arun Isaac" (replace my name with yours, of
course)—and never worry about people not Ccing you correctly. The
possibilities are as limitless as the search queries themselves.

# Search alerts from public inbox

I recently found out that public inbox has similar search alert feeds. I
would definitely recommend that to anyone who wants to subscribe to only
a subset of guix-devel conversation, and not the full mailing list.

# Atom feeds under the hood

Search alerts and issue watching are all powered by Atom feeds under the
hood. Atom is a web standard. And, there exists a plethora of feed
readers out there that can handle them. Feeds are a "pull" mechanism as
opposed to email notifications which are a "push" mechanism. Feeds
provide all the benefits of email notifications (and are arguably
superior), while freeing the server from complex state management.

Hope people find these new features useful! Feedback and patches are
always welcome.

Have a lovely weekend!
Arun

PS: I would appreciate if some CSS-proficient person helped out with
https://issues.guix.gnu.org/77513

Re: bug#76428: [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

[Ludovic Courtès]

Hi 宋文武,

First of all, apologies for not really contributing to the discussion
before.

My sentiment could be summarized as: I agree with the rationale, I like
the idea of storing search path metadata in package outputs, but I’m
concerned about the maintainability and viability of some aspects of the
proposal (see below).  I’ll send my deliberation in a separate message.

宋文武  skribis:

>   ld.so.cache
>   search-paths.d
> GUIX_XDG_DATA_DIRS
> GUIX_GIO_EXTRA_MODULES
> GUIX_GTK4_PATH

I don’t think the “GUIX_” prefix is really justified in the proposal.

There’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow
that this can be generalized to every search path environment variable.

For example, the XDG_ variables are honored by a lot of software, not
just GLib- or Qt-based software, and it’s unrealistic to patch them all.
It’s also undesirable: generally speaking, we want to stay as close to
upstream as possible so that documentation, tutorials, and scripts found
elsewhere also work on Guix.

> ## Find the location of the current executable
>
> To find its search path configuration files when an executable is running,
> we can first find the location of the executable.  Conveniently, Linux
> provides a pseudo-file `/proc/self/exe` for this exact purpose, which works
> well for ELF executables.   But for an interpreter script, `/proc/self/exe`
> would return the file name of its interpreter instead of the script, so
> we patch interpreters to set 2 environment variables:
>
>   - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter
>   - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script

We won’t patch every interpreter out there, that’s not reasonable.

These two variables could also have unexpected consequences since an
attacker could override them to cause confusion.

> ## Implementation plan
>
> A WIP implementation can be found in .
>
> - Add a new function `g_guix_build_search_path_dirs` to GLib, which returns a
>   search path as a list of file or directory names from a search path
>   configuration file and an environment variable.
> - Patch GLib to use `g_guix_build_search_path_dirs` for `GUIX_XDG_DATA_DIRS`,
>   `GUIX_XDG_CONFIG_DIRS`, `GUIX_GIO_EXTRA_MODULES` and
>   `GUIX_GSETTINGS_SCHEMA_DIR`.
> - Patch Python to set `GUIX_INTERPRETER_FILE` and `GUIX_MAIN_SCRIPT_FILE`.
> - Patch Qt to use `g_guix_build_search_path_dirs` for `GUIX_XDG_DATA_DIRS`,
>   `GUIX_XDG_CONFIG_DIRS`, `GUIX_QT_PLUGIN_PATH`, `GUIX_QML_IMPORT_PATH`,
>   `GUIX_QML2_IMPORT_PATH`.
> - Modify `glib-or-gtk-build-system` to get rid of `wrap-program`.
> - Modify `qt-build-system` to get rid of `wrap-program`.

I’m concerned about the cost of maintaining these patches.  Again, the
ld.so patch (for glibc) sets a precedent, but this part of glibc changes
relatively rarely, and it’s just one patch; what if we have to maintain
ten such patches in big and changing libraries like GLib and Qt?

Overall, I think I’d be reassured if we reduced the scope a little bit:
don’t insist on the “GUIX_” prefix, focus on GTK and Qt applications.

Thanks,
Ludo’.

Daemon in Docker/GitLab-CI and Buildah

[Ludovic Courtès]

Hi Simon,

I guess you’re ahead on me on these issues :-) so I’m glad you’re
testing it and reporting back!

Simon Josefsson  skribis:

> I get the following error:
>
> guix pull: error: cloning builder process: Operation not permitted
>
> If I add --cap-add and instead run:
>
> time buildah build --debug --cap-add=CAP_SYS_ADMIN -t 
> $CI_REGISTRY_IMAGE:$CI_JOB_NAME debian-with-install-guix
>
> I get this error:
>
> guix pull: error: while setting up the build environment: cannot set loopback 
> interface flags: Operation not permitted

Is there some AppArmor policy in place or something along these lines?

It definitely works on Debian 12 (which is what we use in the system
test¹), but Ubuntu for instance has an AppArmor policy that restrains
the use of unprivileged user namespaces (I have not looked into how to
work around that).

Thanks,
Ludo’.

¹ https://ci.guix.gnu.org/build/9790957/details