From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIULV-0000vU-8X for guix-patches@gnu.org; Tue, 15 May 2018 03:26:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fIULS-0001LK-38 for guix-patches@gnu.org; Tue, 15 May 2018 03:26:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:55210) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fIULR-0001L7-W3 for guix-patches@gnu.org; Tue, 15 May 2018 03:26:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fIULR-0005im-Nq for guix-patches@gnu.org; Tue, 15 May 2018 03:26:01 -0400 Subject: [bug#31444] 'guix health': a tool to report vulnerable packages Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87fu2vjj76.fsf@gnu.org> <20180514164941.kjokoakkooajpunx@abyayala> Date: Tue, 15 May 2018 09:24:59 +0200 In-Reply-To: <20180514164941.kjokoakkooajpunx@abyayala> (Nils Gillmann's message of "Mon, 14 May 2018 16:49:41 +0000") Message-ID: <87y3gljs8k.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Nils Gillmann Cc: 31444@debbugs.gnu.org Hi! Nils Gillmann 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 g= ood. They eventually made it there: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31442 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 att= ach > more information to the package, mentioned in the past was "support the d= evelopers" > links (not everyone publishes this on their website). > Personally I'm going to make use of the "maintainer" function for package= s, > 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 is good enough. > Anyways, I have some other package related experiments.. Did you have any= thing > 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=E2=80=99t think we can= go this far (in the sense of being able to reconstruct a from its output), but having some metadata kept around can help. Thanks, Ludo=E2=80=99.