May 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Sign Windows VMs

by philippe.back＠highoctane.be

https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml looks like a plan. Phil On Tue, May 15, 2018, 10:00 Fabio Niephaus <lists(a)fniephaus.com> wrote: > Hi Vincent, > > On Tue, May 15, 2018 at 1:15 AM <Vincent.Blondeau(a)lamresearch.com> wrote: > >> >> >> Hi! >> >> >> >> I am using Pharo in a company network under a firewall, an antivirus, and >> windows, and each day I have an issue with some parts of the Pharo >> application that are recognized as a threat. So, I cannot download it or >> execute it straightforwardly. >> >> >> >> Today was this one: >> >> >> >> [image: image003.png] >> >> Another day was the Cairo Dll where a âVeil Evasion Payloadâ has been >> detected. >> > > I agree, this is bad. > > >> >> >> And some people has encounter the same kind of issues: >> >> - https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/152 >> - >> https://pharo.fogbugz.com/f/cases/20500/WindowsDefender-consider-SqueakSSL-… >> >> >> >> It seems that the solution is to sign the VM with Authenticode, but for >> this, one needs to acquire a certificate (which is, of course, not free). >> >> Has the community such a certificate? Maybe the same that for MacOS? >> > > No, we don't have such a certificate yet and we can't use the certificate > from Apple because it can only be used for macOS VMs unfortunately. > > >> Would someone configure the VM builds to automatically sign them? (I can >> spend some time for this if needed) >> > > Of course, but first we need a certificate I'm afraid. > > Cheers, > Fabio > > >> >> >> TIA, >> >> >> >> Cheers, >> >> Vincent >> >> >> >

May 15, 2018

Re: [Pharo-dev] [Vm-dev] Sign Windows VMs

by Fabio Niephaus

Hi Vincent, On Tue, May 15, 2018 at 1:15 AM <Vincent.Blondeau(a)lamresearch.com> wrote: > > > Hi! > > > > I am using Pharo in a company network under a firewall, an antivirus, and > windows, and each day I have an issue with some parts of the Pharo > application that are recognized as a threat. So, I cannot download it or > execute it straightforwardly. > > > > Today was this one: > > > > [image: image003.png] > > Another day was the Cairo Dll where a âVeil Evasion Payloadâ has been > detected. > I agree, this is bad. > > > And some people has encounter the same kind of issues: > > - https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/152 > - > https://pharo.fogbugz.com/f/cases/20500/WindowsDefender-consider-SqueakSSL-… > > > > It seems that the solution is to sign the VM with Authenticode, but for > this, one needs to acquire a certificate (which is, of course, not free). > > Has the community such a certificate? Maybe the same that for MacOS? > No, we don't have such a certificate yet and we can't use the certificate from Apple because it can only be used for macOS VMs unfortunately. > Would someone configure the VM builds to automatically sign them? (I can > spend some time for this if needed) > Of course, but first we need a certificate I'm afraid. Cheers, Fabio > > > TIA, > > > > Cheers, > > Vincent > > >

May 15, 2018

Sign Windows VMs

by Vincent.Blondeau＠lamresearch.com

Hi! I am using Pharo in a company network under a firewall, an antivirus, and windows, and each day I have an issue with some parts of the Pharo application that are recognized as a threat. So, I cannot download it or execute it straightforwardly. Today was this one: [https://cdn.discordapp.com/attachments/365850577340727296/44568885694850662…] Another day was the Cairo Dll where a "Veil Evasion Payload" has been detected. And some people has encounter the same kind of issues: * https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/152 * https://pharo.fogbugz.com/f/cases/20500/WindowsDefender-consider-SqueakSSL-… It seems that the solution is to sign the VM with Authenticode, but for this, one needs to acquire a certificate (which is, of course, not free). Has the community such a certificate? Maybe the same that for MacOS? Would someone configure the VM builds to automatically sign them? (I can spend some time for this if needed) TIA, Cheers, Vincent

May 14, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Nicolas Cellier

2018-05-14 15:15 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 14 May 2018, at 15:09, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > 2018-05-14 14:44 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> > >> > >> > For ByteArray, I didn't check recently in Pharo, but I know that it's >> quite a mess in Squeak because some methods are in Alien, other in FFI, >> other in base Squeak... >> > IMO all methods should be in core Squeak/Pharo because of general usage >> (like decoding binary data). >> > >> I want to move the methods from FFI to the base since yearsâ¦ I was told >> that this is impossible to ever happen because it is not important to do >> changes like that. >> > > Marcus >> > > Hi Marcus, > we all know that those un-important and not-so-much-rewarding changes > makes a big difference at the end. > like commenting classes, classifying methods, deprecating duplicates, > reducing package inter-dependencies, etc... > I thought that the defenders of statu quo had two reasons in mind: > - the will to keep a FFI-less (locked-in) image > - the fear to loose backward compatibility > > > The idea that âonly big important changesâ are worth doingâ¦ you know, itâs > âinventing the futureâ business, not âcleaning upâ! > > (Of course revolutionary changes while staying 100% backward compatibleâ¦ > because think about the Children!) > > It would be funny if it would not be sadâ¦ > > But's it the past, now you are free :) > > > Not really, because we share that package with Squeak. If I would be free > to change it, it would have happened a loong time agoâ¦ > > Marcus > > OK, coordinated changes must be performed then, but it's a bit more difficult... It can be a two step process: 1) separate the methods to be re-integrated in core into a separate package 2) move this methods in core, or use the separate package for old images (backward compatibility) It has to be performed both in FFI and Alien.

