Re: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

You are absolutely right Alex. Jacqueline had given me the correct handler
and I made the mistake, and Panos corrected me. I have now corrected it but
still same result. See forum post.

https://forums.livecode.com/viewtopic.php?f=9&t=33678&p=188122#p188122

-- 
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[Alex Tweedly via use-livecode]

H - you're doing that on 'standalonesaved'.

Isn't that too late ?  Shouldn't it be on 'savingstandalone' ?

(I've not made a standalone on years, far less ever used either of those 
handlers, but based on their names, that seems like a possible idea :-)


Alex.

On 17/02/2020 22:57, Kaveh Bazargan via use-livecode wrote:


Hi Jacqueline

I tried but could not make it work. I have posted a minimal stack on the
forum in case you get time to comment.

https://forums.livecode.com/viewtopic.php?f=9&t=33678&p=188122#p188122

Thanks. I have learnt a lot already!

Kaveh





--
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



--
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn






___
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: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

>
>
>>
>>
> Sounds great Jacqueline. I will give it a go. :-)
>

Hi Jacqueline

I tried but could not make it work. I have posted a minimal stack on the
forum in case you get time to comment.

https://forums.livecode.com/viewtopic.php?f=9&t=33678&p=188122#p188122

Thanks. I have learnt a lot already!

Kaveh


>
>
>>
>> --
>> 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
>>
>
>
> --
> Kaveh Bazargan PhD
> Director
> River Valley Technologies  • Twitter
>  • LinkedIn
> 
>


-- 
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

On Wed, 15 Jan 2020 at 19:27, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 1/15/20 10:56 AM, Kaveh Bazargan via use-livecode wrote:
> > I want to be able to build standalones often, and I cannot distribute the
> > code. So from what I understand I have to convert these back into
> standard
> > stacks every just before making a standalone, then load them thro the
> > Stacks tab (not Files tab). This is quite labour intensive. I do hope
> there
> > is an automated solution to be able to avoid this.
>
> This is off the top of my head and not tested at all, but here's the idea:
>
> on savingStandalone
>   put "stack1,stack2,stack3...stackn" into tStackList
>   repeat for each item i in tStackList
> set the mainstack of stack i to "myMainStack"
> set the password of stack i to "somePassword"
>   end repeat
> end savingStandalone
>
> Since the above doesn't change the original mainstack I don't think
> you'll need a standaloneSaved handler to undo the changes but see what
> happens. Make backups first.
>

Sounds great Jacqueline. I will give it a go. :-)


>
> --
> 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
>


-- 
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[J. Landman Gay via use-livecode]

On 1/15/20 10:56 AM, Kaveh Bazargan via use-livecode wrote:

I want to be able to build standalones often, and I cannot distribute the
code. So from what I understand I have to convert these back into standard
stacks every just before making a standalone, then load them thro the
Stacks tab (not Files tab). This is quite labour intensive. I do hope there
is an automated solution to be able to avoid this.


This is off the top of my head and not tested at all, but here's the idea:

on savingStandalone
 put "stack1,stack2,stack3...stackn" into tStackList
 repeat for each item i in tStackList
   set the mainstack of stack i to "myMainStack"
   set the password of stack i to "somePassword"
 end repeat
end savingStandalone

Since the above doesn't change the original mainstack I don't think 
you'll need a standaloneSaved handler to undo the changes but see what 
happens. Make backups first.


--
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: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

