unsigned jar files flagged as untrusted even if the content is non-code about p2

[laeubi]

I think that the complexity of such solution won't outweigh its benefits, the only safe thing to assume would be if the jar is completely empty in wich case one might ask why it should be installed anyways. Now we enhance this with one more file and assume we have a check that can tell us it is harmless because it won't have an effect on the system this again means the jar can be omitted. So following the principle of complete induction we can say:

1. either there is no harm by a jar then it could be omitted and is useless to install
2. the jar has an influence on the system state in any way so it needs to pass basic security checks (even though not perfect)

[merks]

From a user's point of view, some of these things are quite annoying indeed! For example, some older jar-signed content is no longer recognized as jar-signed because the JREs are updated to specifically exclude certain old, weak algorithms. So the user might see warnings about unsigned content for a jar that was in fact jar-signed at the time it was produced. 😱

If would of course be great if Babel produces a new release with newly jar-signed content!!

[laeubi]

a user reported that they get warnings and prompts to trust untrusted / unsigned jars (for example org.eclipse.core.runtime.nl1_3.24.100.v202204221352.jar) while installing.
the file has only textual content, just zipped into jar.

Just assume I would replace e.g. a translation string that is shown inside a SWT Link control with an URL to a website that contains bad content, or I'm able to replace some html files (e.g. javadoc) with some nasty inline javascript or make the load-screen show some adult ad banners, your user will hopefully see that also "non-code" can be harmful.

[merks]

Signing is a certificate of origin of the content. The type of content is not relevant. So I would not agree to anything that skips checks for some content but not other content.

[gireeshpunathil]

sad to see the close without giving a chance to the OP to respond / clarify!

[gireeshpunathil]

Signing is a certificate of origin of the content. The type of content is not relevant. So I would not agree to anything that skips checks for some content but not other content.

when you successfully validate the content origin, it implies that you trust that origin - no matter what content that origin provides: current implementation.

by the same logic, if you (p2) find a content is coming from a trusted origin, can't you trust rest of its content? signed or unsigned?

[gireeshpunathil]

a user reported that they get warnings and prompts to trust untrusted / unsigned jars (for example org.eclipse.core.runtime.nl1_3.24.100.v202204221352.jar) while installing.
the file has only textual content, just zipped into jar.

Just assume I would replace e.g. a translation string that is shown inside a SWT Link control with an URL to a website that contains bad content, or I'm able to replace some html files (e.g. javadoc) with some nasty inline javascript or make the load-screen show some adult ad banners, your user will hopefully see that also "non-code" can be harmful.

@laeubi - I agree that there are implementation hurdles, but that does not invalidate the feature request, does it?

[gireeshpunathil]

agree - p2 is a provisioning system, not a security module; and in that perspective it is not in its purview to make sure incoming content is safe or not. and from that point of view, the most reasonable thing to do is to resort to check for signatures.

so the question now is, can p2 be made more efficient by focusing on the credibility of the source to take the trust decision rather than resorting to the signed state of the content.

[laeubi]

P2 support signed jars or PGP signatures, I don't know what "credibility of the source" means as the source for example can be a mirror or even unknown if it is a locally cached artifact.

[gireeshpunathil]

let me give an example:

• a user attempts to install a feature from a repo (local / remote does not matter)
• the feature has 10 jars; some are signed, some are not
• p2 picks up a signed one. it finds it is signed. a trust is established (or are there additional checks? IDK)
• p2 picks up another one - this time it is unsigned.

should it care to establish the trust again, as the source is the same?

[laeubi]

As said trust is build on the artifact not the jar, I can get one signed jar very easy and put it on my "bad site", just because P2 can trust this jar does not mean it can trust any jar from my updatesite.

[merks]

Sorry, but these types of discussions about security are typically long, twisted, and will tend to go on circles. Also note that an issue does not need open in order for there to continue to be a discussion; this issue might have better started as a discussion in the first place. As I feature request this is not only something I would not implement, and not only that, I would not support the contribution of an implementation of it. The reasons can be deeply elaborated as necessary.

With the current mechanisms, as @laeubi suggests, even once an artifact is on your machine, there is either an intrinsic jar signature for that artifact or an extrinsic PGP signature along with the PGP key associated with that artifact. Both help to certify the origin of the content and generally help to ensure that the content has not been tampered between when it was produced and when it arrived on the machine.

You're effectively asking for a distinction between "this type of content is intrinsically always fine regardless of origin, so no need to track that" versus "this type of content is dicey and should be tracked". But this is not a well-defined concept and I really do not care to go down the path of defining such a concept. It's simply better that we err on the side of being overly cautious than looking to provide some loop-hole for someone to deliver content that circumvents the mechanisms we have worked hard to put in place over a great many years.

Also note that you can already specify to trust all content regardless of signatures:

One could instead rely purely only on trusting the sites/authorities from which the content originates:

Or even here, one could trust everything blindly.

Trying to define the concept of "always safe content" just seems a very dark path to me. Can you assert with 100% certainty that the contents of a MANIFST.MF can never have a negative impact, potentially even an impact affecting the security of the system? I'd personally not want to be on the hook for making that assumption. That is the reason why I don't want to see anything implemented around such a concept.

[gireeshpunathil]

thank you @laeubi and @merks for providing explanations and reasons on the current behaviour!

I was looking things from a user experience improvement point of view; but from your descriptions, looks like this requirement is hard to implement in a fool proof manner.

fair!