Community
Participate
Working Groups
3.1 M7 The about dialog should indicate whether or not a plug-in is signed. One option would be to include an extra "Signed" column, with a check box or Yes/No indication. Can features be signed too?
For more details, see bug 78208.
Kevin and Adrian, how important is this for 3.2?
interestingly we are just working out the kinks in the JAR signing approach and Adrian and I were just talking about this. Seems like this would be pretty important to have.
It should not just be a yes/no thing but it should indicate the signing party and perhaps there should be a way to get to the certificate.
Minimaly, there should be a column indicating if the bundle (plugin/feature) is signed and if it is signed, a column with the Distinguished Name of the signer. You can "one plus" this many times, but time is running short. Showing the validity dates of the signing certificate, and if present the signing date (this is the new timestamp in Java 1.5 ) could be helpful too.
It seems both costly and cluttered to have all this information any time anyone goes to the About dialog. We should have a mode or separate window that shows all the signing info. We can put an icon in a column if there is signing info. Change the icon if we have verified the signature and allow the user to click on the icon to get signer info.
FYI, there is a certificate verifier service org.eclipse.osgi.internal.provisional.verifier.CertificateVerifierFactory that can be used to get signer information from bundles and jar files. See bug 130383 and bug 127110 for more information.
To find out whether a bundle is signed, I have to create a CertificateVerifier. This takes time since it needs to access the disk. To actually verify a bundle's content takes even more time. I can start fetching the information whether a bundle is signed in a background thread once the dialog is opened, or I could put a button in the dialog that triggers the background thread. How important is it to always display whether bundles are signed? Is it important enough to cause the hard disk to start working when you open the dialog? To be precise, I am not talking about the about dialog itself, I am talking about the dialogs with tables in them that open when you click "Feature Details" or "Plug-in Details" in the about dialog.
Two more questions: 1. Would users typically want to find out which plug-ins (of all plug-ins) are signed, or would they want to multi-select some bundles to find out whether these specific bundles are signed? (The first option seems to be less complex in the UI, but it causes more disk accesses.) 2. The contents of signed plug-ins can be verified to make sure that the content has not change since it was signed. Would users want to do this for all bundles, or just for a multi-selection of bundles (less costly, but again, more complex to present in the UI)? I am leaning towards the first option in each case, with two buttons "Show Signers" and "Verify Contents" to trigger Jobs that would stop when the user exits the dialog.
If it's remotely expensive we shouldn't be triggering this for free when the dialog opens. People going to that dialog for other reasons shouldn't take that hit. I imagine you could have a "signed" column that would be initially blank or show a "?" character. Then, if the user clicks the "Show Signers" button it populates that entire column. For your other questions, I'm leaning the same way as you ;) Another comment: It might make sense to change the label on the existing "More Info" button if more buttons are added. It doesn't give any clues what it's for. Perhaps "Legal Info" would be clearer.
Created attachment 38162 [details] Simple "issigned" indicator for ABout box Here's a patch I was experimenting with for showing if a bundle is signed or not in the plugin details dialog box. It's a very inexpensive way to see if a bundle is signed, without actually verifying it. I did this before the osgi jarverifyer bundle/service became available. Regarding some of the other issues brought up in this thread... In my opinion, the plugin details dialog is not used very often (correct me if I'm wrong), so adding a little overhead for the addtion of this valuable information would be OK. As I understand the jarverifyer service, it does some caching of the results, so if that is being used, AND verification of bundles at load time is turned on, the perfomance should not be too bad, to just get some of the results, like the signer and the validity of the signature and signature chain. Now I have not had a chance to use the osgi jarverifyer service yet, so I'm just relating what I've been told.. :-) I agree with changing the label on the "More Info" button. Thats always bugged me :-) At a minimum, I think you do want to show that a bundle is signed and who it was signed by. The next level of info would be showing that the signature is still valid, when it was signed, and the validity of the signature chain or certificate hierarchy. Also you start down a slippery slope when you begin to display only parts of a certificate or certificate chain. The next step would be to show the contents of an entire certificate. I'm not sure, you could do a good job with all of this given the time left. I'd opt for the "keep it simple" principle and for 3.2 just do what is useful, but too complicated.
Since we are not shipping signed plugins in 3.2, this will be addressed in 3.3.
This should be back on the radar now that we are producing signed builds.
Reassigning bugs to reflect changes in ownership.
Kim, note that this bug has a target milestone of 3.3M5 - we need to make sure that the API provided by Core/OSGi works for us.
Initial work in HEAD. Work is similar to Jay's patch but re-written. I saw the work as a chance to move the plug-ins dialog to use Jface. Changes include: image indicating signed state of the plug-ins (lazily populated) changed "More Info" to "Legal Info" added "Show Signing Info" When pressed, a dialog tray is opened containing the certificate info. This is only the initial cut. I'm not sure I like the dialog tray - it messes with the help implementation. I also need to add problems to the signing info (if parts of the jar are incorrect) and ensure that the new column is accessible. I've created bug 169887 and bug 169888 to track these defects.
Verified in I20070206-0010
