Artifacts downloaded from repository no longer present in target file about p2

[mickaelistria]

Do the artifact have the same id/version/classifier? p2 may optimize the download as it assumes that artifact with same id/version/classifier are the same independently of the source repository; so it is expected to fetch them from whatever source it thinks is best.

[merks]

Yes, that's the idea. If the artifact with the same key is available in some local disk (file: URI) repository then reusing it will avoid waiting for a slow download...

[vaclavHala]

Not sure about the classifier but id/version are definitely the same yes.

On one hand I agree that technically artifacts with exactly the same id+version+classifier should be the same,
on the other, apart from the fact this is very surprising behavior, this becomes a big problem security wise no?

Say we have some repo of known good verified artifacts we list in our target and to be compliant with our security policy need all artifacts in the final product to come from there. Now if I have a build machine which used to get artifacts from some different repo and remembers this, by keeping to use that old repo and sidestepping the one it breaks this policy.

Even worse case would be attack which manages to sneak in some completely different repo which contains artifacts with same id but malicious content (p2 has to read the repo list from some persistent file on disk I suppose, so appending to it is not out of question). This would be pretty hard to detect because nothing changed in the source, just in local environment of the build machine.

Also a related question - is there some way to make p2 verbosely log where it is downloading each artifact from? When going through the code I saw it emits some provisioning events which contain the info I need, but I'd like to configure something to print these events without having to write and install my own listener

[mickaelistria]

be attack which manages to sneak in some completely different repo

Then the attack is not the fetch particularly, it's the "sneak in completelly different repo". This attack should be protected enough earlier, not be something we work around during the fetch.

is there some way to make p2 verbosely log where it is downloading each artifact from?

I don't think there is something built-in p2; but maybe ECF that is used under the hood has some logging capabilities.

[vaclavHala]

Ok, I'm no security expert so let's not follow that angle further. I just thought I saw article about something like this already happening somewhere so I brought it up.

Say I wanted to disable that optimization for any reason whatsoever - is there some option/flag I could use to do that? I want strictly locations from the target file to be used and potentially also local bundle pool. Currently I'm seeing the optimization not just for file:// URIs as @merks wrote but also for remote repos.

If this is currently not possible would you consider implementing this feature request?

[merks]

There is no support for such a thing as far as I can see. It's not been my experience that p2 is installing artifacts from non-local sites either, so I wonder about that...

I doubt this issue is a big priority for anyone in particular. Would you consider contributing such a feature yourself or sponsoring someone to contribute it on your behalf?

[vogella]

Should this be moved to PDE? I think the code in question is located in PDE. I also have seen such unexpected access to update sites which are no longer part of the target platform and agree that this is not correct behavior.

cc @HannesWell

[merks]

One of the classes in question is this one:

org.eclipse.equinox.internal.p2.engine.DownloadManager.start(IProgressMonitor)

The behavior is that p2 is generally trying to avoid downloading from a remote URI any artifact that is available via file: as well.