Community
Participate
Working Groups
Signature verification has two aspects: - integrity verification - signer trust (do I trust the signer of this file?) When we first thought about adding support for signature verification to p2, we envisioned that those 2 aspects would be handled by one processing step during the fetch phase. However this approach has the following problems: - The pre-download of artifacts could cause the user to be prompted when he has not initiated any provisioning operation, and if we chose to not prompt/check in "pre-download" then the user never has the ability to say whether or not the signer is trusted. - The installation of the same IU would not result in the same user experience depending on whether the artifacts are already available locally. For example installing the SDK twice in a row reusing the same bundle pool would cause prompting only once. To solve these problem I'm proposing to handle the two aspects of signature verification at two different times. The first one, related to the integrity would be handled during the fetch phase (as we were initially thinking). This would allow to try to redownload the artifact as part of the download manager loop if a corruption was detected. The second one, related to signer trust, would be done in a new phase running after the fetch but before the install meant to verify the signer trust with the end user. This would solve the two issues mentioned previously. Of course this raises a few questions: - when the user denies trust to a signer, should anything more than abortion of the installation happen? - When an unsigned jar is signed by two different parties not knowing of each others should the jars resulting from this operation have the same artifact key? (e.g I grab an unsigned foo.jar and sign it my signature, and somebody else take the same unsigned foo.jar and sign it with its signature). This raises the question of what *is* an artifact.
some thoughts - the artifact key need not be any different but the descriptors might have some properties that talk about their signers etc. - During the fetch phase we establish the set of artifacts that are to be used in the install. Perhaps it is at that point that we should be selecting artifacts based on signing and preferred signers and trust. - since verification takes non-trivial time it would be unfortunate to verify the same thing multiple times - ther eis a chanllenging case where there are two copies of the same artifact but with different signers. How does the artifact repo handle that? Can it just store the first under the normal name and subsequent ones go in the blob store?
Just a clarification: under the system Pascal describes, the signature is only verified once, during the fetch phase. By verification here, we're just answering the question "is the signature valid". This is the expensive computation, and doesn't require any interaction with the user. The second question, "Do I trust the guy that signed it" - is a relatively inexpensive operation, but it will often require interaction with the user. The advantage of pooling these up and doing this "trust check" after the fetch is that you can control when this interaction happens. This is useful when the fetch phase is down in an automatic background operation. It also allows you to ask the user questions all at once. This saves you from the pain in old update manager where, during an install that took four hours, you would have to periodically check your computer to see if the download is stalled on a dialog asking about signature checks.
I like the idea of making the 'what to do with trust' decision later - we're doing something similar with the "Trusted Bundles" work in the incubator. We load (and evaluate trust) early, and then either enable or disable the bundles. The user is then notified by a widget that there are disabled bundles in the system, and can inspect and enable them if so desired. It' called Safe Staging - the techical term for deferring security decisions to a time when the user is in a comfortable place to deal with it, and can move on to the next stage by either allowing or denying the operation in question. It's a nice fit for well defined state-change processes like the installing or loading of large grain artifacts like bundles. Gets harder when dealing with things like runtime permissions. The more elegant the user interaction can be around something like this, the more likely the user will make the right decision. Removing the pressure of interrrupting a download, etc is a good idea. Link to pertinent research: http://www.andrewpatrick.ca/CHI2003/HCISEC/hcisec-workshop-whitten.pdf www.acsac.org/2002/papers/7.pdf
Created attachment 90487 [details] Trust Check v01 Patch changes: + Added a new phase CheckTrust. The phase collects the locations of the artifacts that have to be installed. At the end of the phase, the files' trust will be checked. + Added a CertificateChecker that loads each JAR file and collects a list of certificates (duplicates ignored) that are untrusted. It starts a service that will show the certificates to the user for trust verification. + Added an IServiceUI interface that can provide a hook to #showCertificates(*). + Added a TrustCertificateService that implments IServiceUI. It opens a dialog with the given certificates. The user may select the certificates to be trusted. + Added a TrustCertificateDialog that displays a list of certificates that can be selected for adding to the keystore. Selecting a certificate in the list will display the certificate's details. If the user does not select all of the certificates for approval, the installation will quit since the CheckTrust phase will return an error status. No message is displayed to the user so I'm thinking that some kind of dialog might need to be shown.
Created attachment 94924 [details] Trust Check v02 Patch changes: +Using the provisional API from equinox.security.ui to display individual certificates. +The certificate confirmation dialog uses a CheckedTreeSelectionDialog to display the certificate chain for each unique certificate. Double-clicking or using the Details button will display a dialog for the selected certificate. TODO: -get the code into the end-user UI -externalize strings -check that the dialog is using the input content correctly -the code for checking if the content is already trusted has been disabled I think this current interface for viewing certificates works well. This should minimally display the required information for the user to make an informed decision on whether to trust the signed content or not.
Created attachment 96932 [details] Trust Check v03 Patch changes: +Externalized the strings +Changed the TrustCertificateDialog to show the selected certificate's chain of trust
Created attachment 97499 [details] Trust Check v04 Merged with changes from HEAD, and added further comments in the source
Created attachment 97632 [details] Trust Check v05 Minor updates to exception handling
Patch released. Tom, can you release the small patch to org.eclipse.equinox.security.ui to add org.eclipse.p2.ui as an x-friend on the provisional package?
I released a change to make org.eclipse.equinox.p2.ui a friend to the org.eclipse.equinox.internal.provisional.security.ui package.
*** Bug 213192 has been marked as a duplicate of this bug. ***
