What happens if I want to use an in-house patch build of junit? I will not have the same origin...
On Wednesday 28 September 2016, Stephen Connolly < [email protected]> wrote: > > > On Wednesday 28 September 2016, Christian Schulte <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] >> For additional commands, e-mail: [email protected] >> >> > > -- > Sent from my phone > -- Sent from my phone
