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