can i force that a bundle/jar must come from a specific location specified in the target file?

[jcompagner]

Hi,

i have an annoying thing that we do make a p2 site of all kinds of 3rd party plugins:
https://github.com/Servoy/servoy-eclipse/blob/master/shipplugins/category.xml

and i use the feature of tycho that i use signing: https://github.com/Servoy/servoy-eclipse/blob/master/shipplugins/pom.xml#L81 and then fix the artifacts:https://github.com/Servoy/servoy-eclipse/blob/master/shipplugins/pom.xml#L121
to get a nice fully signed p2 site that i then use in my target:
https://github.com/Servoy/servoy-eclipse/blob/master/launch_targets/com.servoy.eclipse.target.target#L6
(i even have it on top of the file, hoping that order would do something)

but when i build my product with that target:
it should get these nicely signed files:

https://developer.servoy.com/p2_repository/ship_plugins/2022.03/plugins/org.apache.commons.commons-text_1.9.0.jar
https://developer.servoy.com/p2_repository/ship_plugins/2022.03/plugins/org.apache.commons.commons-fileupload_1.4.0.jar

but the end result of the full products p2 site:

https://download.servoy.com/developer/latest/plugins/org.apache.commons.commons-text_1.9.0.jar
https://download.servoy.com/developer/latest/plugins/org.apache.commons.commons-fileupload_1.4.0.jar

are suddenly different files.. that are not signed.
So if somebody now does a upgrade of our product they get a warning of unsigned content..

not sure which target it gets it from, mostly are just hard coded versions of jars, but also of features so i guess it could ride with something.
But i really want to force to get it from my p2 site...

[laeubi]

You can also sign your product with jarsigner. Or you can build your product from the generated updatesite in a separate reactor project.

[jcompagner]

hmm i really would like to avoid resigning our fully product...
because that would really slow down our product build..
that would mean resigning 400 plugins (and thats only 1 OS so per OS there will be a few more)
where most of them are already signed (once by us like the 3rd party libs, eclipse itself, or our own product build)

i guess it would be nice to have a mojo that says "sign if needed"(just before/after a repo is generated where the product is generated from again)

[mickaelistria]

No, you can't. It's part of the fun with p2.
The general rule is that all artifacts/units with same id/version/classifier are supposed to actually be the same unit. If you break this contract, then you're indeed going to face issues like this one in mulitple place, whenever p2 is involved.
The proper solution is to not publish "incorrect" units and hence to not make them visible to your build.

[jcompagner]

right the question is then which one are incorrect?
i guess you talk about mine from our own p2 site?
but those are correct for me, i need them signed.

and where the others are really coming from... no idea, its a bit annoying because they are not orbit, because orbit does sign them with the eclipse certificate (As far as i know)
so this is p2 site somewhere in eclipse that gets those also directly from mvn central without signing them, and via via i consume them again.

[mickaelistria]

i guess you talk about mine from our own p2 site?

Yes, those units are "fake" units that you tampered but kept their "official" coordinates. That's not a good practice, it's better to just create new units in that case (eg prefix Bundle-SymbolicName with com.servoy.). What you're trying to achieve is fundamentally wrong, sorry.
But somehow, it's a known issue of the overall signing story, and a reason why some of us have invested in support of "external" signature (with PGP signatures in p2 metadata, without modifying artifacts), so you can sign an artifact without modifying it. Maybe you should consider using PGP signatures instead of jarsigner ones.

so this is p2 site somewhere in eclipse that gets those also directly from mvn central without signing them, and via via i consume them again.

If you find out which one, please report to the providing project.

[jcompagner]

so you are kind of saying:

https://download.eclipse.org/tools/orbit/downloads/drops/R20211213173813/

that orbit is wrong....

what orbit does is what i kind of do.. take mvn central (if we say thats the "real" source) and sign them and put them under a p2 site...

the only real difference between orbit and mine is that they have a qualifier.. but that will not really help me.. (or i really need to specifcy everything really hard in a feature or so with the qualifier)

