Obtaining URL to latest Stable LC Server

Richard Gaskin ambassador at fourthworld.com
Thu May 21 13:01:59 EDT 2020

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.

  Richard Gaskin
  Fourth World Systems

JeeJeeStudio wrote:
> Yes, true.
> Does the commercial version not contain options comparable like LC Indy 
> e.g. Encrypting or otherwise?
> Thanks for your answer.
> Op 21-5-2020 om 18:21 schreef Richard Gaskin via use-livecode:
>> JeeJeeStudio wrote:
>> > Op 20-5-2020 om 21:18 schreef Richard Gaskin via use-livecode:
>> >> It would be helpful to have a convenient way to obtain the URL to the
>> >> latest stable version of LC Server, to automate deployments.
>> >>
>> >> I don't believe the company provides that, do they?
>> >>
>> >> Without a company-maintained URL, I suppose one could write a
>> >> function that relies on a scraper for the downloads.liveocde.com
>> >> page.  Has anyone here done that?
>> >
>> >
>> > that's not the same version as the one you can download from
>> > livecode.com when you log-in. Community vs commercial
>> True, but my focus on the Community Edition is based on two 
>> considerations:
>> 1. The proprietary edition requires an account-specific licensing key
>>    which AFAIK precludes external automation.
>> 2. The proprietary edition is very rarely needed.
>> Most modern server solutions are open source, and many use GPL 
>> specifically, including not only LiveCode but also MySQL, MariaDB, 
>> Neo4j, MediaWiki, NextCloud, Wordpress, Drupal, Joomla, Git, Ansible, 
>> and a good many more.
>> The GPL being a distribution license, proprietary edition of LiveCode 
>> Server would be needed only in those cases where the developer is 
>> distributing a server solution for other devs making server solutions, 
>> and where they want their own code to be under proprietary license. I 
>> can imagine such a specific use may case exist in our community, but I 
>> haven't yet come across it.
>> For services accessed over a network, the code remains on the server 
>> and is not distributed to the user. So open source, even GPL, is a 
>> very good fit for web sites, apps, and other network-delivered services.

More information about the use-livecode mailing list