Unable to not trust individual sites on install

[ajohnson1]

If 'Contact all update sites during install to find required software' is selected, and one of the sites is not trusted then an install always seems to bring up a 'Trust authorities' dialog with:
'Do you trust content originating from the following authorities?'

even if the install doesn't require anything from that site.

There is then no way to proceed without clicking trust.

This is a bit confusing. I think the work-around is to disable the site from the 'Install/Update' > 'Available Software Sites', or to disable 'Contact all update sites' (but that could be needed to find other needed software.)

To reproduce:
Download a Memory Analyzer development build: https://eclipse.dev/mat/snapshotBuilds.php (so you get something built on Eclipse 4.30).

Help > Install > --All Available Sites--
Testing > SWT Bot for Eclipse Testing > Next > Finish

I would have expected to be able to continue the install without trusting, and for that site to be ignored.

Also, there isn't a good tie-up between the 'Available Software Sites' and the 'Trust' part - but perhaps there isn't a direct mapping, but it would be nice if they were linked.

[merks]

This is one of the security issues that was reported. Even the metadata from any site might be used and could be installed into your profile with touch-points that alter the behavior of the application. So in general you should trust all the sites being contacted or you should avoid contacting sites you don't trust.

https://eclipse.dev/eclipse/news/4.28/platform.php#trusted-authorities

It's not entirely clear what you hope/expect will be mapped? Also, if you have some composite that composes other sites, such sites cannot simply be ignore by p2. The devil here is in the details and there aren't so many details.

[ajohnson1]

Perhaps this is working as designed to avoid that vulnerability where the p2 metadata could cause problems.

The use case is that Eclipse Memory Analyzer has a plugin that can use a plugin from IBM to read IBM / Semeru heap dumps. The IBM plugin isn't trusted, but MAT includes a reference to the IBM update site in case the end user wants to install that plugin. Many users won't want that plugin, but might want to install something else. If they attempt to install something else then a dialog will appear to trust the IBM site.

Choices now:

1. MAT gives the IBM update site, but disabled. One extra step for the user to install from there.
2. End user trusts the IBM site on installing something else. Okay, but not great to trust a site you have no intention to install from.
3. Clear 'Contact all update sites' check box. Need to select the correct update site, might need some other data and so fail to install.

So perhaps I expected the install to proceed without contacting the untrusted sites, so pressing 'Trust Selected' was possible if just some or none of the items were selected, rather than having to select all, or having to work out from the trust authorities what are the corresponding update sites and disable those.

[laeubi]

It's not entirely clear what you hope/expect will be mapped?

@merks I also recently noticed that, I think the main point is that the user is asked to trust a site even though nothing is installed from there (I can understand that actually contacting the site is neccesary to actually present items to the user).

This might also related to the follwoing observation (if MAT is used in a target and then becomes a "kown location"):

• IU location queries ALL knwon artifact repositories eclipse-pde/eclipse.pde#793

so it might looks like for P2 as if the user is trying to install something from the site...

[merks]

Note that if you read carefully, you'll see this in the description:

The system property p2.trustedAuthorities can be used to specify a (comma or space separated) list of authorities considered trusted. The default value is effectively -Dp2.trustedAuthorities=https://download.eclipse.org,https://archive.eclipse.org, but product providers may set it differently in their product's eclipse.ini.

So given that you do build a product you can ensure that your *.ini has the authorities listed that you feel the user ought to trust without prompting. That is a pretty simple option 4. isn't it?

[ajohnson1]

Using -Dp2.trustedAuthorities is a possibility, though could be tricky to merge and add as a JVM argument as a p2 touchpoint if the org.eclipse.mat.dtfj plugin is installed as part of the MAT feature into Eclipse, rather than a standalone RCP product.
https://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instructions_35

Also, adding the site as trusted by default might not be what some users want, given that an install generates warning such as:

The digest algorithms (md5) used to verify osgi.bundle,com.ibm.dtfj.j9,1.12.29003.202006111057 have severely compromised security. Please report this concern to the artifact provider.

in the error log. I think that is a warning about the actual artifact, and not the website though. I'm a bit surprised I didn't get a prompt about the warning on install though.

[merks]

It's easy to add to a product. (Edited to show the correct section:

I agree that a touch point in a bundle is a good idea. Better for that would be an extension point...

Unfortunately, design/implementation changes around this topic is not something for which I'm likely to find time personally...