Re: store reference detection (was Re: JARs and reference scanning)

[Chris Marusich]

Mark H Weaver <address@hidden> writes:

> Hartmut Goebel <address@hidden> writes:
>
>> Am 02.05.2017 um 14:43 schrieb Ludovic Courtès:
>>> Hartmut Goebel <address@hidden> skribis:
>>>
>>>> Am 27.04.2017 um 15:46 schrieb Ludovic Courtès:
>>>>> ‘propagated-inputs’ is one way to manually specify run-time references.
>>>>> It works at the package level and not at the store level—that is, the
>>>>> store item’s references are unaffected by what ‘propagated-inputs’
>>>>> contains.  It’s 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’s what I meant by “not at the store level” above.
>>>
>>> Ludo’.
>>  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?

-- 
Chris

signature.asc
Description: PGP signature