January 2019 - Pharo-dev - lists.pharo.org

Recommendation for password encryption?
by Mariano Martinez Peck Sept. 30, 2022

Sept. 30, 2022

Hi guys. Some time ago I asked about the best way to encrypt a password. Some of the recommendations I got was: 1) Generally for passwords you do not write a decrypt method for security purposes (eg you do not want people to be able to reverse engineer the encrypted password easily) 2) put a little salt 3) There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI 4) I should not decrypt password but instead I should compare both encrypted versions to see if they are equal. My scenario is the following. I need to store database passwords in text files. So I don't want to let them as plain text. And while I understand 4), I think it's a different scenario than mine. I know that some database driver may allow you to directly send the encrypted password. But still...I have another similar scenario in which I have to store a password and then send it (unencrypted)...so I kind of really need a bi-directional encryption. Now..I would try to avoid having an external library + FFI. Any ideas what is the best thing I can do? And how could I solve 1) if I want bidirectional like in my case? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

9 26

Re: [Pharo-project] Parsing and navigating Html
by Paul DeBruicker July 16, 2020

July 16, 2020

On 12/05/2010 06:02 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: > From: St?phane Ducasse<stephane.ducasse(a)inria.fr> > Subject: [Pharo-project] Parsing and navigating Html > To:"Pharo-project(a)lists.gforge.inria.fr Development" > <Pharo-project(a)lists.gforge.inria.fr> > Message-ID:<1C53DFD8-3021-4233-BC83-CE8C1EA8D103(a)inria.fr> > Content-Type: text/plain; charset=us-ascii > > Hi > > I would like extract partial information from HTML pages. > So I started to play and fix HTMLParser. > > Now does anybody know alternatives? > > Second, does anybody develop a lib to query HTML structure as with the XMLSupport package? > > Stef The Soup package on SqueakSource.com works OK.

3 4

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC
by Eliot Miranda June 3, 2019

June 3, 2019

Hi Damien, On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > Here are the files (image and various outputs). Running with --leakcheck > does mention a few object leaks (see output.txt); > Indeed the image is corrupt at start-up. See below. > I'm not sure where to get or how to build an assert VM. > When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app. > I also realized the VM I had was from this summer (the one that comes with > a 70 image with zeroconf). The output files I include were produced by the > VM at get.pharo.org/64/vmLatest70 > > https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0 > > On 20 March 2018 at 18:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> Hi Damien, >> >> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet(a)gmail.com> >> wrote: >> >>> >>> Hi, I have a Pharo image that crashes the VM on startup. The crash >>> report below seems to incriminate GC. Should I make it available somewhere >>> online? What's most convenient? >>> >> >> Don't care. Anywhere it can be downloaded from. Also, try running with >> -leakcheck 15, preferably in an assert VM and see if that gets you >> additional information. >> >> >>> >>> Process: Pharo [64892] >>> Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo >>> Identifier: org.pharo.Pharo >>> Version: 5.0.201708271955 (5.0.201708271955) >>> >> Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320: Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime. Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. > Code Type: X86-64 (Native) >>> Parent Process: ??? [64888] >>> Responsible: Pharo [64892] >>> User ID: 501 >>> >>> Date/Time: 2018-03-19 20:27:03.906 +0100 >>> OS Version: Mac OS X 10.13.3 (17D102) >>> Report Version: 12 >>> Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE >>> >>> Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154 >>> >>> Time Awake Since Boot: 28000 seconds >>> Time Since Wake: 6500 seconds >>> >>> System Integrity Protection: enabled >>> >>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >>> >>> Exception Type: EXC_BAD_ACCESS (SIGABRT) >>> Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 >>> Exception Note: EXC_CORPSE_NOTIFY >>> >>> VM Regions Near 0x12b67c0b0: >>> VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] >>> rw-/rwx SM=PRV >>> --> >>> STACK GUARD 0000700005613000-0000700005614000 [ 4K] >>> ---/rwx SM=NUL stack guard for thread 1 >>> >>> Application Specific Information: >>> abort() called >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 >>> 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 >>> 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 >>> 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 >>> 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 >>> 5 ??? 000000000000000000 0 + 0 >>> 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 >>> 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 >>> 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + >>> 45 >>> 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 >>> 10 org.pharo.Pharo 0x0000000104e5c7f6 >>> enterSmalltalkExecutiveImplementation + 152 >>> 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 >>> 12 org.pharo.Pharo 0x0000000104ed9cc1 >>> -[sqSqueakMainApplication runSqueak] + 394 >>> 13 com.apple.Foundation 0x00007fff2e6d696c >>> __NSFirePerformWithOrder + 360 >>> 14 com.apple.CoreFoundation 0x00007fff2c579127 >>> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 >>> 15 com.apple.CoreFoundation 0x00007fff2c57904f >>> __CFRunLoopDoObservers + 527 >>> 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + >>> 1240 >>> 17 com.apple.CoreFoundation 0x00007fff2c55af43 >>> CFRunLoopRunSpecific + 483 >>> 18 com.apple.HIToolbox 0x00007fff2b872e26 >>> RunCurrentEventLoopInMode + 286 >>> 19 com.apple.HIToolbox 0x00007fff2b872a9f >>> ReceiveNextEventCommon + 366 >>> 20 com.apple.HIToolbox 0x00007fff2b872914 >>> _BlockUntilNextEventMatchingListInModeWithFilter + 64 >>> 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + >>> 2085 >>> 22 com.apple.AppKit 0x00007fff2a2d3b4c >>> -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] >>> + 3044 >>> 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication >>> run] + 764 >>> 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain >>> + 804 >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > -- _,,,^..^,,,_ best, Eliot

