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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