So who is wrong here? i say.. the one putting an unsiged jar from mvn central right in a p2 repo is wrong
not me.. i sign..

if we are using a PGP signature (need to investigate how to do that, but can this by done by tycho when generating our products p2 site?)
then eclipse will use that and also just reports it as signed and valid?

[jcompagner]

also prefixing a bundle doesn't really help if you just import packages... (from a minimum version so not an actual version)

[jcompagner]

ok so that is this plugin right:
https://www.eclipse.org/tycho/sitedocs/tycho-gpg-plugin/sign-p2-artifacts-mojo.html

then i need to look what that all needs for a setup, is there some documentation for that?

[mickaelistria]

I've been saying Orbit is wrong for a long time, nothing new here ;) And to be honest my latest investments towards PGP signatures have for side-effect goal to turn Orbit useless and make it disappear.

So who is wrong here? i say.. the one putting an unsiged jar from mvn central right in a p2 repo is wrong not me.. i sign..

Actually, the unsigned one is the right one, yours is a tampered version that uses "official" coordinates for different content, maybe adding some malicious code in it to run a botnet, who knows? (I trust you're not doing anything malicious, it's just an illustration of how a different artifact with official coordinates can be interpreted per se an unsafe)

if we are using a PGP signature [...] then eclipse will use that and also just reports it as signed and valid?

If you use a recent Eclipse Platform/p2 and configure it so your signer public key is trusted by default, then yes, it will be interpreted as signed during the installation.
Note that "valid" has no technical meaning here, it has the meaning you want to provide as part of your support. I don't know why you feel like you need signing to say something is valid; and I don't know what you mean by "valid"; maybe there are better ways to check something is "valid" for your case then relying on signatures... FWIW, in JBoss Tools/Red Hat CodeReady Studio, we usually never cared too much about signing as part of the support, we typically ask consumers who need support to send checksums of their artifacts and we verify them against the one we know we support.

also prefixing a bundle doesn't really help if you just import packages...

It helps in the sense that you won't have 2 different artifacts for the same p2 coordinates. It disambiguates everything.

is there some documentation for that?

Not much beyond the mojo description. But specific questions (and contributions to improve that doc) are welcome.

[laeubi]

I find it already annoying that eclipse ask one time i think to allow a certificate (that is fully valid). We get question for that from customers again "should i allow this"

You can register a validation service that simply accepts anything....

[jcompagner]

I find it already annoying that eclipse ask one time i think to allow a certificate (that is fully valid). We get question for that from customers again "should i allow this"

You can register a validation service that simply accepts anything....

wait... is there a extension point that i can override so i can do the check?
like ok if it comes from our HTTPS site (or a white list of sites) its always valid?
that would solve everything...

[laeubi]

Take a look at org.eclipse.equinox.p2.core.UIServices and org.eclipse.equinox.internal.p2.ui.ValidationDialogServiceUI

[jcompagner]

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.eclipse.equinox.p2.ui.serviceuifactory">
   <implementation class="org.eclipse.equinox.internal.p2.ui.ServiceUIComponent"/>
   <service>
      <provide interface="org.eclipse.equinox.p2.core.spi.IAgentServiceFactory"/>
   </service>
   <property name="p2.agent.servicename" type="String" value="org.eclipse.equinox.p2.core.UIServices"/>
</scr:component>

ah so that is in the org.eclipse.equinox.p2.ui/OSGI-INF/serviceui.xml

so if kind of do the same thing, how can i really overwrite that one i wonder...

[laeubi]

so if kind of do the same thing, how can i really overwrite that one i wonder...

http://docs.osgi.org/specification/osgi.core/7.0.0/framework.service.html#framework.service.servicerankingorder

and just be sure you bundle is start as soon as possible

[mickaelistria]

people don't come back to me asking question like "should accept this" (because of the popup that our product update now has because of unsigned content)

OK, so PGP signatures cover that part well.