You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2017/10/30 12:58:03 UTC
Downloading from other Maven repositories was: Integrating with
complex third-party software
2017-10-25 6:21 GMT+02:00 Antonio Vieiro <an...@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.
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.
-jt
Re: Downloading from other Maven repositories was: Integrating with
complex third-party software
Posted by Antonio <an...@vieiro.net>.
On 30/10/17 20:02, Antonio Vieiro wrote:
>
> I’ll add this to PR#204. Let’s get this done ASAP.
>
Ready for review. Let's find some nice maven repos to add to
nbbuild/default-properties.xml#binary.repositories
Cheers,
Antonio
Re: Downloading from other Maven repositories was: Integrating with
complex third-party software
Posted by Antonio Vieiro <an...@vieiro.net>.
> El 30 oct 2017, a las 20:47, Matthias Bläsing <mb...@doppel-helix.eu> escribió:
>
> Hey,
>
> Am Montag, den 30.10.2017, 20:02 +0100 schrieb Antonio Vieiro:
>>>> 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.
>>
>> Untrusted because missing https certificates, maybe?
>>
>> The DownloadBinaries.java ant task currently uses plain http, so no worries about https certificates (but we could use a custom SSLSocketFactory with some certs if required).
>>
>
> Please see the DownloadBinaries#doDownload method. The download is done
> and after that the file hash is compared with the reference from the
> binaries-list.
I agree with you that the SHA1 is enough. I meant that maybe Yaroslav was talking about “untrusted HTTPS” connections.
Cheers,
Antonio
>
> So you'd need to create a SHA1 collision to inject code when
> downloading. While theoretically possible, I'd currently not think
> about the problem.
>
> We should think about making the hashing extendable, so that we can
> later switch to saver hashing algorithms.
>
> Greetings
>
> Matthias
Re: Downloading from other Maven repositories was: Integrating with
complex third-party software
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hey,
Am Montag, den 30.10.2017, 20:02 +0100 schrieb Antonio Vieiro:
> > > 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.
>
> Untrusted because missing https certificates, maybe?
>
> The DownloadBinaries.java ant task currently uses plain http, so no worries about https certificates (but we could use a custom SSLSocketFactory with some certs if required).
>
Please see the DownloadBinaries#doDownload method. The download is done
and after that the file hash is compared with the reference from the
binaries-list.
So you'd need to create a SHA1 collision to inject code when
downloading. While theoretically possible, I'd currently not think
about the problem.
We should think about making the hashing extendable, so that we can
later switch to saver hashing algorithms.
Greetings
Matthias
Re: Downloading from other Maven repositories was: Integrating with
complex third-party software
Posted by Antonio Vieiro <an...@vieiro.net>.
> El 30 oct 2017, a las 18:35, Matthias Bläsing <mb...@doppel-helix.eu> escribió:
>
> Hey,
>
> Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach:
>> 2017-10-25 6:21 GMT+02:00 Antonio Vieiro <an...@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.
I’ll add this to PR#204. Let’s get this done ASAP.
Later on we can fine-tune the downloads mechanism, using some sort of parallelization to speed things up.
>
>> 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.
Untrusted because missing https certificates, maybe?
The DownloadBinaries.java ant task currently uses plain http, so no worries about https certificates (but we could use a custom SSLSocketFactory with some certs if required).
Cheers,
Antonio
Re: Downloading from other Maven repositories was: Integrating with
complex third-party software
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hey,
Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach:
> 2017-10-25 6:21 GMT+02:00 Antonio Vieiro <an...@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