Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

Mark is talking about downloading and installing on the fly so as long as
baked into the app it would be fine. Widgets do use foreign code if native.

As long as the private key isn’t compromised, then you can keep using the
same pair. One advantage to changing though would be to ensure that the
code couldn’t be mixed since the old key wouldn’t verify something signed
with the new one. So if you changed something in the app where you couldn’t
mix code, changing the key would ensure that didn’t happen.
On Wed, May 23, 2018 at 2:21 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Do Android widgets use foreign handlers? If only some of them would be
> excluded, it would be helpful to know which those are. A symbol or note
> in the inclusions list would be nice. Or am I conflating widgets with
> other extensions?
>
> I'm using the Android toast library. Would that count? It doesn't seem
> like it should, it doesn't affect the OS.
>
> On 5/23/18 2:56 AM, Mark Waddingham via use-livecode wrote:
> > On 2018-05-23 05:14, Brian Milby wrote:
> >> @Mark
> >> Would the loading of LCB extensions be a good thing to add to the
> >> securityPermissions (or does external already cover it)?
> >
> > The securityPermissions is definitely the right place to do this.
> > Standalones are built with a small startup script which is run, so we
> > can tie the option in the S/B to adding a line in that script to
> > restrict permissions.
> >
> > As to whether it should be rolled into external, or whether it needs a
> > new one needs a little thought. I suspect it won't do any harm to add
> > another permission for it - after all it is quite specific (eventually
> > we want it to be - don't allow loading of LCB extensions which use
> > foreign handlers).
> >
> > Warmest Regards,
> >
> > Mark.
> >
> >>
> >> On Tue, May 22, 2018 at 7:12 PM Brian Milby  wrote:
> >>
> >>> Well, it isn't a full library, but I did put together a demo of how
> >>> it can work:
> >>>
> >>> https://github.com/bwmilby/lc-misc/tree/master/SignVerify [1]
> >>>
> >>>
> >>
> https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode
> >>
> >>> [2]
> >>>
> >>> I've only tested on Mac, but it should work everywhere if you
> >>> already have the keys. Not sure how to generate the keys on
> >>> Windows, but the button should work on Linux.
> >>>
> >>> Hope it helps.
> >>>
> >>> Thanks,
> >>> Brian
> >>>
> >>> On Tue, May 22, 2018 at 2:57 PM, Brian Milby 
> >>> wrote:
> >>> Can’t make any changes to the stack once you generate the hash or
> >>> it will not match.
> >>>
> >>> On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode
> >>>  wrote:
> >>> Would it be okay to store the encrypted hash in a custom property of
> >>> the
> >>> remote stack?
> >>>
> >>> I'll need to experiment to see if I can do what you've outlined,
> >>> unless
> >>> you write a library before I figure it out... ;)
> >>>
> >>> On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:
>  The dictionary entries that you want are "encrypt using rsa",
> >>> "decrypt
>  using rsa", and "messageDigest'.
> 
>  High level process...
>  - Generate a public/private key pair
>  - Package the file that you want to ensure is not tampered with
>  - Generate a hash of the file (messageDigest)
>  - Encrypt the hash with your private key (encrypt using rsa)
>  - Store the encrypted hash along with the file to download (or
> >>> possibly put
>  them both into a zip to make a single download)
> 
>  - Store the public key inside the app
>  - Download the encrypted hash and the file
>  - Decrypt the hash using the public key (decrypt using rsa)
>  - Compare the decrypted hash with a calculated hash of the
> >>> downloaded file
>  - If they match, then the file has not been changed
> 
>  If you also want to utilize a similar process to secure the file
> >>> itself
>  from viewing, then you will need to do something a little
> >>> different. The
>  dictionary suggests that a possible method would be to generate a
> >>> random
>  key to actually encrypt the file (symmetric encryption -
> >>> encrypt). That
>  key would be encrypted with a public key. The encrypted file and
> >>> encrypted
>  key would be stored for download. The app would use the private
> >>> key to
>  decrypt the data encryption key. Once the data encryption key
> >>> was
>  obtained, the data could be decrypted. You would want to use a
> >>> different
>  public/private pair of keys for this operation.
> 
>  This all sounds like a good project for a library (for use in an
> >>> app) and a
>  stack (to handle the front end). I didn't go checking to see if
> >>> one
>  already existed though.
> >>>
> >>> --
> >>> Jacqueline Landman Gay | jac...@hyperactivesw.com
> >>> HyperActive Software | 

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