May 14, 2018

[Pharo 7.0-dev] Build #897: 21900-GTExamplesBrowser-uses-old-Compiler-API

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #897 was: FAILURE. The Pull Request #1353 was integrated: "21900-GTExamplesBrowser-uses-old-Compiler-API" Pull request url: https://github.com/pharo-project/pharo/pull/1353 Issue Url: https://pharo.fogbugz.com/f/cases/21900 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

[Pharo 7.0-dev] Build #896: 21903-GT-tools-still-uses-old-compiler-API-evaluateforlogged

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #896 was: FAILURE. The Pull Request #1354 was integrated: "21903-GT-tools-still-uses-old-compiler-API-evaluateforlogged" Pull request url: https://github.com/pharo-project/pharo/pull/1354 Issue Url: https://pharo.fogbugz.com/f/cases/21903 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

[Pharo 7.0-dev] Build #895: 21904-TextDoIt-TextPrintIt-uses-old-compiler-API

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #895 was: SUCCESS. The Pull Request #1352 was integrated: "21904-TextDoIt-TextPrintIt-uses-old-compiler-API" Pull request url: https://github.com/pharo-project/pharo/pull/1352 Issue Url: https://pharo.fogbugz.com/f/cases/21904 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Marcus Denker

> On 14 May 2018, at 15:09, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2018-05-14 14:44 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > > > > For ByteArray, I didn't check recently in Pharo, but I know that it's quite a mess in Squeak because some methods are in Alien, other in FFI, other in base Squeak... > > IMO all methods should be in core Squeak/Pharo because of general usage (like decoding binary data). > > > I want to move the methods from FFI to the base since yearsâ¦ I was told that this is impossible to ever happen because it is not important to do changes like that. > > Marcus > > Hi Marcus, > we all know that those un-important and not-so-much-rewarding changes makes a big difference at the end. > like commenting classes, classifying methods, deprecating duplicates, reducing package inter-dependencies, etc... > I thought that the defenders of statu quo had two reasons in mind: > - the will to keep a FFI-less (locked-in) image > - the fear to loose backward compatibility The idea that âonly big important changesâ are worth doingâ¦ you know, itâs âinventing the futureâ business, not âcleaning upâ! (Of course revolutionary changes while staying 100% backward compatibleâ¦ because think about the Children!) It would be funny if it would not be sadâ¦ > But's it the past, now you are free :) Not really, because we share that package with Squeak. If I would be free to change it, it would have happened a loong time agoâ¦ Marcus

May 14, 2018

[Pharo 7.0-dev] Build #894: 21888 Tagging in CodeImportCommandLineHandlers

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #894 was: SUCCESS. The Pull Request #1343 was integrated: "21888 Tagging in CodeImportCommandLineHandlers" Pull request url: https://github.com/pharo-project/pharo/pull/1343 Issue Url: https://pharo.fogbugz.com/f/cases/21888 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Nicolas Cellier

2018-05-14 14:44 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > > For ByteArray, I didn't check recently in Pharo, but I know that it's > quite a mess in Squeak because some methods are in Alien, other in FFI, > other in base Squeak... > > IMO all methods should be in core Squeak/Pharo because of general usage > (like decoding binary data). > > > I want to move the methods from FFI to the base since yearsâ¦ I was told > that this is impossible to ever happen because it is not important to do > changes like that. > Marcus > Hi Marcus, we all know that those un-important and not-so-much-rewarding changes makes a big difference at the end. like commenting classes, classifying methods, deprecating duplicates, reducing package inter-dependencies, etc... I thought that the defenders of statu quo had two reasons in mind: - the will to keep a FFI-less (locked-in) image - the fear to loose backward compatibility But's it the past, now you are free :)

May 14, 2018