Re: [ease-dev] [ease] Sign and Verify Script

[Christian Pontesegger <christian.pontesegger@xxxxxx>]

Hi Varun,

please see my comments below

> I have been researching about how to check a certificate is signed by 
> root CA(Certifying Authority) or not. i.e., certificate of user is 
> authenticated by third party or not? If certificate is signed by root 
> CA, there is a certificate chain associated with that certificate, 
> each one proving signature of previous one. We can check validity of 
> certificate chain using CertPath class. Whether a certificate is 
> signed by root CA or by user can thus be checked too. We need to have 
> an updated list of all root CAs to check whether third party is 
> accepted as CA or not.

> Another question is, are we going to give support for X.509 
> certificate only, or we want to include PGP certificates too? I have 
> been researching about X.509 yet.
I think X.509 would be sufficient. The typical use case will be that we 
have a web server somewhere that hosts signed scripts. Typical these 
servers already have an SSL certificate based on X.509.

> We need to ask user(signer) about using which /Alias/(of private key) 
> he wants to sign script. I have written sample implementation 
> <https://github.com/VarunRaval48/SignCode/tree/master/java.sign/src/signature>, 
> which by knowing place of user keystore, gets all aliases and 
> certificate is imported.
The code sample you provided is already a good start which we could 
reuse later for preferences or user popups. In the beginning it will be 
sufficient to have non-UI code that can verify and sign scripts with a 
given keystore/alias/password combination. There we need to split where 
we put the code. Basic signing/verify functionality should go to 
o.e.ease, where UI components will go to o.e.ease.ui and o.e.ease.scripts.

> Regarding where to place methods for checking Script signature, I have 
> found out several things. First of all we need to check whether script 
> is remote script or not? If remote, then we can verify signature and 
> just extract script part and move on as usual. I think it would be 
> nice to put these methods in /internalInject()/ method of 
> *AbstractScriptEngine* class. Here, before calling /inject()/ method, 
> we can perform above said operations. We can extract script from 
> signature and pass directly the script to /inject().
> /
You already dug quite deep into the code, this is well appreciated! For 
signature checking we do not need to query for remote scripts in first 
place. If code provides a signature, we could check it. Depending on - 
to be defined - preferences users could decide whether they want to 
execute unsigned content and from which source.
The inject() methods of engines might be a bit too deep to add checks 
to. We use these methods also internally to execute dynamic code 
fragments which will not have a signature at all. It would be better to 
protect entry points to script execution, where there are currently 3:
* run targets
    class EaseLaunchDelegate

* script execution
    class ScriptImpl

* include() command
    class EnvironmentModule

By protecting these entry points we still could execute unprotected code 
when we inject it internally. This happens on module loading or when 
users call execute("code").

cheers
Christian