Do Android widgets use foreign handlers? If only some of them would be 
excluded, it would be helpful to know which those are. A symbol or note 
in the inclusions list would be nice. Or am I conflating widgets with 
other extensions?


I'm using the Android toast library. Would that count? It doesn't seem 
like it should, it doesn't affect the OS.


On 5/23/18 2:56 AM, Mark Waddingham via use-livecode wrote:

On 2018-05-23 05:14, Brian Milby wrote:

@Mark
Would the loading of LCB extensions be a good thing to add to the
securityPermissions (or does external already cover it)?


The securityPermissions is definitely the right place to do this. 
Standalones are built with a small startup script which is run, so we 
can tie the option in the S/B to adding a line in that script to 
restrict permissions.


As to whether it should be rolled into external, or whether it needs a 
new one needs a little thought. I suspect it won't do any harm to add 
another permission for it - after all it is quite specific (eventually 
we want it to be - don't allow loading of LCB extensions which use 
foreign handlers).


Warmest Regards,

Mark.



On Tue, May 22, 2018 at 7:12 PM Brian Milby  wrote:


Well, it isn't a full library, but I did put together a demo of how
it can work:

https://github.com/bwmilby/lc-misc/tree/master/SignVerify [1]


https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode 


[2]

I've only tested on Mac, but it should work everywhere if you
already have the keys. Not sure how to generate the keys on
Windows, but the button should work on Linux.

Hope it helps.

Thanks,
Brian

On Tue, May 22, 2018 at 2:57 PM, Brian Milby 
wrote:
Can’t make any changes to the stack once you generate the hash or
it will not match.

On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode
 wrote:
Would it be okay to store the encrypted hash in a custom property of
the
remote stack?

I'll need to experiment to see if I can do what you've outlined,
unless
you write a library before I figure it out... ;)

On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:

The dictionary entries that you want are "encrypt using rsa",

"decrypt

using rsa", and "messageDigest'.

High level process...
- Generate a public/private key pair
- Package the file that you want to ensure is not tampered with
- Generate a hash of the file (messageDigest)
- Encrypt the hash with your private key (encrypt using rsa)
- Store the encrypted hash along with the file to download (or

possibly put

them both into a zip to make a single download)

- Store the public key inside the app
- Download the encrypted hash and the file
- Decrypt the hash using the public key (decrypt using rsa)
- Compare the decrypted hash with a calculated hash of the

downloaded file

- If they match, then the file has not been changed

If you also want to utilize a similar process to secure the file

itself

from viewing, then you will need to do something a little

different. The

dictionary suggests that a possible method would be to generate a

random

key to actually encrypt the file (symmetric encryption -

encrypt). That

key would be encrypted with a public key. The encrypted file and

encrypted

key would be stored for download. The app would use the private

key to

decrypt the data encryption key. Once the data encryption key

was

obtained, the data could be decrypted. You would want to use a

different

public/private pair of keys for this operation.

This all sounds like a good project for a library (for use in an

app) and a

stack (to handle the front end). I didn't go checking to see if

one

already existed though.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
[3]

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode [4]




Links:
--
[1] https://github.com/bwmilby/lc-misc/tree/master/SignVerify
[2] 
https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode 


[3] http://www.hyperactivesw.com
[4] http://lists.runrev.com/mailman/listinfo/use-livecode





--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

Thanks very much for this, Brian. It's not only helpful, it's easier 
than I was trying to make it.


