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