Security-Enhancement: Fine Control for guix pull --allow-downgrades

[Rostislav Svoboda]

Hi geeks,

I've wrote a patch aimed at improving security by introducing
fine-grained control over the `guix pull --allow-downgrades`. This
allows for precise management of channel downgrades during `guix
pull`. Examples:

$ guix pull --allow-downgrades   # same behavior as before -
all current channels can be downgraded (backward compatible)
Updating channel 'foo'; validate-pull 'warn-about-backward-updates'
from Git repository at 'https://foo.domain.org/foo-repo'...
Updating channel 'bar'; validate-pull 'warn-about-backward-updates'
from Git repository at 'https://bar.domain.org/bar-repo'...
Updating channel 'guix'; validate-pull 'warn-about-backward-updates''
from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
[...]

$ guix pull --allow-downgrades=foo   # only the 'foo' channel can
be downgraded
Updating channel 'bar'; validate-pull 'warn-about-backward-updates'
from Git repository at 'https://bar.domain.org/bar-repo'...
Updating channel 'foo'; validate-pull 'ensure-forward-channel-update'
from Git repository at 'https://foo.domain.org/foo-repo'...
Updating channel 'guix'; validate-pull 'ensure-forward-channel-update'
from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
[...]

$ guix pull --allow-downgrades=foo,bar  # same as: guix pull
--allow-downgrades=foo --allow-downgrades=bar
Updating channel 'foo'; validate-pull 'warn-about-backward-updates'
from Git repository at 'https://foo.domain.org/foo-repo'...
Updating channel 'bar'; validate-pull 'warn-about-backward-updates'
from Git repository at 'https://bar.domain.org/bar-repo'...
Updating channel 'guix'; validate-pull 'ensure-forward-channel-update'
from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
[...]


The patch is just a starting point and doesn't have docs yet. If you
see value in this idea, I'll write them.

I’d love to know what you think.

Cheers, Bost
From cd701b66ccb7bcbf3e4e81f1032c5f5261186b5e Mon Sep 17 00:00:00 2001
Message-ID: 
From: Rostislav Svoboda 
Date: Wed, 10 Apr 2024 19:36:33 +0200
Subject: [PATCH] Fine Control: guix pull --allow-downgrades[=CHANNELS]


---
 guix/channels.scm | 118 +++
 guix/scripts/pull.scm | 141 ++
 2 files changed, 165 insertions(+), 94 deletions(-)

