On Wednesday 28 September 2016, Christian Schulte <[email protected]> wrote:
> Am 09/28/16 um 04:48 schrieb Christian Schulte: > > Am 09/28/16 um 04:16 schrieb Christian Schulte: > >> Am 09/27/16 um 15:24 schrieb Stephen Connolly: > >>> I think that may be problematic... but probably not the worst thing to > add > >>> to the schema (would just be an extra attribute) > >> > >> Something you can use to identify the entity having produced an artifact > >> and useable to verify an artifact has not been modified as it has been > >> provided by that entity. Like a common name in a certificate. This > >> decouples things from location (repositories). There always needs to be > >> an entity claiming responsibility of an artifact/group of artifacts. We > >> have GPG signatures and jarsinger already. We maybe should decouple > >> artifacts from technologies like these and make that attributes (maybe > >> just one attribute: a common name like in a X.509 certificate) a > >> property of a projects' dependency trees file. So maybe those project > >> dependency trees files need to somehow hold some information about who > >> is to be claimed responsible for the trees. XMLDsig comes to mind. > >> > >> <https://www.w3.org/TR/xmldsig-core/> > > > > In the sense of: The location an artifact is retrieved from does not > > matter. The verifiable authorship related integrity of that artifact > > matters. Currently you can deploy unrelated artifacts to the same > > coordinates to various repositories. For example: The 'commons-lang' > > artifact jar file obtainable from repository A can contain completely > > different content compared to the 'commons-lang' artifact obtainable > > from repository B. There needs to be a way to express artifact > > responsibility so that an entity not responsible for an artifact cannot > > procude it. This is what I am heading after. There needs to be a way to > > verify that an artifact obtained from group id 'commons-lang' really > > contains content the entity responsible for artifacts of that group id > > claimed responsibility for. That's where the "resolve authoritative > > repositories from DNS TXT records based on group id" proposal came from. > > That's really a: Need a way to verify the artifact I obtained for > > coordinates XYZ really is the artifact the entity responsible for those > > coordinates has provided. I don't see a way to implement that in an > > artifact-self-contained way. Like a service you can post an artifact to > > asking for verification of the artifact to be identical to the artifact > > the orignal author has deployed. > > So that whenever I see something like > > <dependency> > <groupId>junit</groupId> > <artifactId>junit</artifactId> > <version>4.12</version> > <scope>test</scope> > </dependency> > > I can be sure that this will always represent the exactly same files no > matter in what environment this declaration appears. There is only one > and only one 'junit:junit:4.12' artifact and that needs to be enforced > somehow. Currently it isn't. So if we provide a way to decentralise. So now junit hosts their own artifacts, not central Now the absolute worst happens, they lose the artifacts, and the gpg signing key But they still have source code. So they rebuild from source and sign with new key. What happens all the old projects which claim definitive junit 4.12 is the old key? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] <javascript:;> > > -- Sent from my phone
