| Re: [ease-dev] [EASE-dev] Introduction |
Hi Varun,
A couple of questions about:
> Some basic requirements are data(in our case: script) and signature must be in different files as per my knowledge so far about key generation. We can merge certificate and sign in a single file by making our custom format since both are binary files.
I would assume that the script file is plain text and human readable.
The signature tells me that it hasn't been modified since the person
signed it, but it does not tell me the contents.
Also, you can have the signature in the same file. See for example how
pgp does it: https://www.gnupg.org/gph/en/manual/x135.html
specifically the Clearsigned documents section.
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 16 March 2016 at 13:20, Varun Raval <vraval48@xxxxxxxxx> wrote:
> Hi Christian,
>
> Some basic requirements are data(in our case: script) and signature must be
> in different files as per my knowledge so far about key generation. We can
> merge certificate and sign in a single file by making our custom format
> since both are binary files.
>
> So, what we can do is, when we encounter scripts from server, we can check
> if there is a signature file with same name on server in same directory or
> not. If it's not there then we can warn user about dangers of that script.
> If it's there then we can import certificate and verify signature.
>
> For this, we need to tell signing user beforehand, that if they are
> interested in uploading scripts they must prefer to sign those scripts and
> upload signature file. User than will have option to upload signature and
> certificate combined in a file that we have generated(by providing some kind
> of functionality like plugin) or by generating signature in user's own way.
> In second case user will have to upload certificate separately so that we
> can verify before executing scripts.
>
> For verifying, as I mentioned earlier, we can check whether signature and
> certificate are there on server and respond accordingly.
>
> Hope this helps!!
>
> Thanking you,
> Varun Raval
>
>
> On Tue, Mar 15, 2016 at 3:20 AM Christian Pontesegger
> <christian.pontesegger@xxxxxx> wrote:
>>
>> Hi Varun,
>>
>> Jar signing is a bit out of focus for this GSoC project. Eclipse has
>> already a solution for this as part of its build system. External parties
>> may use the jarsigner shipped with java which does a similar job.
>> Verifying signatures stored in a jar is an entire different topic and
>> relevant for GSoC, but currently scripts are not shared as part of jar
>> files, so this topic is of minor relevance.
>>
>> But most importantly users may want to consume scripts directly from
>> websites, from colleagues or stuff they share via github, email, ...
>> Such scripts are shared as simple files and should contain their signature
>> as part of the file. In EASE you may write code like this
>>
>> ...
>> include("http://eclipse.org/EASE/some_sample_script.js")
>> ...
>>
>>
>> Which fetches the data from the webserver and executes the script right
>> away. Users may want to make sure that such scripts will only execute signed
>> content from trusted sources. So we should think of ways to store a
>> certificate within the file and make sure it gets validated before
>> execution.
>>
>> cheers
>>
>> Christian
>>
>>
>>
>> On 03/14/2016 05:17 AM, Varun Raval wrote:
>>
>> Hi Christian,
>>
>> Thanks for the feedback and Thanks John Graham for helping.
>>
>> Our signing and verifying flow can be like this:
>>
>> 1. User makes plugin of his scripts, user makes feature for that plugin
>> and include feature on update site
>> 2. After jar is created on update site, we can provide support for signing
>> jar using certificate in user keystore by either right clicking on
>> that jar in
>> eclipse window or by some other means.
>> We can automate these first two steps for user using EASE if it's possible
>> or by adding functionality to eclipse
>> 3. Then receiver can install that plugin during which eclipse by default
>> can
>> tell whether software is signed or not and if signed, expired or not
>> 4. We can also give additional options on whether user want to import
>> certificate
>> to keystore for further reference.
>>
>> Hope I am going on right track.
>>
>> Thanks again for helping!!
>>
>> On Wed, Mar 9, 2016 at 4:17 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
>> wrote:
>>>
>>> Hi Varun,
>>>
>>> As part of this investigation, knowing a bit about what key signing is
>>> already done by Eclipse may be useful. As it happens Mikaël Barbero
>>> just wrote a summary on the cbi-dev list.
>>> http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01652.html
>>>
>>> Jonah
>>> ~~~
>>> Jonah Graham
>>> Kichwa Coders Ltd.
>>> www.kichwacoders.com
>>>
>>>
>>> On 9 March 2016 at 07:30, Christian Pontesegger
>>> <christian.pontesegger@xxxxxx> wrote:
>>> > Hi Varun,
>>> >
>>> > first, just call me Christian, 'sir' is definitely not required :)
>>> >
>>> > The general idea of signing scripts is that eg eclipse may put up some
>>> > scripts on their web servers which users may consume. As scripts are
>>> > potentially dangerous - they would have access to the local file system
>>> > -
>>> > users want to be sure that remote scripts are safe and untampered.
>>> > Basically
>>> > very similar to an https connection. You rely on some root certificates
>>> > to
>>> > be sure that you may trust these scripts. Self signing certificates
>>> > might be
>>> > used, but it will be harder for the user to decide on the trust level
>>> > of
>>> > such certificates.
>>> >
>>> > For option 1 this means that we need to retrieve public keys from
>>> > script
>>> > authors first and import them before we can verify scripts. This is an
>>> > option, but forces the user to manually deal with security stuff.
>>> >
>>> > Option 2 uses the keystore and its root certificates automatically. Eg
>>> > scripts signed by eclipse.org would be recognized as safe out of the
>>> > box. I
>>> > prefer this one. We then need some UI to ask the user for unknown
>>> > certificates if he wants to trust them and eventually import them into
>>> > the
>>> > keystore.
>>> >
>>> > Option 3 is not needed, as eclipse can do this automatically during the
>>> > build. Scripts delivered within a jar are already on the localhost, so
>>> > it is
>>> > easier to make sure these scripts are safe.
>>> >
>>> > Regarding CSRs I do not think that eclipse would start signing keys for
>>> > anybody. So I guess for this project we can rely on certificates that
>>> > either
>>> > are already part of your keystore or could be imported into it.
>>> >
>>> > I like that you already play around with the code and give it a try!
>>> >
>>> > cheers
>>> >
>>> > Christian
>>> >
>>> > _______________________________________________
>>> > ease-dev mailing list
>>> > ease-dev@xxxxxxxxxxx
>>> > To change your delivery options, retrieve your password, or unsubscribe
>>> > from
>>> > this list, visit
>>> > https://dev.eclipse.org/mailman/listinfo/ease-dev
>>> _______________________________________________
>>> ease-dev mailing list
>>> ease-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/ease-dev
>>
>> --
>> Varun Raval
>>
>> _______________________________________________
>> ease-dev mailing list
>> ease-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ease-dev
>>
>>
>> _______________________________________________
>> ease-dev mailing list
>> ease-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ease-dev
>
> --
> Varun Raval
> _______________________________________________
> ease-dev mailing list
> ease-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ease-dev
_______________________________________________
ease-dev mailing list
ease-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ease-dev