Am I correct that I can continue to use the same .pem files for each 
update, as long as I recreate the signatures? Is there any disadvantage 
to that? It doesn't matter too much since your generator script works 
great on my Mac so it's easy to make new keys.


On 5/22/18 7:12 PM, Brian Milby via use-livecode wrote:

Well, it isn't a full library, but I did put together a demo of how it can
work:

https://github.com/bwmilby/lc-misc/tree/master/SignVerify
https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode

I've only tested on Mac, but it should work everywhere if you already have
the keys.  Not sure how to generate the keys on Windows, but the button
should work on Linux.

Hope it helps.

Thanks,
Brian

On Tue, May 22, 2018 at 2:57 PM, Brian Milby  wrote:


Can’t make any changes to the stack once you generate the hash or it will
not match.

On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


Would it be okay to store the encrypted hash in a custom property of the
remote stack?

I'll need to experiment to see if I can do what you've outlined, unless
you write a library before I figure it out... ;)


On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:

The dictionary entries that you want are "encrypt using rsa", "decrypt
using rsa", and "messageDigest'.

High level process...
- Generate a public/private key pair
- Package the file that you want to ensure is not tampered with
- Generate a hash of the file (messageDigest)
- Encrypt the hash with your private key (encrypt using rsa)
- Store the encrypted hash along with the file to download (or possibly

put

them both into a zip to make a single download)

- Store the public key inside the app
- Download the encrypted hash and the file
- Decrypt the hash using the public key (decrypt using rsa)
- Compare the decrypted hash with a calculated hash of the downloaded

file

- If they match, then the file has not been changed

If you also want to utilize a similar process to secure the file itself
from viewing, then you will need to do something a little different.

The

dictionary suggests that a possible method would be to generate a random
key to actually encrypt the file (symmetric encryption - encrypt).  That
key would be encrypted with a public key.  The encrypted file and

encrypted

key would be stored for download.  The app would use the private key to
decrypt the data encryption key.  Once the data encryption key was
obtained, the data could be decrypted.  You would want to use a

different

public/private pair of keys for this operation.

This all sounds like a good project for a library (for use in an app)

and a

stack (to handle the front end).  I didn't go checking to see if one
already existed though.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Mark Waddingham via use-livecode]

On 2018-05-23 05:14, Brian Milby wrote:

@Mark
Would the loading of LCB extensions be a good thing to add to the
securityPermissions (or does external already cover it)?


The securityPermissions is definitely the right place to do this. 
Standalones are built with a small startup script which is run, so we 
can tie the option in the S/B to adding a line in that script to 
restrict permissions.


As to whether it should be rolled into external, or whether it needs a 
new one needs a little thought. I suspect it won't do any harm to add 
another permission for it - after all it is quite specific (eventually 
we want it to be - don't allow loading of LCB extensions which use 
foreign handlers).


Warmest Regards,

Mark.



On Tue, May 22, 2018 at 7:12 PM Brian Milby  wrote:


Well, it isn't a full library, but I did put together a demo of how
it can work:

https://github.com/bwmilby/lc-misc/tree/master/SignVerify [1]



https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode

[2]

I've only tested on Mac, but it should work everywhere if you
already have the keys. Not sure how to generate the keys on
Windows, but the button should work on Linux.

Hope it helps.

Thanks,
Brian

On Tue, May 22, 2018 at 2:57 PM, Brian Milby 
wrote:
Can’t make any changes to the stack once you generate the hash or
it will not match.

On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode
 wrote:
Would it be okay to store the encrypted hash in a custom property of
the
remote stack?

I'll need to experiment to see if I can do what you've outlined,
unless
you write a library before I figure it out... ;)

On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:

The dictionary entries that you want are "encrypt using rsa",

"decrypt

using rsa", and "messageDigest'.

High level process...
- Generate a public/private key pair
- Package the file that you want to ensure is not tampered with
- Generate a hash of the file (messageDigest)
- Encrypt the hash with your private key (encrypt using rsa)
- Store the encrypted hash along with the file to download (or

possibly put

them both into a zip to make a single download)

