[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#31444] 'guix health': a tool to report vulnerable packages
From: |
Ludovic Courtès |
Subject: |
[bug#31444] 'guix health': a tool to report vulnerable packages |
Date: |
Tue, 15 May 2018 09:24:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hi!
Nils Gillmann <address@hidden> skribis:
> Did you intend to attach a patch to one of the 3 or 4 messages that made
> it to the bugtracker? I've checked when you've sent the message and today
> and saw no patches. I'm interested in the code, the general idea sounds good.
They eventually made it there:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31442
But Debbugs is weird; for some reason for it failed to reply for several
hours.
>> I think that longer-term we probably need to attach this kind of
>> meta-data to packages themselves, by adding a bunch of files in each
>> package, say under PREFIX/guix. We could do that for search paths as
>> well.
>
> If you mean with metadata what I understand:
> I've started playing with this idea a while back. It would be good to attach
> more information to the package, mentioned in the past was "support the
> developers"
> links (not everyone publishes this on their website).
> Personally I'm going to make use of the "maintainer" function for packages,
> so people know where (hopefully relatively) exactly the package came from.
Well this is not the kind of meta-data I had in mind, and for that I
think a field in <package> is good enough.
> Anyways, I have some other package related experiments.. Did you have anything
> else in mind, other than search-paths and CVE information?
Not really, but that would be extensible.
The bigger picture is that of packages that would remain live data
structures, as Ricardo proposed a while back. I don’t think we can go
this far (in the sense of being able to reconstruct a <package> from its
output), but having some metadata kept around can help.
Thanks,
Ludo’.