grafted package and CLI

grafted package and CLI

[zimoun]

Hi,

Commit 3fc6709d4285f44d1e861c7b09951adf3073e898 is a security fixes for
the package ’curl’; it reads,

--8<---------------cut here---------------start------------->8---
(define-public curl
   (package
    (name "curl")
    (version "7.79.1")
+   (replacement curl-7.84.0)

[...]

+;; Replacement package with fixes for multiple vulnerabilities.
+;; See <https://curl.se/docs/security.html>.
+(define curl-7.84.0
+  (package
+    (inherit curl)
--8<---------------cut here---------------end--------------->8---

So far, so good!  Well, it leads to these behaviour:

        $ guix show curl | recsel -p name,version
        name: curl
        version: 7.79.1

        $ guix build curl -S
        /gnu/store/67w9zrlm1xahczf55f9rd15aaqadbixj-curl-7.84.0.tar.xz

Or even, it can be confusing:

        $ guix shell curl@7.79.1 -- curl --version
        curl 7.84.0 (x86_64-unknown-linux-gnu) libcurl/7.84.0 GnuTLS/3.7.2 zlib/1.2.11 libidn2/2.3.1 nghttp2/1.44.0
        Release-Date: 2022-06-27
        [..]

The issue is not new, e.g., see [1].  I proposed a patch [2] (see below)
which addresses the issue with “guix show”.

However, it does not address issue with “guix package -A | grep ^curl”;
and it is potentially not fixable because it uses
’fold-available-packages’ which loads the cache (for performance) and
this cache does not contain the ’replacement’ field – it is not a good
idea to introduce it, IMHO.

About “guix shell”, a warning could be added.

Well, WDYT?


Cheers,
simon


--8<---------------cut here---------------start------------->8---
diff --git a/guix/ui.scm b/guix/ui.scm
index 7fbd4c63a2..b6497f5e5c 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -1528,9 +1528,18 @@ HYPERLINKS? is true, emit hyperlink escape sequences when appropriate."
   (define (package<? p1 p2)
     (string<? (package-full-name p1) (package-full-name p2)))

+  (define replacement
+    (package-replacement p))
+
   ;; Note: Don't i18n field names so that people can post-process it.
   (format port "name: ~a~%" (package-name p))
   (format port "version: ~a~%" (package-version p))
+  (when replacement
+    (unless
+     (string=?
+      (package-version p)
+      (package-version replacement))
+     (format port "replacement: ~a~%" (package-version replacement))))
   (format port "outputs: ~a~%" (string-join (package-outputs p)))
   (format port "systems: ~a~%"
           (string-join (package-transitive-supported-systems p)))
--8<---------------cut here---------------end--------------->8---

1: <https://yhetil.org/guix/871rc5jv1o.fsf@netris.org>
2: <https://yhetil.org/guix/86im5a6ea4.fsf@gmail.com>

Re: grafted package and CLI

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> Or even, it can be confusing:
>
>         $ guix shell curl@7.79.1 -- curl --version
>         curl 7.84.0 (x86_64-unknown-linux-gnu) libcurl/7.84.0 GnuTLS/3.7.2 zlib/1.2.11 libidn2/2.3.1 nghttp2/1.44.0
>         Release-Date: 2022-06-27
>         [..]
>
> The issue is not new, e.g., see [1].  I proposed a patch [2] (see below)
> which addresses the issue with “guix show”.
>
> However, it does not address issue with “guix package -A | grep ^curl”;
> and it is potentially not fixable because it uses
> ’fold-available-packages’ which loads the cache (for performance) and
> this cache does not contain the ’replacement’ field – it is not a good
> idea to introduce it, IMHO.

Usually, when the replacement is a different version, we make it public,
so it also shows up in ‘guix package -A’.  It’s just a convention, but
it’s probably good enough?

> diff --git a/guix/ui.scm b/guix/ui.scm
> index 7fbd4c63a2..b6497f5e5c 100644
> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -1528,9 +1528,18 @@ HYPERLINKS? is true, emit hyperlink escape sequences when appropriate."
>    (define (package<? p1 p2)
>      (string<? (package-full-name p1) (package-full-name p2)))
>
> +  (define replacement
> +    (package-replacement p))
> +
>    ;; Note: Don't i18n field names so that people can post-process it.
>    (format port "name: ~a~%" (package-name p))
>    (format port "version: ~a~%" (package-version p))
> +  (when replacement
> +    (unless
> +     (string=?
> +      (package-version p)
> +      (package-version replacement))
> +     (format port "replacement: ~a~%" (package-version replacement))))
>    (format port "outputs: ~a~%" (string-join (package-outputs p)))
>    (format port "systems: ~a~%"
>            (string-join (package-transitive-supported-systems p)))

I’m all for it!  If you want you can resent the whole thing produced by
‘git format-patch’, or I can apply it and provide a commit message on
your behalf.

Thanks,
Ludo’.

Re: grafted package and CLI

[zimoun]

Hi,

On Thu, 07 Jul 2022 at 10:00, Ludovic Courtès <ludo@gnu.org> wrote:

> Usually, when the replacement is a different version, we make it public,
> so it also shows up in ‘guix package -A’.  It’s just a convention, but
> it’s probably good enough?

About “guix package -A”, we cannot do more, so let say it is good
enough. ;-)

About other situation (guix shell, install, etc.), maybe it could useful
to display a warning or something.


Aside, the convention is to make the replacement public for different
versions, so my naive question is: why not hide the replaced version?


Cheers,
simon

Re: grafted package and CLI

[Ludovic Courtès]

zimoun <zimon.toutoune@gmail.com> skribis:

> Aside, the convention is to make the replacement public for different
> versions, so my naive question is: why not hide the replaced version?

You mean hide with the ‘hidden?’ property?

Good question.  There’s probably little point in exposing the original
(replaced) version, so yes, hiding it makes sense I guess.  Should we
just do that systematically?

Ludo’.

Re: grafted package and CLI

[zimoun]

Hi,

On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès <ludo@gnu.org> wrote:

> You mean hide with the ‘hidden?’ property?

I do not know what I mean. ;-)

The replacement could have an ’hidden?’ property or not being
’define-public’.  

> Good question.  There’s probably little point in exposing the original
> (replaced) version, so yes, hiding it makes sense I guess.  Should we
> just do that systematically?

Well, we should follow the same strategy independently of the version
bump.  Systematically hide original (replaced) original version.

Bah I do not know, what other think?


Cheers,
simon

Re: grafted package and CLI

[bokr]

Hi Simon,

On +2022-07-07 18:58:41 +0200, zimoun wrote:
> Hi,
> 
> On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > You mean hide with the ‘hidden?’ property?
> 
> I do not know what I mean. ;-)
> 
> The replacement could have an ’hidden?’ property or not being
> ’define-public’.  
> 
> > Good question.  There’s probably little point in exposing the original
> > (replaced) version, so yes, hiding it makes sense I guess.  Should we
> > just do that systematically?
> 
> Well, we should follow the same strategy independently of the version
> bump.  Systematically hide original (replaced) original version.
> 
> Bah I do not know, what other think?
> 
> 
> Cheers,
> simon
>

"Other" here, reacting to word "hidden":
(equal? hidden some-trojan-horse-contents) :-)