On Wed, 15 Jan 2020 at 16:49, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> [...]
>
>  I don't think the SB does that on its own, and I'm not sure it's
> something it should do automatically all the time. In the delivered app
> is there (or should there be) a difference between a substack and a
> stack file?
>
> But it's easy to do in the PI by changing the mainstack property of the
> script-only stack.
>
>
>
Mark, my problem is that I loved the idea of script only stacks so got them
working (7 or more SoS's) that are loaded through the  Files tab of
Standalone Application builder. Obvious advantages are allowing me to
use GitHub and to collaborate as discussed.

I want to be able to build standalones often, and I cannot distribute the
code. So from what I understand I have to convert these back into standard
stacks every just before making a standalone, then load them thro the
Stacks tab (not Files tab). This is quite labour intensive. I do hope there
is an automated solution to be able to avoid this.

I could use Levure and would love to, but it's one more thing to learn and
I feel an overkill for me as all my scripts are now in SoS files.

Kaveh


-- 
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/14/20 8:54 PM, Richard Gaskin via use-livecode wrote:

Mark Wieder wrote:

 > On 1/14/20 7:52 AM, Richard Gaskin via use-livecode wrote:
 >
 >> Is it a bug that script-only stacks can't be imported into the
 >> stackfile to become binary substacks?
 >>
 >
 > They can, but it's a one-way operation. Once you've done that the
 > substack and the script-only text file are two different entities.
 > Editing one won't affect the other.

For building standalones that would be fine.  Is that in the Standalone 
Builder, or something every one of us needs to write our own script for?




I don't think the SB does that on its own, and I'm not sure it's 
something it should do automatically all the time. In the delivered app 
is there (or should there be) a difference between a substack and a 
stack file?


But it's easy to do in the PI by changing the mainstack property of the 
script-only stack.


--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/14/20 9:25 PM, Trevor DeVore via use-livecode wrote:


I've only used Github so I can't offer up a comparison. I've been happy
with Github for the most part and my company has been working with it for a
number of years.



Same here. We investigated moving some repos to gitlab some time ago in 
order to keep private repos local, but never made the jump. But that 
seems like a good use case for using an in-house gitlab server.


--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/15/20 8:24 AM, Bob Sneidar via use-livecode wrote:

I REALLY need to start using GIT. I am running into that constantly. Are 
database schema changes gitable, or would I need to create a separate schema?


Export the schema - it's a text file, so it's a good candidate for 
archiving. You won't want to archive binary files, as the git repository 
will grow alarmingly fast.


We accidentally archived an instructional video in a repo some years 
ago, and eventually had to scrap the archive and start over.


--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Bob Sneidar via use-livecode]

I REALLY need to start using GIT. I am running into that constantly. Are 
database schema changes gitable, or would I need to create a separate schema?

Bob S


> On Jan 14, 2020, at 20:36 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:
> 
>> Beyond backup across versions (since that's widely available in most cloud 
>> storage for even binary files), that Git features do you find most valuable?
> 
> As in Trevor's description, the advantage of being able to create new 
> branches for experimental work can't be overstated.
> 
> Consider: you have a working project and want to try making some changes that 
> may or may not work. And that may or may not stop existing things from 
> working. Or maybe you just want to try some A-B testing and be able to create 
> two different versions. Or create a new version and be able to do some 
> performance benchmarking.
> 
> All without messing with your existing product code.
> 
> If it works you can merge the branch into the main code. If not then just 
> dump the branch and you haven't lost anything except some time.
> 
> I also use tagging in git to set release values, so that I can easily see 
> what's changed from one release to the next.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.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: encrypting script-only stacks

[Trevor DeVore via use-livecode]

On Tue, Jan 14, 2020 at 10:36 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:
>
> > Beyond backup across versions (since that's widely available in most
> > cloud storage for even binary files), that Git features do you find most
> > valuable?
> >
>
> As in Trevor's description, the advantage of being able to create new
> branches for experimental work can't be overstated.
>
> Consider: you have a working project and want to try making some changes
> that may or may not work. And that may or may not stop existing things
> from working. Or maybe you just want to try some A-B testing and be able
> to create two different versions. Or create a new version and be able to
> do some performance benchmarking.
>
> All without messing with your existing product code.
>
> If it works you can merge the branch into the main code. If not then
> just dump the branch and you haven't lost anything except some time.
>
> I also use tagging in git to set release values, so that I can easily
> see what's changed from one release to the next.
>

I'll toss in an amen to both of these points (testing optimizations, etc.
and tagging releases). I use Tower as my Git GUI with Kaleidoscope for
diffs. I can easily see a diff of all files that have changed between two
releases because I tag the commit that was current at release time of each
version.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Trevor DeVore via use-livecode]

