Re: [ease-dev] [EASE-dev] Introduction

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hi Varun,

You are on the right track. Looking good.

> Signature file must be containing both data and signature.

This sounds right. I'm looking forward to a mocked up suggestion of
what a signed script looks like on a website.

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 17 March 2016 at 02:16, Varun Raval <vraval48@xxxxxxxxx> wrote:
> Hi Jonah,
>
> It's true that signature file doesn't tell us anything about original data.
> Signature is encrypted form of the hash message digest.
> That is, initially our txt file is applied to hash algorithm like SHA1, hash
> is created and that hash is encrypted using private key, encrypted hash is
> our signature. Verifier can decrypt signature and get original hash using
> public key. We can't generate original data from hash. So, for verification
> on verifier end, user will again calculate hash of original data and if both
> hashes are same than it is guaranteed that original data is not modified.
>
> What gpg might be doing is, after generating signature, it will append that
> to original data. Signature file must be containing both data and signature.
> Later on to verify data, it will just use data part to calculate hash and
> signature to get original hash. So, in short, before verifying data,
> signature and data are separated in some way.
>
> Thanking you,
> Varun Raval
>
> On Thu, Mar 17, 2016 at 2:29 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>>
>> 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
>
> --
> 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