Differences between Commercial and Community versions of LiveCode

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
On LiveCode's webpage there is a chart of differences between the
Commercial veriosn
and the Community version.

I was given to understand one of the most important differences was
that, in the Commercial versions,
code in standalones was "obfuscated" in such a way that an end-user
could not "peek round the back"
and access that code.

Recently I ran off a very simple standalone with the Indy and the
Community version of LC 8.1.9
and cracked both of them open with a text editor.

In neither of the standalones could I access the code.

Presumably this means that a standalone generated with the Community
version cannot be
reverse-engineered in such a way that its original code can be read?

Richmond.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
if u open up a lc standalone exe in a hex editor or even notepad++ you can
totally read the code contained.  at least it used to be the case before v9
(haven't looked)

maybe your text editor wasn't able to display the code in some way.... but
I assure you its there.

Not so the case for non community stacks.  those are encrypted.

On Tue, Jun 5, 2018 at 3:05 PM, Richmond Mathewson via use-livecode <
[hidden email]> wrote:

> On LiveCode's webpage there is a chart of differences between the
> Commercial veriosn
> and the Community version.
>
> I was given to understand one of the most important differences was that,
> in the Commercial versions,
> code in standalones was "obfuscated" in such a way that an end-user could
> not "peek round the back"
> and access that code.
>
> Recently I ran off a very simple standalone with the Indy and the
> Community version of LC 8.1.9
> and cracked both of them open with a text editor.
>
> In neither of the standalones could I access the code.
>
> Presumably this means that a standalone generated with the Community
> version cannot be
> reverse-engineered in such a way that its original code can be read?
>
> Richmond.
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
Thanks: very useful information.

Richmond.

On 5/6/2018 10:08 pm, Tom Glod via use-livecode wrote:

> if u open up a lc standalone exe in a hex editor or even notepad++ you can
> totally read the code contained.  at least it used to be the case before v9
> (haven't looked)
>
> maybe your text editor wasn't able to display the code in some way.... but
> I assure you its there.
>
> Not so the case for non community stacks.  those are encrypted.
>
> On Tue, Jun 5, 2018 at 3:05 PM, Richmond Mathewson via use-livecode <
> [hidden email]> wrote:
>
>> On LiveCode's webpage there is a chart of differences between the
>> Commercial veriosn
>> and the Community version.
>>
>> I was given to understand one of the most important differences was that,
>> in the Commercial versions,
>> code in standalones was "obfuscated" in such a way that an end-user could
>> not "peek round the back"
>> and access that code.
>>
>> Recently I ran off a very simple standalone with the Indy and the
>> Community version of LC 8.1.9
>> and cracked both of them open with a text editor.
>>
>> In neither of the standalones could I access the code.
>>
>> Presumably this means that a standalone generated with the Community
>> version cannot be
>> reverse-engineered in such a way that its original code can be read?
>>
>> Richmond.
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
Richmond Mathewson wrote:

 > Recently I ran off a very simple standalone with the Indy and the
 > Community version of LC 8.1.9
 > and cracked both of them open with a text editor.
 >
 > In neither of the standalones could I access the code.
 >
 > Presumably this means that a standalone generated with the Community
 > version cannot be
 > reverse-engineered in such a way that its original code can be read?

Binding the stack to the runtime engine makes the source difficult to
access, and the objects impossible to modify.

The requirement of GPL-governed works is that source code is available
in a form that allows modification.

I would not imagine requiring end-users to sift through bits of a binary
executable would satisfy any definition of GPL compliance.

Either the source stack files are made available to any user of the
executable who wants them, or the entity distributing the executable is
in violation of LiveCode Ltd's copyright.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
I believe this thread started as a result is someone asking if there was a way to recover their work if all they could salvage was a built binary (from community edition). It sounds like there should be a way based on another response in the thread.

Thanks,
Brian
On Jun 5, 2018, 2:16 PM -0500, Richard Gaskin via use-livecode <[hidden email]>, wrote:

> Richmond Mathewson wrote:
>
> > Recently I ran off a very simple standalone with the Indy and the
> > Community version of LC 8.1.9
> > and cracked both of them open with a text editor.
> >
> > In neither of the standalones could I access the code.
> >
> > Presumably this means that a standalone generated with the Community
> > version cannot be
> > reverse-engineered in such a way that its original code can be read?
>
> Binding the stack to the runtime engine makes the source difficult to
> access, and the objects impossible to modify.
>
> The requirement of GPL-governed works is that source code is available
> in a form that allows modification.
>
> I would not imagine requiring end-users to sift through bits of a binary
> executable would satisfy any definition of GPL compliance.
>
> Either the source stack files are made available to any user of the
> executable who wants them, or the entity distributing the executable is
> in violation of LiveCode Ltd's copyright.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email] http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
so i went to check the standalone file from v9 ...and indeed the code
cannot be seen.  in previous versions, I could clearly see the script text
of a stack by opening it up in notepad++.....

maybe i was hallucinating...... but i'm pretty sure i checked this before
because of my own curiosities about this subject. can anyone confirm this
change?


On Tue, Jun 5, 2018 at 3:49 PM, Brian Milby via use-livecode <
[hidden email]> wrote:

> I believe this thread started as a result is someone asking if there was a
> way to recover their work if all they could salvage was a built binary
> (from community edition). It sounds like there should be a way based on
> another response in the thread.
>
> Thanks,
> Brian
> On Jun 5, 2018, 2:16 PM -0500, Richard Gaskin via use-livecode <
> [hidden email]>, wrote:
> > Richmond Mathewson wrote:
> >
> > > Recently I ran off a very simple standalone with the Indy and the
> > > Community version of LC 8.1.9
> > > and cracked both of them open with a text editor.
> > >
> > > In neither of the standalones could I access the code.
> > >
> > > Presumably this means that a standalone generated with the Community
> > > version cannot be
> > > reverse-engineered in such a way that its original code can be read?
> >
> > Binding the stack to the runtime engine makes the source difficult to
> > access, and the objects impossible to modify.
> >
> > The requirement of GPL-governed works is that source code is available
> > in a form that allows modification.
> >
> > I would not imagine requiring end-users to sift through bits of a binary
> > executable would satisfy any definition of GPL compliance.
> >
> > Either the source stack files are made available to any user of the
> > executable who wants them, or the entity distributing the executable is
> > in violation of LiveCode Ltd's copyright.
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > ____________________________________________________________________
> > [hidden email] http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
hmmmm..... maybe i'm thinking all the way back to v6 or v7 standalones. cuz
v8 is also not visible.

On Tue, Jun 5, 2018 at 5:20 PM, Tom Glod <[hidden email]> wrote:

> so i went to check the standalone file from v9 ...and indeed the code
> cannot be seen.  in previous versions, I could clearly see the script text
> of a stack by opening it up in notepad++.....
>
> maybe i was hallucinating...... but i'm pretty sure i checked this before
> because of my own curiosities about this subject. can anyone confirm this
> change?
>
>
> On Tue, Jun 5, 2018 at 3:49 PM, Brian Milby via use-livecode <
> [hidden email]> wrote:
>
>> I believe this thread started as a result is someone asking if there was
>> a way to recover their work if all they could salvage was a built binary
>> (from community edition). It sounds like there should be a way based on
>> another response in the thread.
>>
>> Thanks,
>> Brian
>> On Jun 5, 2018, 2:16 PM -0500, Richard Gaskin via use-livecode <
>> [hidden email]>, wrote:
>> > Richmond Mathewson wrote:
>> >
>> > > Recently I ran off a very simple standalone with the Indy and the
>> > > Community version of LC 8.1.9
>> > > and cracked both of them open with a text editor.
>> > >
>> > > In neither of the standalones could I access the code.
>> > >
>> > > Presumably this means that a standalone generated with the Community
>> > > version cannot be
>> > > reverse-engineered in such a way that its original code can be read?
>> >
>> > Binding the stack to the runtime engine makes the source difficult to
>> > access, and the objects impossible to modify.
>> >
>> > The requirement of GPL-governed works is that source code is available
>> > in a form that allows modification.
>> >
>> > I would not imagine requiring end-users to sift through bits of a binary
>> > executable would satisfy any definition of GPL compliance.
>> >
>> > Either the source stack files are made available to any user of the
>> > executable who wants them, or the entity distributing the executable is
>> > in violation of LiveCode Ltd's copyright.
>> >
>> > --
>> > Richard Gaskin
>> > Fourth World Systems
>> > Software Design and Development for the Desktop, Mobile, and the Web
>> > ____________________________________________________________________
>> > [hidden email] http://www.FourthWorld.com
>> >
>> > _______________________________________________
>> > use-livecode mailing list
>> > [hidden email]
>> > Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
Looking at the code, “deflate” is called on the stack as it is being written out (zlib). So while not easy, it should be possible to separate a stack file from the binary if deployed from the community edition. It would take a bit of work to figure out where the file started and ended. Well over what I would be willing to tackle at the moment. For anyone so motivated, the relevant source code is in deploy*.cpp (along with the header files).
On Jun 5, 2018, 4:25 PM -0500, Tom Glod via use-livecode <[hidden email]>, wrote:

> hmmmm..... maybe i'm thinking all the way back to v6 or v7 standalones. cuz
> v8 is also not visible.
>
> On Tue, Jun 5, 2018 at 5:20 PM, Tom Glod <[hidden email]> wrote:
>
> > so i went to check the standalone file from v9 ...and indeed the code
> > cannot be seen. in previous versions, I could clearly see the script text
> > of a stack by opening it up in notepad++.....
> >
> > maybe i was hallucinating...... but i'm pretty sure i checked this before
> > because of my own curiosities about this subject. can anyone confirm this
> > change?
> >
> >
> > On Tue, Jun 5, 2018 at 3:49 PM, Brian Milby via use-livecode <
> > [hidden email]> wrote:
> >
> > > I believe this thread started as a result is someone asking if there was
> > > a way to recover their work if all they could salvage was a built binary
> > > (from community edition). It sounds like there should be a way based on
> > > another response in the thread.
> > >
> > > Thanks,
> > > Brian
> > > On Jun 5, 2018, 2:16 PM -0500, Richard Gaskin via use-livecode <
> > > [hidden email]>, wrote:
> > > > Richmond Mathewson wrote:
> > > >
> > > > > Recently I ran off a very simple standalone with the Indy and the
> > > > > Community version of LC 8.1.9
> > > > > and cracked both of them open with a text editor.
> > > > >
> > > > > In neither of the standalones could I access the code.
> > > > >
> > > > > Presumably this means that a standalone generated with the Community
> > > > > version cannot be
> > > > > reverse-engineered in such a way that its original code can be read?
> > > >
> > > > Binding the stack to the runtime engine makes the source difficult to
> > > > access, and the objects impossible to modify.
> > > >
> > > > The requirement of GPL-governed works is that source code is available
> > > > in a form that allows modification.
> > > >
> > > > I would not imagine requiring end-users to sift through bits of a binary
> > > > executable would satisfy any definition of GPL compliance.
> > > >
> > > > Either the source stack files are made available to any user of the
> > > > executable who wants them, or the entity distributing the executable is
> > > > in violation of LiveCode Ltd's copyright.
> > > >
> > > > --
> > > > Richard Gaskin
> > > > Fourth World Systems
> > > > Software Design and Development for the Desktop, Mobile, and the Web
> > > > ____________________________________________________________________
> > > > [hidden email] http://www.FourthWorld.com
> > > >
> > > > _______________________________________________
> > > > use-livecode mailing list
> > > > [hidden email]
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> >
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
On 6/5/18 4:20 PM, Tom Glod via use-livecode wrote:
> so i went to check the standalone file from v9 ...and indeed the code
> cannot be seen.  in previous versions, I could clearly see the script text
> of a stack by opening it up in notepad++.....
>
> maybe i was hallucinating...... but i'm pretty sure i checked this before
> because of my own curiosities about this subject. can anyone confirm this
> change?

Yes, scripts in standalones used to be plain-text but that was a long
time ago. It may have been LC 7 where it changed but I think it was even
before that.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
Don't we want that NOT to be possible?? Otherwise bring back the runtime engine and run the app as a stack file of the runtime.

Bob S


> On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <[hidden email]> wrote:
>
> Looking at the code, “deflate” is called on the stack as it is being written out (zlib). So while not easy, it should be possible to separate a stack file from the binary if deployed from the community edition. It would take a bit of work to figure out where the file started and ended. Well over what I would be willing to tackle at the moment. For anyone so motivated, the relevant source code is in deploy*.cpp (along with the header files).

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
For commercial I would think so, but don’t see any issue on the community side.
On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> Don't we want that NOT to be possible?? Otherwise bring back the runtime engine and run the app as a stack file of the runtime.
>
> Bob S
>
>
> > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <[hidden email]> wrote:
> >
> > Looking at the code, “deflate” is called on the stack as it is being written out (zlib). So while not easy, it should be possible to separate a stack file from the binary if deployed from the community edition. It would take a bit of work to figure out where the file started and ended. Well over what I would be willing to tackle at the moment. For anyone so motivated, the relevant source code is in deploy*.cpp (along with the header files).
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
what if for example you want to hard code a hash salt into your code?.....
if the code is readable, then so is the salt.  I would vote for unreadable
code 100% of the time.

On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
[hidden email]> wrote:

> For commercial I would think so, but don’t see any issue on the community
> side.
> On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> [hidden email]>, wrote:
> > Don't we want that NOT to be possible?? Otherwise bring back the runtime
> engine and run the app as a stack file of the runtime.
> >
> > Bob S
> >
> >
> > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> [hidden email]> wrote:
> > >
> > > Looking at the code, “deflate” is called on the stack as it is being
> written out (zlib). So while not easy, it should be possible to separate a
> stack file from the binary if deployed from the community edition. It would
> take a bit of work to figure out where the file started and ended. Well
> over what I would be willing to tackle at the moment. For anyone so
> motivated, the relevant source code is in deploy*.cpp (along with the
> header files).
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
Can’t do that with community... code must be available.
On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <[hidden email]>, wrote:

> what if for example you want to hard code a hash salt into your code?.....
> if the code is readable, then so is the salt. I would vote for unreadable
> code 100% of the time.
>
> On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
> [hidden email]> wrote:
>
> > For commercial I would think so, but don’t see any issue on the community
> > side.
> > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> > [hidden email]>, wrote:
> > > Don't we want that NOT to be possible?? Otherwise bring back the runtime
> > engine and run the app as a stack file of the runtime.
> > >
> > > Bob S
> > >
> > >
> > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> > [hidden email]> wrote:
> > > >
> > > > Looking at the code, “deflate” is called on the stack as it is being
> > written out (zlib). So while not easy, it should be possible to separate a
> > stack file from the binary if deployed from the community edition. It would
> > take a bit of work to figure out where the file started and ended. Well
> > over what I would be willing to tackle at the moment. For anyone so
> > motivated, the relevant source code is in deploy*.cpp (along with the
> > header files).
> > >
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
The code doesn't need to be available "in the clear" either in Community or
Business in the executable.
So there is nothing stopping us using something like

https://www.pelock.com/products/pelock/buy

or a free one here
https://upx.github.io/
http://www.pazera-software.com/products/free-upx/

You must make the source files available though. You cant see the C or C++
source text in programs written in those languages except for say headers
and library calls and there are programs that can go through and obfuscate
those as well.

Lagi




On 6 June 2018 at 17:12, Brian Milby via use-livecode <
[hidden email]> wrote:

> Can’t do that with community... code must be available.
> On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <
> [hidden email]>, wrote:
> > what if for example you want to hard code a hash salt into your
> code?.....
> > if the code is readable, then so is the salt. I would vote for unreadable
> > code 100% of the time.
> >
> > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
> > [hidden email]> wrote:
> >
> > > For commercial I would think so, but don’t see any issue on the
> community
> > > side.
> > > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> > > [hidden email]>, wrote:
> > > > Don't we want that NOT to be possible?? Otherwise bring back the
> runtime
> > > engine and run the app as a stack file of the runtime.
> > > >
> > > > Bob S
> > > >
> > > >
> > > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> > > [hidden email]> wrote:
> > > > >
> > > > > Looking at the code, “deflate” is called on the stack as it is
> being
> > > written out (zlib). So while not easy, it should be possible to
> separate a
> > > stack file from the binary if deployed from the community edition. It
> would
> > > take a bit of work to figure out where the file started and ended. Well
> > > over what I would be willing to tackle at the moment. For anyone so
> > > motivated, the relevant source code is in deploy*.cpp (along with the
> > > header files).
> > > >
> > > > _______________________________________________
> > > > use-livecode mailing list
> > > > [hidden email]
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
great suggestion Lagi... thats a great solution for anyone who needs an
extra layer of obfuscation on the binaries.

Yes indeed...the .livecode files must be made available.

On Wed, Jun 6, 2018 at 12:51 PM, Lagi Pittas via use-livecode <
[hidden email]> wrote:

> The code doesn't need to be available "in the clear" either in Community or
> Business in the executable.
> So there is nothing stopping us using something like
>
> https://www.pelock.com/products/pelock/buy
>
> or a free one here
> https://upx.github.io/
> http://www.pazera-software.com/products/free-upx/
>
> You must make the source files available though. You cant see the C or C++
> source text in programs written in those languages except for say headers
> and library calls and there are programs that can go through and obfuscate
> those as well.
>
> Lagi
>
>
>
>
> On 6 June 2018 at 17:12, Brian Milby via use-livecode <
> [hidden email]> wrote:
>
> > Can’t do that with community... code must be available.
> > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <
> > [hidden email]>, wrote:
> > > what if for example you want to hard code a hash salt into your
> > code?.....
> > > if the code is readable, then so is the salt. I would vote for
> unreadable
> > > code 100% of the time.
> > >
> > > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
> > > [hidden email]> wrote:
> > >
> > > > For commercial I would think so, but don’t see any issue on the
> > community
> > > > side.
> > > > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> > > > [hidden email]>, wrote:
> > > > > Don't we want that NOT to be possible?? Otherwise bring back the
> > runtime
> > > > engine and run the app as a stack file of the runtime.
> > > > >
> > > > > Bob S
> > > > >
> > > > >
> > > > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> > > > [hidden email]> wrote:
> > > > > >
> > > > > > Looking at the code, “deflate” is called on the stack as it is
> > being
> > > > written out (zlib). So while not easy, it should be possible to
> > separate a
> > > > stack file from the binary if deployed from the community edition. It
> > would
> > > > take a bit of work to figure out where the file started and ended.
> Well
> > > > over what I would be willing to tackle at the moment. For anyone so
> > > > motivated, the relevant source code is in deploy*.cpp (along with the
> > > > header files).
> > > > >
> > > > > _______________________________________________
> > > > > use-livecode mailing list
> > > > > [hidden email]
> > > > > Please visit this url to subscribe, unsubscribe and manage your
> > > > subscription preferences:
> > > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > > _______________________________________________
> > > > use-livecode mailing list
> > > > [hidden email]
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > >
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
after trying UPX on my win32 standalone executable i got a upx: UMP.exe:
NotCompressibleException :)

On Wed, Jun 6, 2018 at 1:00 PM, Tom Glod <[hidden email]> wrote:

> great suggestion Lagi... thats a great solution for anyone who needs an
> extra layer of obfuscation on the binaries.
>
> Yes indeed...the .livecode files must be made available.
>
> On Wed, Jun 6, 2018 at 12:51 PM, Lagi Pittas via use-livecode <
> [hidden email]> wrote:
>
>> The code doesn't need to be available "in the clear" either in Community
>> or
>> Business in the executable.
>> So there is nothing stopping us using something like
>>
>> https://www.pelock.com/products/pelock/buy
>>
>> or a free one here
>> https://upx.github.io/
>> http://www.pazera-software.com/products/free-upx/
>>
>> You must make the source files available though. You cant see the C or C++
>> source text in programs written in those languages except for say headers
>> and library calls and there are programs that can go through and obfuscate
>> those as well.
>>
>> Lagi
>>
>>
>>
>>
>> On 6 June 2018 at 17:12, Brian Milby via use-livecode <
>> [hidden email]> wrote:
>>
>> > Can’t do that with community... code must be available.
>> > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <
>> > [hidden email]>, wrote:
>> > > what if for example you want to hard code a hash salt into your
>> > code?.....
>> > > if the code is readable, then so is the salt. I would vote for
>> unreadable
>> > > code 100% of the time.
>> > >
>> > > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
>> > > [hidden email]> wrote:
>> > >
>> > > > For commercial I would think so, but don’t see any issue on the
>> > community
>> > > > side.
>> > > > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
>> > > > [hidden email]>, wrote:
>> > > > > Don't we want that NOT to be possible?? Otherwise bring back the
>> > runtime
>> > > > engine and run the app as a stack file of the runtime.
>> > > > >
>> > > > > Bob S
>> > > > >
>> > > > >
>> > > > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
>> > > > [hidden email]> wrote:
>> > > > > >
>> > > > > > Looking at the code, “deflate” is called on the stack as it is
>> > being
>> > > > written out (zlib). So while not easy, it should be possible to
>> > separate a
>> > > > stack file from the binary if deployed from the community edition.
>> It
>> > would
>> > > > take a bit of work to figure out where the file started and ended.
>> Well
>> > > > over what I would be willing to tackle at the moment. For anyone so
>> > > > motivated, the relevant source code is in deploy*.cpp (along with
>> the
>> > > > header files).
>> > > > >
>> > > > > _______________________________________________
>> > > > > use-livecode mailing list
>> > > > > [hidden email]
>> > > > > Please visit this url to subscribe, unsubscribe and manage your
>> > > > subscription preferences:
>> > > > > http://lists.runrev.com/mailman/listinfo/use-livecode
>> > > > _______________________________________________
>> > > > use-livecode mailing list
>> > > > [hidden email]
>> > > > Please visit this url to subscribe, unsubscribe and manage your
>> > > > subscription preferences:
>> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
>> > > >
>> > > _______________________________________________
>> > > use-livecode mailing list
>> > > [hidden email]
>> > > Please visit this url to subscribe, unsubscribe and manage your
>> > subscription preferences:
>> > > http://lists.runrev.com/mailman/listinfo/use-livecode
>> > _______________________________________________
>> > use-livecode mailing list
>> > [hidden email]
>> > Please visit this url to subscribe, unsubscribe and manage your
>> > subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
Oh

and for those who do want to make totally sure ..

https://www.cybrary.it/0p3n/advanced-exe-multi-protection-reverse-engineering-free-tools/

shows you how to modify the UPX compressor so that someone with the source
code (it's open source) will have difficulty.

I don't use it - my copy protection is my support and a base64encode name
of company string - it is breakable but I don't care
when something goes wrong - and it will especially if windows is involved -
they will have to come to me  or start again.

If somebody "cracks" it and it gets spread so what I wouldn't have had them
as clients in the first place.
In the old apple 2 days I bought an assembler called Lisa ($139.95) on a
copy protected disk.
I had a disk copier that could copy the disk but the new disk would still
be copy protected so I was up
till 4 in the morning with my copy of "Beneath Apple Dos" going through 3
levels of protection from the unprotected Boot Loader
to other bits of code that was Xored before executing and then I got to a
bit of text ... For $139.95 you can go to sleep tonight.
I Laughed and went to bed.

Most crackers do it for pedagogical reason and our systems aren't on their
Radar so why put hoops in the way of the honest people.

btw for anyone who remembers those Halcyon days I also bought (not copied)
Randall Hydes Anix system (love the name) which was a "Unix Like" OS for
the Apple 2
which had 48K Ram and 143K on a floppy disk WT?~#@!

http://www.appleoldies.ca/anix/index.htm

On 6 June 2018 at 17:12, Brian Milby via use-livecode <
[hidden email]> wrote:

> Can’t do that with community... code must be available.
> On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <
> [hidden email]>, wrote:
> > what if for example you want to hard code a hash salt into your
> code?.....
> > if the code is readable, then so is the salt. I would vote for unreadable
> > code 100% of the time.
> >
> > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
> > [hidden email]> wrote:
> >
> > > For commercial I would think so, but don’t see any issue on the
> community
> > > side.
> > > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> > > [hidden email]>, wrote:
> > > > Don't we want that NOT to be possible?? Otherwise bring back the
> runtime
> > > engine and run the app as a stack file of the runtime.
> > > >
> > > > Bob S
> > > >
> > > >
> > > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> > > [hidden email]> wrote:
> > > > >
> > > > > Looking at the code, “deflate” is called on the stack as it is
> being
> > > written out (zlib). So while not easy, it should be possible to
> separate a
> > > stack file from the binary if deployed from the community edition. It
> would
> > > take a bit of work to figure out where the file started and ended. Well
> > > over what I would be willing to tackle at the moment. For anyone so
> > > motivated, the relevant source code is in deploy*.cpp (along with the
> > > header files).
> > > >
> > > > _______________________________________________
> > > > use-livecode mailing list
> > > > [hidden email]
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
Never tried it for Livecode because as in my previous message - Just encode
their name - you dont even have to tell them its encoded
but check on boot up - which I do and wait 6 Months and then tell them -
that will F**Ck them up when they thought they got away with it.

Revenge is a dish best served cold ;-)

I know it worked with a VB program years ago and the DLL's - but that was
to make the executables smaller

Since its open source and actively updated why don't you tell them - In
fact I might  probably use it on my LC9 executables even though I have
indy/business because they are 3 times larger than my LC6 executables.

Lagi



On 6 June 2018 at 18:05, Tom Glod via use-livecode <
[hidden email]> wrote:

> after trying UPX on my win32 standalone executable i got a upx: UMP.exe:
> NotCompressibleException :)
>
> On Wed, Jun 6, 2018 at 1:00 PM, Tom Glod <[hidden email]> wrote:
>
> > great suggestion Lagi... thats a great solution for anyone who needs an
> > extra layer of obfuscation on the binaries.
> >
> > Yes indeed...the .livecode files must be made available.
> >
> > On Wed, Jun 6, 2018 at 12:51 PM, Lagi Pittas via use-livecode <
> > [hidden email]> wrote:
> >
> >> The code doesn't need to be available "in the clear" either in Community
> >> or
> >> Business in the executable.
> >> So there is nothing stopping us using something like
> >>
> >> https://www.pelock.com/products/pelock/buy
> >>
> >> or a free one here
> >> https://upx.github.io/
> >> http://www.pazera-software.com/products/free-upx/
> >>
> >> You must make the source files available though. You cant see the C or
> C++
> >> source text in programs written in those languages except for say
> headers
> >> and library calls and there are programs that can go through and
> obfuscate
> >> those as well.
> >>
> >> Lagi
> >>
> >>
> >>
> >>
> >> On 6 June 2018 at 17:12, Brian Milby via use-livecode <
> >> [hidden email]> wrote:
> >>
> >> > Can’t do that with community... code must be available.
> >> > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode <
> >> > [hidden email]>, wrote:
> >> > > what if for example you want to hard code a hash salt into your
> >> > code?.....
> >> > > if the code is readable, then so is the salt. I would vote for
> >> unreadable
> >> > > code 100% of the time.
> >> > >
> >> > > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
> >> > > [hidden email]> wrote:
> >> > >
> >> > > > For commercial I would think so, but don’t see any issue on the
> >> > community
> >> > > > side.
> >> > > > On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode <
> >> > > > [hidden email]>, wrote:
> >> > > > > Don't we want that NOT to be possible?? Otherwise bring back the
> >> > runtime
> >> > > > engine and run the app as a stack file of the runtime.
> >> > > > >
> >> > > > > Bob S
> >> > > > >
> >> > > > >
> >> > > > > > On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode <
> >> > > > [hidden email]> wrote:
> >> > > > > >
> >> > > > > > Looking at the code, “deflate” is called on the stack as it is
> >> > being
> >> > > > written out (zlib). So while not easy, it should be possible to
> >> > separate a
> >> > > > stack file from the binary if deployed from the community edition.
> >> It
> >> > would
> >> > > > take a bit of work to figure out where the file started and ended.
> >> Well
> >> > > > over what I would be willing to tackle at the moment. For anyone
> so
> >> > > > motivated, the relevant source code is in deploy*.cpp (along with
> >> the
> >> > > > header files).
> >> > > > >
> >> > > > > _______________________________________________
> >> > > > > use-livecode mailing list
> >> > > > > [hidden email]
> >> > > > > Please visit this url to subscribe, unsubscribe and manage your
> >> > > > subscription preferences:
> >> > > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> > > > _______________________________________________
> >> > > > use-livecode mailing list
> >> > > > [hidden email]
> >> > > > Please visit this url to subscribe, unsubscribe and manage your
> >> > > > subscription preferences:
> >> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> > > >
> >> > > _______________________________________________
> >> > > use-livecode mailing list
> >> > > [hidden email]
> >> > > Please visit this url to subscribe, unsubscribe and manage your
> >> > subscription preferences:
> >> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> > _______________________________________________
> >> > use-livecode mailing list
> >> > [hidden email]
> >> > Please visit this url to subscribe, unsubscribe and manage your
> >> > subscription preferences:
> >> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
In reply to this post by dunbarxx via use-livecode
On 2018-06-06 18:09, Tom Glod via use-livecode wrote:
> what if for example you want to hard code a hash salt into your
> code?.....
> if the code is readable, then so is the salt.  I would vote for
> unreadable
> code 100% of the time.