9 26

Recent Pharo 6.1 OSX shows lots of "Error: unsupported compressor 8 on command line"
by Tim Mackinnon April 19, 2019

April 19, 2019

I noticed that recent Pharo 6.1 zero conf downloads show lots of these errors when you run the image in the terminal. Previous versions didnât do this - is this something to do with the latest vm upgrade? ./pharo-ui PagerDuty.image /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' Tim

6 6

Pharo Downloads are sluggish
by Esteban Maringolo March 13, 2019

March 13, 2019

Is there a reason why the latest version of the builds linked from the website are not hosted in some CDN, Amazon S3 or similar? Maybe in Europe the speed is fast, but where I am (Argentina) it is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of 40KB/s. This is an pitiful boarding experience, that will make many cancel it even before getting to open the downloaded launcher. [image: node-pharo.png] The screenshot shows that is not a problem with my home connection, which isn't the fastest but is "normal" for my use cases. Regards, Esteban A. Maringolo ps: When I finished writing this email, this was the progress... [image: image.png]

4 15

Apparently Zodiac plugin can crash VM on Linux
by Max Leske Feb. 26, 2019

Feb. 26, 2019

Hi, I'm writing on behalf of Martin (eMBee) who's experiencing crashes when using SSL. You can find a VM crash stack trace here: http://ws.stfx.eu/AKVNLUPMPGLG. He says he hasn't updated openssl since December 15th but that the crashes started to happen only recently (within the last couple of days). I asked him to try HTTP only connections and those work. The VM crashes immediately when using SSL. To me it looks like the cuplrit is the Zodiac plugin, or at least the library it works with. His system: linux, fedora 29, and from the system reporter i get: Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git cheers, Max

2 4

Debugger opening on user halt and not Object>>halt
by Thomas Dupriez Feb. 2, 2019

Feb. 2, 2019

Hello, Does someone know which is the code responsible for the debugger opening on the halt of the user instead of Object>>halt (see picture)? It's neat but it's not the regular behaviour so I'm guessing it is handled somewhere specifically for halt messages? Thomas

4 5

Re: [Pharo-dev] [Pharo-users] Class name with diacritic character and Pharo
by Sven Van Caekenberghe Feb. 2, 2019

Feb. 2, 2019