diff --git a/guix/channels.scm b/guix/channels.scm
index 66f3122f79..992e7e5ee8 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -497,26 +497,35 @@ (define (channel-instance-primary-url instance)
 
 (define* (latest-channel-instances store channels
#:key
-   (current-channels '())
-   (authenticate? #t)
-   (validate-pull
-ensure-forward-channel-update))
+   (current-channels-with-validation '())
+   (authenticate? #t))
   "Return a list of channel instances corresponding to the latest checkouts of
 CHANNELS and the channels on which they depend.
 
 When AUTHENTICATE? is true, authenticate the subset of CHANNELS that has a
 \"channel introduction\".
 
-CURRENT-CHANNELS is the list of currently used channels.  It is compared
-against the newly-fetched instances of CHANNELS, and VALIDATE-PULL is called
-for each channel update and can choose to emit warnings or raise an error,
+CURRENT-CHANNELS-WITH-VALIDATION is a list of pairs of currently used channels with
+desired validation procedure: (current-channel . validate-pull).  The current-channel
+is compared against the newly-fetched instances of CHANNELS, and validate-pull is
+called for each channel update and can choose to emit warnings or raise an error,
 depending on the policy it implements."
   (define (current-commit name)
 ;; Return the current commit for channel NAME.
-(any (lambda (channel)
-   (and (eq? (channel-name channel) name)
-(channel-commit channel)))
- current-channels))
+(any (lambda (channel-with-validation)
+   (let* [(channel (car channel-with-validation))]
+ (and (eq? (channel-name channel) name)
+  (channel-commit channel
+ current-channels-with-validation))
+
+  (define (current-validate-pull name)
+;; Return the desired validate-pull procedure for channel NAME.
+(any (lambda (channel-with-validation)
+   (let* [(channel (car channel-with-validation))
+  (validate-pull (cdr channel-with-validation))]
+ (and (eq? (channel-name channel) name)
+  validate-pull)))
+ current-channels-with-validation))
 
   (define instance-name
 (compose channel-name channel-instance-channel))
@@ -545,50 +554,53 @@ (define* (latest-channel-instances store channels
   (not (more-specific? channel previous)))
  (loop rest previous-channels 

Re: [shepherd] several patches that i deem ready

[Ludovic Courtès]

Hi Attila,

Attila Lendvai  skribis:

> i have prepared the rest of my commits that were needed to hunt down the 
> shepherd hanging bug. you can find them at:
>
> https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila
>
> there's some dependency among the commits, so sending them to debbugs would 
> be either as one big series of commits, or a hopeless labirinth of patches 
> otherwise.

Yes, but OTOH, piecemeal, focused changes sent to Debbugs are easier to
review for me.  (There are 34 commits in this branch touching different
aspects.)

> therefore i recommend the following workflow instead (assuming that Ludo is 
> pretty much the only one hacking on shepherd):
>
> Ludo, please take a look at my branch, and cherry-pick whatever you are happy 
> with. then based on your feedback, and the new main branch, i'll rebase and 
> refine my commits and give you a head's up when it's ready for another 
> merge/review.
>
> the commits are more or less ordered in least controversial order, modulo 
> dependencies.
>
> the main additions are:
>
> - a multi-layered error handler that got employed at various points in
>   the codebase. this makes shepherd much more resilient, even in case
>   of nested errors, and much more communicative in the log when errors
>   end up happening.
>
> - a lightweight logging infrastructure together with plenty of log
>   lines throughout the codebase, and some hints in the README on how
>   to turn log lines gray in emacs (i.e. easily ignorable).

I cherry-picked a couple of patches.

Some notes:

+ 94c1143 shepherd: Add tests/startup-error.sh

  Redundant with ‘tests/startup-failure.sh’ I think?

+ e802761 service: Add custom printer for  records.

  Good idea, but the goal is to remove GOOPS, so put aside for now.

+ af2ebec service: respawn-limit: make #f mean no limit.

  I’d rather not do that: one can use +inf.0 when needed.

+ 095e930 shepherd: Do not respawn disabled services.

  That’s already the case (see commit
  7c88d67076a0bb1d9014b3bc23ed9c68f1c702ab; maybe we hacked it
  independently in parallel).

+ dbc9150 shepherd: Increase the time range for the default respawn limit.

  This arbitrary and thus debatable, but I think the current setting
  works well, doesn’t it?

+ e03b958 support: Add logging operators.
+ 39c2e14 shepherd: add call-with-error-handling

  I like the idea: we really need those backtraces to be logged!
  There are mostly-stylistic issues that would need to be discussed
  though.  I’d like logging to be less baroque; I’m not convinced by:

+ 7183c9c shepherd: Populate the code with some log lines.

  This is exactly what I’d like to avoid—adding logging statements all
  around the code base, possibly redundant with existing logging
  statements that target users.

  What I do want though is to have “first-class logs”, pretty much like
  what we see with ‘herd log’ etc.  To me, that is much more useful than
  writing the arguments passed each and every ‘fork+exec-command’ call.

I’ll have to look further that branch.  I admit I have limited bandwidth
available and, perhaps selfishly, I like to use my free-time computing
to hack myself.

Regardless, I’d like to thank you for your continued efforts on the
Shepherd.  In one way or another, it contributes to shaping it.

Ludo’.

Re: HEPiX Spring 2024 in Paris, France

[Ludovic Courtès]

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  skribis:

> An event for system administrators in high-energy physics may still be
> looking for for talks for next week in Paris:
>
> https://indico.cern.ch/event/1377701/overview
>
> The event is called HEPiX:
>
> https://www.hepix.org/

Looks like an interesting venue to talk about reproducible deployment,
indeed.  Maybe next time?

Ludo’.

Re: The `channels' field of `operating-system' record

[Ludovic Courtès]

Hello,

Tomas Volf <~@wolfsden.cz> skribis:

> After ~2 hours of digging I realized this is caused by the changes in
> 883e69cdfd226c8f40b6e3b76ce0740b59857de6.
>
> I see couple of issues here (in no particular order, questions prefixed with 
> Q):
>
> * My configuration file just *silently* stopped working.
>
> That is not great for obvious reasons.
>
> * There is no news entry

Oops, my apologies; the change felt pretty innocuous when I merged it,
but in hindsight, it seems clear that a news entry was warranted.
Lesson learned.

We can still add that news entry, though fewer people will see it now.

Thoughts?

> * Broken default behavior.
>
> Currently, out of the box, extra-special-file with "/etc/guix/channels.scm" 
> just
> does not do anything.  No error, no warning.  That is pretty unexpected.

Yes, why is that?  At first sight, that’s because ‘extra-special-file’
does things at activation time; there’s no check happening at
configuration time.

It was really meant for /bin/sh, /usr/bin/env, and similar.  The reason
its effect is silently dismissed in this case is, I think, because its
activation runs before the /etc activation.  So it’s really bad luck.

I’m not sure what to do here, apart from maybe recommending against
broad use of this service.

> * There is no terse way to turn it off
>
> Currently my configuration contains this:
>
>   (modify-services %base-services
> (guix-service-type
>  config => (guix-configuration
> (inherit config)
> (channels #f

Hmm right.  You do want to create /etc/guix/channels.scm though, right?
(Since you had it initially.)

> * Q: Is there an easy way to fill (channels)?
>
> After I learned that (channels) is a thing, I wanted to use it, but did not 
> find
> any simple way how to do so.  My channels are in channels.scm produced by 
> `guix
> describe --format=channels', and I do not see any simple way to pass the 
> content
> of that file into (channels).  No, it does not accept (local-file).  I tried
> just (read)-ing it, but that too does not work.

That would be: (guix-configuration … (channels (load "channels.scm"))).

> * Q: Is the default value right?
>
> Currently it defaults to %default-channels, which causes all this magic.  
> Would
> it not be better to default to #f, so that it would do nothing magical out of
> the box and would be backwards compatible?  You could still turn it on by
> (Somehow?  See above.) providing desired value.

Yes, we could change the default to #f: it’s equivalent to
‘%default-channels’ but wouldn’t cause the undesirable side effect you
experienced.

Do you want to prepare a patch (or two)? :-)

Thanks for your feedback, and apologies again for the inconvenience!

Ludo’.

Re: A paper about Plan 9 and Guix

[Ludovic Courtès]

Hi,

Edouard Klein  skribis:

> I'll be presenting it not next week end, but the one after (12-14 April
> 2024).

Yay, congrats!

> I'd be happy if some of you would be so kind as to read it with their
> extensive knowledge of Guix, in case I've made a mistake somewhere.
>
> https://the-dam.org/docs/explanations/Plan9ListenOnLinux.html

Interesting read!

I wonder to what extent the combination of ‘make-inetd-constructor’ and
‘least-authority-wrapper’ would fit the bill for you?  (This is currently
used for the bitlbee, dicod, and rsync services.)  It seems to address
the main shortcomings listed in Section 1.

Thanks,
Ludo’.

Re: Should we include nss-certs out of the box?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> It's been Guix policy to let people choose whether to install or not TLS
> root certificates and which one to their machine.  While I applaud the
> idea to have the users make a conscious decision about it, in practice I
> suppose very few of us choose to *not* install any as that basically
> breaks using web browsers, especially ones like IceCat which (by
> default) ensures HTTPS is used on every page.

Right.

> It apparently even makes it impossible to run 'guix pull', if I am to
> believe bug#62026.

I don’t think that’s the case: see use of ‘le-certs’ in (guix scripts
pull).

> Should we do as in bug#62026 and have this package be part of the
> recommended basic installation?  It'd be in the basic set of an
> operating-system packages (via its default %base-packages set).  It
> could still be manipulated via the Guix API (filtered out/replaced with
> something else).
>
> Is anyone opposed to having nss-certs in %base-packages?

No objection from me.  I’m partly responsible for the initial choice to
not include nss-certs by default, but as you write, most likely everyone
installs it these days.

Note that we’ll also need to remove that choice from the installer in
(gnu installer services).

Thanks!

Ludo’.

Re: Shepherd timers

[Ludovic Courtès]

Felix Lechner  skribis:

> The status seems a bit bungled, though.  I now use a lambda, i.e. no
> 'command', with a fresh pull from 'devel'.  Thanks!

[...]

> Upcoming timer alarms:
> Backtrace:
>8 (primitive-load "/run/current-system/profile/bin/herd")
> In shepherd/scripts/herd.scm:
> 796:9  7 (main . _)
> In ice-9/boot-9.scm:
>   1747:15  6 (with-exception-handler # ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ # _)
> In shepherd/scripts/herd.scm:
>727:11  5 (_)
> In srfi/srfi-1.scm:
> 634:9  4 (for-each # args> ((service (version 0) (# (#)) # ?)))
> In shepherd/scripts/herd.scm:
>323:19  3 (display-timer-events #< seconds: (0) minutes: 
> (3 8 13 18 23 28 33 38 43 48 53 58) h?> ?)
> In shepherd/service/timer.scm:
>253:21  2 (next-calendar-event #< seconds: (0) minutes: (3 
> 8 13 18 23 28 33 38 43 48 53 58) ho?> ?)
>233:18  1 (week-days->month-days #f 4 _)
> In unknown file:
>0 (memv 1 #f)
>
> ERROR: In procedure memv:
> In procedure memv: Wrong type argument in position 2 (expecting list): #f

Could you share this service or at least the (calendar-event …) bit?

Thanks,
Ludo’.

Re: Shepherd timers

[Ludovic Courtès]

Hi!

Felix Lechner  skribis:

> On Sun, Mar 24 2024, Ludovic Courtès wrote:
>
>> you can do anything you can do with a service: stop it, unload it,
>> load a replacement, and so on.
>
> Wow, do I love those timers!  I just converted my system Mcron jobs to
> Shepherd timers.  The user jobs are next.  What a great new feature!

:-)

> One small suggestion:
>
> Could calendar-event please offer a symbolic interface for days-of-week?
> I'm thinking of 'monday, 'tuesday, and so on instead of numbers.

Sure, I can look into it.

Maybe we’ll need to support both so that one can still more conveniently
generate lists of weekdays.

Thanks your feedback!

Ludo’.

Re: Status of ‘core-updates’

[Ludovic Courtès]

Hello!

Josselin Poiret  skribis:

> Disclaimer: I've been quite busy with work recently and haven't been
> able to work on core-updates that much (having to build the world
> locally doesn't help).

No problem.  We should find someone willing to pick up the coordination
work for the coming month or so.  Any volunteer?  :-)

To be clear (but I guess it’s crystal clear to anyone who’s been around
long enough :-)), what we need most is someone to keep track of changes,
coordinate efforts, decide what goes in the branch and what’s postponed
or moved to a separate branch, and send periodic (weekly) status updates
over the course of a couple of months.  This can (and probably should)
be done without doing any actual hacking on the branch.

> Currently, the desktop system image doesn't build anymore because we've
> also integrated patches to use pkgconf instead of pkg-config.  I think
> the effort to actually make that work with all of our packages is going
> to be a bit too much to handle right now.  IMO, we should probably
> revert/branch out before then so that we can push core-updates past the
> finish line.  A feature branch to integrate pkgconf properly could then
> be worked on later.

Last time we discussed it on IRC, you were in the process of putting up
a branch without those pkgconf changes, IIRC.  Were you able to complete
that work?

If not, I guess that’ll be the first thing to do, unless someone has a
better idea.

> Other than that, I was able to get a working desktop before the
> aforementioned patches but with some locale errors that I fixed with
> ae07bc2dd0124b625acf70e594ccc90d6d128562, so I'm not expecting too much
> trouble.  We'll probably have to add libxcrypt as an input to some other
> packages that I haven't tested yet, but that's quite trivial.

Alright.

Thanks for all the work so far!

Ludo’.

Re: Error handling when 'guix substitute' dies

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Philip McGrath  skribis:
>
>> I don't know if the root cause is related, but this reminded me of
>> some networking errors I sometimes get accessing substitutes. I had
>> the luck (good or bad?) to get an example while building
>> , so I thought I'd report.
>>
>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> ERROR:
>>>   1. :
>>>   uri: #< scheme: https userinfo: #f host: 
>>> "bordeaux-us-east-mirror.cbaines.net" port: #f path: 
>>> "/nar/lzip/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz" query: 
>>> #f fragment: #f>
>>>   code: 404
>>>   reason: "Not Found"
>>>   headers: ((server . "nginx") (date . #>> minute: 20 hour: 6 day: 1 month: 4 year: 2024 zone-offset: 0>) 
>>> (content-type application/json (charset . "utf-8")) (content-length . 35) 
>>> (connection keep-alive))
>>>   2. : 
>>> "https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz:
>>>  HTTP download failed: 404 (\"Not Found\")"
>>> substitution of 
>>> /gnu/store/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz failed
>>> guix build: error: corrupt input while restoring archive from #>> file 7f9f7deaad90>
>
> No, that’s another problem: bordeaux.guix would delete nars before their
> advertised TTL has expired.  See .
> Chris explained that this was solved recently I believe.

This only applied to zstd nars, whereas this is an lzip nar that was
apparently missing at the time.

Maybe this is/was some problem with the mirror.


signature.asc
Description: PGP signature

Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[Matt]

We're working through a list of feedback one item at a time:
https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00117.html

We have completed the first two items.

The next item reported is:

#+begin_quote
2.4 Setting up the deamon

Seems like an issue with info.  Have seen this in the Emacs manual as well.  
There is also sometimes see see (doc)

L15 See also see Substitutes.
#+end_quote

This sounds like the use of an @xref instead of @ref.  However, I can't find it 
in the current version (5a95cf76) of the documentation, nor the reported 
version (ee7c9d25).  The last change to doc/guix.texi at that the reported time 
was in e5ed1712 (git log -n 1 ee7c9d25 -- doc/guix.texi).

The full reported sentence currently reads,

#+begin_quote
See also @ref{Substitutes}, for information on how to allow the daemon to 
download pre-built binaries.
#+end_quote

The use of the comma after "Substitutes" is inappropriate, if I have the 
terminology correct, because "See also Substitutes" is not a participial 
phrase.  "Also" and "information on" are also unnecessary.  I suggest the 
following:

#+begin_quote
See @ref{Substitutes} for how to allow the daemon to download pre-built 
binaries.
#+end_quote

Searching for "see also" turns up the following in 'Mail Services':

#+begin_quote
See also ssl=required setting.
#+end_quote

This needs "the" before "ssl=required" as it refers to a specific setting.  It 
should probably use the @option or @samp markup:

#+begin_quote
See also the @samp{ssl=required} setting.
#+end_quote

I have opted for @samp because it's used elsewhere for similar items.  In the 
same section is:

#+begin_quote
NOTE: See also @samp{disable-plaintext-auth} setting.
#+end_quote

This too should have "the" before the setting.  The "NOTE:" designation is also 
unnecessary.  I suggest:

#+begin_quote
See also the @samp{disable-plaintext-auth} setting.
#+end_quote

Included is a patch which makes these suggested changes.

It was advised to submit the previous patch to guix-patches.  I opted to submit 
this next patch here to keep the thread connected since it's part of a larger 
discussion (I suppose).  If we're agreed that guix-patches is more appropriate, 
I can submit the next item in a new thread there using the same message format 
I've been following.  Thoughts?


0001-doc-Fix-grammar-and-markup.patch
Description: Binary data

Re: Emacs and Gnome branches are merged now

[Ludovic Courtès]

Hello,

Liliana Marie Prikler  skribis:

> I've now pushed the merge commits for both emacs-team and gnome-team. 
> If you have a weak machine, PLEASE DO NOT PULL IMMEDIATELY AND WAIT FOR
> CI TO CATCH UP!  Despite efforts to prebuild things on the respective
> branches, the merge commit carries with it a rebuild of the most nasty
> package to have to compile locally.

Congrats to you and everyone involved!

Ludo’.

Re: guix --container is RAM hungry

[Ludovic Courtès]

Hi,

Edouard Klein  skribis:

> Maxim Cournoyer  writes:
>
>> Hi Ludovic,
>>
>> Ludovic Courtès  writes:
>>
>>> Hi Edouard,
>>>
>>> Edouard Klein  skribis:
>>>
 I'm a huge fan of guix --container, and I created a system to use those
 by default for network services. But the VPS these services run on has
 only 2GB of RAM, and I just realized that a container, by default,
 requires at least 200MB.
>>>
>>> Ouch, confirmed:
>>>
>>> $ \time -v guix shell -C coreutils -- uname 2>&1 |grep 'Maximum resident'
>>> Maximum resident set size (kbytes): 283048
>>> $ \time -v guix shell coreutils -- uname 2>&1 |grep 'Maximum resident'
>>> Maximum resident set size (kbytes): 56588
>>> $ guix describe
>>> Generation 297  Mar 24 2024 23:12:25(current)
>>>   guix 28bc0e8
>>> repository URL: https://git.savannah.gnu.org/git/guix.git
>>> branch: master
>>> commit: 28bc0e870b4d48b8e3e773382bb0e999df2e3611
>>>
>>>
>>> As raingloom and Ricardo wrote, there’s a Guile process that keeps
>>> waiting.
>>
>> Is there a technical reason for this?  Couldn't we replace the
>> current Guix process with 'exec', as hinted by Edouard?
>>
>
> Raingloom did, I just reported the problem without investigating the
> cause.

Did what?

I don’t think execing is possible in this case, unless we let the user’s
process run as PID 1 inside its namespace (which isn’t recommended).
See #:child-is-pid1? in ‘call-with-container’.

I submitted a patch set to help a bit with that and related issues:

  https://issues.guix.gnu.org/70132

(I shouldn’t have said in the cover letter that it’s a boring patch
series: I got zero comments.  :-))

Thanks,
Ludo’.

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Ludovic Courtès]

Hi,

Ekaitz Zarraga  skribis:

> On 2024-04-04 21:48, Attila Lendvai wrote:
>> all in all, just by following my gut insctincts, i was advodating
>> for building everything from git even before the exposure of this
>> backdoor. in fact, i found it surprising as a guix newbie that not
>> everything is built from git (or their VCS of choice).
>
> That has happened to me too.
> Why not use Git directly always?

Because it create{s,d} a bootstrapping issue.  The
“builtin:git-download” method was added only recently to guix-daemon and
cannot be assumed to be available yet:

  https://issues.guix.gnu.org/65866

> In the bootstrapping it's also a problem, as all those tools
> (autotools) must be bootstrapped, and they require other programs
> (compilers) that actually use them. And we'll be forced to use git,
> too, or at least clone the bootstrapping repos, git-archive them
> ourselves and host them properly signed. At least, we could challenge
> them using git (similar to what we do with the substitutes), which we
> cannot do right now with the release tarballs against the actual code
> of the repository.

I think we should gradually move to building everything from
source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.

This has been suggested several times before.  The difficulty, as you
point out, will lie in addressing bootstrapping issues with core
packages: glibc, GCC, Binutils, Coreutils, etc.  I’m not sure how to do
that but…

> In live-bootstrap they just write the build scripts by hand, and
> ignore whatever the ./configure script says. That's also a reasonable
> way to tackle the bootstrapping, but it's a hard one. Thankfully, we
> are working together in this Bootstrapping effort so we can learn from
> them and adapt their recipes to our Guix commencement.scm module. This
> would be some effort, but it's actually doable.

… live-bootstrap can probably be a good source of inspiration to find a
way to build those core packages (or some of them) straight from a VCS
checkout.  And here the trick will be to find a way to do that in a
concise and maintainable way (generating config.h and Makefiles by hand
may prove unmaintainable in practice.)

Ludo’.

Re: Error handling when 'guix substitute' dies

[Ludovic Courtès]

Hi,

Lars Bilke  skribis:

> I ran the command in a loop on 4 machines for around 2 hours doing 1 request 
> per machine per second but no errors occured...

Hmm OK, thanks for testing.  Not sure how to understand the problem
then.  It could be triggered keep-alive and connection reuse, who knows.

If/when that happens again, could you please try to gather as much data
as possible about networking conditions?

Thanks,
Ludo’.

Re: Error handling when 'guix substitute' dies

[Ludovic Courtès]

Hi,

Philip McGrath  skribis:

> I don't know if the root cause is related, but this reminded me of
> some networking errors I sometimes get accessing substitutes. I had
> the luck (good or bad?) to get an example while building
> , so I thought I'd report.
>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> ERROR:
>>   1. :
>>   uri: #< scheme: https userinfo: #f host: 
>> "bordeaux-us-east-mirror.cbaines.net" port: #f path: 
>> "/nar/lzip/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz" query: 
>> #f fragment: #f>
>>   code: 404
>>   reason: "Not Found"
>>   headers: ((server . "nginx") (date . #> minute: 20 hour: 6 day: 1 month: 4 year: 2024 zone-offset: 0>) (content-type 
>> application/json (charset . "utf-8")) (content-length . 35) (connection 
>> keep-alive))
>>   2. : 
>> "https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz:
>>  HTTP download failed: 404 (\"Not Found\")"
>> substitution of 
>> /gnu/store/r8w68mhsvqlkvazncvfn36jcpvz404x6-chez-fmt-0.8.11.tar.gz failed
>> guix build: error: corrupt input while restoring archive from #> 7f9f7deaad90>

No, that’s another problem: bordeaux.guix would delete nars before their
advertised TTL has expired.  See .
Chris explained that this was solved recently I believe.

Ludo’.

policy for packaging insecure apps

[Attila Lendvai]

the context:


there's an app currently packaged in guix, namely 
gnome-shell-extension-clipboard-indicator, that has a rather questionable 
practice: by default it saves the clipboard history (passwords included) in 
clear text, and the preferences for it is called something obscure. its author 
actively defends this situation for several years now, rejecting patches and 
bug reports.

a detailed discussion is available at:

https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/issues/138

the fact that its name suggests that it is *the* standard gnome clipboard app 
makes the situation that much worse.


my question:


how shall we deal with a situation like this?

 1) shall i create a guix patch that makes the necessary changes in
this app, and submit it to guix? this would be a non-trivial, and
a rather hidden divergence from upstream, potentially leading to
confusion.

 2) is there a way to attach a warning message to a package to explain
such situations to anyone who installs them? should there be a
feature like that? should there be a need for a --force switch, or
an interactive y/n, to force installing such apps?

 3) is there a point where packages refusing to address security
issues should be unpackaged? and also added to a blacklist until the
security issue is resolved? where is that point? would this one
qualify?

 4) is this the responsibility of a project like guix to address
situations like this?

 5) do you know another forum where this dispute should be brought up
instead of guix-devel?

i'm looking forward to your thoughts, and/or any pointers or patches to the 
documentation that i should read.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
The price of liberty is eternal vigilance.

Re: Google Summer of Code Inquiry

[Efraim Flashner]

On Tue, Apr 09, 2024 at 05:25:35PM +0200, Ludovic Courtès wrote:
> Hi Sebastian,
> 
> Sebastian Dümcke  skribis:
> 
> > just wanted to chime in. Since last week I have some working code to
> > generate AppImages with guix pack. I was planning on tidying this up
> > for submission over the next weeks.
> > There is still work to do regarding documentation, adding options
> > specific to the AppImage format, building the AppImageKit runtime from
> > source and a lot of testing.
> 
> This is great news!  Looking forward to incorporating those changes.
> 
> > However, I believe that the remaining effort is around 8-10 hours. I
> > am happy to hand the code over to you to finish up and co-mentor
> > (though this patch would be my first contribution to guix) if you
> > think this is appropriate.
> 
> It does sound like it jeopardizes this specific project.  In a way,
> that’s a good problem to have as a project, but it does mean that
> Zachary would need to look for another project (which could still be
> related to ‘guix pack’).
> 
> Thoughts?

There's always the option of trying to create flatpaks using Guix.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: [fr] Moment de convivialité Guix@Paris en avril

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à 19h au local de l'April… ou chez Easter-eggs. Et pour
celles et ceux qui ne veulent pas braver la circulation parisienne,
c’est en direct *live* sur .

Au plaisir de vous y rencontrer,

-- 
Tanguy

Clojure is working on better supporting XDG base directory rules

[Jesús Gómez]

Hello.

I just wanted to mention that the Clojure project had recently
accepted to work on enhancing its support to XDG base directory rules,
as described in their ticket TDEPS-262[1]

I'm sure there are important considerations related to your work. For
example, how would an eventual change affect Debian users when
upgrading the Clojure package?

Anyway, I'm going to work the best I can on this issue, and I'm
opening this thread simply as a "heads-up" and a place to discuss it.

Thank you for your work and contribution to Guix and Clojure!

[1] https://clojure.atlassian.net/browse/TDEPS-262