- Store the public key inside the app
- Download the encrypted hash and the file
- Decrypt the hash using the public key (decrypt using rsa)
- Compare the decrypted hash with a calculated hash of the

downloaded file

- If they match, then the file has not been changed

If you also want to utilize a similar process to secure the file

itself

from viewing, then you will need to do something a little

different. The

dictionary suggests that a possible method would be to generate a

random

key to actually encrypt the file (symmetric encryption -

encrypt). That

key would be encrypted with a public key. The encrypted file and

encrypted

key would be stored for download. The app would use the private

key to

decrypt the data encryption key. Once the data encryption key

was

obtained, the data could be decrypted. You would want to use a

different

public/private pair of keys for this operation.

This all sounds like a good project for a library (for use in an

app) and a

stack (to handle the front end). I didn't go checking to see if

one

already existed though.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
[3]

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode [4]




Links:
--
[1] https://github.com/bwmilby/lc-misc/tree/master/SignVerify
[2] 
https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode

[3] http://www.hyperactivesw.com
[4] http://lists.runrev.com/mailman/listinfo/use-livecode


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

@Mark
Would the loading of LCB extensions be a good thing to add to the
securityPermissions (or does external already cover it)?

On Tue, May 22, 2018 at 7:12 PM Brian Milby  wrote:

> Well, it isn't a full library, but I did put together a demo of how it can
> work:
>
> https://github.com/bwmilby/lc-misc/tree/master/SignVerify
>
> https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode
>
> I've only tested on Mac, but it should work everywhere if you already have
> the keys.  Not sure how to generate the keys on Windows, but the button
> should work on Linux.
>
> Hope it helps.
>
> Thanks,
> Brian
>
> On Tue, May 22, 2018 at 2:57 PM, Brian Milby  wrote:
>
>> Can’t make any changes to the stack once you generate the hash or it will
>> not match.
>>
>> On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>>> Would it be okay to store the encrypted hash in a custom property of the
>>> remote stack?
>>>
>>> I'll need to experiment to see if I can do what you've outlined, unless
>>> you write a library before I figure it out... ;)
>>>
>>>
>>> On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:
>>> > The dictionary entries that you want are "encrypt using rsa", "decrypt
>>> > using rsa", and "messageDigest'.
>>> >
>>> > High level process...
>>> > - Generate a public/private key pair
>>> > - Package the file that you want to ensure is not tampered with
>>> > - Generate a hash of the file (messageDigest)
>>> > - Encrypt the hash with your private key (encrypt using rsa)
>>> > - Store the encrypted hash along with the file to download (or
>>> possibly put
>>> > them both into a zip to make a single download)
>>> >
>>> > - Store the public key inside the app
>>> > - Download the encrypted hash and the file
>>> > - Decrypt the hash using the public key (decrypt using rsa)
>>> > - Compare the decrypted hash with a calculated hash of the downloaded
>>> file
>>> > - If they match, then the file has not been changed
>>> >
>>> > If you also want to utilize a similar process to secure the file itself
>>> > from viewing, then you will need to do something a little different.
>>> The
>>> > dictionary suggests that a possible method would be to generate a
>>> random
>>> > key to actually encrypt the file (symmetric encryption - encrypt).
>>> That
>>> > key would be encrypted with a public key.  The encrypted file and
>>> encrypted
>>> > key would be stored for download.  The app would use the private key to
>>> > decrypt the data encryption key.  Once the data encryption key was
>>> > obtained, the data could be decrypted.  You would want to use a
>>> different
>>> > public/private pair of keys for this operation.
>>> >
>>> > This all sounds like a good project for a library (for use in an app)
>>> and a
>>> > stack (to handle the front end).  I didn't go checking to see if one
>>> > already existed though.
>>>
>>>
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

Well, it isn't a full library, but I did put together a demo of how it can
work:

https://github.com/bwmilby/lc-misc/tree/master/SignVerify
https://github.com/bwmilby/lc-misc/raw/master/SignVerify/SignVerify.livecode