On Tue, Jan 14, 2020 at 4:14 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks, Trevor.  That's a helpful outline.
>
> I haven't had a business case to support so many branches, but I can see
> where it might be useful down the road.
>
> Any opinions on Github vs Gitlab?
>

I've only used Github so I can't offer up a comparison. I've been happy
with Github for the most part and my company has been working with it for a
number of years.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> On 1/14/20 7:52 AM, Richard Gaskin via use-livecode wrote:
>
>> Is it a bug that script-only stacks can't be imported into the
>> stackfile to become binary substacks?
>>
>
> They can, but it's a one-way operation. Once you've done that the
> substack and the script-only text file are two different entities.
> Editing one won't affect the other.

For building standalones that would be fine.  Is that in the Standalone 
Builder, or something every one of us needs to write our own script for?


--
 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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/14/20 2:13 PM, Richard Gaskin via use-livecode wrote:


Any opinions on Github vs Gitlab?



SCaLE is coming up soon. Gitlab always has a table set up.
They're good at answering the hard questions.

--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:

Beyond backup across versions (since that's widely available in most 
cloud storage for even binary files), that Git features do you find most 
valuable?




As in Trevor's description, the advantage of being able to create new 
branches for experimental work can't be overstated.


Consider: you have a working project and want to try making some changes 
that may or may not work. And that may or may not stop existing things 
from working. Or maybe you just want to try some A-B testing and be able 
to create two different versions. Or create a new version and be able to 
do some performance benchmarking.


All without messing with your existing product code.

If it works you can merge the branch into the main code. If not then 
just dump the branch and you haven't lost anything except some time.


I also use tagging in git to set release values, so that I can easily 
see what's changed from one release to the next.


--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Mark Wieder via use-livecode]

On 1/14/20 7:52 AM, Richard Gaskin via use-livecode wrote:

Is it a bug that script-only stacks can't be imported into the stackfile 
to become binary substacks?




They can, but it's a one-way operation. Once you've done that the 
substack and the script-only text file are two different entities. 
Editing one won't affect the other.


--
 Mark Wieder
 ahsoftw...@gmail.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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

Thanks, Trevor.  That's a helpful outline.

I haven't had a business case to support so many branches, but I can see 
where it might be useful down the road.


Any opinions on Github vs Gitlab?

--
 Richard Gaskin
 Fourth World Systems


Trevor DeVore wrote:

On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:


...

Help me motivate to move my Git transition forward sooner:

Beyond backup across versions (since that's widely available in most
cloud storage for even binary files), that Git features do you find most
valuable?



Hi Richard -

One way I use Git is to develop multiple features in tandem without
affecting the version I distribute of my app that I distribute to
customers. I love how I can silo my own work on features as well as the
flexibility to see detailed history of changes throughout the life of my
application. I use the Git commit notes and the ease with which you can
review changes in those commits a number of times when trying to track down
at what point a bug was introduced.

Here is an example of how I silo work I'm doing right now. If you looked at
my Git repo earlier today you would see the following branches:

- master
- develop
- tkd-htmltidy
- tkd-remove-answer-types
- tkd-mammoth
- tkd-hires-annotations

`master` always has the release version of the code.

`develop` is code that has been developed, tested, and is ready to go into
the next release. I will create builds from this branch to send to
customers who want early access to a feature or bug fix.

All other branches are features that are being worked on but which are not
finished and require more testing. Some of those branches exist for an
afternoon. Some last for a month or more.

