Re: [Pharo-users] pharo bash script with startup

[Norbert Hartl]

> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand 
> :
> 
> 2018-06-27 23:21 GMT-03:00 Otto Behrens :
>> 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 <> *  hardrtprio  2
>> *  softrtprio  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  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
  wrote:
 
 2018-06-27 10:50 GMT-03:00 K K Subbu :
>> 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
> 
 
>>> 
>>> 
>> 
> 

Re: [Pharo-users] pharo bash script with startup

[Esteban Lorenzano]

> On 17 Jul 2018, at 09:07, Norbert Hartl  wrote:
> 
> 
> 
>> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand 
>> :
>> 
>> 2018-06-27 23:21 GMT-03:00 Otto Behrens :
>>> 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.

+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 <>> *  hardrtprio  2
>>> *  softrtprio  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  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
>  wrote:
> 
> 2018-06-27 10:50 GMT-03:00 K K Subbu :
>>> 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 "$

Re: [Pharo-users] Iceberg issue on Ubuntu 16.04.3 Pharo 6.1

[Juraj Kubelka via Pharo-users]

--- Begin Message ---
Hi Guillermo,

Thank you for the explanation. I have noticed that if I use  
https://get.pharo.org/64/vm61  instead of 
64/vmI61 (__I__ letter) it works. The same happens for Pharo 7.0. 

Cheers,
Juraj

