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

Hartmut Goebel writes: > Am 12.05.2017 um 23:51 schrieb Mark H Weaver: >> What's the motivation for this proposal, if not to allow the scanner to >> see references that would otherwise be obfuscated? > The motivation is to have references at all. See >

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

Am 12.05.2017 um 23:51 schrieb Mark H Weaver: > What's the motivation for this proposal, if not to allow the scanner to > see references that would otherwise be obfuscated? The motivation is to have references at all. See for an

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

Hartmut Goebel writes: > Am 12.05.2017 um 19:39 schrieb Mark H Weaver: > > It would not interfere, but it could have the effect of *hiding* > security problems due to a failure to graft properly. > [...] > If we create a redundant set of references in another file,

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

Hartmut Goebel writes: > Am 12.05.2017 um 20:22 schrieb Mark H Weaver: >> Might the compressed portions contain store references that >> will fail to be grafted? > > Class files per se do not contain references to any JAR file AFAIK. For > all other files

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

Am 12.05.2017 um 20:22 schrieb Mark H Weaver: > Might the compressed portions contain store references that > will fail to be grafted? Class files per se do not contain references to any JAR file AFAIK. For all other files (resources, etc.) its the same as for other programming languages --

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

Am 12.05.2017 um 19:39 schrieb Mark H Weaver: > It would not interfere, but it could have the effect of *hiding* > security problems due to a failure to graft properly. > [...] > If we create a redundant set of references in another file, then > problems like this could go undetected for a long

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

On Fri, May 12, 2017 at 01:39:18PM -0400, Mark H Weaver wrote: > 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

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

Hartmut Goebel writes: > Am 11.05.2017 um 10:41 schrieb Chris Marusich: >> Based on this test, it looks like we can embed absolute paths in >> uncompressed JAR files. > > Only the MANIFEST within the JAR file needs to be uncompressed, the > remaining files can be

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

Chris Marusich writes: > Mark H Weaver writes: > >> Hartmut Goebel writes: >> >>> Am 02.05.2017 um 14:43 schrieb Ludovic Courtès: Hartmut Goebel skribis: > Am 27.04.2017 um 15:46

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

Am 11.05.2017 um 10:41 schrieb Chris Marusich: > Based on this test, it looks like we can embed absolute paths in > uncompressed JAR files. Only the MANIFEST within the JAR file needs to be uncompressed, the remaining files can be compressed. JARs are zip files, which include data compressed

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

Chris Marusich writes: > Ricardo Wurmus writes: > >> Chris Marusich writes: >> Jar files can be told to import classes from another Jar by adding it to the “Class-Path” field of the Jar’s manifest. Here’s an

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

Mark H Weaver writes: > Hartmut Goebel writes: > >> Am 02.05.2017 um 14:43 schrieb Ludovic Courtès: >>> Hartmut Goebel skribis: >>> Am 27.04.2017 um 15:46 schrieb Ludovic Courtès: > ‘propagated-inputs’ is one

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

Ricardo Wurmus writes: > Chris Marusich writes: > >>> Jar files can be told to import classes from another Jar by adding it to >>> the “Class-Path” field of the Jar’s manifest. >>> >>> Here’s an example: >>>

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

Hartmut Goebel writes: > Am 02.05.2017 um 14:43 schrieb Ludovic Courtès: >> Hartmut Goebel skribis: >> >>> Am 27.04.2017 um 15:46 schrieb Ludovic Courtès: ‘propagated-inputs’ is one way to manually specify run-time references.

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

Chris Marusich writes: >> Jar files can be told to import classes from another Jar by adding it to >> the “Class-Path” field of the Jar’s manifest. >> >> Here’s an example: >> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html > > I didn't know this!

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

Hi Ricardo, Ricardo Wurmus writes: > Chris Marusich writes: > >> There are probably many ways to accomplish that. For example, in Java, >> perhaps we could implement a custom classloader. Or maybe we could >> patch the built-in class loading

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

Ricardo Wurmus skribis: > Chris Marusich writes: > >> There are probably many ways to accomplish that. For example, in Java, >> perhaps we could implement a custom classloader. Or maybe we could >> patch the built-in class loading mechanism [1].

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

Hartmut Goebel writes: > Am 02.05.2017 um 14:43 schrieb Ludovic Courtès: >> Hartmut Goebel skribis: >> >>> Am 27.04.2017 um 15:46 schrieb Ludovic Courtès: ‘propagated-inputs’ is one way to manually specify run-time references.

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

Hartmut Goebel 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

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

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

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

Hello, Thomas Danckaert skribis: > From: Chris Marusich > Subject: Re: JARs and reference scanning > Date: Tue, 25 Apr 2017 22:34:02 -0700 > >>> I have to admit that I do not know at all how the reference >>> scanning and >>> dependency-tracking

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

On April 26, 2017 4:53:33 AM PDT, Thomas Danckaert wrote: [...] >The code scanning for reference is in nix/libstore/references.cc . >It looks for base32 hashes encoded as character strings in the >binaries. > >Could/should this be generalized somehow? Apart from

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

From: Chris Marusich Subject: Re: JARs and reference scanning Date: Tue, 25 Apr 2017 22:34:02 -0700 I have to admit that I do not know at all how the reference scanning and dependency-tracking in the store works. As I understand it, the mechanism used by the Guix