Obtaining URL to latest Stable LC Server

JeeJeeStudio jeejeestudio at gmail.com
Thu May 21 13:16:41 EDT 2020


Thanks for your extensive explanation Richard.


Op 21-5-2020 om 19:01 schreef Richard Gaskin via use-livecode:
> The encrypt and decrypt commands are part of the core language common 
> to all editions, along with hashing with messageDigest and the older 
> md5Digest and sha1Digest functions.
>
> The one form of encryption proprietary editions enjoy is with stacks, 
> to protect scripts. For the most part this is irrelevant to any open 
> source use since of course the whole point is sharing code.
>
> But there are at least two use cases where stack encryption might be 
> useful with open source projects:
>
> - Preventing code modification: If you had a system that uses unlocked 
> stacks downloaded from multiple sources, it's possible that one script 
> downloaded from  nefarious source could modify another.
>
> - Protecting secrets: Other scripting languages (PHP, Python, Ruby, 
> etc.) are plain text files, so secrets like DB passwords need to be 
> handled with care.  With LC it would be possible to put that info in 
> an encrypted stack for an additional level of protection that would 
> give LC a competitive advantage no plain-text scripting language could 
> match.
>
> That said, both are edge cases and neither prevents us from getting 
> serious work done with what we have today.
>
> In the first case, if one dared to make a system that ran stacks from 
> unknown sources, code modification would be the least concern compared 
> with all the other ways script behavior can be modified at runtime 
> within a single LC instance (frontScripts, backScripts, etc.).  In a 
> server context it's almost completely irrelevant because that's the 
> last place we'd want to put code from unknown sources. :)
>
> And the second case puts even unlocked LC stacks at no disadvantage 
> compared to pretty much any other language everyone else everyone 
> uses. If traditional ways of managing secrets are good enough for 
> healthcare and banking, they're probably good enough for the types of 
> web services the rest of us make.
>




More information about the use-livecode mailing list