Today I merged in `tkd-htmltidy` and tkd-remove-answer-types` into
`develop` as they were finished and are ready to send to customers who need
early access. When I squashed and merged those branches in there were a
number of changes which had been made in the develop branch since I had
started `tkd-htmltidy`. Those changes were seamless blended together
without any problem, even though there were changes changes made in some of
the same files. In addition, because I squashed the merge, all of the
changes that went into the addition of HTML Tidy are seen as one commit in
my `develop` branch. I made dozens of commits during development but was
able to make one clean commit when I was all done and ready to merge the
changes with the main code branch. This makes for a clean history that is
easier to review later on.

I will continue to work on the tkd-hires-annotations and tkd-mammoth
branches as they aren't done yet and require more revisions. But once they
are ready I perform the same squash and merge. If I want an internal tester
or a customer to test those features out before they are ready I can do
that too. I can use the Git rebase feature to bring in all changes to
`develop` that have been made since I created a particular branch. That
means the tester is using the latest version of the app along with the new
feature I'm working on.

One last example. Let's say that a nasty bug turns up while I'm working on
`develop` and need to get a release out to customers right away. I can go
to master, create a new branch from that code, make the fix, and package up
a new installer. I can merge that fix into `develop` as well so that it
will be included in a future update.

I think the scenarios I describe above are my favorite reasons for using
Git as they make my daily development and management of the code easier.

--
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Trevor DeVore via use-livecode]

On Tue, Jan 14, 2020 at 2:35 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor DeVore wrote:
>
> > I use SoS extensively but I had never tried using the SB to encrypt them
> as
> > I use Levure. The Levure packaging library automatically encrypts script
> > only stacks for you during the packaging process. While Levure uses the
> SB
> > to create the standalone, encrypting the stacks is handled in the Levure
> > packaging library, not the SB.
>
> I'm assuming Levure does this by converting a copy of the SoS stack
> files to binary stack files, yes?
>

That is correct. The SoS is opened, the the scriptonly property of the
stack is set to false, and then it is saved using the same filename. This
is all done in a temporary directory so that the source file isn't modified
at all.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Trevor DeVore via use-livecode]

On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> ...
>
> Help me motivate to move my Git transition forward sooner:
>
> Beyond backup across versions (since that's widely available in most
> cloud storage for even binary files), that Git features do you find most
> valuable?
>

Hi Richard -

One way I use Git is to develop multiple features in tandem without
affecting the version I distribute of my app that I distribute to
customers. I love how I can silo my own work on features as well as the
flexibility to see detailed history of changes throughout the life of my
application. I use the Git commit notes and the ease with which you can
review changes in those commits a number of times when trying to track down
at what point a bug was introduced.

Here is an example of how I silo work I'm doing right now. If you looked at
my Git repo earlier today you would see the following branches:

- master
- develop
- tkd-htmltidy
- tkd-remove-answer-types
- tkd-mammoth
- tkd-hires-annotations

`master` always has the release version of the code.

`develop` is code that has been developed, tested, and is ready to go into
the next release. I will create builds from this branch to send to
customers who want early access to a feature or bug fix.

All other branches are features that are being worked on but which are not
finished and require more testing. Some of those branches exist for an
afternoon. Some last for a month or more.

Today I merged in `tkd-htmltidy` and tkd-remove-answer-types` into
`develop` as they were finished and are ready to send to customers who need
early access. When I squashed and merged those branches in there were a
number of changes which had been made in the develop branch since I had
started `tkd-htmltidy`. Those changes were seamless blended together
without any problem, even though there were changes changes made in some of
the same files. In addition, because I squashed the merge, all of the
changes that went into the addition of HTML Tidy are seen as one commit in
my `develop` branch. I made dozens of commits during development but was
able to make one clean commit when I was all done and ready to merge the
changes with the main code branch. This makes for a clean history that is
easier to review later on.

I will continue to work on the tkd-hires-annotations and tkd-mammoth
branches as they aren't done yet and require more revisions. But once they
are ready I perform the same squash and merge. If I want an internal tester
or a customer to test those features out before they are ready I can do
that too. I can use the Git rebase feature to bring in all changes to
`develop` that have been made since I created a particular branch. That
means the tester is using the latest version of the app along with the new
feature I'm working on.

One last example. Let's say that a nasty bug turns up while I'm working on
`develop` and need to get a release out to customers right away. I can go
to master, create a new branch from that code, make the fix, and package up
a new installer. I can merge that fix into `develop` as well so that it
will be included in a future update.

