December 2016 - Pharo-users

Re: [Pharo-users] Password storage options

by Paul DeBruicker

I made a crypt/bcrypt ffi library for older versions of Pharo that sounds like it meets your needs and is in the cryptography project here: http://smalltalkhub.com/#!/~Cryptography/Cryptography But I have not updated it for the new FFI versions in Pharo 5/6. And Pierce Ng made a blog post and library about his own set up here: http://www.samadhiweb.com/blog/2013.11.17.shacrypt.html Jan BlizniÄenko wrote > Hello > > I'm working on Pharo-based webserver and right now I got to the topic of > storing user passwords. I found SHA256 integrated in Pharo, but hashing > with > SHA is far from enough. I also looked around the mailing list history to > find few posts from 2011 about bcrypt using Linux libraries. I'd like to > ask > what is current status - what are my options under following conditions: > > I prefer Pharo 5 compatibility. I could downgrade to Pharo 4 or use beta > Pharo 6, but latest stable relase is preferred. > > I require at least bcrypt or PDKBF2, but I much more prefer > GPU-attack-resistant solutions like scrypt or Argon2. > > I require Linux compatibility, but platform independent solution would be > kinda nice (we could use the same algorithm on our local machines with Mac > and Win for development). > > Thank you > Jan > > > > -- > View this message in context: > http://forum.world.st/Password-storage-options-tp4927471.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Password-storage-options-tp4927480p4927501.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 19, 2016

Password storage options

by Torsten Bergmann

