> On 17 Jul 2018, at 09:07, Norbert Hartl <norb...@hartl.name> wrote: > > > >> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand >> <hernan.mora...@gmail.com>: >> >> 2018-06-27 23:21 GMT-03:00 Otto Behrens <o...@finworks.biz>: >>> 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 <http://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 <http://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.
+1 Esteban > > 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 <tim@testit.works> 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 >>>>> <hernan.mora...@gmail.com> wrote: >>>>> >>>>> 2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu...@gmail.com>: >>>>>>> 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
