| Summary: | Should content.jar and artifacts.jar be signed? | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | kim.moir |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
David Williams
We implemented these files as jars so that signing could be done on them, but didn't see an immediate need for signing in this release. These jars are not currently served up by mirrors, since the mirror definition URL is contained in the JAR itself - we don't know how to get the mirrors until we read that file. Currently there is no point in signing them because we would need to make the corresponding code changes in p2 to check the signatures, which we don't have time for in this release. Having said that, there is definitely value in signing in the long term, so that clients can establish whether they came from a trusted source. I've opened bug 234641 as a reminder to implement these changes in 3.5 for the Eclipse Project. We'll let 234641 be _the_ bug to track this potential enhancement. *** This bug has been marked as a duplicate of bug 234641 *** |