I've only tested on Mac, but it should work everywhere if you already have
the keys.  Not sure how to generate the keys on Windows, but the button
should work on Linux.

Hope it helps.

Thanks,
Brian

On Tue, May 22, 2018 at 2:57 PM, Brian Milby  wrote:

> Can’t make any changes to the stack once you generate the hash or it will
> not match.
>
> On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Would it be okay to store the encrypted hash in a custom property of the
>> remote stack?
>>
>> I'll need to experiment to see if I can do what you've outlined, unless
>> you write a library before I figure it out... ;)
>>
>>
>> On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:
>> > The dictionary entries that you want are "encrypt using rsa", "decrypt
>> > using rsa", and "messageDigest'.
>> >
>> > High level process...
>> > - Generate a public/private key pair
>> > - Package the file that you want to ensure is not tampered with
>> > - Generate a hash of the file (messageDigest)
>> > - Encrypt the hash with your private key (encrypt using rsa)
>> > - Store the encrypted hash along with the file to download (or possibly
>> put
>> > them both into a zip to make a single download)
>> >
>> > - Store the public key inside the app
>> > - Download the encrypted hash and the file
>> > - Decrypt the hash using the public key (decrypt using rsa)
>> > - Compare the decrypted hash with a calculated hash of the downloaded
>> file
>> > - If they match, then the file has not been changed
>> >
>> > If you also want to utilize a similar process to secure the file itself
>> > from viewing, then you will need to do something a little different.
>> The
>> > dictionary suggests that a possible method would be to generate a random
>> > key to actually encrypt the file (symmetric encryption - encrypt).  That
>> > key would be encrypted with a public key.  The encrypted file and
>> encrypted
>> > key would be stored for download.  The app would use the private key to
>> > decrypt the data encryption key.  Once the data encryption key was
>> > obtained, the data could be decrypted.  You would want to use a
>> different
>> > public/private pair of keys for this operation.
>> >
>> > This all sounds like a good project for a library (for use in an app)
>> and a
>> > stack (to handle the front end).  I didn't go checking to see if one
>> > already existed though.
>>
>>
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

Can’t make any changes to the stack once you generate the hash or it will
not match.
On Tue, May 22, 2018 at 2:41 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Would it be okay to store the encrypted hash in a custom property of the
> remote stack?
>
> I'll need to experiment to see if I can do what you've outlined, unless
> you write a library before I figure it out... ;)
>
>
> On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:
> > The dictionary entries that you want are "encrypt using rsa", "decrypt
> > using rsa", and "messageDigest'.
> >
> > High level process...
> > - Generate a public/private key pair
> > - Package the file that you want to ensure is not tampered with
> > - Generate a hash of the file (messageDigest)
> > - Encrypt the hash with your private key (encrypt using rsa)
> > - Store the encrypted hash along with the file to download (or possibly
> put
> > them both into a zip to make a single download)
> >
> > - Store the public key inside the app
> > - Download the encrypted hash and the file
> > - Decrypt the hash using the public key (decrypt using rsa)
> > - Compare the decrypted hash with a calculated hash of the downloaded
> file
> > - If they match, then the file has not been changed
> >
> > If you also want to utilize a similar process to secure the file itself
> > from viewing, then you will need to do something a little different.  The
> > dictionary suggests that a possible method would be to generate a random
> > key to actually encrypt the file (symmetric encryption - encrypt).  That
> > key would be encrypted with a public key.  The encrypted file and
> encrypted
> > key would be stored for download.  The app would use the private key to
> > decrypt the data encryption key.  Once the data encryption key was
> > obtained, the data could be decrypted.  You would want to use a different
> > public/private pair of keys for this operation.
> >
> > This all sounds like a good project for a library (for use in an app)
> and a
> > stack (to handle the front end).  I didn't go checking to see if one
> > already existed though.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

Would it be okay to store the encrypted hash in a custom property of the 
remote stack?


