pharo bash script with startup

Am 27.06.2018 um 09:38 schrieb Otto Behrens <[hidden email]>:

I am running with an absolute image path. 

The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works. 

/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st"

gives me the same problem

On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <[hidden email]> wrote:

Try with ./pharo or try with an absolute image path.

On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <[hidden email]> wrote:

I’ve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.

Sent from my iPhone

On 27 Jun 2018, at 07:30, Otto Behrens <[hidden email]> wrote:

Hi,

I just installed pharo 6.1 using the .zip file (http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.

The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:

# execute

exec "$LINUX/pharo" \

        --plugins "$LINUX" \

        --encoding utf8 \

        -vm-display-X11 \

        "$image"

where

image = $*

The impact is that if I want to run a startup script, eg.

pharo my.image startup.st

pharo complains with "Could not open the Pharo image file: 'my.image startup.st'

So I must run the executable directly?

If so, some questions about the options that the bash script passes in:

--plugins "$LINUX"    is this necessary? will the default not be enough?

--encoding utf8          the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing?

-vm-display-X11        I tried starting without this, and it worked. Do I need to explicitly start with this?

Thanks

Otto

On 17 Jul 2018, at 09:07, Norbert Hartl <[hidden email]> wrote:

Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <[hidden email]>:

2018-06-27 23:21 GMT-03:00 Otto Behrens <[hidden email]>:

Thanks for the effort guys.

I tried to download the image, sources and vm separately (basically
extracted what https://get.pharo.org/64/61+vm does), but ran into fresh
trouble.

Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in
terms of security? It should be quite possible to inject a lovely trojan
horse with this, or not?

Yes, this is possible:

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

I like this kind of articles because it proofs every time how less people know about security.  If it comes to security eyerone goes hysterical. 
The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next.

But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org. If this is the case I can also make the client download a different image with malicious code or a vm or ..
Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesn‘t mean it is safe.

Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.

Norbert

Secondly, the pharo bash script that it generates is different to the one in
the zip. The directory structure (where the image & vm goes) is also
different. Why is that?

I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with
the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got
the following, which I tried to do, but that did not take the message away:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat <<END | sudo tee /etc/security/limits.d/pharo.conf
*      hard    rtprio  2
*      soft    rtprio  2
END

and report to the pharo mailing list whether this improves behaviour.

You will need to log out and log back in for the limits to take effect.

(I did do this).

I reverted to the deb package for now, because this have take some time and
I can't focus on it now.

I'll give it another shot soon, I hope

On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <[hidden email]> wrote:

When we get confirmation of success - we need to make sure this gets
applied to both zeroconf and official downloads.

Anything we can do to simplify and make it robust is gratefully
appreciated as there is nothing worse than falling at the lunch hurdle.

It’s cool to see so many clever minds on this.

Tim

Sent from my iPhone

On 27 Jun 2018, at 19:52, Hernán Morales Durand
<[hidden email]> wrote:

2018-06-27 10:50 GMT-03:00 K K Subbu <[hidden email]>:

On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:


The double quotes are required here to skip splitting arguments with
embedded spaces into different words.

I suspect the error is earlier in the image=$@ assignment. This
requires
double quotes. Double quotes are also required while calling zenity to
avoid
word splitting.

My earlier fix is also in error, Sorry!

Essentially, we are mixing up single value variable (image) with
argument
array ($@). I found a cleaner fix :

````
if [ $# -eq 0 ]; then
     image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
     if [ "$image_count"  -eq 1 ]; then
             set -- "$RESOURCES"/*.image
     elif which zenity &>/dev/null; then
             set -- "$(zenity --title 'Select an image'
--file-selection
--filename "$RESOURCES/" --file-filter '*.image' --file-
filter '*')"
     else
             set -- "$RESOURCES/Pharo6.1-64.image"
     fi
fi

Use $() instead of backticks for command substitution:
http://mywiki.wooledge.org/BashFAQ/082

Cheers,

Hernán

# execute
exec "$LINUX/pharo" \
     --plugins "$LINUX" \
     --encoding utf8 \
     -vm-display-X11 \
     "$@"
````

HTH .. Subbu

Am 17.07.2018 um 17:31 schrieb Hernán Morales Durand <[hidden email]>:

2018-07-17 4:07 GMT-03:00 Norbert Hartl <[hidden email]>:

Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <[hidden email]>:

2018-06-27 23:21 GMT-03:00 Otto Behrens <[hidden email]>:

Thanks for the effort guys.

I tried to download the image, sources and vm separately (basically
extracted what https://get.pharo.org/64/61+vm does), but ran into fresh
trouble.

Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in
terms of security? It should be quite possible to inject a lovely trojan
horse with this, or not?

Yes, this is possible:

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

I like this kind of articles because it proofs every time how less people know about security.  If it comes to security eyerone goes hysterical.
The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next.

Well, you have a case: "People telling people to execute arbitrary
code over the network" : https://curlpipesh.tumblr.com/ ;)

When it comes to security, it is better to keep humble. Even the guys
behind cryptographic functions got caught, so it is better to follow
the best practices around, at least in a really complex domain as
security.
You don't need a big script to get fooled, have a look at
http://people.zoy.org/~sam/filsdepute.txt and copy-paste its contents
in a text editor.

But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org. If this is the case I can also make the client download a different image with malicious code or a vm or ..
Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesn‘t mean it is safe.

Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.

We don't agree this time Norbert. Even without a real scenario the
theoretical problem is enough. Two examples are: 1) In security if a
vector is prone to attacks, with a success probability, then could be
considered obsolete or weak, and weakness increases over time (SHA-1,
SHA-2). As computer speeds gets faster, they just calculate an
algorithm resistance and estimate its life-expectancy. 2) People use
package managers precisely because is a delivery mechanism which
transfer the burden of trust from the Pharo maintainers to the package
manager (which verify signatures). That without counting the pleasure
of deniability if an installation got compromised :)

Cheers

Hernán

Norbert

Secondly, the pharo bash script that it generates is different to the one in
the zip. The directory structure (where the image & vm goes) is also
different. Why is that?

I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with
the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got
the following, which I tried to do, but that did not take the message away:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat <<END | sudo tee /etc/security/limits.d/pharo.conf
*      hard    rtprio  2
*      soft    rtprio  2
END

and report to the pharo mailing list whether this improves behaviour.

You will need to log out and log back in for the limits to take effect.

(I did do this).

I reverted to the deb package for now, because this have take some time and
I can't focus on it now.

I'll give it another shot soon, I hope

On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <[hidden email]> wrote:

When we get confirmation of success - we need to make sure this gets
applied to both zeroconf and official downloads.

Anything we can do to simplify and make it robust is gratefully
appreciated as there is nothing worse than falling at the lunch hurdle.

It’s cool to see so many clever minds on this.

Tim

Sent from my iPhone

On 27 Jun 2018, at 19:52, Hernán Morales Durand
<[hidden email]> wrote:

2018-06-27 10:50 GMT-03:00 K K Subbu <[hidden email]>:

On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:


The double quotes are required here to skip splitting arguments with
embedded spaces into different words.

I suspect the error is earlier in the image=$@ assignment. This
requires
double quotes. Double quotes are also required while calling zenity to
avoid
word splitting.

My earlier fix is also in error, Sorry!

Essentially, we are mixing up single value variable (image) with
argument
array ($@). I found a cleaner fix :

````
if [ $# -eq 0 ]; then
     image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l`
     if [ "$image_count"  -eq 1 ]; then
             set -- "$RESOURCES"/*.image
     elif which zenity &>/dev/null; then
             set -- "$(zenity --title 'Select an image'
--file-selection
--filename "$RESOURCES/" --file-filter '*.image' --file-
filter '*')"
     else
             set -- "$RESOURCES/Pharo6.1-64.image"
     fi
fi

Use $() instead of backticks for command substitution:
http://mywiki.wooledge.org/BashFAQ/082

Cheers,

Hernán

# execute
exec "$LINUX/pharo" \
     --plugins "$LINUX" \
     --encoding utf8 \
     -vm-display-X11 \
     "$@"
````

HTH .. Subbu