Hi Dominique, > On 27 Jan 2019, at 11:40, Dominique Dartois <dom(a)dartois.org> wrote: > > Hello all. > If a use french diacritic character in a class name, the code runs but I canât fileout the package nor save it with Monticello. > For example, the C cedilla in the class name drive me to an âZnInvalidUTF8:Illegal byte for utf-8 encoding' when filing out. > > Is it a bug or a feature? > Thank you > > <image.png>--- > Dominique Dartois Thanks for reporting this. This is most definitely a bug, I can confirm its occurrence. I'm CC pharo-dev as this is quite important. This will be a long mail. This is one manifestation of a problem that has been present for quite a while. I'll start by describing what I did, what went well and where/how this fails, some generic points, and two conceptual solutions (that need further verification). Like you, I created a new subclass: Object subclass: #ClasseFranÃ§aise instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage' With comment: I am ClasseFranÃ§aise. Try: ClasseFranÃ§aise new Ã©lÃ¨ve. ClasseFranÃ§aise new euro. And two methods (in the 'test' protocol): Ã©lÃ¨ve ^ 'Ã©lÃ¨ve' euro ^ 'â¬' I added the euro sign (because that is encoded in UTF-8 with 3 bytes, not 2 like Ã§). Like you said, the system can cope with such class and method names and seems to function fine. Looking at the .changes file, the correct source code was appended: ----SNAPSHOT----2019-01-26T23:36:18.548555+01:00 work.image priorSource: 339848! Object subclass: #ClasseFranÃ§aise instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage'! !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:25' prior: 0! I am ClasseFranÃ§aise.! !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:26'! Ã©lÃ¨ve ^ 'Ã©lÃ¨ve'! ! !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:27' prior: 33898360! I am ClasseFranÃ§aise. Try: ClasseFranÃ§aise new Ã©lÃ¨ve. ClasseFranÃ§aise new euro. ! !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:27'! euro ^ 'â¬'! ! Doing a file out (or otherwise saving the source code) fails. The reason is an incorrect manipulation of this source file while looking for what is called the method preamble, in SourcFileArray>>#getPreambleFrom:at: position An programmatic way to invoke the same error is by doing (ClasseFranÃ§aise>>#Ã©lÃ¨ve) timeStamp. (ClasseFranÃ§aise>>#Ã©lÃ¨ve) author. Both fail with the same error. The source code of methods is (currently) stored in a .sources or .changes file. CompiledMethods know their source pointer, an offset in one of these files. Right before the place where the source starts is a preamble that contains some meta information (including the author and timestamp). To access that preamble, the source code pointer is moved backwards to the beginning of the preamble (which begins and ends with a !). The current approach fails in the presence of non-ASCII characters. More specifically because of a mixup between the concept of byte position and character position when using UTF-8, a variable length encoding (both the .changes and the .sources are UTF-8 encoded). For example, consider 'Ã partir de 10 â¬' size. "16" 'Ã partir de 10 â¬' utf8Encoded size. "19" So although the string contains 16 characters, it is encoded as 19 bytes, Ã using 2 bytes and â¬ using 3 bytes. In general, moving backwards or forwards in UTF-8 encoded bytes cannot be done without understanding UTF-8 itself. ZnUTF8Encoder can do both (moving forward is #nextFromStream: while moving backwards is #backOnStream:). However, ZnUTF8Encoder is also strict: it will signal an error when forced to operate in between encoded characters, which is what happens here. It is thus not possible to move to arbitrary bytes positions and assume/hope to always arrive on the correct character boundaries and it is also wrong to take the difference between two byte positions as the count of characters present (since their encoding is of variable length). SourcFileArray>>#getPreambleFrom:at: is doing both of these wrong (but gets away with it in 99.99% of all cases since very few people name their classes like that). There are two solutions: operate mostly on the byte level or operate correctly on the character level. Here are two conceptual solutions (you must execute either solution 1 or 2, not both), with two different inputs. src := '!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! euro ^ ''â¬''! !'. "startPosition := 83" str := ZnCharacterReadStream on: (src utf8Encoded readStream). str position: 83. "at start of euro, the methods source string" str upToEnd. str position: (83 - 3). "before ! before euro" "find the previous ! before position" position := str position. binary := str wrappedStream. encoder := str encoder. "solution 1" [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. position. encoder decodeBytes: (binary next: 80 - position). "solution 2" count := 0. [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. str position. str next: count. Same code, different input (and starting position): src := '!ABC!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! euro ^ ''â¬''! !'. "startPosition := 87" str := ZnCharacterReadStream on: (src utf8Encoded readStream). str position: 87. "at start of euro, the methods source string" str upToEnd. str position: (87 - 3). "before ! before euro" "find the previous ! before position" position := str position. binary := str wrappedStream. encoder := str encoder. "solution 1" [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. position. encoder decodeBytes: (binary next: 80 - position). "solution 2" count := 0. [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. str position. str next: count. Solution 1 (at the byte level) works because $! (ASCII code 33) is also encoded as such in UTF-8 and this byte pattern cannot be part of a 2, 3 or 4 byte UTF-8 encoded character. The final byte segment must then be given to the proper encoder to turn it into characters. Solution 2 (at the character level) works because it essentially counts characters while moving backwards correctly (it moves back 2 steps each time because #next moves 1 step forward, while #peek would not help). Note that in Solution 1 the moving position is held in an external variable, while in Solution 2 it is held inside the stream. Implementing either solution requires more internal access of the streams (#wrappedStream), so SourcFileArray>>#getPreambleFrom:at: should at least be moved to SourceFile, IMHO. Obviously this is a sensitive/critical area to touch. We will also need a regression unit test. On a higher design level, I think that CompiledMethod>>#timeStamp and CompiledMethod>>#author should be cached at the instance level (a unix timestamp and a symbol would cost very little). Sven

3 6

Contribute to pharo8.0 ?
by Sven Van Caekenberghe Feb. 1, 2019

Feb. 1, 2019

Hi, I am trying my first contribution / PR to pharo8.0 I started with a latest zeroconfig 8.0 image/vm and I deleted my old fork and made a new one. But repairing the repository by fetching does not bring it to the detached state I also don't understand how to make an issue branch for https://github.com/pharo-project/pharo/issues/2395 Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github > Create new branch for issue ? What is the difference ? What about the Remote ? Can I work with only an issue on GitHub ? Is the documentation https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo really up to date ? Sven

6 9

contribution workflow
by Ben Coman Feb. 1, 2019

Feb. 1, 2019

I'm not sure how closely my contribution workflow matches the standard advertised, so just wanted to share it for feedback. I may remember wrongly, but my understanding of the advertised process was forking the "pharo-project/pharo" repo, then cloning from my fork. However I found it awkward to keep the "master" branch of my fork synchronised with upstream. What I ended up finding easiest is *always* cloning "pharo-project/pharo" then adding my "bencoman/pharo" repo as a remote. Iceberg then makes it simple to push just my working branches to my fork from where I can issue a PR. I never need to trouble synchronising the master branch in my fork. How does that compare to your contribution workflow? cheers -ben

3 3