I'll need to experiment to see if I can do what you've outlined, unless 
you write a library before I figure it out... ;)



On 5/22/18 12:03 AM, Brian Milby via use-livecode wrote:

The dictionary entries that you want are "encrypt using rsa", "decrypt
using rsa", and "messageDigest'.

High level process...
- Generate a public/private key pair
- Package the file that you want to ensure is not tampered with
- Generate a hash of the file (messageDigest)
- Encrypt the hash with your private key (encrypt using rsa)
- Store the encrypted hash along with the file to download (or possibly put
them both into a zip to make a single download)

- Store the public key inside the app
- Download the encrypted hash and the file
- Decrypt the hash using the public key (decrypt using rsa)
- Compare the decrypted hash with a calculated hash of the downloaded file
- If they match, then the file has not been changed

If you also want to utilize a similar process to secure the file itself
from viewing, then you will need to do something a little different.  The
dictionary suggests that a possible method would be to generate a random
key to actually encrypt the file (symmetric encryption - encrypt).  That
key would be encrypted with a public key.  The encrypted file and encrypted
key would be stored for download.  The app would use the private key to
decrypt the data encryption key.  Once the data encryption key was
obtained, the data could be decrypted.  You would want to use a different
public/private pair of keys for this operation.

This all sounds like a good project for a library (for use in an app) and a
stack (to handle the front end).  I didn't go checking to see if one
already existed though.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

The dictionary entries that you want are "encrypt using rsa", "decrypt
using rsa", and "messageDigest'.

High level process...
- Generate a public/private key pair
- Package the file that you want to ensure is not tampered with
- Generate a hash of the file (messageDigest)
- Encrypt the hash with your private key (encrypt using rsa)
- Store the encrypted hash along with the file to download (or possibly put
them both into a zip to make a single download)

- Store the public key inside the app
- Download the encrypted hash and the file
- Decrypt the hash using the public key (decrypt using rsa)
- Compare the decrypted hash with a calculated hash of the downloaded file
- If they match, then the file has not been changed

If you also want to utilize a similar process to secure the file itself
from viewing, then you will need to do something a little different.  The
dictionary suggests that a possible method would be to generate a random
key to actually encrypt the file (symmetric encryption - encrypt).  That
key would be encrypted with a public key.  The encrypted file and encrypted
key would be stored for download.  The app would use the private key to
decrypt the data encryption key.  Once the data encryption key was
obtained, the data could be decrypted.  You would want to use a different
public/private pair of keys for this operation.

This all sounds like a good project for a library (for use in an app) and a
stack (to handle the front end).  I didn't go checking to see if one
already existed though.

On Mon, May 21, 2018 at 10:24 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> @Mark, thanks so much for your post, it helps. When you get a chance it
> would be great to get more detail about how to set up the RSA keys. I'm
> sure I won't be the only person here who needs this, so you'll be helping
> everyone.
>
> I think I can find out how to generate the keys, but I'm not quite sure
> what to do with them after that, although I get the gist of it.
>
> On 5/21/18 1:15 PM, Mark Waddingham via use-livecode wrote:
>
>> P.S. I realize the above 'outline' of how to do code signing using PKI is
>> somewhat brief. I'll endeavour to write it up in more detail as soon as I
>> can.
>>
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

@Mark, thanks so much for your post, it helps. When you get a chance it 
would be great to get more detail about how to set up the RSA keys. I'm 
sure I won't be the only person here who needs this, so you'll be 
helping everyone.


I think I can find out how to generate the keys, but I'm not quite sure 
what to do with them after that, although I get the gist of it.


On 5/21/18 1:15 PM, Mark Waddingham via use-livecode wrote:
P.S. I realize the above 'outline' of how to do code signing using PKI 
is somewhat brief. I'll endeavour to write it up in more detail as soon 
as I can.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Mark Waddingham via use-livecode]

On 2018-05-21 17:51, J. Landman Gay via use-livecode wrote:

