[
https://issues.apache.org/jira/browse/FELIX-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422547#comment-13422547
]
Guillaume Nodet commented on FELIX-3610:
----------------------------------------
That's exactly the reason, to make sure bundles are not modified.
I don't think all bets are off because you can verify the signatures.
Signatures of trusted sources can't be changed unless you know the private key
to sign those. So either you unsign the bundle (and it will be known because
the bundle won't return signatures) or you sign it with a different source
which you'll know too.
The cpu consumption would only be there for signed bundles, and that's only
about computing the checksum of the zip entry, which is quite fast, there's no
real cryptography involved here, so I don't think that's a problem. Besides,
that's a decision for the user to take.
The use case, to give a bit more background, is to give a trusted framework to
a third party so that it will use it, but we need to ensure some stuff can't be
modified by this third party. We don't trust the third party to not hack with
our framework, so we need to secure it.
> Support runtime verification for signed bundles
> -----------------------------------------------
>
> Key: FELIX-3610
> URL: https://issues.apache.org/jira/browse/FELIX-3610
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security
> Reporter: Guillaume Nodet
> Assignee: Karl Pauls
>
> Signed bundles are only checked when installed, but the goal of signed
> bundles is to make sure no one has changed the jar. This is not ensured
> unless bundle entries are verified when loaded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
