Bug 396282 - Integrate signing on a more granular level
Summary: Integrate signing on a more granular level
Status: NEW
Alias: None
Product: Virgo
Classification: RT
Component: virgo-build (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL: https://bugs.eclipse.org/bugs/show_bu...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-11 10:19 EST by Borislav Kapukaranov CLA
Modified: 2015-06-11 15:30 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Borislav Kapukaranov CLA 2012-12-11 10:19:54 EST
Virgo's update site is being signed before producing the zipped distributions. This way after installing the distributions their content is signed.

This has several downfalls:
1. Only the features and the content in /plugins are signed.
2. Sometimes we may sign Eclipse bundles twice.
3. There are third-parties in our repos that can sneak in unsigned, for example via the resources binaries.

The current approach of signing an assembled update site works but tolerates these gaps in the process.

An approach I think might work better is to execute signing on a more granular level.

This way it will be possible to sign all Virgo owned bundles right after they are built and upload them signed in the Ivy repos. The other Eclipse and Orbit content is already signed as part of their build and we consume it signed.

This only leaves the few gaps of uploading third party dependencies and hotfixed jars to EBR or our Ivy build.eclipse.org repos. This gap can be covered in the eclipse-mirror repo - it can be easily made to sign every mirrored or hotfixed artifact prior uploading it to Ivy.

I don't have a solution on EBR yet. If it becomes an Eclipse-hosted entity it would be easier I think.

All thoughts above lead to the state where everything in Ivy is signed so when we assemble p2 repos or resources they would also be signed.

Wdyt?
Comment 1 Borislav Kapukaranov CLA 2012-12-14 09:07:10 EST
Signing seems to brake app deployment on VNF. 
Here's the related bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=396403
Comment 2 Florian Waibel CLA 2015-06-11 15:30:58 EDT
The buildship plugin we use now is able to fullfill this request:

    localPlugin project(':org.eclipse.buildship.core')
    localFeature project(':org.eclipse.buildship.feature')

    // include 3rd party dependencies in the update site
    externalPlugin withEclipseBundle('org.slf4j.api')

    // official 3rd party dependencies from Orbit which are already signed and normalized with pack200
    signedExternalPlugin withEclipseBundle('com.google.gson')

Currently only oev.* bundles and features are signed.