My client sells supplies to hospitals and the mobile app is part of a
tracking system. We have been distributing the app from a web site but
some users don't trust that and others don't understand why they need
to enable "unknown sources" in prefs. It would be easier to distribute
through the official channel.

If there are any issues with the app we need immediate fixes or the
tracking breaks. A remote stack allows me to do that.

A while back Colin was going to get a Google reviewer in touch with
Mark Waddingham so Mark could explain why this isn't dangerous in LC
but I'm not sure what happened to that.


I never received any contact from Google on this topic - although it 
sounds like Colin has had confirmation that they seem relatively happy 
with the LiveCode apps they have found with regards the new Play Store 
rules.


Re-reading the policy again the two main points it contains which are 
relevant here are as follows:


"An app distributed via Google Play may not modify, replace, or update 
itself using any method other than Google Play’s update mechanism. 
Likewise, an app may not download executable code (e.g. dex, JAR, .so 
files) from a source other than Google Play. This restriction does not 
apply to code that runs in a virtual machine and has limited access to 
Android APIs (such as JavaScript in a webview or browser)."


"The following are explicitly prohibited:
...
Apps or SDKs that download executable code, such as dex files or native 
code, from a source other than Google Play.

..."

The reason to impose these rules is simply to protect the end-user from 
malicious intent. In this case, the specific thing they are trying to 
protect users from is an app vendor who unknowingly creates a vehicle 
for such action - the maliciousness could be from being able to exploit 
unknown vulnerabilities in system APIs (breaking the app sandbox), or 
from being able to subvert an app and the interaction it has with the 
user.


The thing to remember is that anything downloaded over the internet is 
at risk if the connection is not properly secured. For a connection to 
be properly secured it is not just sufficient to use SSL (or variants 
there-of) but also to ensure that the server end-point is also secure. 
For example, you might put your code update on a server which is subject 
to a hacking attack, and in through doing so the hackers find they can 
inject arbitrary code into all currently installed instances of your app 
by changing the update code file which is downloaded.


Maintaining a server which allows download of invisible executable code 
updates straight into apps on end-user devices is a significant 
responsibility - and it is too much of a risk to allow in the general 
case especially given both the quantity of app vendors and their widely 
varying resources.


So, what can we do?

The first thing is something you as a developer can do (and really 
should if you need this convenicene)...


If you need to download updates 'on the fly', and your updates do 
contain executable code (which LiveCode Script is) the you can use 
public key cryptography to sign your downloads. Basically you generate a 
public and private RSA key pair. The private one must be treated with 
due diligence, and is used to create a signature of the stack which 
contains your updates. The app itself contains the public key - when the 
app updates, after downloading the stack, it verifies the signature and 
only applies it if the verification succeeds. Assuming you take due 
diligence over your private key (in particular never store it on the 
same server as the app update!), then it means that your updates cannot 
be subverted - regardless of whether your update server is hacked. If 
your private key does become compromised, then you release no more 
updates signed with it, and issue a Google Play Store update for your 
app which contains a new public key.


Note: I should point out, you don't need a 'root CA signed code cert' 
for the above - a public/private key pair you generate yourself is more 
than sufficient since you are baking the public key into an app 
submitted to the google play store which is signed using similar trust 
mechanisms which is globally verifiable.


The second thing is something we can do to the engine itself...

There is a critical line in the above: "This restriction does not apply 
to code that runs in a virtual machine and has limited access to Android 
APIs (such as JavaScript in a webview or browser)."


As it stands right now, you can load LCB extensions at runtime in 
standalones which have bene downloaded. This is a hole we can close by 
adding an option to turn off the 'load extension' command in standalones 
in the S/B. This means that LiveCode Android apps, when built with that 
option turned on fall into the category of "code that runs in a virtual 
machine and has limited access to Android APIs". I'll chat to Ali 

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

That's great! Thanks for posting that Colin, I'm going to take the chance. 
I didn't know things had proceeded that far.



Do you have any more details about the decision so we can avoid potential 
conflicts? How is the determination about noncompliance made?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 21, 2018 12:03:24 PM Colin Holgate via use-livecode 
 wrote:


