Re: Encrypted standalones
In my case it isn't a splash stack this time, it's self-contained. But that pane is always disabled for mobile apps, regardless of the structure of the mainstack. On 4/19/19 12:35 AM, prothero--- via use-livecode wrote: I’ll be interested in hearing the answer to this. I had assumed that the setup would be a splash stack that loaded the other app stacks, which were in the resources folder. True? Bill William Prothero http://es.earthednet.org On Apr 18, 2019, at 9:25 PM, Richard Gaskin via use-livecode wrote: J. Landman Gay jacque at hyperactivesw.com It's not actually a regression, it's always been that way. But it's too piddly to bother the team with right now, and there's a workaround. Maybe It's curious that the entire Stacks pane is disabled when either mobile platform is selected. That seems intentional, but I can't imagine why each one of those features is irrelevant when building for mobile. At a minimum, it would be nice to be able to set the password. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
I’ll be interested in hearing the answer to this. I had assumed that the setup would be a splash stack that loaded the other app stacks, which were in the resources folder. True? Bill William Prothero http://es.earthednet.org > On Apr 18, 2019, at 9:25 PM, Richard Gaskin via use-livecode > wrote: > > J. Landman Gay jacque at hyperactivesw.com > > It's not actually a regression, it's always been that way. But it's > > too piddly to bother the team with right now, and there's a > > workaround. Maybe > > It's curious that the entire Stacks pane is disabled when either mobile > platform is selected. > > That seems intentional, but I can't imagine why each one of those features is > irrelevant when building for mobile. > > At a minimum, it would be nice to be able to set the password. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
J. Landman Gay jacque at hyperactivesw.com > It's not actually a regression, it's always been that way. But it's > too piddly to bother the team with right now, and there's a > workaround. Maybe It's curious that the entire Stacks pane is disabled when either mobile platform is selected. That seems intentional, but I can't imagine why each one of those features is irrelevant when building for mobile. At a minimum, it would be nice to be able to set the password. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
It's not actually a regression, it's always been that way. But it's too piddly to bother the team with right now, and there's a workaround. Maybe I'll ask why it works that way when I see them at the conference. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On April 18, 2019 6:20:24 PM Richard Gaskin via use-livecode wrote: J. Landman Gay wrote: > ...encrypted scripts don't matter in the app stores. So I'm still > wondering what the reason is for disabling it in the SB. The key question is whether the disabling was intentional. If it's a regression while making other changes it all makes sense. Without a bug report we can only hope they take a break from their work to discover this thread -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
J. Landman Gay wrote: > ...encrypted scripts don't matter in the app stores. So I'm still > wondering what the reason is for disabling it in the SB. The key question is whether the disabling was intentional. If it's a regression while making other changes it all makes sense. Without a bug report we can only hope they take a break from their work to discover this thread -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
Apparently my theory of why we can't do it in the standalone builder was wrong, and encrypted scripts don't matter in the app stores. So I'm still wondering what the reason is for disabling it in the SB. I knew how to set a password on a stack, but if you do that then you have to enter the password every time you open the stack during development. The nice thing about using the SB to set a password is that it only applies to the built app and you don't need to mess with it during development. I can just set a password before I build I guess. A savingMobileStandalone handler would work for that, followed by a mobileStandaloneSaved to remove the password. On 4/18/19 11:30 AM, JJS via use-livecode wrote: If you use this sentence in the message box (which i got from another fine member here) the stack is encrypted, and when turned into an APK is well accepted by Google Play Store: *set*thepasswordofstack"beststackever"to"mostdifficultpasswordofalltimes" Op 18-4-2019 om 02:33 schreef Richard Gaskin via use-livecode: J. Landman Gay wrote: > Finally got to this. The password is saved in the standalone custom > property set, but when testing on a trial standalone it isn't actually > being used. So the answer is "no, you can't set a password on a mobile > app via the standalone builder." > > After thinking about this, I realized that since none of the three > major app stores will accept an encrypted app, that's why it's > disabled. That seems a strangely LiveCode-specific policy. It would be cool if Apple, Google, and Amazon were so impressed with LC that they felt the need to write policies just for it, but I suspect I merely don't understand. If the policy prohibits encrypting compiled machine code, I can understand it. All three use automated processes to review code for inappropriate symbols, and encryption would thwart those good efforts. But LC standalones don't encrypt the engine, only the scripts. The compiled machine code remains available for automated review, while the it's just scripts that operate within the constraints imposed on that engine sandbox that are protected. In that sense they're not much different from tokenized bytecode used in many game engines. Unless this policy is oddly LiveCode-specific, I suspect you've discovered a regression, one worth reporting. ___ 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: Encrypted standalones
I'm sure you meant the source code is encrypted. The stack itself is never encrypted. Bob S > On Apr 18, 2019, at 09:30 , JJS via use-livecode > wrote: > > If you use this sentence in the message box (which i got from another fine > member here) the stack is encrypted, and when turned into an APK is well > accepted by Google Play Store: > > *set*thepasswordofstack"beststackever"to"mostdifficultpasswordofalltimes" ___ 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: Encrypted standalones
If you use this sentence in the message box (which i got from another fine member here) the stack is encrypted, and when turned into an APK is well accepted by Google Play Store: *set*thepasswordofstack"beststackever"to"mostdifficultpasswordofalltimes" Op 18-4-2019 om 02:33 schreef Richard Gaskin via use-livecode: J. Landman Gay wrote: > Finally got to this. The password is saved in the standalone custom > property set, but when testing on a trial standalone it isn't actually > being used. So the answer is "no, you can't set a password on a mobile > app via the standalone builder." > > After thinking about this, I realized that since none of the three > major app stores will accept an encrypted app, that's why it's > disabled. That seems a strangely LiveCode-specific policy. It would be cool if Apple, Google, and Amazon were so impressed with LC that they felt the need to write policies just for it, but I suspect I merely don't understand. If the policy prohibits encrypting compiled machine code, I can understand it. All three use automated processes to review code for inappropriate symbols, and encryption would thwart those good efforts. But LC standalones don't encrypt the engine, only the scripts. The compiled machine code remains available for automated review, while the it's just scripts that operate within the constraints imposed on that engine sandbox that are protected. In that sense they're not much different from tokenized bytecode used in many game engines. Unless this policy is oddly LiveCode-specific, I suspect you've discovered a regression, one worth reporting. ___ 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: Encrypted standalones
J. Landman Gay wrote: > Finally got to this. The password is saved in the standalone custom > property set, but when testing on a trial standalone it isn't actually > being used. So the answer is "no, you can't set a password on a mobile > app via the standalone builder." > > After thinking about this, I realized that since none of the three > major app stores will accept an encrypted app, that's why it's > disabled. That seems a strangely LiveCode-specific policy. It would be cool if Apple, Google, and Amazon were so impressed with LC that they felt the need to write policies just for it, but I suspect I merely don't understand. If the policy prohibits encrypting compiled machine code, I can understand it. All three use automated processes to review code for inappropriate symbols, and encryption would thwart those good efforts. But LC standalones don't encrypt the engine, only the scripts. The compiled machine code remains available for automated review, while the it's just scripts that operate within the constraints imposed on that engine sandbox that are protected. In that sense they're not much different from tokenized bytecode used in many game engines. Unless this policy is oddly LiveCode-specific, I suspect you've discovered a regression, one worth reporting. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
On 4/15/19 3:17 PM, Richard Gaskin via use-livecode wrote: It may be that the password isn't being set, or it may be a UI bug in which the password is set but just isn't being displayed. You can determine which is the case with a quick test build that does something like: answer line 10 of the script of this stack If the standalone can get the script, it's not encrypted it. If it complains, you're fine and it's just a UI bug. Finally got to this. The password is saved in the standalone custom property set, but when testing on a trial standalone it isn't actually being used. So the answer is "no, you can't set a password on a mobile app via the standalone builder." After thinking about this, I realized that since none of the three major app stores will accept an encrypted app, that's why it's disabled. -- 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: Encrypted standalones
J. Landman Gay wrote: > I take that back. If I turn Android builds back on, close Standalone > Settings, and re-open it, the password is gone. So, we can't protect > Android mainstacks? > > Android apps can be distributed through private web sites, and without > any encryption they would be easier to hack. I understand that I can > set the password manually, but it's much easier not to worry about it > during development and still be assurred it will be set on a build. > > If there's a reason we can't do that, okay. If there isn't a reason, > I'll put in a request for it. It may be that the password isn't being set, or it may be a UI bug in which the password is set but just isn't being displayed. You can determine which is the case with a quick test build that does something like: answer line 10 of the script of this stack If the standalone can get the script, it's not encrypted it. If it complains, you're fine and it's just a UI bug. Either way, once the nature of the problem is determined a bug report would be helpful. It may be that some of the recent work on the Standalone Builder caused this regression, and reporting it while it's fresh in the team member's head will likely yield a quick fix. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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: Encrypted standalones
I take that back. If I turn Android builds back on, close Standalone Settings, and re-open it, the password is gone. So, we can't protect Android mainstacks? Android apps can be distributed through private web sites, and without any encryption they would be easier to hack. I understand that I can set the password manually, but it's much easier not to worry about it during development and still be assurred it will be set on a build. If there's a reason we can't do that, okay. If there isn't a reason, I'll put in a request for it. On 4/15/19 1:10 PM, J. Landman Gay via use-livecode wrote: Is there a reason we can't encrypt the main stack in standalone settings when building for mobile? I can set set a password if I uncheck the mobile app options, set the password, then re-enable mobile builds, and the password remains. I'm not sure if it is actually used though when building for mobile. Anyone know? -- 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
Encrypted standalones
Is there a reason we can't encrypt the main stack in standalone settings when building for mobile? I can set set a password if I uncheck the mobile app options, set the password, then re-enable mobile builds, and the password remains. I'm not sure if it is actually used though when building for mobile. Anyone know? -- 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