Technically even if the code isn't readable, then the salt will still be
there - all you are doing is making it more difficult for relatively
unmotivated individuals to get at it. Which perhaps doesn't help much,
as the unmotivated are probably not the ones who are going to cause any
problems.

The only way to truly protect secrets is for no-one to see them and to
only transmit and store them in an encrypted way, where unlocking them
is tied to a secret the end-user has - e.g. user account / password
login.

Certainly if there is a server involved in your app somehow, and if you
control that server then you are far better off making the server the
'keeper of the secrets' because then *you* have control - its much
easier to delete a record from a server then it is to force all your
users to reinstall a new version of your app because a secret contained
within it has been compromised.

Warmest Regards,

Mark.

P.S. I realize that sometimes storing secrets in distributed apps is the
'only' way - but always think to see if there is a way to avoid it if
you can.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Differences between Commercial and Community versions of LiveCode

dunbarxx via use-livecode
thanks for that reply mark........totally hear you on that........ my
application works fully on 1 local machine......I will have a central
registration server, but it will be optional.  So everything is on a local
drive or on a server on a lan.   my task is to follow standards  and add to
the pain in the ass level for anyone who wants to play hacker.

on top of using aes 256 encryption and making the user type in a password
to unlock the data.  salts are useful in that .... on a single machine.
but they become problematic with software upgrades or fixes like you said.
i don't currently use a hardcoded salt..... but i generate a salt from
unique data that binds to the password and the user.


your participation in these topics is much appreciated. cheers

On Wed, Jun 6, 2018 at 1:40 PM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2018-06-06 18:09, Tom Glod via use-livecode wrote:
>
>> what if for example you want to hard code a hash salt into your code?.....
>> if the code is readable, then so is the salt.  I would vote for unreadable
>> code 100% of the time.
>>
>
> Technically even if the code isn't readable, then the salt will still be
> there - all you are doing is making it more difficult for relatively
> unmotivated individuals to get at it. Which perhaps doesn't help much, as
> the unmotivated are probably not the ones who are going to cause any
> problems.
>
> The only way to truly protect secrets is for no-one to see them and to
> only transmit and store them in an encrypted way, where unlocking them is
> tied to a secret the end-user has - e.g. user account / password login.
>
> Certainly if there is a server involved in your app somehow, and if you
> control that server then you are far better off making the server the
> 'keeper of the secrets' because then *you* have control - its much easier
> to delete a record from a server then it is to force all your users to
> reinstall a new version of your app because a secret contained within it
> has been compromised.
>
> Warmest Regards,
>
> Mark.
>
> P.S. I realize that sometimes storing secrets in distributed apps is the
> 'only' way - but always think to see if there is a way to avoid it if you
> can.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123