I think the scenarios I describe above are my favorite reasons for using
Git as they make my daily development and management of the code easier.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:


On Tue, Jan 14, 2020 at 1:13 PM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:


Exactly.  I was hoping the Standalone Builder would do that if you
choose to include external SoS in the standalone.

What I found instead is that it doesn't being them into the standalone
stack file as substacks, nor even convert them to binary stack files in
place.  It just refuses to allow a password to be set.

For apps making rich use of SoS, it would seem tedious to do that
conversion by hand, or to expect every developer to write the same pair
of handlers to automate that before and after building the standalone.

How do folks who use SoS frequently protect those SoS scripts?



I use SoS extensively but I had never tried using the SB to encrypt them as
I use Levure. The Levure packaging library automatically encrypts script
only stacks for you during the packaging process. While Levure uses the SB
to create the standalone, encrypting the stacks is handled in the Levure
packaging library, not the SB.


I'm assuming Levure does this by converting a copy of the SoS stack 
files to binary stack files, yes?


--
 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: encrypting script-only stacks

[Trevor DeVore via use-livecode]

On Tue, Jan 14, 2020 at 1:13 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Exactly.  I was hoping the Standalone Builder would do that if you
> choose to include external SoS in the standalone.
>
> What I found instead is that it doesn't being them into the standalone
> stack file as substacks, nor even convert them to binary stack files in
> place.  It just refuses to allow a password to be set.
>
> For apps making rich use of SoS, it would seem tedious to do that
> conversion by hand, or to expect every developer to write the same pair
> of handlers to automate that before and after building the standalone.
>
> How do folks who use SoS frequently protect those SoS scripts?
>

I use SoS extensively but I had never tried using the SB to encrypt them as
I use Levure. The Levure packaging library automatically encrypts script
only stacks for you during the packaging process. While Levure uses the SB
to create the standalone, encrypting the stacks is handled in the Levure
packaging library, not the SB.

I agree that the SB should handle this for you though.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

Exactly.  I was hoping the Standalone Builder would do that if you 
choose to include external SoS in the standalone.


What I found instead is that it doesn't being them into the standalone 
stack file as substacks, nor even convert them to binary stack files in 
place.  It just refuses to allow a password to be set.


For apps making rich use of SoS, it would seem tedious to do that 
conversion by hand, or to expect every developer to write the same pair 
of handlers to automate that before and after building the standalone.


How do folks who use SoS frequently protect those SoS scripts?

--
 Richard Gaskin
 Fourth World Systems


J. Landman Gay wrote:
My thought was that you'd use the text files during development and then 
save them as binary with encryption for the final build.


--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode 
 wrote:



The benefits of SoS are so important that I would hate to have to go back
to binary again. Nothing like having pure text files to version, back up
etc. so I am also hoping for an elegant solution to encode these in
standalone.

On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:


Sure, and with the extra benefit that you wouldn't have to expose your
code to end-users.

That is, unless there's a way to include SoS in a standalone that
includes encryption, such as an automated method in the Standalone Builder.

I couldn't find one, but it seems like such a pervasive issue for the
class of devs most likely to use SoS (pros dependent on VCS) that I'm
hoping I just missed something.

--
  Richard Gaskin
  Fourth World Systems



___
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: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

That’s a great idea. :-)