At the time Mark thought there might be some LCB tweaks LiveCode might make 
to keep Google happy, but after the Google guys looked at a number of 
LiveCode apps, they concluded that they don’t seem to violate the new 
policy. Well, it was new 11 months ago when this came up last time!

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Colin Holgate via use-livecode]

At the time Mark thought there might be some LCB tweaks LiveCode might make to 
keep Google happy, but after the Google guys looked at a number of LiveCode 
apps, they concluded that they don’t seem to violate the new policy. Well, it 
was new 11 months ago when this came up last time!
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Brian Milby via use-livecode]

Would you need to go full “splash stack”? Could you have a “supplemental
data” stack that is checked for/updated on launch and has data inside it to
update any objects that need to be adjusted?
On Mon, May 21, 2018 at 10:52 AM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My client sells supplies to hospitals and the mobile app is part of a
> tracking system. We have been distributing the app from a web site but
> some
> users don't trust that and others don't understand why they need to enable
> "unknown sources" in prefs. It would be easier to distribute through the
> official channel.
>
> If there are any issues with the app we need immediate fixes or the
> tracking breaks. A remote stack allows me to do that.
>
> A while back Colin was going to get a Google reviewer in touch with Mark
> Waddingham so Mark could explain why this isn't dangerous in LC but I'm
> not
> sure what happened to that.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On May 21, 2018 6:41:34 AM Lagi Pittas via use-livecode
>  wrote:
>
> > Hi Jacque,
> >
> > If your app is for a specific client/company do you put it on the Play
> > Store still?
> > Or is it an app for a company who wants to sell it? -
> >
> > Lagi
> >
> > On 20 May 2018 at 21:06, J. Landman Gay via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Has anyone released an Android app on Google Play that uses the
> >> splash-stack method to download the real working stack from a server?
> Was
> >> it rejected? My current project needs to provide instant updates in case
> >> there is a serious bug, and having an accessible stack on the server
> >> accomodates that.
> >>
> >> --
> >> Jacqueline Landman Gay | jac...@hyperactivesw.com
> >> HyperActive Software   | http://www.hyperactivesw.com
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

My client sells supplies to hospitals and the mobile app is part of a 
tracking system. We have been distributing the app from a web site but some 
users don't trust that and others don't understand why they need to enable 
"unknown sources" in prefs. It would be easier to distribute through the 
official channel.


If there are any issues with the app we need immediate fixes or the 
tracking breaks. A remote stack allows me to do that.


A while back Colin was going to get a Google reviewer in touch with Mark 
Waddingham so Mark could explain why this isn't dangerous in LC but I'm not 
sure what happened to that.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 21, 2018 6:41:34 AM Lagi Pittas via use-livecode 
 wrote:



Hi Jacque,

If your app is for a specific client/company do you put it on the Play
Store still?
Or is it an app for a company who wants to sell it? -

Lagi

On 20 May 2018 at 21:06, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


Has anyone released an Android app on Google Play that uses the
splash-stack method to download the real working stack from a server? Was
it rejected? My current project needs to provide instant updates in case
there is a serious bug, and having an accessible stack on the server
accomodates that.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Splash-stack apps on Google Play

[Lagi Pittas via use-livecode]

Hi Jacque,

If your app is for a specific client/company do you put it on the Play
Store still?
Or is it an app for a company who wants to sell it? -

Lagi

On 20 May 2018 at 21:06, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Has anyone released an Android app on Google Play that uses the
> splash-stack method to download the real working stack from a server? Was
> it rejected? My current project needs to provide instant updates in case
> there is a serious bug, and having an accessible stack on the server
> accomodates that.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Splash-stack apps on Google Play

[J. Landman Gay via use-livecode]

Has anyone released an Android app on Google Play that uses the 
splash-stack method to download the real working stack from a server? 
Was it rejected? My current project needs to provide instant updates in 
case there is a serious bug, and having an accessible stack on the 
server accomodates that.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode