Date   

Re: Is i possible hide AppleScript "do shell script" commands from bash/bash history?

David Wegener laptop
 


On Dec 29, 2017, at 5:46 PM, Deivy Petrescu <applescript@...> wrote:


On Dec 28, 2017, at 09:48 , davew@... wrote:

I was recommended to come here, by some knowledgeable folks on a Filemaker Pro forum.
So, I'm using some older versions in an active filemaker solution (FMPA 13, 14, 15), and need to enhance some security features.
This is within a database solution that's 'in the wild', on customers' Macs around the world. We don't really want them being able to view certain encrypted data nuggets (which may need to be sent back & forth via email).  And for certain other reasons, we can't force an upgrade to a different database version (with built-in encryption)..
So, to accomplish this, I use Applescript to pass data from a field into an openssl shell for encryption, then put results into an encrypted data field..
Calculated AppleScript here:
"property targetCell: \"cp_thisismyencrypteddatafield\" ¶
set theResult to do shell script \"echo " & cp_thisismydatasourcefield & " | openssl aes-256-cbc -k thisisMYP5SSW0rd! -base64\" ¶
copy theResult to cell targetCell of current record”

So, this work perfectly well, in that I'm able to pass both data and a password into openssl for encryption, and pass back.
My concern is this: is this action visible to prying eyes?  I've been given multiple conflicting answers from multiple 'experts', but would really appreciate someone who actually **IS** an expert to confirm or deny the security of this..
I thought perhaps I could see the command thru ./bash_history, but it doesn't show up.. Nor does it in any console logs that I can find... nor in 'history' (as either a user or as root). Some folks have said that a 'do shell script' (being non-interactive) is shielded from bash history...


But all of this is moot without something definitive - I am concerned that a well-informed hacker can perform some level of 'ps aux' at some point and actually see (or log) that shell script going by... is that so?