On Tue, 14 Jan 2020 at 18:30, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My thought was that you'd use the text files during development and then
> save them as binary with encryption for the final build.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode
>  wrote:
>
> > The benefits of SoS are so important that I would hate to have to go back
> > to binary again. Nothing like having pure text files to version, back up
> > etc. so I am also hoping for an elegant solution to encode these in
> > standalone.
> >
> > On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Sure, and with the extra benefit that you wouldn't have to expose your
> >> code to end-users.
> >>
> >> That is, unless there's a way to include SoS in a standalone that
> >> includes encryption, such as an automated method in the Standalone
> Builder.
> >>
> >> I couldn't find one, but it seems like such a pervasive issue for the
> >> class of devs most likely to use SoS (pros dependent on VCS) that I'm
> >> hoping I just missed something.
> >>
> >> --
> >>   Richard Gaskin
> >>   Fourth World Systems
> >>
> >>
> >> Jacque wrote:
> >>
> >>  > Wouldn't a binary script-only stack be the library stack we already
> >>  > have now?
> >>  > --
> >>  > Jacqueline Landman Gay | jacque at hyperactivesw.com
> >>  >
> >>  > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
> >>  >
> >>  >> Since script-only stacks contain only a script with no properties,
> >>  >> they have no password property, and thus cannot be encrypted.
> >>  >>
> >>  >> I had thought that including them in the Stacks pane of the
> >>  >> Standalone Builder might convert them to binary substacks, where
> >>  >> the password could apply.  No dice.
> >>  >>
> >>  >> Is it a bug that script-only stacks can't be imported into the
> >>  >> stackfile to become binary substacks?
> >>  >>
> >>  >> --
> >>  >>  Richard Gaskin
> >>  >>  Fourth World Systems
> >>
> >>
> >>
> >> ___
> >> 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
> >>
> >
> >
> > --
> > Kaveh Bazargan PhD
> > Director
> > River Valley Technologies  •
> Twitter
> >  • LinkedIn
> > 
> > ___
> > 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
>
-- 
Sent from MetroMail
___
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: encrypting script-only stacks

[J. Landman Gay via use-livecode]

My thought was that you'd use the text files during development and then 
save them as binary with encryption for the final build.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode 
 wrote:



The benefits of SoS are so important that I would hate to have to go back
to binary again. Nothing like having pure text files to version, back up
etc. so I am also hoping for an elegant solution to encode these in
standalone.

On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


Sure, and with the extra benefit that you wouldn't have to expose your
code to end-users.

That is, unless there's a way to include SoS in a standalone that
includes encryption, such as an automated method in the Standalone Builder.

I couldn't find one, but it seems like such a pervasive issue for the
class of devs most likely to use SoS (pros dependent on VCS) that I'm
hoping I just missed something.

--
  Richard Gaskin
  Fourth World Systems


Jacque wrote:

 > Wouldn't a binary script-only stack be the library stack we already
 > have now?
 > --
 > Jacqueline Landman Gay | jacque at hyperactivesw.com
 >
 > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
 >
 >> Since script-only stacks contain only a script with no properties,
 >> they have no password property, and thus cannot be encrypted.
 >>
 >> I had thought that including them in the Stacks pane of the
 >> Standalone Builder might convert them to binary substacks, where
 >> the password could apply.  No dice.
 >>
 >> Is it a bug that script-only stacks can't be imported into the
 >> stackfile to become binary substacks?
 >>
 >> --
 >>  Richard Gaskin
 >>  Fourth World Systems



___
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




--
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

I use Nextcloud with my work folders, so backup with versions is 
automatic, and it keeps everything synced across my Mac, Linux, and Win 
boxes along with it.


But my needs are modest.  Because I rarely work in teams larger than 
three to five developers, and we assign tasks by skill focus so we 
rarely need to have two devs working on the same stack file at the same 
time, we rarely need automated merge assistance.  In the few cases where 
we have needed a merge, a prop diff and tossed-together script-diff have 
been sufficient.


I will be using Git more in 2020, though, for open source work, likely 
on Github (though I'm still considering Gitlab since it's open source 
itself).


Help me motivate to move my Git transition forward sooner:

Beyond backup across versions (since that's widely available in most 
cloud storage for even binary files), that Git features do you find most 
valuable?


--
 Richard Gaskin
 Fourth World Systems


Kaveh Bazargan wrote:

