Re: worth it's salt in security
One big difference is that encrypt is reversible and messagedigest is not.
Generally for password “storage” you want to use a hash that is one way. You
don’t actually store anything that can be reversed to obtain the actual
password. For that, you are probably better off just doing a couple of rounds
of the digest as the dictionary example shows.
On Jun 6, 2018, 11:57 PM -0500, J. Landman Gay via use-livecode
, wrote:
> I'm learning this along with you. But this is what I think I know so
> far. If you do a test in the message box:
>
> encrypt "mysecret" using "aes256" with password "mypass";put it
>
> You get this:
>
> Salted__«!óÈ/rm55ıit @ˇrȨßQ -- (there's a return in there)
>
> The salt is prepended to the encrypted value (the "hash") so the
> receiver knows what it is. The dictionary says that the salt and the
> password are combined and scrambled before the encryption is actually
> done, thus making the password longer, more random, and more secure.
> Without the password, an observer can't decrypt the string. They need to
> know both.
>
> Except...hackers have provided lists of all possible combinations of
> salted passwords up to 14 characters long ("rainbow tables".) So you
> don't want to use short combinations or common passwords or it might
> show up in one of those lists. (I assume if you have a very long and/or
> random password then it would be okay to have a short salt, or vice
> versa, since the two are combined.)
>
> Brian says that the default random salt is short (8 chars) and Kee says
> it is safest to provide 32 chars or more. So instead of letting LC
> auto-generate a salt, you could provide your own. Bob said he does that.
> If you decide to strip out the salt value from the front of the
> encrypted string, then your receiver would need to know what it is.
>
> Kee says it is common for online services to store a unique salt value
> for each user, along with the encrypted string that was generated with
> that salt when the password was first created. The password itself is
> not stored. When a user logs in, the service looks up their salt value,
> uses that salt to encrypt the password the user just sent, and compares
> the computed one to the one stored in the database. (Since no actual
> passwords are ever kept, breaches or employees can't know what they are
> either.)
>
> In any case, the salt alone is not enough to do decryption. Kee says a
> long enough salt makes decryption virtually impossible because the
> number of scrambled combinations becomes astronomical, too many to
> pre-compute.
>
> That's what I've pieced together, I welcome any corrections. This has
> been a useful thread because I had a vague idea of how it worked but not
> many particulars.
>
>
> On 6/6/18 10:37 PM, prothero--- via use-livecode wrote:
> > Hmmm
> > If the salt is included in the encrypted text, doesn’t that enable anyone
> > who intercepts it to decrypt it more easily, invalidating the purpose of
> > using the salt in the first place.
> >
> > Or, if the server decrypting the text uses a standard, but secret, salt
> > that is known by both parties, it seems more reasonable to me.
>
> --
> 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
___
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: worth it's salt in security
I'm learning this along with you. But this is what I think I know so
far. If you do a test in the message box:
encrypt "mysecret" using "aes256" with password "mypass";put it
You get this:
Salted__«!óÈ/rm55ı it @ˇrȨßQ -- (there's a return in there)
The salt is prepended to the encrypted value (the "hash") so the
receiver knows what it is. The dictionary says that the salt and the
password are combined and scrambled before the encryption is actually
done, thus making the password longer, more random, and more secure.
Without the password, an observer can't decrypt the string. They need to
know both.
Except...hackers have provided lists of all possible combinations of
salted passwords up to 14 characters long ("rainbow tables".) So you
don't want to use short combinations or common passwords or it might
show up in one of those lists. (I assume if you have a very long and/or
random password then it would be okay to have a short salt, or vice
versa, since the two are combined.)
Brian says that the default random salt is short (8 chars) and Kee says
it is safest to provide 32 chars or more. So instead of letting LC
auto-generate a salt, you could provide your own. Bob said he does that.
If you decide to strip out the salt value from the front of the
encrypted string, then your receiver would need to know what it is.
Kee says it is common for online services to store a unique salt value
for each user, along with the encrypted string that was generated with
that salt when the password was first created. The password itself is
not stored. When a user logs in, the service looks up their salt value,
uses that salt to encrypt the password the user just sent, and compares
the computed one to the one stored in the database. (Since no actual
passwords are ever kept, breaches or employees can't know what they are
either.)
In any case, the salt alone is not enough to do decryption. Kee says a
long enough salt makes decryption virtually impossible because the
number of scrambled combinations becomes astronomical, too many to
pre-compute.
That's what I've pieced together, I welcome any corrections. This has
been a useful thread because I had a vague idea of how it worked but not
many particulars.
On 6/6/18 10:37 PM, prothero--- via use-livecode wrote:
Hmmm
If the salt is included in the encrypted text, doesn’t that enable anyone who
intercepts it to decrypt it more easily, invalidating the purpose of using the
salt in the first place.
Or, if the server decrypting the text uses a standard, but secret, salt that is
known by both parties, it seems more reasonable to me.
--
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: worth it's salt in security
Bill Prothero wrote:
> On Jun 6, 2018, at 7:32 PM, Richard Gaskin wrote:
>> Are we talking about hashing or encrypting?
>
> Richard,
> I’m talking about using the LC encrypt command, with aes-256
> encryption.
Thanks. The mention of passwords in this discussion threw me.
> I’m trying to figure out how the “salt” works, because
> my php code sends me a warning that I am not using a salt,
> or IV to encrypt the sql query. I bought Andre Garza’s database
> software and have modified it pretty extensively. But, I’ve use his
> encryption implementation. His code doesn’t use a salt in his
> encryption implementation. So, I’m trying to get some info on how
> to implement the salt, and I haven’t had much luck with google.
> It seems to be one of those things where the experts are speaking
> a different language, one I don’t understand. Perhaps it’s so trivial
> that I’m missing the mark utterly.
A salt is any random set of bytes. I would imagine LC's randomBytes
function would do the trick, or even UUID("random") may suffice.
> If the salt is included in the encrypted text, doesn’t that enable
> anyone who intercepts it to decrypt it more easily, invalidating
> the purpose of using the salt in the first place.
>
> Or, if the server decrypting the text uses a standard, but secret,
> salt that is known by both parties, it seems more reasonable to me.
The salt isn't a second password, just a way to produce unique output to
slow down cracking.
Kee's post on salting passwords covers the benefits:
http://lists.runrev.com/pipermail/use-livecode/2018-June/247634.html
--
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: worth it's salt in security
If you are using a known salt, then I would say it makes sense to strip it. It would make it easier to decrypt if included, but still not easy to break a cipher that isn’t already cracked. Since only 8 bytes of the salt are unique/used, it may be better to generate your own key instead of using the built in password and salt, but I’m not a security expert. If you are just using a password, then a random salt is added. That means that each encrypted message (even if the message and password is the same) will be unique. On Jun 6, 2018, 10:38 PM -0500, prothero--- via use-livecode , wrote: > Hmmm > If the salt is included in the encrypted text, doesn’t that enable anyone who > intercepts it to decrypt it more easily, invalidating the purpose of using > the salt in the first place. > > Or, if the server decrypting the text uses a standard, but secret, salt that > is known by both parties, it seems more reasonable to me. > > Sorry if I’m being dense. > Bill > > William Prothero > http://earthlearningsolutions.org > > > On Jun 6, 2018, at 7:56 PM, Brian Milby via use-livecode > > wrote: > > > > I’m not sure what the original thread was using the salt for but the > > initial post in this one was more about hashing. The question about > > encryption was introduced so I answered that. > > > > For encryption, it looks like there is only an effective 8 byte salt (the > > first 8 are static - “Salted__”). Specifying more than 8 bytes does not > > change the resulting encrypted text. > > > > Since LC does include the salt, it does not need to be separately provided > > to decrypt. If you strip the salt (first 16 bytes), then you must supply > > the salt to decrypt. Providing the salt without stripping it from the > > encrypted text did not pose a problem in my test. > > > On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode > > > , wrote: > > > Brian Milby wrote: > > > > From the dictionary: > > > > > > > > The password and salt value are combined and scrambled to form the key > > > > and IV which are used as described above. The key derivation process > > > > is the same as that used in the openSSL utility. A 16-byte salt prefix > > > > is prepended to the encrypted data, based on the salt value. This is > > > > used in decryption. > > > > > > "decryption"? > > > > > > Are we talking about hashing or encrypting? > > > > > > -- > > > Richard Gaskin > > > Fourth World Systems > > > Software Design and Development for the Desktop, Mobile, and the Web > > > > > > ambassa...@fourthworld.com http://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 > > > ___ > 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: worth it's salt in security
Hmmm If the salt is included in the encrypted text, doesn’t that enable anyone who intercepts it to decrypt it more easily, invalidating the purpose of using the salt in the first place. Or, if the server decrypting the text uses a standard, but secret, salt that is known by both parties, it seems more reasonable to me. Sorry if I’m being dense. Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 7:56 PM, Brian Milby via use-livecode > wrote: > > I’m not sure what the original thread was using the salt for but the initial > post in this one was more about hashing. The question about encryption was > introduced so I answered that. > > For encryption, it looks like there is only an effective 8 byte salt (the > first 8 are static - “Salted__”). Specifying more than 8 bytes does not > change the resulting encrypted text. > > Since LC does include the salt, it does not need to be separately provided to > decrypt. If you strip the salt (first 16 bytes), then you must supply the > salt to decrypt. Providing the salt without stripping it from the encrypted > text did not pose a problem in my test. >> On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode >> , wrote: >> Brian Milby wrote: >>> From the dictionary: >>> >>> The password and salt value are combined and scrambled to form the key >>> and IV which are used as described above. The key derivation process >>> is the same as that used in the openSSL utility. A 16-byte salt prefix >>> is prepended to the encrypted data, based on the salt value. This is >>> used in decryption. >> >> "decryption"? >> >> Are we talking about hashing or encrypting? >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> >> ambassa...@fourthworld.com http://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 ___ 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: worth it's salt in security
Richard, I’m talking about using the LC encrypt command, with aes-256 encryption. I’m trying to figure out how the “salt” works, because my php code sends me a warning that I am not using a salt, or IV to encrypt the sql query. I bought Andre Garza’s database software and have modified it pretty extensively. But, I’ve use his encryption implementation. His code doesn’t use a salt in his encryption implementation. So, I’m trying to get some info on how to implement the salt, and I haven’t had much luck with google. It seems to be one of those things where the experts are speaking a different language, one I don’t understand. Perhaps it’s so trivial that I’m missing the mark utterly. A few lines of code that shows how to encrypt, then decrypt a string, with aes-256 and a salt, would solve my problem. Also, I think the responses so far have given me enough hints so when I get back to my computer in a week, I can trial and error figure it out. Thanks for chiming in. I’ll post some code when I figure it out, unless somebody does it first. Best, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 7:32 PM, Richard Gaskin via use-livecode > wrote: > > Brian Milby wrote: > > From the dictionary: > > > > The password and salt value are combined and scrambled to form the key > > and IV which are used as described above. The key derivation process > > is the same as that used in the openSSL utility. A 16-byte salt prefix > > is prepended to the encrypted data, based on the salt value. This is > > used in decryption. > > "decryption"? > > Are we talking about hashing or encrypting? > > -- > 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
Re: worth it's salt in security
I’m not sure what the original thread was using the salt for but the initial post in this one was more about hashing. The question about encryption was introduced so I answered that. For encryption, it looks like there is only an effective 8 byte salt (the first 8 are static - “Salted__”). Specifying more than 8 bytes does not change the resulting encrypted text. Since LC does include the salt, it does not need to be separately provided to decrypt. If you strip the salt (first 16 bytes), then you must supply the salt to decrypt. Providing the salt without stripping it from the encrypted text did not pose a problem in my test. On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode , wrote: > Brian Milby wrote: > > From the dictionary: > > > > The password and salt value are combined and scrambled to form the key > > and IV which are used as described above. The key derivation process > > is the same as that used in the openSSL utility. A 16-byte salt prefix > > is prepended to the encrypted data, based on the salt value. This is > > used in decryption. > > "decryption"? > > Are we talking about hashing or encrypting? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.com http://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
Re: worth it's salt in security
Yes, My description was about hashing. If your main concern is encrypting …. not something I know. sorry. Kee > On Jun 6, 2018, at 7:32 PM, Richard Gaskin via use-livecode > wrote: > > Brian Milby wrote: > > From the dictionary: > > > > The password and salt value are combined and scrambled to form the key > > and IV which are used as described above. The key derivation process > > is the same as that used in the openSSL utility. A 16-byte salt prefix > > is prepended to the encrypted data, based on the salt value. This is > > used in decryption. > > "decryption"? > > Are we talking about hashing or encrypting? > > -- > 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
Re: worth it's salt in security
Brian Milby wrote: > From the dictionary: > > The password and salt value are combined and scrambled to form the key > and IV which are used as described above. The key derivation process > is the same as that used in the openSSL utility. A 16-byte salt prefix > is prepended to the encrypted data, based on the salt value. This is > used in decryption. "decryption"? Are we talking about hashing or encrypting? -- 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: worth it's salt in security
Brian, This, accidentally, didn’t go to the list. Sorry. Thanks for your reply. I will look into the OpenSSL utility. But, from what I can figure, it seems that the decode process extracts the salt from the encrypted password. And for me, I’m encrypting a MySQL query, so I assume it will be the same. I’m not on my computer for a week or so now, but I think I’m far enough along to solve this by diddling with the php. Best, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 6:44 PM, Brian Milby wrote: > > From the dictionary: > > The password and salt value are combined and scrambled to form the key and IV > which are used as described above. The key derivation process is the same as > that used in the openSSL utility. A 16-byte salt prefix is prepended to the > encrypted data, based on the salt value. This is used in decryption. If no > salt value is specified for a password, one is randomly generated. The use of > a randomized salt value is a protection against dictionary attacks. > > I have not tried this yet though. One point is that it is either key and IV > or password and salt. >> On Jun 6, 2018, 6:50 PM -0500, prothero--- via use-livecode >> , wrote: >> Kee, >> So does the decrypt need the salt somehow? Or does it get it from the stuff >> that is encrypted with the salt? That is, when I encrypt “with salt my salt” >> does the decode function somehow get the salt from the encoded data, because >> it has the “key”? >> >> Btw, thanks for responding, >> Bill >> >> William Prothero >> http://earthlearningsolutions.org >> >>> On Jun 6, 2018, at 3:48 PM, kee nethery via use-livecode >>> wrote: >>> >>> There is a bunch of basic info on the use of a salt on the web. The >>> wikipedia article is a good start. It depends upon where and how you are >>> using it. Mostly they discuss using a salt with a hash function. They >>> recommend a long salt. They recommend storing the salt with the hashed >>> password. >>> >>> User enters their name and password. You look up the salt for their name. >>> You hash the password they provided using the salt you have stored for >>> them. You compare the hash with the hash you had stored. If they match, >>> bingo. >>> >>> The salt eliminates the ability for a hacker to use a rainbow table. It is >>> trivial to buy a CD of all hashes for all possible password that are 1 to >>> 14 characters in length. Take a hash, look it up on the CD, and it displays >>> the original password that created that hash. >>> >>> Now … if you use a salt, your hash for that password will not match the >>> hash for that password in the rainbow table on the CD. If you have a 32 >>> character salt that is different for each password, assuming lower and >>> upper case ascii and numbers (26 + 26 + 10 = 62) the number of possible >>> salts for a 32 char salt is 62^32. To pre-compute rainbow table for each 14 >>> char possible password would mean 2.27 * 10^57 rainbow tables. Just isn’t >>> practical. So they would have to snag your password table, see the salts >>> for each password, create a rainbow table for that salt, then do a lookup >>> to see if the hash you stored is in the rainbow table. if yes, they know >>> the users password. For the next password, new rainbow table. >>> >>> So for a password hash, use a 32 char salt, and store the salt along with >>> the password hash, and toss the password, don’t store it. >>> >>> Kee >>> On Jun 6, 2018, at 2:52 PM, prothero--- via use-livecode wrote: I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a salt. However, the docs say it’s beyond the scope of the docs to explain how to choose a salt. For example, how many characters need to be in a salt. Are any characters permissible? Are all character formats permissible? There is no guidance on what makes an acceptable salt. Best, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode > wrote: > > The encrypt command in the dictionary has that info. > > Bob S > > >> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode >> wrote: >> >> I’ve been having questions about aes 256 encryption lately. I encrypt >> MySQL queries and data ,(in livecode) before sending it to a php script >> on my remote server. The php version returns a warning message that I am >> not using a salt, which reduces security. Ok, but I can’t find info >> about how to create and use salts. What are the parameters needed to >> make a salt, and do I have to do anything to my decode script in php to >> make it recognize the salt? >> >> It would be wonderful if there was a sample code for this. >> >> Best, >> Bill >> >> William Prothero >> http://earthlearningsolutions.org
Re: worth it's salt in security
From the dictionary: The password and salt value are combined and scrambled to form the key and IV which are used as described above. The key derivation process is the same as that used in the openSSL utility. A 16-byte salt prefix is prepended to the encrypted data, based on the salt value. This is used in decryption. If no salt value is specified for a password, one is randomly generated. The use of a randomized salt value is a protection against dictionary attacks. I have not tried this yet though. One point is that it is either key and IV or password and salt. On Jun 6, 2018, 6:50 PM -0500, prothero--- via use-livecode , wrote: > Kee, > So does the decrypt need the salt somehow? Or does it get it from the stuff > that is encrypted with the salt? That is, when I encrypt “with salt my salt” > does the decode function somehow get the salt from the encoded data, because > it has the “key”? > > Btw, thanks for responding, > Bill > > William Prothero > http://earthlearningsolutions.org > > > On Jun 6, 2018, at 3:48 PM, kee nethery via use-livecode > > wrote: > > > > There is a bunch of basic info on the use of a salt on the web. The > > wikipedia article is a good start. It depends upon where and how you are > > using it. Mostly they discuss using a salt with a hash function. They > > recommend a long salt. They recommend storing the salt with the hashed > > password. > > > > User enters their name and password. You look up the salt for their name. > > You hash the password they provided using the salt you have stored for > > them. You compare the hash with the hash you had stored. If they match, > > bingo. > > > > The salt eliminates the ability for a hacker to use a rainbow table. It is > > trivial to buy a CD of all hashes for all possible password that are 1 to > > 14 characters in length. Take a hash, look it up on the CD, and it displays > > the original password that created that hash. > > > > Now … if you use a salt, your hash for that password will not match the > > hash for that password in the rainbow table on the CD. If you have a 32 > > character salt that is different for each password, assuming lower and > > upper case ascii and numbers (26 + 26 + 10 = 62) the number of possible > > salts for a 32 char salt is 62^32. To pre-compute rainbow table for each 14 > > char possible password would mean 2.27 * 10^57 rainbow tables. Just isn’t > > practical. So they would have to snag your password table, see the salts > > for each password, create a rainbow table for that salt, then do a lookup > > to see if the hash you stored is in the rainbow table. if yes, they know > > the users password. For the next password, new rainbow table. > > > > So for a password hash, use a 32 char salt, and store the salt along with > > the password hash, and toss the password, don’t store it. > > > > Kee > > > > > On Jun 6, 2018, at 2:52 PM, prothero--- via use-livecode > > > wrote: > > > > > > I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set > > > a salt. However, the docs say it’s beyond the scope of the docs to > > > explain how to choose a salt. For example, how many characters need to be > > > in a salt. Are any characters permissible? Are all character formats > > > permissible? There is no guidance on what makes an acceptable salt. > > > > > > Best, > > > Bill > > > > > > William Prothero > > > http://earthlearningsolutions.org > > > > > > > On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode > > > > wrote: > > > > > > > > The encrypt command in the dictionary has that info. > > > > > > > > Bob S > > > > > > > > > > > > > On Jun 6, 2018, at 14:16 , prothero--- via use-livecode > > > > > wrote: > > > > > > > > > > I’ve been having questions about aes 256 encryption lately. I encrypt > > > > > MySQL queries and data ,(in livecode) before sending it to a php > > > > > script on my remote server. The php version returns a warning message > > > > > that I am not using a salt, which reduces security. Ok, but I can’t > > > > > find info about how to create and use salts. What are the parameters > > > > > needed to make a salt, and do I have to do anything to my decode > > > > > script in php to make it recognize the salt? > > > > > > > > > > It would be wonderful if there was a sample code for this. > > > > > > > > > > Best, > > > > > Bill > > > > > > > > > > William Prothero > > > > > http://earthlearningsolutions.org ___ 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: Area of regular polygon triangles
If you need to use the box method, and the control rect isn't perfect, it might be easier to create the rect on your own. Go through the points and find the topmost, left most, rightmost, bottom most coordinates and that gives you your box. Alternatively, if you just want the area and don't care how you get it the equation is pretty straightforward. area = A x ( B y − C y ) + B x ( C y − A y ) + C x ( A y − B y ) 2 where Ax and Ay are the x and y coordinates of the point A etc.. I have a stack that does this while dragging points around, it works well enough. On Wed, Jun 6, 2018 at 5:14 PM, David Epstein via use-livecode < use-livecode@lists.runrev.com> wrote: > If a regular polygon has 4 or 8 sides it seems to be inscribed so that all > points touch the square defined by the object’s height and width, which > means that it should be fairly easy to deduce the polygon’s area. > But with 3 sides, the triangle appears slightly smaller than the maximum > size that could fit into that square. Is there some math that would give > me the area of that triangle from the height and width of the square (i.e., > the official height and width of the polygon object)? > David Epstein > ___ > 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: worth it's salt in security
Kee, So does the decrypt need the salt somehow? Or does it get it from the stuff that is encrypted with the salt? That is, when I encrypt “with salt my salt” does the decode function somehow get the salt from the encoded data, because it has the “key”? Btw, thanks for responding, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 3:48 PM, kee nethery via use-livecode > wrote: > > There is a bunch of basic info on the use of a salt on the web. The wikipedia > article is a good start. It depends upon where and how you are using it. > Mostly they discuss using a salt with a hash function. They recommend a long > salt. They recommend storing the salt with the hashed password. > > User enters their name and password. You look up the salt for their name. You > hash the password they provided using the salt you have stored for them. You > compare the hash with the hash you had stored. If they match, bingo. > > The salt eliminates the ability for a hacker to use a rainbow table. It is > trivial to buy a CD of all hashes for all possible password that are 1 to 14 > characters in length. Take a hash, look it up on the CD, and it displays the > original password that created that hash. > > Now … if you use a salt, your hash for that password will not match the hash > for that password in the rainbow table on the CD. If you have a 32 character > salt that is different for each password, assuming lower and upper case ascii > and numbers (26 + 26 + 10 = 62) the number of possible salts for a 32 char > salt is 62^32. To pre-compute rainbow table for each 14 char possible > password would mean 2.27 * 10^57 rainbow tables. Just isn’t practical. So > they would have to snag your password table, see the salts for each password, > create a rainbow table for that salt, then do a lookup to see if the hash you > stored is in the rainbow table. if yes, they know the users password. For the > next password, new rainbow table. > > So for a password hash, use a 32 char salt, and store the salt along with the > password hash, and toss the password, don’t store it. > > Kee > >> On Jun 6, 2018, at 2:52 PM, prothero--- via use-livecode >> wrote: >> >> I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a >> salt. However, the docs say it’s beyond the scope of the docs to explain how >> to choose a salt. For example, how many characters need to be in a salt. Are >> any characters permissible? Are all character formats permissible? There is >> no guidance on what makes an acceptable salt. >> >> Best, >> Bill >> >> William Prothero >> http://earthlearningsolutions.org >> >>> On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode >>> wrote: >>> >>> The encrypt command in the dictionary has that info. >>> >>> Bob S >>> >>> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode wrote: I’ve been having questions about aes 256 encryption lately. I encrypt MySQL queries and data ,(in livecode) before sending it to a php script on my remote server. The php version returns a warning message that I am not using a salt, which reduces security. Ok, but I can’t find info about how to create and use salts. What are the parameters needed to make a salt, and do I have to do anything to my decode script in php to make it recognize the salt? It would be wonderful if there was a sample code for this. Best, Bill William Prothero http://earthlearningsolutions.org >>> >>> ___ >>> 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 > > > ___ > 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
Area of regular polygon triangles
If a regular polygon has 4 or 8 sides it seems to be inscribed so that all points touch the square defined by the object’s height and width, which means that it should be fairly easy to deduce the polygon’s area. But with 3 sides, the triangle appears slightly smaller than the maximum size that could fit into that square. Is there some math that would give me the area of that triangle from the height and width of the square (i.e., the official height and width of the polygon object)? David Epstein ___ 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
worth it's salt in security
There is a bunch of basic info on the use of a salt on the web. The wikipedia article is a good start. It depends upon where and how you are using it. Mostly they discuss using a salt with a hash function. They recommend a long salt. They recommend storing the salt with the hashed password. User enters their name and password. You look up the salt for their name. You hash the password they provided using the salt you have stored for them. You compare the hash with the hash you had stored. If they match, bingo. The salt eliminates the ability for a hacker to use a rainbow table. It is trivial to buy a CD of all hashes for all possible password that are 1 to 14 characters in length. Take a hash, look it up on the CD, and it displays the original password that created that hash. Now … if you use a salt, your hash for that password will not match the hash for that password in the rainbow table on the CD. If you have a 32 character salt that is different for each password, assuming lower and upper case ascii and numbers (26 + 26 + 10 = 62) the number of possible salts for a 32 char salt is 62^32. To pre-compute rainbow table for each 14 char possible password would mean 2.27 * 10^57 rainbow tables. Just isn’t practical. So they would have to snag your password table, see the salts for each password, create a rainbow table for that salt, then do a lookup to see if the hash you stored is in the rainbow table. if yes, they know the users password. For the next password, new rainbow table. So for a password hash, use a 32 char salt, and store the salt along with the password hash, and toss the password, don’t store it. Kee > On Jun 6, 2018, at 2:52 PM, prothero--- via use-livecode > wrote: > > I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a > salt. However, the docs say it’s beyond the scope of the docs to explain how > to choose a salt. For example, how many characters need to be in a salt. Are > any characters permissible? Are all character formats permissible? There is > no guidance on what makes an acceptable salt. > > Best, > Bill > > William Prothero > http://earthlearningsolutions.org > >> On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode >> wrote: >> >> The encrypt command in the dictionary has that info. >> >> Bob S >> >> >>> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode >>> wrote: >>> >>> I’ve been having questions about aes 256 encryption lately. I encrypt MySQL >>> queries and data ,(in livecode) before sending it to a php script on my >>> remote server. The php version returns a warning message that I am not >>> using a salt, which reduces security. Ok, but I can’t find info about how >>> to create and use salts. What are the parameters needed to make a salt, and >>> do I have to do anything to my decode script in php to make it recognize >>> the salt? >>> >>> It would be wonderful if there was a sample code for this. >>> >>> Best, >>> Bill >>> >>> William Prothero >>> http://earthlearningsolutions.org >> >> ___ >> 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 ___ 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
Android won't quit
Does anyone have a workaround to completely quit an Android app? I just re-opened this bug report that claimed to have fixed the problem but it didn't really: https://quality.livecode.com/show_bug.cgi?id=19420 I can block the backKey message and do nothing, but then the user can't use the backKey to quit the app. They can use the Home or Switcher buttons but the app is still in its old state when it is restarted. If I pass backKey, the app crashes on relaunch if it is still in RAM. I want to wipe the app completely so that on next launch I can reinitialize everything. -- 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: Differences between Commercial and Community versions of LiveCode
I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a salt. However, the docs say it’s beyond the scope of the docs to explain how to choose a salt. For example, how many characters need to be in a salt. Are any characters permissible? Are all character formats permissible? There is no guidance on what makes an acceptable salt. Best, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode > wrote: > > The encrypt command in the dictionary has that info. > > Bob S > > >> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode >> wrote: >> >> I’ve been having questions about aes 256 encryption lately. I encrypt MySQL >> queries and data ,(in livecode) before sending it to a php script on my >> remote server. The php version returns a warning message that I am not using >> a salt, which reduces security. Ok, but I can’t find info about how to >> create and use salts. What are the parameters needed to make a salt, and do >> I have to do anything to my decode script in php to make it recognize the >> salt? >> >> It would be wonderful if there was a sample code for this. >> >> Best, >> Bill >> >> William Prothero >> http://earthlearningsolutions.org > > ___ > 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: Differences between Commercial and Community versions of LiveCode
The encrypt command in the dictionary has that info. Bob S > On Jun 6, 2018, at 14:16 , prothero--- via use-livecode > wrote: > > I’ve been having questions about aes 256 encryption lately. I encrypt MySQL > queries and data ,(in livecode) before sending it to a php script on my > remote server. The php version returns a warning message that I am not using > a salt, which reduces security. Ok, but I can’t find info about how to create > and use salts. What are the parameters needed to make a salt, and do I have > to do anything to my decode script in php to make it recognize the salt? > > It would be wonderful if there was a sample code for this. > > Best, > Bill > > William Prothero > http://earthlearningsolutions.org ___ 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: Differences between Commercial and Community versions of LiveCode
I’ve been having questions about aes 256 encryption lately. I encrypt MySQL queries and data ,(in livecode) before sending it to a php script on my remote server. The php version returns a warning message that I am not using a salt, which reduces security. Ok, but I can’t find info about how to create and use salts. What are the parameters needed to make a salt, and do I have to do anything to my decode script in php to make it recognize the salt? It would be wonderful if there was a sample code for this. Best, Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 1:51 PM, Richard Gaskin via use-livecode > wrote: > > Tom Glod wrote: > > > what if for example you want to hard code a hash salt into your > > code?. > > Most auth DBs store a salt in plain text, but unique for each user. > > A single RAM dump doesn't slow attacks; eating up clock cycles does. > > -- > 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
Re: Differences between Commercial and Community versions of LiveCode
yupgood point Richard On Wed, Jun 6, 2018 at 4:51 PM, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Tom Glod wrote: > > > what if for example you want to hard code a hash salt into your > > code?. > > Most auth DBs store a salt in plain text, but unique for each user. > > A single RAM dump doesn't slow attacks; eating up clock cycles does. > > -- > 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
Re: Differences between Commercial and Community versions of LiveCode
Tom Glod wrote: > what if for example you want to hard code a hash salt into your > code?. Most auth DBs store a salt in plain text, but unique for each user. A single RAM dump doesn't slow attacks; eating up clock cycles does. -- 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: Differences between Commercial and Community versions of LiveCode
I do the same thing, but if they can get to your code, they can discern how you get your salt. I guess that is the upshot of what Mark was saying. If they cannot get to your code however and read it, then it seems safe enough for me. My salts are dynamically generated using a method only I know, so even if someone were able somehow to crack one password, it wouldn't work with any of the others. Bob S > On Jun 6, 2018, at 12:10 , Tom Glod via use-livecode > wrote: > > 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 ___ 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: Differences between Commercial and Community versions of LiveCode
thanks for that reply marktotally 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 < use-livecode@lists.runrev.com> 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 ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > > ___ > 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: Differences between Commercial and Community versions of 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 ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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: Differences between Commercial and Community versions of 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 < use-livecode@lists.runrev.com> 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 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 < > > use-livecode@lists.runrev.com> 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 < > >> use-livecode@lists.runrev.com> wrote: > >> > >> > Can’t do that with community... code must be available. > >> > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode < > >> > use-livecode@lists.runrev.com>, 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 < > >> > > use-livecode@lists.runrev.com> 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 < > >> > > > use-livecode@lists.runrev.com>, 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 < > >> > > > use-livecode@lists.runrev.com> 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 > >> > > > > 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 > >> > > > > >> > > ___ > >> > > 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 > >> ___ > >> use-livecode mailing list > >>
Re: Differences between Commercial and Community versions of 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 < use-livecode@lists.runrev.com> wrote: > Can’t do that with community... code must be available. > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode < > use-livecode@lists.runrev.com>, 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 < > > use-livecode@lists.runrev.com> 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 < > > > use-livecode@lists.runrev.com>, 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 < > > > use-livecode@lists.runrev.com> 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 > > > > 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 > > > > > ___ > > 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 ___ 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: Differences between Commercial and Community versions of 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 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 < > use-livecode@lists.runrev.com> 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 < >> use-livecode@lists.runrev.com> wrote: >> >> > Can’t do that with community... code must be available. >> > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode < >> > use-livecode@lists.runrev.com>, 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 < >> > > use-livecode@lists.runrev.com> 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 < >> > > > use-livecode@lists.runrev.com>, 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 < >> > > > use-livecode@lists.runrev.com> 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 >> > > > > 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 >> > > > >> > > ___ >> > > 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 >> ___ >> 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: Differences between Commercial and Community versions of 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 < use-livecode@lists.runrev.com> 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 < > use-livecode@lists.runrev.com> wrote: > > > Can’t do that with community... code must be available. > > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode < > > use-livecode@lists.runrev.com>, 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 < > > > use-livecode@lists.runrev.com> 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 < > > > > use-livecode@lists.runrev.com>, 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 < > > > > use-livecode@lists.runrev.com> 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 > > > > > 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 > > > > > > > ___ > > > 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 > ___ > 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: Differences between Commercial and Community versions of 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 < use-livecode@lists.runrev.com> wrote: > Can’t do that with community... code must be available. > On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode < > use-livecode@lists.runrev.com>, 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 < > > use-livecode@lists.runrev.com> 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 < > > > use-livecode@lists.runrev.com>, 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 < > > > use-livecode@lists.runrev.com> 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 > > > > 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 > > > > > ___ > > 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 ___ 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: Differences between Commercial and Community versions of LiveCode
Can’t do that with community... code must be available. On Jun 6, 2018, 11:09 AM -0500, 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. > > On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode < > use-livecode@lists.runrev.com> 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 < > > use-livecode@lists.runrev.com>, 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 < > > use-livecode@lists.runrev.com> 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 > > > 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 > > > ___ > 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: Differences between Commercial and Community versions of 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 < use-livecode@lists.runrev.com> 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 < > use-livecode@lists.runrev.com>, 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 < > use-livecode@lists.runrev.com> 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 > > 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 > ___ 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: Differences between Commercial and Community versions of 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 , 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 > > 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 > 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: Datagrid selectionChanged bug?
Trevor you are brilliant. Now that you put it that way, that is *exactly* what is happening. The datagrid works so seamlessly it's easy to forget it's not data I am working with but groups of objects that must be deleted and recreated as needed. Bob S > On Jun 5, 2018, at 21:50 , Trevor DeVore via use-livecode > wrote: > > On Tue, Jun 5, 2018 at 5:27 PM, Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> >> I suppose I can get around it by using send in time so the actual >> selectionChanged handler finishes before the cascade of form updates >> happens. But if it is a bug and shouldn't be happening, I suppose I should >> try to make a stack that reproduces it. (I may have already done so but I >> don't keep track of my own bug reports!) >> > > The issue you are seeing is probably caused by the inability of the engine > to delete the object that is the target of the current event. When you > replace the data grid contents during selectionChanged you are trying to > delete the control that was clicked on and trigger the selectionChanged > message. The engine doesn’t like that. You will need to use `send in time` > to accomplish what you are after. > > -- > 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: Differences between Commercial and Community versions of 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 > 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 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: Cheese
!??? Heather Laine Customer Services Manager LiveCode Ltd www.livecode.com > On 6 Jun 2018, at 14:18, Richmond Mathewson via use-livecode > wrote: > > Please ignore the previous post: something to do with too much . . . > > Richmond. > > On 6/6/2018 4:16 pm, Richmond Mathewson wrote: >> saadfs > > ___ > 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: Cheese
Please ignore the previous post: something to do with too much . . . Richmond. On 6/6/2018 4:16 pm, Richmond Mathewson wrote: saadfs ___ 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
Cheese
saadfs ___ 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: THOUGHT: the [effective] [working] screenLoc
Enhancement request: https://quality.livecode.com/show_bug.cgi?id=21337 ___ 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: Problems with jsonToArray and special chars like: æøå
Hi Tore,
Sorry, the line:
put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into tFile
should be:
put url ("file:" & specialFolderPath("resources")& "/Kommunedata.txt") into
tFile
Does it work now?
>although I am certain I should use textDecode when importing text to
LiveCode
Yes, this is correct. But I think in that case you want to export text from
LC into the outside world (e.g. to the mergJSON external), so the text has
to be utf8-encoded
If this does not work, could you file a bug with a sample stack and the
json file so as we investigate further
Best,
Panos
--
On Wed, Jun 6, 2018 at 1:06 PM, Tore Nilsen via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Hi Panos.
>
> This does not work, and it is somewhat similar to what I tried initially,
> although I am certain I should use textDecode when importing text to
> LiveCode, as per the Dictionary. Also note that tFile only holds the url to
> the file containing the JSON, and your suggestion only encodes the file
> path. The strange thing is that the text I try to import was encoded as
> “UTF-8” when it was initially exported from LiveCode. It shows up all right
> in all other applications that can read .txt files.
>
> When I do only a single run of text decoding, no array is created. When I
> do a double decoding, the array is created, but the chars in question does
> not show up in the keys of the array. Another thing that puzzles me is that
> som values, like -0.2 or -0.4 will show up with som additional zeros in the
> JSON-text. When I add a space between the minus operator and the number, it
> is displayed correctly.
>
> I am still at odd with what may be the cause of this.
>
> Regards Tore
>
> > 6. jun. 2018 kl. 13:40 skrev panagiotis merakos via use-livecode <
> use-livecode@lists.runrev.com>:
> >
> > on preOpenStack
> > put empty into kommuneArray
> > put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into
> > tFile
> > put textEncode(tFile,"UTF-8") into tData
> > put jsonToArray(tData) into kommuneArray
> > end preOpenStack
> >
> > Best,
> > Panos
> > --
>
> ___
> 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: Problems with jsonToArray and special chars like: æøå
Hi Panos.
This does not work, and it is somewhat similar to what I tried initially,
although I am certain I should use textDecode when importing text to LiveCode,
as per the Dictionary. Also note that tFile only holds the url to the file
containing the JSON, and your suggestion only encodes the file path. The
strange thing is that the text I try to import was encoded as “UTF-8” when it
was initially exported from LiveCode. It shows up all right in all other
applications that can read .txt files.
When I do only a single run of text decoding, no array is created. When I do a
double decoding, the array is created, but the chars in question does not show
up in the keys of the array. Another thing that puzzles me is that som values,
like -0.2 or -0.4 will show up with som additional zeros in the JSON-text. When
I add a space between the minus operator and the number, it is displayed
correctly.
I am still at odd with what may be the cause of this.
Regards Tore
> 6. jun. 2018 kl. 13:40 skrev panagiotis merakos via use-livecode
> :
>
> on preOpenStack
> put empty into kommuneArray
> put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into
> tFile
> put textEncode(tFile,"UTF-8") into tData
> put jsonToArray(tData) into kommuneArray
> end preOpenStack
>
> Best,
> Panos
> --
___
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: Problems with jsonToArray and special chars like: æøå
Hi Tore,
jsonToArray uses the mergJSON external. The mergJSON external expects the
data passed to JSONtoArray() to be utf-8 encoded (this is the case with any
LC external, such revDB etc).
So something like this should work:
global kommuneArray
on preOpenStack
put empty into kommuneArray
put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into
tFile
put textEncode(tFile,"UTF-8") into tData
put jsonToArray(tData) into kommuneArray
end preOpenStack
Best,
Panos
--
On Wed, Jun 6, 2018 at 11:16 AM, Tore Nilsen via use-livecode <
use-livecode@lists.runrev.com> wrote:
> I have run into a problem with jsonToArray and the special Norwegian chars
> æøå. They do not show up in the keys of the array when the array is made
> from an external file. The external file is generated by LiveCode and the
> arrayToJSON function. All text are encoded to “UTF-8” before the array is
> made and passed to arrayToJSON. The script I use to generate the array on
> start up is as follows:
>
> global kommuneArray
>
> on preOpenStack
>
> put empty into kommuneArray
>
> put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into
> tFile
>
> put textDecode(url tFile,"UTF-8") into tData
>
> put jsonToArray(textDecode(tData,"UTF-8")) into kommuneArray
>
> end preOpenStack
>
>
> The array generated contains all the right information, but keys that
> should include æ, ø or å do not show up correctly. Any ideas anyone?
>
> Best regards
> Tore Nilsen
>
>
> ___
> 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
Problems with jsonToArray and special chars like: æøå
I have run into a problem with jsonToArray and the special Norwegian chars æøå.
They do not show up in the keys of the array when the array is made from an
external file. The external file is generated by LiveCode and the arrayToJSON
function. All text are encoded to “UTF-8” before the array is made and passed
to arrayToJSON. The script I use to generate the array on start up is as
follows:
global kommuneArray
on preOpenStack
put empty into kommuneArray
put "file:" & specialFolderPath("resources")& "/Kommunedata.txt" into tFile
put textDecode(url tFile,"UTF-8") into tData
put jsonToArray(textDecode(tData,"UTF-8")) into kommuneArray
end preOpenStack
The array generated contains all the right information, but keys that should
include æ, ø or å do not show up correctly. Any ideas anyone?
Best regards
Tore Nilsen
___
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
