Comments (13)
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:
- either there is no harm by a jar then it could be omitted and is useless to install
- the jar has an influence on the system state in any way so it needs to pass basic security checks (even though not perfect)
from p2.
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!!
from p2.
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.
from p2.
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.
from p2.
sad to see the close without giving a chance to the OP to respond / clarify!
from p2.
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?
from p2.
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?
from p2.
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.
from p2.
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.
from p2.
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?
from p2.
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.
from p2.
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.
from p2.
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!
from p2.
Related Issues (20)
- Unlikely argument type HOT 2
- Bundles placed to "linked" locations not found since 4.31 HOT 26
- Getting error "Problems downloading artifact: osgi.bundle,com.sun.jna,5.13.0.v20230812-1000. The signature is invalid for current content", when exporting product for simple target for Eclipse 4.30 HOT 2
- UpdateSitePublisher -addJREIU argument doesn't add current JVM HOT 1
- Jenkins builds fail with Java heap space
- P2 is not supporting the effective directive properly HOT 2
- Updating a touchpoint action and calling it calls the previous version of the action HOT 7
- Broken Java 11 Tycho Build due to new org.eclipse.equinox.common 3.19 getting picked up HOT 2
- Enhance p2 director with "addJREIU" option HOT 13
- Do not show error popup on failed automatic update checks HOT 1
- Migrate wiki pages to repo HOT 7
- Overhaul documentation on p2 director application HOT 3
- "Verify provisioning operation is compatible with currently running JRE" is not working HOT 7
- API error on org.eclipse.equinox.p2.core HOT 2
- redirect configuration / p2 runtime data to non-default location
- A "org.eclipse.equinox.p2.transport.javahttpclient" transport using directly Java HTTP client or OSGi services HOT 9
- p2 director does not handle GOAWAY gracefully HOT 11
- Incorrect usage of File.renameTo() in CacheManager HOT 10
- IRepository.PROP_COMPRESSED is confusing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from p2.