From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: store reference detection (was Re: JARs and reference scanning) Date: Fri, 12 May 2017 13:39:18 -0400 Message-ID: <87inl6ht4p.fsf@netris.org> References: <87a876pwaq.fsf@gmail.com> <8760hr7mwl.fsf@gmail.com> <20170426.135333.1620868924745053745.post@thomasdanckaert.be> <87fugu6jzg.fsf@gnu.org> <59022E86.1020709@crazy-compilers.com> <8760hjig4r.fsf@gnu.org> <590F179B.4060306@crazy-compilers.com> <87shkafvhu.fsf@netris.org> <87o9uyv665.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d9EXR-0001BF-5j for guix-devel@gnu.org; Fri, 12 May 2017 13:39:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d9EXM-0003mJ-BS for guix-devel@gnu.org; Fri, 12 May 2017 13:39:37 -0400 Received: from world.peace.net ([50.252.239.5]:38883) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d9EXM-0003lW-6G for guix-devel@gnu.org; Fri, 12 May 2017 13:39:32 -0400 In-Reply-To: <87o9uyv665.fsf@gmail.com> (Chris Marusich's message of "Fri, 12 May 2017 01:19:14 -0700") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org Chris Marusich writes: > Mark H Weaver writes: > >> Hartmut Goebel writes: >> >>> Am 02.05.2017 um 14:43 schrieb Ludovic Court=C3=A8s: >>>> Hartmut Goebel skribis: >>>> >>>>> Am 27.04.2017 um 15:46 schrieb Ludovic Court=C3=A8s: >>>>>> =E2=80=98propagated-inputs=E2=80=99 is one way to manually specify r= un-time references. >>>>>> It works at the package level and not at the store level=E2=80=94tha= t is, the >>>>>> store item=E2=80=99s references are unaffected by what =E2=80=98prop= agated-inputs=E2=80=99 >>>>>> contains. It=E2=80=99s usually enough for our purposes though. >>>>> I'm not sure if 'propagated-inputs' are enough. For example >>>>> "python-passlib" as propagated-input python-py-bcrypt, but the later >>>>> does not show up as reference, requisite nor referrer: >>>> Right, that=E2=80=99s what I meant by =E2=80=9Cnot at the store level= =E2=80=9D above. >>>> >>>> Ludo=E2=80=99. >>> So I propose to add a small text file ".guix-dependencies' to all >>> language's packages which do not add some kind of references themselves: >>> Python, Perl, Java, etc. >> >> I have thought of doing this in the past, but there's another more >> difficult problem that would also need to be solved: how to make >> grafting work for these non-plaintext references. If grafting doesn't >> work, there's a good chance that software with known security flaws will >> continue to be executed. > > That's a good thing to keep in mind. I think that the references we're > talking about putting into a ".guix-dependencies" file or into an > uncompressed JAR file are in fact "plaintext" in the sense that these > files are not using compression, encryption, esoteric encodings, or > other obfuscations which might defeat the reference scanning or grafting > mechanisms. I'm not convinced we need these things (a list of > dependencies in ".guix-dependencies" or embedded classpaths in JAR > files), but if we used them, I don't think it would interfere with > reference scanning or grafting. Would it? It would not interfere, but it could have the effect of *hiding* security problems due to a failure to graft properly. If there are embedded references that Guix cannot see and therefore are not transformed by grafting, we are most likely to become aware of this problem when the referenced store item is reclaimed by the garbage collector, thus breaking things and prompting us to investigate. This is in fact exactly how I discovered another problem of this kind: https://bugs.gnu.org/24703 If we create a redundant set of references in another file, then problems like this could go undetected for a long time. Adding more 'propagating-inputs' would have the same problem, and cause other problems as well. One thing we could do is add a phase to certain build systems, which would try to use additional methods to detect these hidden references, and deliberately cause the build to fail in that case, raising the alarm that grafting would silently fail. What do you think? Mark