>I require at least bcrypt or PDKBF2, but I much more prefer >GPU-attack-resistant solutions like scrypt or Argon2. If required you can use external libraries like scrypt (https://lolware.net/2014/04/29/libscrypt.html) and call it using UFFI from Pharo Thanks T.

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Mariano Martinez Peck

I personally think Denis has raised an important remark. Fuel responsibility here should stop at supporting post materialization actions. So...I do agree that this code is ONE particular usage of Fuel and such code should likely be packaged with the tool and not with Fuel . On Mon, Dec 19, 2016 at 2:41 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Dec 19, 2016, at 6:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > Hi. > > > > 2016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > I suppose that functionality should be resolved via FuelPlatform. > Something like > > > > FLPlatform current > > openDebuggerOn: Processor activeProcess > > context: materialization root > > label: 'External stack' > > > > Is it really nice way to do it? I mean why we force system to open > debugger when serialised context is loaded? > > IMHO it is responsibility of tool to decide what to do with object. It > should be good extension for file browser or inspector. Tool will detect > that it work with context and will allow to debug it. > > > > Post materialisation action is nice feature but for me it is overused > here. > > Looking from far away (I did not check the code) I kind of agree with this > point of view. If we make it the responsibility of the tool, the design > becomes a bit more object-centric. To me it looks like the Platform tries > to know more things that are not about Fuel. > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Tudor Girba

Hi, > On Dec 19, 2016, at 6:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > 2016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > I suppose that functionality should be resolved via FuelPlatform. Something like > > FLPlatform current > openDebuggerOn: Processor activeProcess > context: materialization root > label: 'External stack' > > Is it really nice way to do it? I mean why we force system to open debugger when serialised context is loaded? > IMHO it is responsibility of tool to decide what to do with object. It should be good extension for file browser or inspector. Tool will detect that it work with context and will allow to debug it. > > Post materialisation action is nice feature but for me it is overused here. Looking from far away (I did not check the code) I kind of agree with this point of view. If we make it the responsibility of the tool, the design becomes a bit more object-centric. To me it looks like the Platform tries to know more things that are not about Fuel. Cheers, Doru -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Denis Kudriashov

2016-12-19 18:34 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> I suppose that functionality should be resolved via FuelPlatform. >> Something like >> >> FLPlatform current >> openDebuggerOn: Processor activeProcess >> context: materialization root >> label: 'External stack' >> > As solution to current approach I agree here: it should be resolved by platform

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Denis Kudriashov

Hi. 2016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > I suppose that functionality should be resolved via FuelPlatform. > Something like > > FLPlatform current > openDebuggerOn: Processor activeProcess > context: materialization root > label: 'External stack' > Is it really nice way to do it? I mean why we force system to open debugger when serialised context is loaded? IMHO it is responsibility of tool to decide what to do with object. It should be good extension for file browser or inspector. Tool will detect that it work with context and will allow to debug it. Post materialisation action is nice feature but for me it is overused here.

Dec. 19, 2016

Password storage options

by Jan BlizniÄenko

Hello I'm working on Pharo-based webserver and right now I got to the topic of storing user passwords. I found SHA256 integrated in Pharo, but hashing with SHA is far from enough. I also looked around the mailing list history to find few posts from 2011 about bcrypt using Linux libraries. I'd like to ask what is current status - what are my options under following conditions: I prefer Pharo 5 compatibility. I could downgrade to Pharo 4 or use beta Pharo 6, but latest stable relase is preferred. I require at least bcrypt or PDKBF2, but I much more prefer GPU-attack-resistant solutions like scrypt or Argon2. I require Linux compatibility, but platform independent solution would be kinda nice (we could use the same algorithm on our local machines with Mac and Win for development). Thank you Jan -- View this message in context: http://forum.world.st/Password-storage-options-tp4927471.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Max Leske

I suppose that functionality should be resolved via FuelPlatform. Something like FLPlatform current openDebuggerOn: Processor activeProcess context: materialization root label: 'External stack' That method can then be overriden accoring to the platform. https://github.com/theseion/Fuel/issues/222 <https://github.com/theseion/Fuel/issues/222> > On 19 Dec 2016, at 15:12, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger(a)freyther.de <mailto:holger@freyther.de>> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling out an exception and then using FLMaterializer class>>#materializeFromFileNamed: to load it back and get a debugger up. In Pharo5 I am presented a DNU instead. > Holger, did you load Fuel explicitly or did you use the version that's already in Pharo 5? In the latter case we'll have to port that fix back to Pharo 5. Cheers, Max > > Hi Holger, > > I hope you were able to show that example to him anyways. That example make us won the first price at ESUG awards hahaha. I still remember when I was sitting at home, trying to think of a good example to show and I thought: "what if I serialize the debugger and the stack to another image?". I tried and it worked out of the box. One of the happiest dev programming days ever hahaha. > > > The DNU is on GTGenericStackDebugger as it doesn't understand the message Fuel is sending. What to fix, Fuel to use the new protocol or GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? > > > Well, if the GT developers (CC'ed Dory) do not want to add back the old protocol, then no problem, we do have a way to manage portability across dialects and versions. Max Leske (CC'ed) has changed and improved this in the recent months. So I will wait to see if he can take care. Else, I will do it. > > Thanks for the report. > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Andrei Chis

Hi Holgen, This should be fixed by updating #serializeTestFailureContext:toFileNamed:. The API of the debugger was refactored in Pharo 5 and it seems like #serializeTestFailureContext:toFileNamed: was not updated in Pharo 5. Created an issue case 19477 <https://pharo.fogbugz.com/f/cases/19477/Fuel-out-Stack-uses-old-debugger-AP…>. Also currently on mac there is another issue when fueling out the stack (case 19064 <https://pharo.fogbugz.com/f/cases/19064/Fuel-out-stack-not-working>) Cheers, Andrei On Mon, Dec 19, 2016 at 9:53 AM, Holger Freyther <holger(a)freyther.de> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling > out an exception and then using FLMaterializer class>>#materializeFromFileNamed: > to load it back and get a debugger up. In Pharo5 I am presented a DNU > instead. > > The DNU is on GTGenericStackDebugger as it doesn't understand the message > Fuel is sending. What to fix, Fuel to use the new protocol or > GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext > toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass > it to the debugger? I think loading new fuel in Pharo3.x is still possible > so maybe it is best to re-add that protocol? > > comments? > > holger >

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Mariano Martinez Peck

On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger(a)freyther.de> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling > out an exception and then using FLMaterializer class>>#materializeFromFileNamed: > to load it back and get a debugger up. In Pharo5 I am presented a DNU > instead. > > Hi Holger, I hope you were able to show that example to him anyways. That example make us won the first price at ESUG awards hahaha. I still remember when I was sitting at home, trying to think of a good example to show and I thought: "what if I serialize the debugger and the stack to another image?". I tried and it worked out of the box. One of the happiest dev programming days ever hahaha. The DNU is on GTGenericStackDebugger as it doesn't understand the message > Fuel is sending. What to fix, Fuel to use the new protocol or > GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext > toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass > it to the debugger? I think loading new fuel in Pharo3.x is still possible > so maybe it is best to re-add that protocol? > > Well, if the GT developers (CC'ed Dory) do not want to add back the old protocol, then no problem, we do have a way to manage portability across dialects and versions. Max Leske (CC'ed) has changed and improved this in the recent months. So I will wait to see if he can take care. Else, I will do it. Thanks for the report. -- Mariano http://marianopeck.wordpress.com

Dec. 19, 2016