Am 09/28/16 um 23:23 schrieb Stephen Connolly: > So I am seeing conflicting requirements and I am unsure how we should > approach resolving them: > > 1. Seems perfectly reasonable to add some form of integrity details about > the *project's artifacts* into the PDT. Probably a SHA512 hash...
Adds - depending on the size of an artifact - overhead when hashing artifacts during generating PDTs and - more important - during consuming them. Not an issue. > > 2. We could probably add the SHA512 hashes of dependencies... we know what > the resolved version was when the PDT was generated and we know the hash > that was used... may lead to conflicting hashes for the same artifact at > different points in the tree... may lead to issues if specific artifacts > get regenerated (for example if I use staging, I may stage foo:1.2 you then > stage bar:2.5 depending on foo:1.2... then somebody finds a bug (was > compiled with wrong jdk, so we drop the foo staging repo and respond > foo:1.2 from the tag)... now if we promote bar:2.5 it will never find the > foo:1.2 with a matching hash. > > 3. Alternatively we could add the gpg keys that the artifacts were signed > with... hmm similar set of issues there... > > Basically, other than my project's artifacts and enforcing that they have > been signed by the project key... seems hard to square "don't let somebody > MiM my transitive dependency" with "what if the worst happens and we have > to rebuild from tags and sign with anew key". > > You could argue that "the worst won't happen"... ok while central is the > central point, that's exceeding unlikely given the redundant copies with > more than one organisation... but a goal we have is to allow decentralised > central... so that say junit could choose to host their own artifacts as > the canonical repo that everyone would "discover"... as soon as we open > that door, we let all the projects have the headache of looking after their > DR... > > So, if we want to allow a decentralised central then I think we need some > way to handle "recovered" artifacts from SCM tags. I fail to come up with anything more appropriate than DNS TXT records to map coordinates/group ids to download locations in combination with DNSSEC. It's exactly the model we are heading after. This would make signing/hashing superfluous because DNS/DNSSEC would become responsible for this. We 'just' need to find a way to ensure that resolving artifacts for given coordinates always resolves to the *exact same* artifacts. Is the 'recovered artifacts from SCM tags' use case really existent? I mean - there is no way to re-release an artifact to central using the same coordinates. An artifact at some coordinates is considered immutable, isn't it? > > Similarly I think the origin repo might be kept out of the PDT and managed > by the consumer... but that's a lesser concern for me at present Having the origin repo in the PDT would just be a workaround for lack of artifact authority management at another level. It shouldn't be needed. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