I like "hidden" when it de-clutters my workflow, BUT:

Only when I know it comes with a simple toggle to a view
that reveals what is hidden, to any desired detail,
e.g., with a brief summary and a menu (a la info, with
Ctl-s searchability) to inspect potentially everything reachable.

Otherwise I worry about what's hidden :)

E.g., I'd like to be able to toggle into a first level inspection view
with some default info and a command line prompt where I could type
a repl CLI command like
    reveal-vulns [OPTS]...
that by default starts in the current command line parsing environment,
and with a "-all" opt would show things like OTTOMH e.g., (not all vuln spots here)

   * current execution context, e.g. pidparents defined as:
    -----------cut here---------------start------------->8---
    #!/usr/bin/bash
    # ~/bin/pidparents
    pid=${1:-$$}        #this process if no pid specified as $1
    while [ $(($pid)) -gt 0 ]; do    
          ps h -p $pid -o comm,tt,pid,stat,args
          pid=$(ps -q $pid -o ppid=)
    done
    -----------cut here---------------end--------------->8---
   * door to "systemctl status" etc if available 
   * OS kernel info -- uname -a and doors to details
   * GPU info, other potential attack-via-DMA programmable devices
   * CPU info, fully capable of secure hypervising of VMs? etc. 
   * BIOS type, current booting mode, etc, or info how to boot grub2 or
     whatever tool on the current system to explore that.
   
   * what is not built from guix cloned repo sources (substituted binaries, etc)
   * what is trusted mirror list, with estimate of timeliness vs master sources
   * what is invocable that uses setuid or setgid or sudo or su
   * can a setgid video group invoker present me with a spoof screen?
   * will a newly plugged in USB be accepted as a keyboard just because
     it claims to be, without vetting by asking human and auth by serial?
     - will keystrokes from it be injected into the current keyboard
       input stream? (Insanely promiscuous legacy practice IMO)
   * unusual ELF files (summary: how many exist,+ doors to detailed views)
   * impure references in /gnu/... simple summaries, doors to full details
   * status w.r.t. CVE announcements, (carefully, no tipoffs re exploitables)
   * databases in use, SQL injection vulns?
   * mystery daemons running?
   * hardware error rates, trends
   * ...

In short, I'd like reveal-vulns to give me a complete inventory
of my current vulnerablilities to a selectable detail level.
I know "complete" would be magic :)

I imagine there must be many attempted versions in existence.
Is there a guix package? (I confess not having searched ;/ )
--
Regards,
Bengt Richter