Hey, Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach: > 2017-10-25 6:21 GMT+02:00 Antonio Vieiro <anto...@vieiro.net>: > > > > > I was wondering we could upgrade the “download task” in nbbuild to > > automatically select binary versions for eclipse binaries, so, for > > instance, our binaries-list could be something like: > > > > eclipse://4.7/org.eclipse.core.jobs > > > > And leave the responsibility of choosing (verifying) an appropriate > > version of “org.eclipse.core.jobs” to the download task. > > > > I was thinking about adding List<String> repositories; attribute into the > download task and then configure it to list as many Maven repositories as > possible. The download would then try them one by one as regular Maven > does. Then default.xml or some other file would register all the Maven > repositories we need for the build. This should solve our issues > temporarily.
I think this idea is sound and it would be direction I would take. I would not add complexity by adding a repository prefix. > On the other hand during review of HTML/Java API I had to remove download > from google Maven repository - it was seen as untrusted. I assume the same > will be said about the eclipse repository. I don't follow that argument. The trust basis is the SHA1 hash that is checked at download time. At this point in time I consider SHA1 as a save basis and thus I don't care if the binary comes from maven centra, the eclipse repository or whatever. There are reasons to limit the trusted repositories: - reduce attack vectors - improve download persformance So I'd like to hear reasonable objections to this. Greetings Matthias
