Thank you for your reply and the advice ! I need some more details about this feature to understand the impact. Is there any documentation or examples that you could point me to ?
“only if the installer is p2 enabled”.
Uhm, how should I interpret that ? J Simply calling the p2 APIs (planner, engine, etc.) makes such a scenario possible ? Or to rephrase my question in a different way – can it happen if the p2 director is used (the logic in our tool is very close to it) ?
To elaborate a little bit further – if such a functionality is buried deep inside the p2 code (i.e. cannot be controlled by the p2 client that calls the APIs), then we need to understand what can trigger modification of the installer on the fly – e.g. options, passed to the tool, specific attributes in the p2 repository, etc.
Thanks and regards,
SAP Labs Bulgaria
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: 19 октомври 2011 г. 23:13 ч.
To: P2 developer discussions
Subject: Re: [p2-dev] Dynamic pluggability of touchpoints to the provisionig process ?
It is not just your imagination, but the reality.
p2 is capable of installing on the fly something in your installer, but only if the installer is p2 enabled. This installation is controlled by p2 as well.
I understand the security concern, however I'll just throw this at you :) If you are concerned that the provider of the site is malicious enough to mess around with the installer, how can you trust any provider with what they add to your provisioned instance?
Options that come to mind to protect yourself are:
- Prevent things to be installed in the installer by having the installer be not p2 enabled. That has the drawback to prevent the installer to update itself if needs be.
- Validate the signature of all bundles that get installed and restrict to only a few, and / or you go down the path of certification accompanied with signature (e.g. I provide you a bundle that will be installed in the intaller, you review the code and then you sign it with your own certs).
On 2011-10-19, at 12:53 PM, Yousouf, Shenol wrote:
In my scenario, I have a p2 installation tool (p2 director of the sort) which provisions another system. Assume that I have a repository with my own custom touchpoint and bundles, published with actions, recognized by it. Is it possible to plug dynamically the touchpoint to the provisioning process and execute the custom actions for the bundles, that go to the remote system, with one installation ?
To clarify a little bit more: Our use cases rely heavily on p2 provisioning and we would like to clear the possible security holes. If such scenario is possible for, say, specially constructed update sites, this could lead to some unexpected results. Imagine that you install a feature, which turns out to contain a touchpoint + some bundles with actions, intended for it. If the new touchpoint can plug into the provisioning process at an early stage, it will execute the actions for the other bundles, which, on turn, can execute malicious code or do other nasty things.
I have some vague memories that p2 supports some kind of “self-provisioning of the provisioning process” itself, which motivated me to direct this question to the mailing list, but it could be just my imagination. J
p2-dev mailing list