* List of installed package, version pairs
@ 2019-01-09 22:03 Jack Hill
2019-01-10 7:33 ` Efraim Flashner
2019-01-18 8:36 ` Giovanni Biscuolo
0 siblings, 2 replies; 7+ messages in thread
From: Jack Hill @ 2019-01-09 22:03 UTC (permalink / raw)
To: help-guix
Hi,
It seems that work has noticed the GuixSD host that I brought into the
office. The security office maintains a risk profile be collecting lists
of installed packages, so I've been asked to produce one for the GuixSD
host. I assume that the garbage collector's live-paths is roughly
equivalent to what they want.
However, I've become stuck developing this report as both "guix gc
--list-live" and the live-paths function in the (guix store) Guile module
produce a list of store paths. I would like to get the package name and
version. Is there a good way to do this without resorting to string
manipulation?
Best,
Jack
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-09 22:03 List of installed package, version pairs Jack Hill
@ 2019-01-10 7:33 ` Efraim Flashner
2019-01-15 21:28 ` Jack Hill
2019-01-18 8:36 ` Giovanni Biscuolo
1 sibling, 1 reply; 7+ messages in thread
From: Efraim Flashner @ 2019-01-10 7:33 UTC (permalink / raw)
To: Jack Hill; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
On Wed, Jan 09, 2019 at 05:03:40PM -0500, Jack Hill wrote:
> Hi,
>
> It seems that work has noticed the GuixSD host that I brought into the
> office. The security office maintains a risk profile be collecting lists of
> installed packages, so I've been asked to produce one for the GuixSD host. I
> assume that the garbage collector's live-paths is roughly equivalent to what
> they want.
>
> However, I've become stuck developing this report as both "guix gc
> --list-live" and the live-paths function in the (guix store) Guile module
> produce a list of store paths. I would like to get the package name and
> version. Is there a good way to do this without resorting to string
> manipulation?
>
> Best,
> Jack
>
For packages you have installed in your profile
'guix package -I | cut -f1,2 --output-delimiter=@ | sort -u' gives a
nice list. Perhaps someone else has an idea for the list from your
os-config.
Although the code above doesn't take into account build inputs and
packages that are in your binaries' paths. For that my two initial ideas
are 'guix package -I | cut -f1 | sort -u | xargs guix size' or
'guix package -I | cut -f1 | sort -u | guix refresh --list-transitive'
and some more shell scripting to get the package and version.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-10 7:33 ` Efraim Flashner
@ 2019-01-15 21:28 ` Jack Hill
2019-01-16 7:35 ` Gábor Boskovits
0 siblings, 1 reply; 7+ messages in thread
From: Jack Hill @ 2019-01-15 21:28 UTC (permalink / raw)
To: Efraim Flashner; +Cc: help-guix
Thanks! I'm still not quite there, but the suggestion below have been
quite helpful in my thinking and experimentation.
On Thu, 10 Jan 2019, Efraim Flashner wrote:
> For packages you have installed in your profile
> 'guix package -I | cut -f1,2 --output-delimiter=@ | sort -u' gives a
> nice list. Perhaps someone else has an idea for the list from your
> os-config.
I think I have an answer for the OS config: pass the --profile option to
guix package, so the guix package command becomes 'guix package
--profile=/var/guix/profiles/system/profile -I'
> Although the code above doesn't take into account build inputs and
> packages that are in your binaries' paths. For that my two initial ideas
> are 'guix package -I | cut -f1 | sort -u | xargs guix size' or
> 'guix package -I | cut -f1 | sort -u | guix refresh --list-transitive'
> and some more shell scripting to get the package and version.
Yes, I did want to inputs in the list as well. However, I worry that
calculating these by passing package names to the current guix may
inadvertently list newer inputs than were used by the, potentially older,
guix that instantiated the profile.
Best,
Jack
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-15 21:28 ` Jack Hill
@ 2019-01-16 7:35 ` Gábor Boskovits
2019-01-16 19:27 ` Jack Hill
0 siblings, 1 reply; 7+ messages in thread
From: Gábor Boskovits @ 2019-01-16 7:35 UTC (permalink / raw)
To: Jack Hill; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
Hello Jack,
you could also try to make sense of the individual profile generation
manifests.
The union of those should give a farily comprehensive list, and it comes
with versions.
2019. jan. 15., K 22:29 dátummal Jack Hill <jackhill@jackhill.us> ezt írta:
> Thanks! I'm still not quite there, but the suggestion below have been
> quite helpful in my thinking and experimentation.
>
> On Thu, 10 Jan 2019, Efraim Flashner wrote:
>
> > For packages you have installed in your profile
> > 'guix package -I | cut -f1,2 --output-delimiter=@ | sort -u' gives a
> > nice list. Perhaps someone else has an idea for the list from your
> > os-config.
>
> I think I have an answer for the OS config: pass the --profile option to
> guix package, so the guix package command becomes 'guix package
> --profile=/var/guix/profiles/system/profile -I'
>
> > Although the code above doesn't take into account build inputs and
> > packages that are in your binaries' paths. For that my two initial ideas
> > are 'guix package -I | cut -f1 | sort -u | xargs guix size' or
> > 'guix package -I | cut -f1 | sort -u | guix refresh --list-transitive'
> > and some more shell scripting to get the package and version.
>
> Yes, I did want to inputs in the list as well. However, I worry that
> calculating these by passing package names to the current guix may
> inadvertently list newer inputs than were used by the, potentially older,
> guix that instantiated the profile.
>
> Best,
> Jack
>
>
Best regards,
g_bor
[-- Attachment #2: Type: text/html, Size: 2103 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-16 7:35 ` Gábor Boskovits
@ 2019-01-16 19:27 ` Jack Hill
2019-01-17 11:17 ` Ricardo Wurmus
0 siblings, 1 reply; 7+ messages in thread
From: Jack Hill @ 2019-01-16 19:27 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Wed, 16 Jan 2019, Gábor Boskovits wrote:
>
> Hello Jack,
> you could also try to make sense of the individual profile generation
> manifests.
>
> The union of those should give a farily comprehensive list, and it comes with versions.
Yes, this looks pretty good, thanks. I think that this gets me all the
surface packages exposed in all the profiles. However, I believe that it
is still missing the packages installed as dependencies.
One thought is to drop back to manipulating store objects. I can get a
list of references using query-path-info from the guix store module, and
recurse down those references to build the graph. In the end I have to
then guess the package names and versions from the store paths.
From my experimentation, it seems that store paths/objects are really what
Guix works with and is aware of, and not package names and version that
are reported as what's installed on traditional distributions. Perhaps I
can convince our security office to be happy with store paths.
Thoughts?
Jack
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-16 19:27 ` Jack Hill
@ 2019-01-17 11:17 ` Ricardo Wurmus
0 siblings, 0 replies; 7+ messages in thread
From: Ricardo Wurmus @ 2019-01-17 11:17 UTC (permalink / raw)
To: Jack Hill; +Cc: help-guix
Hi Jack,
> On Wed, 16 Jan 2019, Gábor Boskovits wrote:
>
>>
>> Hello Jack,
>> you could also try to make sense of the individual profile generation
>> manifests.
>>
>> The union of those should give a farily comprehensive list, and it comes with versions.
>
> Yes, this looks pretty good, thanks. I think that this gets me all the
> surface packages exposed in all the profiles. However, I believe that
> it is still missing the packages installed as dependencies.
You can get those with “guix gc -R /gnu/store/…whatever”. It will show
you all the store references that the store item has retained. These
will be libraries and applications that the thing depends on at runtime.
(I’m curious to know if the security folks would also object to you
building packages from source without Guix. Do they ask everyone with a
compiler to provide a list of dependencies?)
--
Ricardo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: List of installed package, version pairs
2019-01-09 22:03 List of installed package, version pairs Jack Hill
2019-01-10 7:33 ` Efraim Flashner
@ 2019-01-18 8:36 ` Giovanni Biscuolo
1 sibling, 0 replies; 7+ messages in thread
From: Giovanni Biscuolo @ 2019-01-18 8:36 UTC (permalink / raw)
To: Jack Hill, help-guix
[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]
Hi Jack,
Jack Hill <jackhill@jackhill.us> writes:
> It seems that work has noticed the GuixSD host that I brought into the
> office. The security office maintains a risk profile be collecting lists
> of installed packages,
this may seem "tangent" but I think your is a *very* interesting use
case, others gave you some tips on how to get a list of "installed
packages" but I'm (others?) very interested in _how_ your security
office use this list to evaluate a "risk profile"
Jack: do you have any info you could share on this please? your use case
could be the use case (or "class" of use cases) of thousand of potential
Guix users
all of us here are *very* concerned about the security risk of our
installed binaries, this is the reason we are seeking a reproducible
*and* bootsrappable based "software environment" like Guix
...unless your security team is keeping an internal list of applications
and associated risk level, but _how_ to reliably assess that?
i.e. are they fine with "Oracle DBMS" installed via a Docker bundle?
would they be fine if you brought a Windows10 host into the office?
as a *sysadmin* and user (*not* as part of the developers community) I'd
like to _forget_ the "sysadmin/user accessed risk profile" (an
illusion?) of my binaries and choose them for their features alone
maybe your security team could share their views with the Guix community
so we can better understand their concerns
if I were a member of your security team I'd say: «uhm... Guix, Ok show
me your channels» ;-)
e.g. Ricardo Wurmus yesterday in this thread said:
> I’m curious to know if the security folks would also object to you
> building packages from source without Guix. Do they ask everyone with a
> compiler to provide a list of dependencies?
this is an interesting point: AFAIK it's common practice by sysadmins in
"corporate" infrastructures to forbid users installing packages in /usr
and alike and sometimes /home is also mounted noexec :-O... so maybe
they manage to also systematically forbid users from executing
self-compiled binaries
...but is it an effective security policy?
Thanks
Giovanni
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-01-18 8:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-09 22:03 List of installed package, version pairs Jack Hill
2019-01-10 7:33 ` Efraim Flashner
2019-01-15 21:28 ` Jack Hill
2019-01-16 7:35 ` Gábor Boskovits
2019-01-16 19:27 ` Jack Hill
2019-01-17 11:17 ` Ricardo Wurmus
2019-01-18 8:36 ` Giovanni Biscuolo
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.