Splash-stack apps on Google Play

Wed May 23 17:29:16 EDT 2018

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 at 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 <brian at milby7.com> 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 <brian at milby7.com>
> >>> 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 at 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 | jacque at hyperactivesw.com
> >>> HyperActive Software | http://www.hyperactivesw.com
> >>> [3]
> >>>
> >>> _______________________________________________
> >>> use-livecode mailing list
> >>> use-livecode at 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         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode