[Probably OT] Strange loss of ability to do SSL (through curl)

Mike Bonner bonnmike at gmail.com
Wed Jan 21 11:42:01 EST 2015


You might check to see the environment variables from the command line, and
via lc shell, and do a comparison.  If I recall correctly, lc shell
environment and the environment you get in a terminal or console can
differ.  If the lc shell is using bash, and you know which files are
processed when a terminal session starts, you can "source" them.  Source is
a built in command that processes the file you give it. So if you have a
file .bashrc in your home directory that has the required env variables set
up you could get shell("source /path/to/my/home/.bashrc; the rest of your
commands here" )

If you can figure out what env variables are missing, but required for what
you want to do, you can probably include them at the top of your curl ssl
script file

On Wed, Jan 21, 2015 at 8:39 AM, Bob Sneidar <bobsneidar at iotecdigital.com>
wrote:

> Use the sudo command. Sudo allows an administrator account to masquerade
> as root. You will need to provide the current login password when you do
> this. I have successfully put the password as a second line in a terminal
> command. The current login must be an administrator.
>
> Bob S
>
>
> > On Jan 21, 2015, at 07:17 , Ben Rubinstein <benr_mc at cogapp.com> wrote:
> >
> > Bob,
> >
> > Thanks for replying - I suspect you're right as to the immediate cause
> and where something has changed (it might just be about a new certificate,
> for example).
> >
> > However, my real question is why it works in terminal but not using LC
> "shell"; although calling the same service does work via LC "shell" on my
> dev machine (including as a standalone).
> >
> > Where can one affect the context in which a shell command is executing?
> >
> > thanks,
> >
> > Ben
> >
> > On 20/01/2015 19:12, Bob Sneidar wrote:
> >> I suspect whatever system you are connecting to has modified in some
> way how it encrypts data using SSL. Sounds crazy, but Microsoft recently
> did something to their TLS in their cloud offerings that summarily
> prevented an entire series of Konica brand copiers from sending email
> through Exchange Online. Other series Konicas were fine, and other
> manufacturers didn’t seem to have a problem either. I was the only one
> saying Microsoft had made changes to their TLS. No one would listen, citing
> all the other copiers that still worked.
> >>
> >> Finally Konica released a bulletin telling us to install special
> firmware and make some changes in the security settings on the affected
> machines. What settings you ask? Why, the TLS settings of course!
> >>
> >> Bob S
> >>
> >>
> >>> On Jan 20, 2015, at 10:59 , Ben Rubinstein <benr_mc at cogapp.com> wrote:
> >>>
> >>> An app built in LC, sitting on an old box (PPC Mac Mini running
> 10.4.11) has for several years happily been running a few times a day to
> perform a batch job involving retrieve some data from a remote system,
> processing it, and pushing a report to a new location.
> >>>
> >>> Recently, it's not been updating correctly, and investigation has
> shown that the cause is a failure to retrieve the remote data.
> >>>
> >>> The remote system (a third-party SaaS product) has a REST interface,
> accessed with simple basic authentication over HTTPS.  I'm not aware that
> anything has changed in their API recently.
> >>>
> >>> When I first wrote this app, I found that LC didn't correctly deal
> with the SSL portion (I forget the details); so I recoded it to use the
> shell function to invoke curl to retrieve each element.
> >>>
> >>> This has worked fine for a long time.   But now the shell command is
> returning code 35, which according to man curl is:
> >>>  35     SSL connect error. The SSL handshaking failed.
> >>>
> >>> So the weird thing is:
> >>> - if I run this app on my dev machine (Intel Mac running 10.8.5), it
> works fine, happily invoking curl and getting the result
> >>> - if I run the curl command in Terminal on the target machine, it
> works fine and retrieves the data
> >>> - if I create a shell script to run the curl command on the target
> machine, and invoke that shell script in Terminal, it works fine and
> retrieves the data
> >>> - if I modify the app to use 'shell' to run that shell script, instead
> of calling curl directly, it fails with code 35 again.
> >>>
> >>> So curl, and shell, are happy on that machine; but using shell in an
> LC app to either invoke curl directly, or run a batch script which invokes
> curl, makes SSL fail.
> >>>
> >>> I've marked this possibly OT because I don't think it's necessarily an
> LC problem.  I get the same result with a version of the app built in 2011
> from LC 4.6.4 as with one built now with LC 6.5.2.  But then again, I'm not
> aware that anything has changed on the machine where this runs.
> >>>
> >>> Something must have changed; my guess is that it is something in the
> setup of the remote service.  But the nature of that change doesn't disturb
> curl or shell running under Terminal on my target machine; nor when invoked
> from LC on my dev machine.
> >>>
> >>> I'm guessing it must be something to do with the environment in which
> the shell command operates when invoked from LC, as opposed to launching a
> terminal window.  This goes considerably outside my knowledge area, so I'm
> appealing for suggestions as to where to investigate...
> >>>
> >>> TIA
> >>>
> >>> Ben
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list