all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.