Re: grafted package and CLI
Hi Simon,
On +2022-07-07 18:58:41 +0200, zimoun wrote:
> Hi,
>
> On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès 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
Re: grafted package and CLI
Hi, On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès 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
zimoun 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
Hi, On Thu, 07 Jul 2022 at 10:00, Ludovic Courtès 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
Hi, zimoun 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 (string > + (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’.