1. IF it can be logged or viewed, how?  Can I replicate that action (to prove/disprove it)?
2. IF it can be viewed, is there another (better) way to do this, without any plug-ins (yeah, i'm biased against 3rd party plug-ins), which would hide it from sight/log?
3. IF it IS hidden, (but I created a variable  - theResult), is theResult visible anywhere (or could someone simply dump that variable into plaintext somehow)?  Or does that variable self-flush when I end the script?
Thanks for any definitive clarity on this!


Dave, you will not be able to see the command in your Terminal. 
do shell script does not use Terminal to send it commands, so it is sheltered from Terminal’s command  history.
However, thisisMYP5SSW0rd! is legible in the script, meaning if you “open” the script on a text editor, it will be there for everyone to see.
There was a big discussion here and Shane managed to break all the passwords.
May be something has changed, but I don’t think so.

I am thinking of a way to save passwords securely on an AS, but haven’t worked on that yet!


Deivy Petrescu
applescript@...

Delvy

Thanks for the followup on that.
my particular application of this is within a Filemaker Pro process - a script which runs this applescript in the background.  The user never sees the actual script (or even that it’s an applescript).
So (it sounds to me) then it will be impossible for anyone to actually see the password or the actual process?

tx


Re: Is i possible hide AppleScript "do shell script" commands from bash/bash history?

Shane Stanley
 

On 30 Dec 2017, at 9:46 am, Deivy Petrescu <applescript@dicas.com> wrote:

However, thisisMYP5SSW0rd! is legible in the script, meaning if you “open” the script on a text editor, it will be there for everyone to see.
There was a big discussion here and Shane managed to break all the passwords.
May be something has changed, but I don’t think so.
There is a way around that issue: stop the script from storing its properties and top-level variable values. That means doing something like changing its privileges, code-signing it, or even using a top-level ASObjC variable. Of course that assumes the script doesn't otherwise rely on property persistence.

I am thinking of a way to save passwords securely on an AS, but haven’t worked on that yet!
Store it in a keychain?

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: Is i possible hide AppleScript "do shell script" commands from bash/bash history?

Deivy Petrescu
 

On Dec 28, 2017, at 09:48 , davew@wegenermedia.com wrote:

I was recommended to come here, by some knowledgeable folks on a Filemaker Pro forum.

So, I'm using some older versions in an active filemaker solution (FMPA 13, 14, 15), and need to enhance some security features.


This is within a database solution that's 'in the wild', on customers' Macs around the world. We don't really want them being able to view certain encrypted data nuggets (which may need to be sent back & forth via email). And for certain other reasons, we can't force an upgrade to a different database version (with built-in encryption)..


So, to accomplish this, I use Applescript to pass data from a field into an openssl shell for encryption, then put results into an encrypted data field..


Calculated AppleScript here:

"property targetCell: \"cp_thisismyencrypteddatafield\" ¶

set theResult to do shell script \"echo " & cp_thisismydatasourcefield & " | openssl aes-256-cbc -k thisisMYP5SSW0rd! -base64\" ¶

copy theResult to cell targetCell of current record"


So, this work perfectly well, in that I'm able to pass both data and a password into openssl for encryption, and pass back.


My concern is this: is this action visible to prying eyes? I've been given multiple conflicting answers from multiple 'experts', but would really appreciate someone who actually **IS** an expert to confirm or deny the security of this..


I thought perhaps I could see the command thru ./bash_history, but it doesn't show up.. Nor does it in any console logs that I can find... nor in 'history' (as either a user or as root). Some folks have said that a 'do shell script' (being non-interactive) is shielded from bash history...


But all of this is moot without something definitive - I am concerned that a well-informed hacker can perform some level of 'ps aux' at some point and actually see (or log) that shell script going by... is that so?


1. IF it can be logged or viewed, how? Can I replicate that action (to prove/disprove it)?

2. IF it can be viewed, is there another (better) way to do this, without any plug-ins (yeah, i'm biased against 3rd party plug-ins), which would hide it from sight/log?

3. IF it IS hidden, (but I created a variable - theResult), is theResult visible anywhere (or could someone simply dump that variable into plaintext somehow)? Or does that variable self-flush when I end the script?


Thanks for any definitive clarity on this!
Dave, you will not be able to see the command in your Terminal.
do shell script does not use Terminal to send it commands, so it is sheltered from Terminal’s command history.
However, thisisMYP5SSW0rd! is legible in the script, meaning if you “open” the script on a text editor, it will be there for everyone to see.
There was a big discussion here and Shane managed to break all the passwords.
May be something has changed, but I don’t think so.

I am thinking of a way to save passwords securely on an AS, but haven’t worked on that yet!


Deivy Petrescu
applescript@dicas.com


Is i possible hide AppleScript "do shell script" commands from bash/bash history?

David Wegener laptop
 

I was recommended to come here, by some knowledgeable folks on a Filemaker Pro forum.

So, I'm using some older versions in an active filemaker solution (FMPA 13, 14, 15), and need to enhance some security features.

 
This is within a database solution that's 'in the wild', on customers' Macs around the world. We don't really want them being able to view certain encrypted data nuggets (which may need to be sent back & forth via email).  And for certain other reasons, we can't force an upgrade to a different database version (with built-in encryption)..

 

So, to accomplish this, I use Applescript to pass data from a field into an openssl shell for encryption, then put results into an encrypted data field..

 

Calculated AppleScript here:

"property targetCell: \"cp_thisismyencrypteddatafield\" ¶

set theResult to do shell script \"echo " & cp_thisismydatasourcefield & " | openssl aes-256-cbc -k thisisMYP5SSW0rd! -base64\" ¶

copy theResult to cell targetCell of current record"

 

So, this work perfectly well, in that I'm able to pass both data and a password into openssl for encryption, and pass back.

 

My concern is this: is this action visible to prying eyes?  I've been given multiple conflicting answers from multiple 'experts', but would really appreciate someone who actually **IS** an expert to confirm or deny the security of this..

 

I thought perhaps I could see the command thru ./bash_history, but it doesn't show up.. Nor does it in any console logs that I can find... nor in 'history' (as either a user or as root). Some folks have said that a 'do shell script' (being non-interactive) is shielded from bash history...

 

But all of this is moot without something definitive - I am concerned that a well-informed hacker can perform some level of 'ps aux' at some point and actually see (or log) that shell script going by... is that so?

 

1. IF it can be logged or viewed, how?  Can I replicate that action (to prove/disprove it)?

2. IF it can be viewed, is there another (better) way to do this, without any plug-ins (yeah, i'm biased against 3rd party plug-ins), which would hide it from sight/log?

3. IF it IS hidden, (but I created a variable  - theResult), is theResult visible anywhere (or could someone simply dump that variable into plaintext somehow)?  Or does that variable self-flush when I end the script?

 

Thanks for any definitive clarity on this!



Re: relative paths etc...

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Dec 27, 2017, at 20:56, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 27 Dec 2017, at 8:59 pm, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

I just want to know if there is a way to accomplish that that does not involve weird (path as string) manipulations...
I guess it depends on your definition of weird.

set fullPath to "/path/to/folder/path/from/folder/file"
set rootPath to "/path/to/folder"
set relpath to "." & text ((length of rootPath) + 1) thru -1 of fullPath
That pretty much fits my definition :)

But thank you. I'll see which of your approach and Yves is easier to fit in my code and will probably come back here for further hints.

In the meanwhile, I hope you all have nice holidays.

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: relative paths etc...

Shane Stanley
 

On 27 Dec 2017, at 8:59 pm, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I just want to know if there is a way to accomplish that that does not involve weird (path as string) manipulations...

I guess it depends on your definition of weird.

set fullPath to "/path/to/folder/path/from/folder/file"
set rootPath to "/path/to/folder"
set relpath to "." & text ((length of rootPath) + 1) thru -1 of fullPath



relative paths etc...

Jean-Christophe Helary <jean.christophe.helary@...>
 

I seem to be wasting a lot of time on something that may already exist...

I'm trying to find a way to add/subtract paths to files.

Like, I have a path from / and I want to subtract it from the path to a given file so that I end up with a path relative to the end of the first path. Sorry it it's not clear:

original path:
/path/to/folder

path to subtract it from:
/path/to/folder/path/from/folder/file

result:
./path/from/folder/file

the idea being that I need to cd to the shortest path and work on the files *relative to that position*.

I just want to know if there is a way to accomplish that that does not involve weird (path as string) manipulations...

(I spent the whole morning fighting with the "a reference to" and I'm still bleeding)

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: Accelerator keys in displayed buttons

Peter Gort
 

Actually, once a control has focus, tapping the space bar will action that control, and once you are used to this, it means you don’t have to move your hand from the keyboard to the mouse nearly as often.  I make use of this when scripting the interface, often when sending a click event to a button whose associated action creates a new window, interface scripting pauses for 5 seconds after the window is drawn, then resumes the script.  However typing a space actions the control and the 5 second pause does not happen.  Weird but true.

Peter Gort

On 26 Dec 2017, at 9:20 am, Shane Stanley <sstanley@...> wrote:

In many cases tabbing highlights a control, but you still have to click on it to make it do anything.


Re: Accelerator keys in displayed buttons

Shane Stanley
 

On 26 Dec 2017, at 2:33 am, Robert Poland <rpoland@usa.net> wrote:

Could you elaborate on the side-effects you are referred to?
The main thing it does is destroys the tabbing order. By default, tabbing takes you through the fields of a dialog in a left-to-right/top-to-bottom order, but in more complex dialogs developers often override this to provide a more logical flow. As soon as you turn on Full Keyboard Access, that goes out the window. And for what? In many cases tabbing highlights a control, but you still have to click on it to make it do anything.

It should be useful, but it's poorly implemented.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: Accelerator keys in displayed buttons

Robert Poland
 

Shane,

Could you elaborate on the side-effects you are referred to?

I haven’t noticed anything.

On Dec 24, 2017, at 6:13 PM, Shane Stanley <sstanley@...> wrote:

On 25 Dec 2017, at 11:20 am, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Tab won't change the focus.

It will if you go to Preferences -> Keyboard -> Shortcuts and change Full Keyboard Access to All controls. But if you do so, you'll probably also find the side-effects more annoying than it's worth.

--
Shane Stanley <sstanley@...>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>

Robert Poland
iMac, Late 2013, 14,2
  3.2 GHz Intel Core I5, 27” 
  16 GB Ram, 1TB Fusion HD
  OS X 10.13.2 (High Sierra)


Re: Accelerator keys in displayed buttons

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Dec 25, 2017, at 11:59, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 25 Dec 2017, at 1:34 pm, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

I'm pretty sure I've seen them in other places too
Those I mentioned are just the built-in defaults. Custom shortcuts can be applied to any buttons -- just not using "display dialog" or "display alert".
Ok.

A simple example is my Dialog Toolkit Plus library. Here's the Simple sample.scpt file that ships with it:
Thank you!


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: Accelerator keys in displayed buttons

Shane Stanley
 

On 25 Dec 2017, at 1:34 pm, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I'm pretty sure I've seen them in other places too

Those I mentioned are just the built-in defaults. Custom shortcuts can be applied to any buttons -- just not using "display dialog" or "display alert".

A simple example is my Dialog Toolkit Plus library. Here's the Simple sample.scpt file that ships with it:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use script "Dialog Toolkit Plus" version "1.0"

set accViewWidth to 650
set {theButtons, minWidth} to create buttons {"Cancel", "Five", "Four", "Three", "Two", "One", "OK"} button keys {"", "5", "4", "3", "2", "1", ""} cancel button 1 default button 7
if minWidth > accViewWidth then set accViewWidth to minWidth -- make sure buttons fit
set {theField, theTop} to create field "" placeholder text "Enter your text here" bottom 0 field width accViewWidth extra height 60 with accepts linebreak and tab
set {boldLabel, theTop} to create label "How many buttons would you like? There's no real limit except for practical and aesthetic considerations." & return & "Of course, I hope you'll never really think about using something as ugly as this!" & return & return & "Choose your heart out!" & return & return & "Also, try the command-1 thru command-5 button shortcuts." bottom theTop + 20 max width accViewWidth control size regular size
set {buttonName, controlsResults} to display enhanced window "Many Buttons" acc view width accViewWidth acc view height theTop acc view controls {theField, boldLabel} button list theButtons active field theField initial position {0, 0} with align cancel button


Return being the default button, right ?

Yes.



Re: Accelerator keys in displayed buttons

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Dec 25, 2017, at 11:11, Shane Stanley <sstanley@myriad-com.com.au> wrote:

Maybe not all, but some buttons can be accessed by hitting Cmd+the first letter, or something like this. It used to be that a TextEdit dialog reacted to Cmd+D for Delete, but now it is "Change location to Desktop", etc.
I suspect you're thinking of "Don't Save". Alerts are hard-wired by default to map escape/command-. to Cancel, return to OK, and command-D to Don't Save:

display alert "Test" buttons {"Cancel", "Don't Save", "OK"}
Ok. I'm pretty sure I've seen them in other places too, but I'm fine with your answer.

Anyway, normal or not, that's the kind of thing I'd like to implement. Is that possible?
Not in standard AppleScript, no -- you can map the buttons that respond to escape/command-. and return, but that's all.
Return being the default button, right ?


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: Accelerator keys in displayed buttons

Shane Stanley
 

On 25 Dec 2017, at 1:03 pm, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Maybe not all, but some buttons can be accessed by hitting Cmd+the first letter, or something like this. It used to be that a TextEdit dialog reacted to Cmd+D for Delete, but now it is "Change location to Desktop", etc.

I suspect you're thinking of "Don't Save".  Alerts are hard-wired by default to map escape/command-. to Cancel, return to OK, and command-D to Don't Save:

display alert "Test" buttons {"Cancel", "Don't Save", "OK"}

Anyway, normal or not, that's the kind of thing I'd like to implement. Is that possible?

Not in standard AppleScript, no -- you can map the buttons that respond to escape/command-. and return, but that's all.



Re: Accelerator keys in displayed buttons

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Dec 25, 2017, at 10:56, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 25 Dec 2017, at 12:22 pm, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

I'd like to have something that acts as normal Mac dialogs.
"Normal" Mac dialogs don't show keyboard equivalents.
Maybe not all, but some buttons can be accessed by hitting Cmd+the first letter, or something like this. It used to be that a TextEdit dialog reacted to Cmd+D for Delete, but now it is "Change location to Desktop", etc.

Anyway, normal or not, that's the kind of thing I'd like to implement. Is that possible?


Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: Accelerator keys in displayed buttons

Shane Stanley
 

On 25 Dec 2017, at 12:22 pm, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

I'd like to have something that acts as normal Mac dialogs.
"Normal" Mac dialogs don't show keyboard equivalents.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: Accelerator keys in displayed buttons

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Dec 25, 2017, at 10:13, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 25 Dec 2017, at 11:20 am, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

Tab won't change the focus.
It will if you go to Preferences -> Keyboard -> Shortcuts and change Full Keyboard Access to All controls. But if you do so, you'll probably also find the side-effects more annoying than it's worth.
Yes, but that's not what there is in normal Mac apps, or am I wrong?
I'd like to have something that acts as normal Mac dialogs. Is that possible?



Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com


Re: Accelerator keys in displayed buttons

Shane Stanley
 

On 25 Dec 2017, at 11:20 am, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

Tab won't change the focus.
It will if you go to Preferences -> Keyboard -> Shortcuts and change Full Keyboard Access to All controls. But if you do so, you'll probably also find the side-effects more annoying than it's worth.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: Accelerator keys in displayed buttons

Jean-Christophe Helary <jean.christophe.helary@...>
 

Not in 10.13 on my machine. Tab won't change the focus.

Jean-Christophe

Dec 25, 2017 8:39、Robert Poland <rpoland@usa.net>のメール:

This script works as I said with OS10.13.2.

display dialog "See the pretty buttons!" buttons {"Cancel", "OK", "Some other button"} cancel button "Cancel" default button "OK"

On Dec 24, 2017, at 2:57 PM, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

Dec 25, 2017 2:40、Robert Poland <rpoland@usa.net>のメール:

It appears that NOW you can use the Tab key to select which button you want then hit return to activate it.
Not on dialogs created with "display dialog". Or not on 10.13. Anyway, my "display dialog" buttons are stuck in the state I define and I can't move around them with the keyboard. Only when I define a cancel button is "esc" registered also to that button.

Jean-Christophe


Re: Accelerator keys in displayed buttons

Robert Poland
 

This script works as I said with OS10.13.2.

display dialog "See the pretty buttons!" buttons {"Cancel", "OK", "Some other button"} cancel button "Cancel" default button "OK"

On Dec 24, 2017, at 2:57 PM, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Dec 25, 2017 2:40、Robert Poland <rpoland@...>のメール:

It appears that NOW you can use the Tab key to select which button you want then hit return to activate it.

Not on dialogs created with "display dialog". Or not on 10.13. Anyway, my "display dialog" buttons are stuck in the state I define and I can't move around them with the keyboard. Only when I define a cancel button is "esc" registered also to that button.

Jean-Christophe

On Dec 24, 2017, at 7:57 AM, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Sorry for the inappropriate term use.

I mean when you have a normal dialog on Mac and you can access the button with a keyboard combination without having to click on the buttons.

Jean-Christophe

Dec 24, 2017 22:58、Robert Poland <rpoland@...>のメール:

Since accelerator keys “ are a PC function, I’m confused by your request. Are you using a Mac or a PC. Which model and OS.

If a Mac, look into Keyboard Maestro. https://www.keyboardmaestro.com/main/

On Dec 24, 2017, at 12:50 AM, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I'm wondering if it's possible to set accelerator keys to access displayed buttons from the keyboard, instead of having to use the mouse.

For ex: buttons {"Action", "Reaction"} where hitting "A" on the keyboard would trigger "Action" and "R" "Reaction...

Jean-Christophe Helary
-----------------------------------------------
@brandelune http://mac4translators.blogspot.com

Robert Poland
Fort Collins, CO

81 - 100 of 275