> The benefits of SoS are so important that I would hate to have to go
> back to binary again. Nothing like having pure text files to version,
> back up etc. so I am also hoping for an elegant solution to encode
> these in standalone.
>
> On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> Sure, and with the extra benefit that you wouldn't have to expose
>> your code to end-users.
>>
>> That is, unless there's a way to include SoS in a standalone that
>> includes encryption, such as an automated method in the Standalone
>> Builder.
>>
>> I couldn't find one, but it seems like such a pervasive issue for the
>> class of devs most likely to use SoS (pros dependent on VCS) that I'm
>> hoping I just missed something.
>>
>> --
>>   Richard Gaskin
>>   Fourth World Systems




___
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: encrypting script-only stacks

[Kaveh Bazargan via use-livecode]

The benefits of SoS are so important that I would hate to have to go back
to binary again. Nothing like having pure text files to version, back up
etc. so I am also hoping for an elegant solution to encode these in
standalone.

On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sure, and with the extra benefit that you wouldn't have to expose your
> code to end-users.
>
> That is, unless there's a way to include SoS in a standalone that
> includes encryption, such as an automated method in the Standalone Builder.
>
> I couldn't find one, but it seems like such a pervasive issue for the
> class of devs most likely to use SoS (pros dependent on VCS) that I'm
> hoping I just missed something.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
> Jacque wrote:
>
>  > Wouldn't a binary script-only stack be the library stack we already
>  > have now?
>  > --
>  > Jacqueline Landman Gay | jacque at hyperactivesw.com
>  >
>  > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
>  >
>  >> Since script-only stacks contain only a script with no properties,
>  >> they have no password property, and thus cannot be encrypted.
>  >>
>  >> I had thought that including them in the Stacks pane of the
>  >> Standalone Builder might convert them to binary substacks, where
>  >> the password could apply.  No dice.
>  >>
>  >> Is it a bug that script-only stacks can't be imported into the
>  >> stackfile to become binary substacks?
>  >>
>  >> --
>  >>  Richard Gaskin
>  >>  Fourth World Systems
>
>
>
> ___
> 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
>


-- 
Kaveh Bazargan PhD
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: encrypting script-only stacks

[Richard Gaskin via use-livecode]

Sure, and with the extra benefit that you wouldn't have to expose your 
code to end-users.


That is, unless there's a way to include SoS in a standalone that 
includes encryption, such as an automated method in the Standalone Builder.


I couldn't find one, but it seems like such a pervasive issue for the 
class of devs most likely to use SoS (pros dependent on VCS) that I'm 
hoping I just missed something.


--
 Richard Gaskin
 Fourth World Systems


Jacque wrote:

> Wouldn't a binary script-only stack be the library stack we already
> have now?
> --
> Jacqueline Landman Gay | jacque at hyperactivesw.com
>
> On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
>
>> Since script-only stacks contain only a script with no properties,
>> they have no password property, and thus cannot be encrypted.
>>
>> I had thought that including them in the Stacks pane of the
>> Standalone Builder might convert them to binary substacks, where
>> the password could apply.  No dice.
>>
>> Is it a bug that script-only stacks can't be imported into the
>> stackfile to become binary substacks?
>>
>> --
>>  Richard Gaskin
>>  Fourth World Systems



___
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: encrypting script-only stacks

[J. Landman Gay via use-livecode]

Wouldn't a binary script-only stack be the library stack we already have now?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 14, 2020 9:55:01 AM Richard Gaskin via use-livecode 
 wrote:



Since script-only stacks contain only a script with no properties, they
have no password property, and thus cannot be encrypted.

I had thought that including them in the Stacks pane of the Standalone
Builder might convert them to binary substacks, where the password could
apply.  No dice.

Is it a bug that script-only stacks can't be imported into the stackfile
to become binary substacks?

--
 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

encrypting script-only stacks

[Richard Gaskin via use-livecode]

Since script-only stacks contain only a script with no properties, they 
have no password property, and thus cannot be encrypted.


I had thought that including them in the Stacks pane of the Standalone 
Builder might convert them to binary substacks, where the password could 
apply.  No dice.


Is it a bug that script-only stacks can't be imported into the stackfile 
to become binary substacks?


--
 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