December 2021 - Pharo-dev - lists.pharo.org

This week (50/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 15 PRs and closed 9 Issue Tracker entries this week: Modularity ========== - Extract freetype to its own baseline (2nd pass) #10641 https://github.com/pharo-project/pharo/pull/10641 - Register bootstrapped projects #10653 https://github.com/pharo-project/pharo/pull/10653 - Split baseline of threadedffi #10637 https://github.com/pharo-project/pharo/pull/10637 - Make Athens not coupled with FT2 #10646 https://github.com/pharo-project/pharo/pull/10646 Refactoring =========== - Migrating RBAbstractVariables and RBMoveMethod #10626 https://github.com/pharo-project/pharo/pull/10626 Fixes ===== - Fix metacello lock #10633 https://github.com/pharo-project/pharo/pulse - 10294-undefinedIdentifier-is-missing-in-SHRBTextStyler #10648 https://github.com/pharo-project/pharo/pull/10648 - fix a couple of regressions #10662 https://github.com/pharo-project/pharo/pull/10662 - 10651-Resuming-a-exception-that-has-been-signalled-twice-does-not-return-correctly #10652 https://github.com/pharo-project/pharo/pull/10652 Cleanup ======= - Cleanup-DuplcatedMethods-12-13 #10654 https://github.com/pharo-project/pharo/pull/10654 - Cleanup-Spec-Deprecated #10624 https://github.com/pharo-project/pharo/pull/10624 - Unused method in FFI #10660 https://github.com/pharo-project/pharo/pull/10660 - Cleanup: STONWriter categorization #10661 https://github.com/pharo-project/pharo/pull/10661 - Categorize-More-Uncategorized #10649 https://github.com/pharo-project/pharo/pull/10649 - Fixing selector type: RBAddMethodChange>>#class:source:contoller: #10643 https://github.com/pharo-project/pharo/pull/10643

Dec. 17, 2021

Re: one year contract

by Sean Glazier

Hi, I emaile Nicolas a few times but Have not heard back. I would be very interested in working on this project. I have a US corporation setup and we can get to work on it as soons as they want. Kind Regards Sean Glazier On Tue, Jul 27, 2021, 12:08 PM stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > Hello > > this is a one year contract with remote working possibility in Pharo of > course. > We will produce an english version. > > Please contact Nicolas Becu. *Nicolas Becu <nicolas.becu(a)cnrs.fr > <nicolas.becu(a)cnrs.fr>>* > _____________ > Nicolas Becu > Chercheur CNRS > Littoral Environnement et SociÃ©tÃ©s (UMR LIENSs) > TÃ©l : 05 16 49 67 94 > > S > >

Dec. 14, 2021

Re: Zinc redirect?

by Sven Van Caekenberghe

There is now a solution described in the issue: https://github.com/svenvc/zinc/issues/69 > On 10 Dec 2021, at 10:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > There is an issue that Ronie created, I am looking into it: > > https://github.com/svenvc/zinc/issues/69 > >> On 10 Dec 2021, at 08:25, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> FYI >> >> >> running catching my train. >> from https://github.com/ronsaldo/form-scene-graph/issues/5#issuecomment-990353154 >> >> >> >> >> >> This seems to be a Zinc error while following a redirect. The following snippet can be used for replicating the issue: >> >> ZnClient new accept: 'application/octet-stream'; "Required by GitHub" url: 'https://api.github.com/repos/ronsaldo/abstract-gpu/releases/assets/49144132'; followRedirects: true; downloadTo: 'agpu.tar.gz' >> >

Dec. 13, 2021

Re: Zinc redirect?

by Sven Van Caekenberghe

There is an issue that Ronie created, I am looking into it: https://github.com/svenvc/zinc/issues/69 > On 10 Dec 2021, at 08:25, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > FYI > > > running catching my train. > from https://github.com/ronsaldo/form-scene-graph/issues/5#issuecomment-990353154 > > > > > > This seems to be a Zinc error while following a redirect. The following snippet can be used for replicating the issue: > > ZnClient new accept: 'application/octet-stream'; "Required by GitHub" url: 'https://api.github.com/repos/ronsaldo/abstract-gpu/releases/assets/49144132'; followRedirects: true; downloadTo: 'agpu.tar.gz' >

Dec. 10, 2021

Zinc redirect?

by stephane ducasse

FYI running catching my train. from https://github.com/ronsaldo/form-scene-graph/issues/5#issuecomment-990353154 This seems to be a Zinc error while following a redirect. The following snippet can be used for replicating the issue: ZnClient new accept: 'application/octet-stream'; "Required by GitHub" url: 'https://api.github.com/repos/ronsaldo/abstract-gpu/releases/assets/49144132'; followRedirects: true; downloadTo: 'agpu.tar.gz <https://api.github.com/repos/ronsaldo/abstract-gpu/releases/assets/49144132';%20followRedirects:%20true;%20downloadTo:%20'agpu.tar.gz>'

Dec. 10, 2021

This week (49/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 29 PRs and closed 43 issue tracker entries. With Pharo10 in freeze, we focus on fixes and simples cleanups. Fixes ===== - Fixes 10610 - CairoFontExtents is missing a field #10611 https://github.com/pharo-project/pharo/pull/10611 - Fix 10565 - Extract freetype to its own baseline #10566 https://github.com/pharo-project/pharo/pull/10566 - 10536 rubric embedded morphs sometimes misplaced #10558 https://github.com/pharo-project/pharo/pull/10558 - Moving the buggy must be boolean magic support outside of the image #10567 https://github.com/pharo-project/pharo/pull/10567 - Fix for Issue #10269 Replaced RBExtractToTemporaryRefactoring with RBExtractToTemporaryTraâ¦ #10388 https://github.com/pharo-project/pharo/pull/10388 - Fix stability of SUnitTest's related to the process monitoring #10514 https://github.com/pharo-project/pharo/pull/10514 Tests ===== - Made tests for embedded morphs skip as they procuce CI errors. #10628 https://github.com/pharo-project/pharo/pull/10628 Cleanups ======== - 17 PRs "Cleanup newlines and blanks" - Beacon "instance" class variable not capitalized #10614 https://github.com/pharo-project/pharo/pull/10614 - Some cleanups in SUnit-Core #10616 https://github.com/pharo-project/pharo/pull/10616 - Fixing the category of QuotedPrintableMimeConverter>>#newline #10617 https://github.com/pharo-project/pharo/pull/10617

Dec. 10, 2021

This week (48/2021) on the Pharo Issue Tracker

by Marcus Denker

For a complete list, see https://github.com/pharo-project/pharo/pulse Fixes ===== - Smooth drag and drop2 #10043 https://github.com/pharo-project/pharo/pull/10043 - Fix so that Rename Method refactoring does not start with a disabled text input #10390 https://github.com/pharo-project/pharo/pull/10390 - Process Changes Meta Pull Request #10429 https://github.com/pharo-project/pharo/pull/10429 - fixes #10516: doing a ffi calll with ByteArray does not pins the object in memory #10518 https://github.com/pharo-project/pharo/pull/10518 - Progress bar interruptible - not interuptable/interruptable #10510 https://github.com/pharo-project/pharo/pull/10510 - Add missing return #10564 https://github.com/pharo-project/pharo/pull/10564 Tests/CI ========= - 10538-run-correct-vm #10541 https://github.com/pharo-project/pharo/pull/10541 - fix-testTearDownMethodInSUnitTestsNeedsToBeInRunningProtocol #10517 https://github.com/pharo-project/pharo/pull/10517 Cleanups ======== - 17 PRs Cleanup newlines and blanks - [cleanup] fix comment for drag and drop setting #10537 https://github.com/pharo-project/pharo/pull/10537 - fixes 10525 - extract Keymapping packages to its own baseline #10526 https://github.com/pharo-project/pharo/pull/10526 - Keymapping-Pragmas package needs to be in UI group #10560 https://github.com/pharo-project/pharo/pull/10560 - fixes 10523 - move ProcessLocalSlot to VariablesLibrary #10524 https://github.com/pharo-project/pharo/pull/10524 - Fix different writing style of "Breakpoints" in Debug menu #10508 https://github.com/pharo-project/pharo/pull/10508 - Cleanup: Fix three more "utilities" cases in Metacello #10506 https://github.com/pharo-project/pharo/pull/10506

Dec. 7, 2021

by Marcus Denker

The Pharo Consortium is very happy to announce that the LIENSs Laboratory of the UniversitÃ© La Rochelle has joined the Consortium as an Academic Member. About - Laboratoire LIENS: https://lienss.univ-larochelle.fr - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org/

Dec. 6, 2021

Re: Hardening Zinc's Core HTTP Server

by Tim Mackinnon

Agreed - that has been a great test and appreciate all the effort that went into this. Tim On Thu, 2 Dec 2021, at 1:11 PM, Guillermo Polito wrote: > Thanks Sven, 51 days uptime is super encouraging :) > >> El 30 nov 2021, a las 17:45, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >> >> Hi, >> >>> On 29 Oct 2021, at 20:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Here is yet another update: >>> >>> The instances >>> >>> - On Amazon AWS: http://34.245.183.130:1701 >>> >>> - On Microsoft Azure: http://51.137.72.94:8080 >>> >>> have now been running for 18+ days. >>> >>> Having observed the overall amounts of critical resources inside the Pharo images, things look good. >>> >>> Seaside WASSession cleanup goes slowly but does work over time. >>> >>> Eventually I will stop at least the Azure instance because it costs me personal money. >> >> I disabled the Microsoft Azure VM instance at http://51.137.72.94:8080 to save money. Final uptime was 51 days. >> >> Here is the final screenshot: >> >> <Screenshot 2021-11-30 at 13.40.31.png> >> >> I'll leave the Amazon AWS VM instance at http://34.245.183.130:1701 up for now. >> >> Sven >> >>>> On 11 Oct 2021, at 19:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Here is an update on the status of both instances. >>>> >>>> A couple of people tried fiddling with invalid input which did result in exceptions, but everything was handled correctly so that the server kept on functioning. >>>> >>>> There were no spurious crashes. >>>> >>>> There was one attack by Levente Uzonyi that was successful though. >>>> >>>> He used the fact that Seaside sessions are long lived (cached for a certain time) combined with the fact that the Reddit.st <http://reddit.st/> app kept one GLORP database connection through P3 open to PostgreSQL and fired off a small denial of service (DOS) attack. Eventually either the VM ran out of space in the ExternalSemaphoreTable, making Socket creation, either for database connections or for handling new HTTP request impossible or the database's own connection limit was reached. At that point the HTTP server or the Pharo VM stopped functioning. >>>> >>>> Although Levente used a sequential number of requests, a concurrent number of request could cause similar problems (related, but differently). >>>> >>>> In looking at what he reported it also became clear that I accidentally left a debugging exception handler active, which is not good in a production image. >>>> >>>> Both instances are now redeployed with the following changes: >>>> >>>> - the Reddit.st <http://reddit.st/> code was changed to not keep the database connection open all the time, but instead connect/disconnect per request. this might be a bit slower, but it conserves resources much better and solves the original issue Levente reported >>>> >>>> https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae6… >>>> >>>> - a new feature was added to Zinc HTTP Components' ZnManagingMultiThreadedServer (the default) to enforce a maximum number of concurrent connections being allowed (the limit is 32 by default, but changeable if you know what you are doing). when the limit is reached, 503 Service Unavailable responses are sent to the excess clients and the connection is closed. this should help protect against concurrent connection DOS attacks >>>> >>>> https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29… >>>> >>>> - the deploy script was changed to use the more primitive WAErrorHandler >>>> >>>> https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d… >>>> >>>> Thanks again to Levente for taking the time to try an attack and for reporting it clearly. >>>> >>>> Sven >>>> >>>>> On 29 Sep 2021, at 17:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Both instances have been up for 5 days now, looking for more testers. >>>>> >>>>>> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of Pharo since version 1.3 (2011). It is an open-source framework to deal with the HTTP networking protocol, modelling all aspects involved. It also offers both client and server functionality. >>>>>> >>>>>> The reliability of the code base has improved steadily over the years, thanks to virtually all Pharo developers using it, directly or indirectly. Over the summer a number of issues that popped up after Pharo 9 was released were resolved. >>>>>> >>>>>> The robustness of the core HTTP server is one important aspect. To put this quality further to the test, I deployed two servers with the same demo Seaside application, Reddit.st, open to the internet, without any further protections. >>>>>> >>>>>> - On Amazon AWS: http://34.245.183.130:1701 >>>>>> >>>>>> - On Microsoft Azure: http://51.137.72.94:8080 >>>>>> >>>>>> The application's source code can be found at [https://github.com/svenvc/Reddit] For the technically curious there are also deploy instructions at [https://github.com/svenvc/Reddit/blob/main/DEPLOY.md] The demo app itself is described in an older article [https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740] Note that, by definition, there is no HTTPS/TLS variant. >>>>>> >>>>>> If you manage to break this server with (a) malicious request(s) in such a way that you can explain what you did for others to confirm your approach, you not only help me/us improve the code, but earn eternal fame as well ;-) >>>>>> >>>>>> Sven >>>>>> >>>>>> PS: I hope I won't regret this, I am looking for constructive criticism. >>>>>> >>>>>> >>>>>> -- >>>>>> Sven Van Caekenberghe >>>>>> Proudly supporting Pharo >>>>>> http://pharo.org >>>>>> http://association.pharo.org >>>>>> http://consortium.pharo.org

Dec. 2, 2021

Re: Hardening Zinc's Core HTTP Server

by Guillermo Polito

Thanks Sven, 51 days uptime is super encouraging :) > El 30 nov 2021, a las 17:45, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > Hi, > >> On 29 Oct 2021, at 20:42, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> Here is yet another update: >> >> The instances >> >> - On Amazon AWS: http://34.245.183.130:1701 <http://34.245.183.130:1701/> >> >> - On Microsoft Azure: http://51.137.72.94:8080 <http://51.137.72.94:8080/> >> >> have now been running for 18+ days. >> >> Having observed the overall amounts of critical resources inside the Pharo images, things look good. >> >> Seaside WASSession cleanup goes slowly but does work over time. >> >> Eventually I will stop at least the Azure instance because it costs me personal money. > > I disabled the Microsoft Azure VM instance at http://51.137.72.94:8080 <http://51.137.72.94:8080/> to save money. Final uptime was 51 days. > > Here is the final screenshot: > > <Screenshot 2021-11-30 at 13.40.31.png> > > I'll leave the Amazon AWS VM instance at http://34.245.183.130:1701 <http://34.245.183.130:1701/> up for now. > > Sven > >>> On 11 Oct 2021, at 19:37, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> >>> Here is an update on the status of both instances. >>> >>> A couple of people tried fiddling with invalid input which did result in exceptions, but everything was handled correctly so that the server kept on functioning. >>> >>> There were no spurious crashes. >>> >>> There was one attack by Levente Uzonyi that was successful though. >>> >>> He used the fact that Seaside sessions are long lived (cached for a certain time) combined with the fact that the Reddit.st <http://reddit.st/> app kept one GLORP database connection through P3 open to PostgreSQL and fired off a small denial of service (DOS) attack. Eventually either the VM ran out of space in the ExternalSemaphoreTable, making Socket creation, either for database connections or for handling new HTTP request impossible or the database's own connection limit was reached. At that point the HTTP server or the Pharo VM stopped functioning. >>> >>> Although Levente used a sequential number of requests, a concurrent number of request could cause similar problems (related, but differently). >>> >>> In looking at what he reported it also became clear that I accidentally left a debugging exception handler active, which is not good in a production image. >>> >>> Both instances are now redeployed with the following changes: >>> >>> - the Reddit.st <http://reddit.st/> code was changed to not keep the database connection open all the time, but instead connect/disconnect per request. this might be a bit slower, but it conserves resources much better and solves the original issue Levente reported >>> >>> https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae6… <https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae6…> >>> >>> - a new feature was added to Zinc HTTP Components' ZnManagingMultiThreadedServer (the default) to enforce a maximum number of concurrent connections being allowed (the limit is 32 by default, but changeable if you know what you are doing). when the limit is reached, 503 Service Unavailable responses are sent to the excess clients and the connection is closed. this should help protect against concurrent connection DOS attacks >>> >>> https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29… >>> >>> - the deploy script was changed to use the more primitive WAErrorHandler >>> >>> https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d… >>> >>> Thanks again to Levente for taking the time to try an attack and for reporting it clearly. >>> >>> Sven >>> >>>> On 29 Sep 2021, at 17:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Both instances have been up for 5 days now, looking for more testers. >>>> >>>>> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of Pharo since version 1.3 (2011). It is an open-source framework to deal with the HTTP networking protocol, modelling all aspects involved. It also offers both client and server functionality. >>>>> >>>>> The reliability of the code base has improved steadily over the years, thanks to virtually all Pharo developers using it, directly or indirectly. Over the summer a number of issues that popped up after Pharo 9 was released were resolved. >>>>> >>>>> The robustness of the core HTTP server is one important aspect. To put this quality further to the test, I deployed two servers with the same demo Seaside application, Reddit.st, open to the internet, without any further protections. >>>>> >>>>> - On Amazon AWS: http://34.245.183.130:1701 >>>>> >>>>> - On Microsoft Azure: http://51.137.72.94:8080 >>>>> >>>>> The application's source code can be found at [https://github.com/svenvc/Reddit] For the technically curious there are also deploy instructions at [https://github.com/svenvc/Reddit/blob/main/DEPLOY.md] The demo app itself is described in an older article [https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740] Note that, by definition, there is no HTTPS/TLS variant. >>>>> >>>>> If you manage to break this server with (a) malicious request(s) in such a way that you can explain what you did for others to confirm your approach, you not only help me/us improve the code, but earn eternal fame as well ;-) >>>>> >>>>> Sven >>>>> >>>>> PS: I hope I won't regret this, I am looking for constructive criticism. >>>>> >>>>> >>>>> -- >>>>> Sven Van Caekenberghe >>>>> Proudly supporting Pharo >>>>> http://pharo.org >>>>> http://association.pharo.org >>>>> http://consortium.pharo.org >>>>> >>>> >>> >> >

Dec. 2, 2021