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

Mike Bonner bonnmike at gmail.com
Wed Jan 21 13:05:32 EST 2015 

yeah, same thing as source, I forgot you could . it

On Wed, Jan 21, 2015 at 10:06 AM, Peter Haworth <pete at lcsql.com> wrote:

> Courtesy of Dariusz Miedzianogora a while back on this list:
>
>
> "You could try the following command in the shell call:
>
> . ~/.profile;<your unix command>
>
> The first dot (.) executes the next file. The ~ (tilde) is a shortcut to
> the home directory of the user. Since .profile is a shell script that is
> executed when the user logs in, this will rerun the .profile script in the
> local shell, and you should get the updated path. The semi-colon means that
> the command continues, so you can then execute your shell command in the
> process instance (and thus the shell instance) that you just refreshed. "
>
>
> On Jan 21, 2015 8:42 AM, "Mike Bonner" <bonnmike at gmail.com> wrote:
>
> > 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
> > >
> > _______________________________________________
> > 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