Re: Security-Enhancement: Fine Control for guix pull --allow-downgrades
Hello Florian, > do not use [] for parentheses; always use (), which is Guix policy. Changed. > This is a good idea in my opinion, but please send the > patch as a mail to guix-patc...@gnu.org. Done. See https://issues.guix.gnu.org/70353 Cheers, Bost
Security-Enhancement: Fine Control for guix pull --allow-downgrades
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 re
Re: Backdoor in upstream xz-utils
> >> Is there a way we can blacklist known bad versions?
>
> I'm not sure what you mean, but I don't think so.
For beginning, what about adding a short comment:
diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 5de17b6b51..fd5ab7ba00 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -493,6 +493,8 @@ (define-public pbzip2
(define-public xz
(package
(name "xz")
+;;; Be reminded of the xz/liblzma backdoor in the versions 5.6.0 and 5.6.1!
+;;; See https://www.openwall.com/lists/oss-security/2024/03/29/4
(version "5.2.8")
(source (origin
(method url-fetch)
as a single commit, with an appropriate commit message. That's a bang
for pretty much no money.
> The main danger is in guix time-machine to the past
Good point. So then a little note here, too:
diff --git a/doc/guix.texi b/doc/guix.texi
index 69a904473c..60909adf5f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -5012,10 +5012,13 @@ Invoking guix time-machine
@quotation Note
The history of Guix is immutable and @command{guix time-machine}
provides the exact same software as they are in a specific Guix
-revision. Naturally, no security fixes are provided for old versions
-of Guix or its channels. A careless use of @command{guix time-machine}
-opens the door to security vulnerabilities. @xref{Invoking guix pull,
-@option{--allow-downgrades}}.
+revision. Naturally, no security fixes are provided for old versions of
+Guix or its channels. A careless use of @command{guix time-machine}
+opens the door to security vulnerabilities, or potentially even
+backdoors. (Do you remember the
+@uref{https://www.openwall.com/lists/oss-security/2024/03/29/4, backdoor
+in upstream xz/liblzma leading to ssh server compromise}?)
+@xref{Invoking guix pull, @option{--allow-downgrades}}.
@end quotation
Cheers Bost
Re: Google Season of Docs 2024
> 3. Any for improving the documentation? Example snippets for every function. Basically like https://clojuredocs.org/ but for Guile / Guix. Thanks in advance.
Re: Guix CLI, thoughts and suggestions
This is something we're capable of too, right? https://everything.curl.dev/libcurl/libcurl Bost Le lun. 22 janv. 2024 à 01:22, Carlo Zancanaro a écrit : > > Hi Ian, > > On Sat, Jan 20 2024, Ian Eure wrote: > > I agree that this would make sense, but my understanding is that `guix > > package' doesn’t work like that -- it only performs the final > > operation in the list. IMO, it should either do *everything* the > > commands specify, or print an error and take no action. > > It can accumulate multiple commands. As an example, if you create a > profile with a single package in it: > > $ guix package -i hello > The following package will be installed: > hello 2.12.1 > ... more output... > > then you can remove that package and install another package in a single > transaction: > > $ guix package -r hello -i coreutils > The following package will be removed: > hello 2.12.1 > > The following package will be installed: > coreutils 9.1 > ... more output... > > The inconsistency here is that some commands can be combined > (specifically adding and removing), whereas others cannot (probably > everything else). > > > I agree, I don’t think the situation can be improved without finding a > > solution to preserve BC. But, I didn’t think it was worth making > > detailed plans for any of this before gauging whether the problem was > > one broadly considered to be worth solving. > > I think it would be great to have a consistent CLI, so I would love it > if we were able to solve this problem. > > Carlo >
Re: Guix CLI, thoughts and suggestions
I find the discrepancy regarding two dashes '--' is annoying: $ guix package --list-generations=1d ... $ guix describe --list-generations=1d guix system: error: list-generations=1d: unrecognized option $ guix describe list-generations=1d ... And more importantly, I'd be happy if the CLI and REPL syntax were united, so that there's minimal difference between a shell command call and a Guile function call. E.g. following would do the same: $ guix :show emacs scheme@(guix-user)> (guix :show emacs) This would greatly facilitate the shell-to-Guile script conversion. (This way, for comp-sci newcomers, it's much easier to see what a (bash) shell, with its quirky DSL, really is - not an interface making computers easier to use, but a barrier obstructing you from properly using computers as programmable stateful machines. See https://www.gnu.org/software/guile/manual/html_node/Prompts.html ) Unfortunately, the '#' indicates a comment-start in shells and, as AFAICS in the source code, we prefer the #:keyword syntax over :keyword. (Here, in the first step, on an experimental branch, we could try to add (read-set! keywords 'prefix) everywhere, just to see what breaks ;-) Cheers Bost
Re: Commit Access: Sharlatan Hellseher
> Just my 2 cents, I imagine every person here has their own workflow. I personally don't have any yet (and I assume I'm not the only one) so I'm really thankful for your snippet. Cheers Bost