> On Jul 17, 2018, at 04:33, Guillermo Polito  wrote:
> 
> Hi Juraj,
> 
> The version of Iceberg in Pharo 6.1 is just a preview and we have decided so 
> far that we will not update it so far to avoid disrupting people using 
> Pharo6.1 for business.
> Also, iceberg development has moved forward a lot on Pharo7, I don't think 
> that a "simple fix" could be just backported.
> 
> Maybe you can try instead to upgrade your pharo6.1 image with latest iceberg? 
> Try using the script in iceberg's readme.
> 
> On Tue, Jul 17, 2018 at 2:58 AM Juraj Kubelka via Pharo-users 
> mailto:pharo-users@lists.pharo.org>> wrote:
> Hi, 
> 
> I am trying to build a project in ubuntu 16.04.3. To this:
>   - I downloaded Pharo 6.1 (60541) 64bit
>   - I open the Pharo image and execute:
> 
> Metacello new
>baseline: 'GToolkit';
>repository: ' <>github://feenkcom/gtoolkit/src 
> ';
>load.
>   
> I have the following issue: LGit_GIT_ERROR: SSL error: error:140E0197:SSL 
> routines:SSL_shutdown:shutdown while in init
> The full stack is below. 
> I can clone the repository from a terminal using: git clone g...@github.com 
> :feenkcom/gtoolkit.git
> I believe that my settings are correct (same that I use on macOS): 
> 
> 
> 
> 
> Is Iceberg suppose to work on Ubuntu 16.04.3 64bit?
> I have noticed that it works in Pharo 7 64bit (excluding the fact gtoolkit 
> does not work in Pharo 7 yet).
> I found this bug report that might be related: 
> https://github.com/libgit2/libgit2/issues/4644 
>  
> 
> Thanks!
> Juraj
> 
> 
> Full stack:
> 
> LGitReturnCodeEnum>>handleLGitReturnCode
> LGitRepository(LGitExternalObject)>>withReturnHandlerDo:
> LGitRepository>>clone:options:to:
> LGitRepository>>clone:options:
> [ repo clone: url options: cloneOptions ] in [ | repo cloneOptions |
> repo := LGitRepository on: self location.
> cloneOptions := LGitCloneOptions
>   withCredentialsProvider: IceCredentialsProvider default.
> cloneOptions checkoutOptions
>   checkoutStrategy: LGitCheckoutStrategyEnum git_checkout_none.
> [ repo clone: url options: cloneOptions ]
>   on: LGit_GIT_ERROR
>   do: [ :e | e acceptError: IceLibgitErrorVisitor new ].
> repo
>   checkout:
>   (aBranchName
>   ifNil:
>   [ self branch ifNotNil: [ :b | b name ] ifNil: 
> [ 'master' ] ]).
> (LGitRemote of: repo named: 'origin')
>   lookup;
>   setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: 
> in Block: [ repo clone: url options: cloneOptions ]
> BlockClosure>>on:do:
> [ | repo cloneOptions |
> repo := LGitRepository on: self location.
> cloneOptions := LGitCloneOptions
>   withCredentialsProvider: IceCredentialsProvider default.
> cloneOptions checkoutOptions
>   checkoutStrategy: LGitCheckoutStrategyEnum git_checkout_none.
> [ repo clone: url options: cloneOptions ]
>   on: LGit_GIT_ERROR
>   do: [ :e | e acceptError: IceLibgitErrorVisitor new ].
> repo
>   checkout:
>   (aBranchName
>   ifNil:
>   [ self branch ifNotNil: [ :b | b name ] ifNil: 
> [ 'master' ] ]).
> (LGitRemote of: repo named: 'origin')
>   lookup;
>   setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: 
> in Block: [ | repo cloneOptions |...
> [ self checkInitialized.
> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self 
> checkInitialized
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in 
> Block: [ activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> LGitActionSequence(DynamicVariable)>>value:during:
> LGitActionSequence class(DynamicVariable class)>>value:during:
> LGitGlobal class>>runSequence:
> IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
> IceRepositoryCreator>>createRepository
> [ (IceRepositoryCreator new
>   url: urlToUse;
>   subdirectory: repoPath;
>   branchName: self projectVersion;
>   createRepository) register ] in [ | urlToUse |
> urlToUse := remote url.
> [ (IceRepositoryCreator new
>   url: urlToUse;
>   subdirectory: repoPath;
>   branchName: self projectVersion;
>   createRepository) register ]
>   on: IceAuthenticationError
>   do: [ :e | 
>   self
>   crLog:
>   ('I got an error while cloning: {1}. I will try 
> to clone the HTTPS variant.'
>   format: {e messageText}).
>   urlToUse := remote httpsUrl.
>   e retry ] ] in 
> MCGitHubRepository(MC

[Pharo-users] [ANN] Pharo Git Thermite Release

[Ronie Salgado]

Hello,

I am finally releasing an initial public version of Pharo Git Thermite, a
tool that I am developing as part of my master thesis for visualizing
Monticello and Git commits, for Pharo and Python:

GitHub Page with sources/documentation/issue tracker:
https://github.com/ronsaldo/pharo-git-thermite

Short video examples:
- Monticello Visualization; https://youtu.be/02CUHBmm-K8
- GitHub pull request: https://youtu.be/f196btLfYxM
- Local git commit: https://youtu.be/LCHTiJ4nx3g

Feedback form:
https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEliOJN7tFlTmYFi8w/viewform?usp=sf_link

Best regards,
Ronie

Re: [Pharo-users] pharo bash script with startup

[Hernán Morales Durand]

2018-07-17 4:07 GMT-03:00 Norbert Hartl :
>
>
>> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand 
>> :
>>
>> 2018-06-27 23:21 GMT-03:00 Otto Behrens :
>>> 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 <>> *  hardrtprio  2
>>> *  softrtprio  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  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
>  wrote:
>
> 2018-06-27 10:50 GMT-03:00 K K Subbu :
>>> 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. Doub

Re: [Pharo-users] pharo bash script with startup

[Norbert Hartl]

> Am 17.07.2018 um 17:31 schrieb Hernán Morales Durand 
> :
> 
> 2018-07-17 4:07 GMT-03:00 Norbert Hartl  >:
>> 
>> 
>>> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand 
>>> :
>>> 
>>> 2018-06-27 23:21 GMT-03:00 Otto Behrens :
 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 :)
> 
I’m not sure why we disagree here. I said that all of those scenarios need to 
be checked against real conditions. An algorithm that can brute forced due to 
the increase in computing power is a real condition. What I was saying is that 
not every theoretical problem is one you need to take care about. Why I am 
saying this? In my career I met far too many „experts“ dealing every 
theoretical problem as a real one without understanding the impact. Those 
people often sit at important positions in corporate infrastructure restricting 
the usage of the internet and software to a bare minimum. And they cannot see 
that they produce an economical damage to the company while keeping everyone 
from working. In order to justify that the damage it should at least be a real 
threat, don’t you think? 
The cost of the measure you take to protect needs to correlate in a sensible 
manner to the value you want to protect. 

Norbert


> 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 <>>> *  hardrtprio  2
 

Re: [Pharo-users] pharo bash script with startup

[Jerry Kott]

I am happy to see some real security conversation here.

Ultimately, security is about risk management, so both of you are somewhat 
correct. However, on the whole I tend to agree with Hernán. OTOH, it is 
theoretically possible to break any known cipher or hash algorithm, given 
sufficient resources, time and motivation. One needs to understand the measure 
of risk and understand their own risk tolerance to decide whether or not 
something is a viable threat. Good security means good behavior as well as 
technical solutions. Questioning 'wget …. | bash’ absolutely counts as good 
behavior in my book.

Jerry Kott
This message has been digitally signed.
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



> On 17-07-2018, at 8:31 AM, Hernán Morales Durand  
> wrote:
> 
> 2018-07-17 4:07 GMT-03:00 Norbert Hartl :
>> 
>> 
>>> Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand 
>>> :
>>> 
>>> 2018-06-27 23:21 GMT-03:00 Otto Behrens :
 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 <>>> *  hardrtprio  2
 *  softrtprio  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.
 

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Git Thermite Release

[Alexandre Bergel via Pharo-users]

--- Begin Message ---
It would be fantastic that people try it out. It is easy to use, and is really 
a big improvement over the tool set we use.

And getting feedback is important.

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Jul 17, 2018, at 11:08 AM, Ronie Salgado  wrote:
> 
> Hello,
> 
> I am finally releasing an initial public version of Pharo Git Thermite, a 
> tool that I am developing as part of my master thesis for visualizing 
> Monticello and Git commits, for Pharo and Python:
> 
> GitHub Page with sources/documentation/issue tracker: 
> https://github.com/ronsaldo/pharo-git-thermite 
> 
> 
> Short video examples:
> - Monticello Visualization; https://youtu.be/02CUHBmm-K8 
> 
> - GitHub pull request: https://youtu.be/f196btLfYxM 
> 
> - Local git commit: https://youtu.be/LCHTiJ4nx3g 
> 
> 
> Feedback form: 
> https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEliOJN7tFlTmYFi8w/viewform?usp=sf_link
>  
> 
> 
> Best regards,
> Ronie
> 
> 
> 

--- End Message ---