Hi Simon,
On +2022-07-07 18:58:41 +0200, zimoun wrote:
> Hi,
>
> On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès <l...@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
