| Selective signing [message #546286] |
Mon, 12 July 2010 07:40  |
Eclipse User |
|
|
|
Hi all,
I'm trying to get signing set up for our update site. I have the signing process itself running fine already. But now I'm facing the problem
that the site contains some org.eclipse.* artifacts that of course I don't want to sign.
So is there a way to selectively sign just a part of the site?
I already tried excluding the eclipse artifacts from the site in the first place (I don't really need them there, so that would have been a
plus). But I failed because that left the products on the site broken and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff
and a few others included in our product feature. I tried excluding them from the site by adapting the bundle.jars and feature.jars groups,
which worked fine as far as site contents were concerned. However that seems to fry the product because afterwards it fails to launch
because of a missing org.eclipse.core.runtime (which gets installed from anotehr site, but there seems to be something wrong with the
product's config.ini and related config files)
Best regards,
Carsten
|
|
|
| Re: Selective signing [message #546314 is a reply to message #546286] |
Mon, 12 July 2010 08:57  |
| Eclipse User |
|
|
|
Hi,
Perhaps not the best way, but you could perhaps do this:
- create your site with only your things (all signed)
- use the b3 aggregator to set up a repository that you create the
product against, and that you can use as the update site.
- the repository you create can be a composite site pointing to your
built site and Eclipse Helios for instance.
- henrik
On 7/12/10 1:40 PM, Carsten Reckord wrote:
> Hi all,
>
> I'm trying to get signing set up for our update site. I have the signing
> process itself running fine already. But now I'm facing the problem that
> the site contains some org.eclipse.* artifacts that of course I don't
> want to sign.
>
> So is there a way to selectively sign just a part of the site?
>
> I already tried excluding the eclipse artifacts from the site in the
> first place (I don't really need them there, so that would have been a
> plus). But I failed because that left the products on the site broken
> and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff and
> a few others included in our product feature. I tried excluding them
> from the site by adapting the bundle.jars and feature.jars groups, which
> worked fine as far as site contents were concerned. However that seems
> to fry the product because afterwards it fails to launch because of a
> missing org.eclipse.core.runtime (which gets installed from anotehr
> site, but there seems to be something wrong with the product's
> config.ini and related config files)
>
>
> Best regards,
> Carsten
|
|
|
| Re: Selective signing [message #546359 is a reply to message #546314] |
Mon, 12 July 2010 10:26 |
| Eclipse User |
|
|
|
Hi Henrik,
On 12.07.2010 14:57, Henrik Lindberg wrote:
> Hi,
> Perhaps not the best way, but you could perhaps do this:
> - create your site with only your things (all signed)
> - use the b3 aggregator to set up a repository that you create the
> product against, and that you can use as the update site.
I assume with "create the product" you mean the installation step, i.e. pulling the jars from the site and installing them using director?
In that case the problem still exists, because it appears that it's not the installation step that messes up the product, but the metadata
generated by the p2SiteGenerator in the site.p2 step.
I could just completely exclude the feature that defines our product from the site, however we'd prefer to have the product feature and
launchers on the site...
> - the repository you create can be a composite site pointing to your
> built site and Eclipse Helios for instance.
>
> - henrik
>
> On 7/12/10 1:40 PM, Carsten Reckord wrote:
>> Hi all,
>>
>> I'm trying to get signing set up for our update site. I have the signing
>> process itself running fine already. But now I'm facing the problem that
>> the site contains some org.eclipse.* artifacts that of course I don't
>> want to sign.
>>
>> So is there a way to selectively sign just a part of the site?
>>
>> I already tried excluding the eclipse artifacts from the site in the
>> first place (I don't really need them there, so that would have been a
>> plus). But I failed because that left the products on the site broken
>> and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff and
>> a few others included in our product feature. I tried excluding them
>> from the site by adapting the bundle.jars and feature.jars groups, which
>> worked fine as far as site contents were concerned. However that seems
>> to fry the product because afterwards it fails to launch because of a
>> missing org.eclipse.core.runtime (which gets installed from anotehr
>> site, but there seems to be something wrong with the product's
>> config.ini and related config files)
>>
>>
>> Best regards,
>> Carsten
>
|
|
|
| Re: Selective signing [message #546372 is a reply to message #546359] |
Mon, 12 July 2010 11:04 |
| Eclipse User |
|
|
|
On 7/12/10 4:26 PM, Carsten Reckord wrote:
> Hi Henrik,
>
> On 12.07.2010 14:57, Henrik Lindberg wrote:
>> Hi,
>> Perhaps not the best way, but you could perhaps do this:
>> - create your site with only your things (all signed)
>> - use the b3 aggregator to set up a repository that you create the
>> product against, and that you can use as the update site.
>
> I assume with "create the product" you mean the installation step, i.e.
> pulling the jars from the site and installing them using director?
yes.
> In that case the problem still exists, because it appears that it's not
> the installation step that messes up the product, but the metadata
> generated by the p2SiteGenerator in the site.p2 step.
>
That is bad. I believe we do publish Buckminster products that are
signed this way - but I need Thomas to verify (don't know if he is back
from vacation yet).
- henrik
|
|
|
|
|
| Re: Selective signing [message #549122 is a reply to message #549097] |
Sat, 24 July 2010 17:11 |
| Eclipse User |
|
|
|
--nextPart24175780.vaeNJFYEL5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
OK, Buckminster isn't that bad ;-) I found a nice way to circumvent the
problem. I added a CSPECX to the US feature and altered the site.signed
actor so that it calls a custom ant script that only signs selected jars.
See the attached files. The sign.jars task was copied from the default
Buckminster task and slightly modified.
--nextPart24175780.vaeNJFYEL5
Content-Type: application/xml; name="buckminster.cspex"
Content-Disposition: attachment; filename="buckminster.cspex"
Content-Transfer-Encoding: base64
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGNzcGVj RXh0ZW5zaW9uIHht
bG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5z dGFuY2UiCgl4bWxu
czpiYz0iaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9Db21t b24tMS4wIiB4bWxu
cz0iaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9DU3BlYy0x LjAiPgkKCTxhY3Rp
b25zPgoJCTxwdWJsaWMgbmFtZT0ic2l0ZS5zaWduZWQiIGFjdG9yPSJhbnQi PgoJCQk8YWN0b3JQ
cm9wZXJ0aWVzPgoJCQkJPHByb3BlcnR5IGtleT0iYnVpbGRGaWxlIiB2YWx1 ZT0ic2lnbmluZy5h
bnQiIC8+CgkJCQk8cHJvcGVydHkga2V5PSJ0YXJnZXRzIiB2YWx1ZT0ic2ln bi5qYXJzIiAvPgoJ
CQk8L2FjdG9yUHJvcGVydGllcz4KCQkJPHByZXJlcXVpc2l0ZXMgYWxpYXM9 ImFjdGlvbi5yZXF1
aXJlbWVudHMiPgoJCQkJPGF0dHJpYnV0ZSBuYW1lPSJzaXRlLnJlcGFja2Vk IiBmaWx0ZXI9Iihz
aXRlLnBhY2syMDA9dHJ1ZSkiIC8+CgkJCQk8YXR0cmlidXRlIG5hbWU9InNp dGUuZmVhdHVyZS5l
eHBvcnRzIiBmaWx0ZXI9IighKHNpdGUucGFjazIwMD10cnVlKSkiIC8+CgkJ CTwvcHJlcmVxdWlz
aXRlcz4KCQkJPHByb2R1Y3RzIGFsaWFzPSJhY3Rpb24ub3V0cHV0IiBiYXNl PSIke2J1Y2ttaW5z
dGVyLm91dHB1dH0vc2l0ZS5zaWduZWQvIgoJCQkJdXBUb0RhdGVQb2xpY3k9 Ik1BUFBFUiIgLz4K
CQk8L3B1YmxpYz4KCTwvYWN0aW9ucz4KCTxhbHRlckFjdGlvbnM+CgkJPHJl bW92ZSBuYW1lPSJz
aXRlLnNpZ25lZCIgLz4KCTwvYWx0ZXJBY3Rpb25zPgo8L2NzcGVjRXh0ZW5z aW9uPgo=
--nextPart24175780.vaeNJFYEL5
Content-Type: text/plain; name="signing.ant"
Content-Disposition: attachment; filename="signing.ant"
Content-Transfer-Encoding: 8Bit
<project>
<property name="output.folder" location="${sp:action.output}" />
<target name="sign.jars">
<property name="local.keystore.path" value=""/>
<property name="local.keystore.alias" value=""/>
<property name="local.keystore.password" value=""/>
<buckminster.contextProperty name="local.keystore.path"/>
<buckminster.contextProperty name="local.keystore.alias"/>
<buckminster.contextProperty name="local.keystore.password"/>
<fail message="The properties 'local.keystore.path', 'local.keystore.alias', and 'local.keystore.password' must be set in order to do local jar signing">
<condition>
<not>
<and>
<length string="${local.keystore.path}" when="greater" length="0"/>
<length string="${local.keystore.alias}" when="greater" length="0"/>
<length string="${local.keystore.password}" when="greater" length="0"/>
</and>
</not>
</condition>
</fail>
<delete dir="${output.folder}" />
<mkdir dir="${output.folder}" />
<copy todir="${output.folder}">
<buckminster.valuefileset value="${fs:action.requirements}" />
</copy>
<signjar keystore="${local.keystore.path}" alias="${local.keystore.alias}" storepass="${local.keystore.password}">
<fileset dir="${output.folder}">
<include name="**/org.knime.*.jar"/>
<include name="**/com.knime.*.jar"/>
</fileset>
</signjar>
</target>
</project>
--nextPart24175780.vaeNJFYEL5--
|
|
|
Powered by
FUDForum. Page generated in 0.08180 seconds
Home