- Pharo-users - lists.pharo.org

Recovery log thoughts

by Chris

One area I see some beginners struggle with image development is with regards to losing work, and I feel that Pharo's recovery log could be improved to help with this. Two scenarios that come to mind are firstly where methods are filed in that created an instance variable at method save the first time round. These log to the transcript that the variable is now undeclared, but that can go unseen, and the result is things appearing to work while you only have one instance of that object. Could this bring up a similar prompt maybe? Another difficulty is that you can not simply file in all selections as any do-it's which were done in a different context will fail. Is there any way we can differentiate the important do-it's such as class definitions, selector removes and so on from the rest? Regards, Chris

July 22, 2012

Re: [Pharo-users] The opposite of encodeForHTTP

by StÃ©phane Ducasse

On Jul 21, 2012, at 2:13 PM, Davide Varvello wrote: > Right, I seconded urlEncoded and urlDecoded go for it. we will deprecate or let encodeForHTTP for backward compat. My point is: let us steadily improve the situation. And if tomorrow something nicer exists then we just replace and throw away what we did :). Stef > Davide > > > Norbert Hartl wrote >> >> IMHO that would worsen the problem :) >> >> encodeForHTTP is not a good name. The encoding is defined for URLs and has >> nothing to do with HTTP. It is mostly called "url safe encoded" or just >> "url encoded". Doing it similar as base64 I would propose >> >> urlEncoded >> urlDecoded >> >> or >> >> urlSafeEncoded >> urlSafeDecoded >> >> my 2 cents, >> >> Norbert >> >> Am 19.07.2012 um 21:47 schrieb StÃ©phane Ducasse: >> >>> Let us fix it and propose a decodeFromHTTP method >>> >>> Stef >>> >>> On Jul 18, 2012, at 2:02 PM, Davide Varvello wrote: >>> >>>> Thanks Sven, >>>> I was looking for String>>decode..whatever... with no luck :-) >>>> Cheers >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4640510.html >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>> >>> >>> >> > > > > > -- > View this message in context: http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4641004.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 22, 2012

Re: [Pharo-users] The opposite of encodeForHTTP

by StÃ©phane Ducasse

On Jul 20, 2012, at 6:25 PM, Brenda Larcom wrote: > I suppose I could unlurk at this point. :) > > I'm a security geek (specifically, a secure development geek focusing on security architecture) in my day job, and I have a long unmaintained architecture security analysis tool written in Squeak (http://www.octotrike.org/ for the curious), which I have been unmothballing. We are considering switching to Pharo, partly because we are planning to add some P2P collaboration features we think have an HTTP layer in there somewhere & partly because we like it small, tidy, and self-compatible. Hence my lurking. Welcome and I would love to have more people working on these areas :). > I've done some work on how data validation should be done for security purposes, for my day job. This includes output encoding and decoding, like what Davide is talking about. It's pretty tricky to get right because of the large number of contexts, with subtly different rules. E.g. I would expect encodeForHTTP to be appropriate for HTTP headers, except that e.g. two things you usually want to put in HTTP headers are URIs and cookies, each of which have different rules (for different subparts, even) for what should be encoded. The differences don't seem like much, but in the wild, my coworkers & I see these sorts of differences lead to vulnerabilities on a daily basis. > > From a security architecture perspective, the absolute best way to handle encoding & decoding for a structured object like an HTTP request or response (or a URI, or a cookie, or an HTML document, or..) is to use a validating parser. Basically, when you get an HTTP request, parse it & put it in an object structured like the request. At that time, you know the meaning of each portion of the string you are parsing, so you can interpret the bits correctly/safely. The object(s) should store the individual strings that are actually content (vs. structure & constants) in a decoded state. The developer should get everything from the objects, in decoded form, and put everything into the objects in decoded form. Then, when it is time to send the response, the objects encode everything safely/canonically based on the exact type of objects they are. This design concentrates the hard stuff (encoding, decoding, canonicalization, layering encodings on top of each other) near the interfaces, at the first/last possible moment enough context is known to interpret the information accurately. It separates the mechanics of using a protocol or format from the intent of using the protocol. It lets someone like me easily QA both the library and application code for security. It is also simple for the developer to use safely (all the dev needs to think about is what objects/content they want to assemble, and the data validation at that layer is taken care of automatically) & is therefore the only design pattern I have seen consistently avoid all encoding-related vulnerabilities in the wild. > > So what does this mean? Basically, from a security perspective, encoding & decoding methods should live in the objects they encode and decode, and never be called from outside code. That is, there should be an HTTPHeader>>fromString: or fromStream: method, which is called from an HTTPResponse >>fromString: or fromStream: method, and no String>>decodeFromHTTP. Adding a String>>decodeFromHTTP method is easy from the library maintainer's point of view, approximately correct (way more correct than no method at all), and it matches what most languages are doing these days, but it shifts the burden of all that thought about the specific HTTP header & context to the application developer, who is usually just trying to write an application, not learn every single detail of the HTTP & gazillion other standards he would need to do this safely. > > Since this is a suggestion for substantial architecture change that would cause significant backwards compatibility issues throughout the entire Web application stack, and I'm new to Pharo to boot, I am expecting some interesting discussion to occur next. Or maybe profound silence. :) Thanks for the explanation. It makes sense. String is a dead object just counting and assembling characters. So Now what I would love to see is if you interested: - how can we improve the infrastructure of Pharo? step by step or via a big refactoring :) - I would add a simple decodeFromHTTP as a convenience method and in the future point to the validators. > In my back pocket somewhere amongst the code I am unmothballing, I have 95% of a thouroughly documented URI implementation and test suite that follows this pattern and is pedantically compliant with one or another of the URI RFCs (it's old, may not be the most recent). Bring it to life. We were discussing internally that we would like to have a decent URI implementation and we would like to massively clean the URL/URI â¦. with ZnURL whatever. So it would be great to have a good part. Now what I see from your mail :) is that you are a kind of perfectionist and you should pay attention (I know some of them) and you should force yourself to be happy with 80% and release it - 1 your 80% may be the 95% of somebody else - 2 release often, make progress is the best way to finish. :) > I believe Spoon & Slate are using a previous version of it or its derivatives. I'll need a fully pedantic HTTP parsing stack to feel comfortable releasing a P2P architecture security analysis tool (high value target, large attack surface, potentially very large professional embarrassment), so whatever isn't available, I expect we'll end up writing. If Pharo folks are interested in this pattern, Yes I'm. I will let the other reply to you because I'm far down in south of france but I'm quite sure that we are all interested. > I would love to contribute my libraries/changes as I finish them, get advice on backward compatibility, performance, and APIs people would like to see, review whatever related code you'd like for security issues, and/or collaborate with any other developer who is interested. I would love to learn from your expertise. Stef > > Brenda > > > On Jul 20, 2012, at 1:47 AM, Davide Varvello <varvello(a)yahoo.com> wrote: > >> Good Stef, I opened a new feature as reminder here: http://code.google.com/p/pharo/issues/detail?id=6430 >> >> Davide >> >> ---- >> - Cerchi un bravo Dentista, Avvocato, Commercialista? Un buon Hotel, Ristorante, Pizzeria? Io l'ho trovato su Oltre il Passaparola >> >> - Blog: Cambia il Tempo >> >> From: StÃ©phane Ducasse [via Smalltalk] <[hidden email]> >> To: Davide Varvello <[hidden email]> >> Sent: Thursday, July 19, 2012 10:43 PM >> Subject: Re: The opposite of encodeForHTTP >> >> Let us fix it and propose a decodeFromHTTP method >> >> Stef >> >> On Jul 18, 2012, at 2:02 PM, Davide Varvello wrote: >> >> > Thanks Sven, >> > I was looking for String>>decode..whatever... with no luck :-) >> > Cheers >> > >> > -- >> > View this message in context: http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4640510.html >> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >> >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4640822.html >> To unsubscribe from The opposite of encodeForHTTP, click here. >> NAML >> >> >> >> View this message in context: Re: The opposite of encodeForHTTP >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 22, 2012

Re: [Pharo-users] WaveFront File importer on Pharo

by Jean Baptiste Arnaud

On Jul 18, 2012, at 7:34 AM, StÃ©phane Ducasse wrote: > > On Jul 17, 2012, at 2:21 PM, Jean Baptiste Arnaud wrote: > >> Hi, >> Under the pressure of Camillo i publish the code. > > Thanks camillo :) > > >> I beginning to do a Wavefront (human readable standard for 3d Obj Model ) importer on Pharo. >> >> So i made a importer. >> Not all the case are manage, only the case I need to import the current Obj model. > > you relax from PhD writing :). Exactly ^^. > >> >> And a drawer which is in Alpha version. >> face and normal vector are manage. >> Missing color (in progress), and texturing. >> >> You need .obj file and all the .mtl related (open you blender and make it nice). >> >> If you are not running on Mac os comment this code in GLWorldTest>>#render, the >> >> display makeCurrent. >> >> else if you running on mac os implement it in >> NBMSAAOffscreenDisplay>>#makeCurrent >> ^driver makeCurrent. >> >> My code can be find on JBARepo on squeaksource >> ObjModel Package but you need NBOpenGL (i do a configuration in same place i just need to be motivated for keep it up to date). > > Keep it up to date. > > >> >> So >> put on same folder of the .image your .obj and .mtl file (i am lazy) (maybe it is VM folder i do not know). >> open a workspace and do >> >> "s := ObjImporter importFrom: 'xwing-map.obj'. >> s parse. >> object := s objects. >> >> w := GLWorldTest new. >> object do: [:e | w addElement: e]. >> w openInWorld." >> >> 3d result with normal >> <Screen Shot 2012-07-17 at 1.59.22 PM.png> >> >> >> With normal and color but not texture : >> >> <Screen Shot 2012-07-17 at 1.58.18 PM.png> >> >> Enjoy >> >> >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

July 21, 2012

Re: [Pharo-users] WaveFront File importer on Pharo

by Jean Baptiste Arnaud

I will check tomorrow, because i don't manage all the dispatch case g Object001 in file is not manage is do that tomorow fast. On Jul 21, 2012, at 9:44 AM, Luc Fabresse wrote: > Hi JB, > > Excellent! > I tried to give it a try for the fun. > I couldn't make it work. > > I updated some stuff (find it attached): > - ConfigurationOfObjModel-LucFabresse.2.mcz > added repository for package OBJModel in baseline > - OBJModel-LucFabresse.7 > add support for empty lines and "g" lines in wavefront format parser (ObjImporter>>dispach:) > > Here the snippet I tried: > > filename := 'teapot.obj'. > response := ZnEasy get: 'http://people.sc.fsu.edu/~jburkardt/data/obj/',filename. > (FileSystem disk workingDirectory / filename) > writeStreamDo: [ :stream | stream nextPutAll: response contents]. > > s := ObjImporter importFrom: filename. > s parse. > object := s objects. > > w := GLWorldTest new. > object do: [:e | w addElement: e]. > w openInWorld. > > Parsing seems to be ok. > But, creating the GL context failed: invalid pixel format. > On a mac OSX 10.6.8. > > I am eager to play deeper with that ;-) > > #Luc > > > > 2012/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 17, 2012, at 2:21 PM, Jean Baptiste Arnaud wrote: > > > Hi, > > Under the pressure of Camillo i publish the code. > > Thanks camillo :) > > > > I beginning to do a Wavefront (human readable standard for 3d Obj Model ) importer on Pharo. > > > > So i made a importer. > > Not all the case are manage, only the case I need to import the current Obj model. > > you relax from PhD writing :). > > > > > And a drawer which is in Alpha version. > > face and normal vector are manage. > > Missing color (in progress), and texturing. > > > > You need .obj file and all the .mtl related (open you blender and make it nice). > > > > If you are not running on Mac os comment this code in GLWorldTest>>#render, the > > > > display makeCurrent. > > > > else if you running on mac os implement it in > > NBMSAAOffscreenDisplay>>#makeCurrent > > ^driver makeCurrent. > > > > My code can be find on JBARepo on squeaksource > > ObjModel Package but you need NBOpenGL (i do a configuration in same place i just need to be motivated for keep it up to date). > > Keep it up to date. > > > > > > So > > put on same folder of the .image your .obj and .mtl file (i am lazy) (maybe it is VM folder i do not know). > > open a workspace and do > > > > "s := ObjImporter importFrom: 'xwing-map.obj'. > > s parse. > > object := s objects. > > > > w := GLWorldTest new. > > object do: [:e | w addElement: e]. > > w openInWorld." > > > > 3d result with normal > > <Screen Shot 2012-07-17 at 1.59.22 PM.png> > > > > > > With normal and color but not texture : > > > > <Screen Shot 2012-07-17 at 1.58.18 PM.png> > > > > Enjoy > > > > > > > > > > Best Regards > > Jean Baptiste Arnaud > > jbaptiste.arnaud(a)gmail.com > > > > > > > > > > > > > > > > > > <OBJModel-LucFabresse.7.mcz><ConfigurationOfObjModel-LucFabresse.2.mcz> Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

July 21, 2012

Re: [Pharo-users] [Esug-list] [ANN] humane assessment / moose courses

by HwaJongOh

Pity! I already fixed all my travel reservations. HwaJong Oh 2012. 7. 22., ìì¹¨ 5:46, Tudor Girba ìì±: > Hi, > > Humane assessment is a method for making software engineering decisions. Assessing software systems to make decisions is a critical activity that needs to be approached explicitly during development. Humane assessment is made possible by the Moose analysis platform. > > > I am organizing a couple of courses in Bern that might be of interest to people on this list: > > Humane Assessment Primer (August 17) > - This course is relevant for both managers and engineers. It covers assessment economics and the means to integrate humane assessment in the development process and in the organization > - http://www.humane-assessment.com/courses/humane-assessment-primer > > Moose Apprentice (September 6-7) > - This course is relevant for engineers. This is an introductory hands-on course on using the Moose analysis platform for putting humane assessment into practice > - http://www.humane-assessment.com/courses/moose-apprentice > > > If you are interested in participating, please contact me directly. > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

July 21, 2012

[ANN] humane assessment / moose courses

by Tudor Girba

Hi, Humane assessment is a method for making software engineering decisions. Assessing software systems to make decisions is a critical activity that needs to be approached explicitly during development. Humane assessment is made possible by the Moose analysis platform. I am organizing a couple of courses in Bern that might be of interest to people on this list: Humane Assessment Primer (August 17) - This course is relevant for both managers and engineers. It covers assessment economics and the means to integrate humane assessment in the development process and in the organization - http://www.humane-assessment.com/courses/humane-assessment-primer Moose Apprentice (September 6-7) - This course is relevant for engineers. This is an introductory hands-on course on using the Moose analysis platform for putting humane assessment into practice - http://www.humane-assessment.com/courses/moose-apprentice If you are interested in participating, please contact me directly. Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

July 21, 2012

Re: [Pharo-users] Zinc downloadTo: help required

by Chris

On 20/07/2012 18:30, Sven Van Caekenberghe wrote: > On 20 Jul 2012, at 18:22, Chris wrote: > >> Thanks for that. I'm actually still having a bit of trouble when the file is bigger than the chunk size. ZnChunkedReadStream>>#readInto:startingAt:count: uses a limit variable which is bigger than the collection and requestedCount. > I won't be able to do anything until the beginning of August. > > It would be really helpful if you could provide me with an actual test case that fails. > > Okay thanks Sven, I'll see what I can do. I am just working with a third party server which is sending chunks of 1mb (which I assume is valid) and I think Zinc just needs to support chunks bigger than the 16k in the above method Regards, Chris

July 21, 2012

glamorous inspector - extensions

by Tudor Girba

Hi, I see that there is a bit of an interest in the GTInspector, so here are some extra info about it. Beyond the things you can do out-of-the-box with it, the true power of the inspector comes from its extensibility. The idea is to offer each object an easy way to exhibit its own characteristics. This changes the way you can think of interacting with objects. Some more details here: http://www.humane-assessment.com/blog/equal-browsing-opportunity-for-every-… A new feature is the ability to edit code directly in the methods presentation. Combined with the possibility of executing a method in place and previewing the result, this opens the door for a prototype-like programming style. The GTInspector is part of the Glamorous Toolkit. It is still in its infancy, but I think it shows that there is a great deal of possibilities to improve the IDE and to depart from the what we might think is a given. I am still looking for people interested in joining this effort (remember the idea of the ide taskforce). It would be great to get more people interested in improving this part of Pharo. Cheers, Doru p.s. You can get the Glamorous Inspector in the following ways: - download the Moose image: http://www.moosetechnology.org/download/4.7 - download Pharo 1.4 (summer) with the Glamorous Inspector: http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… - load it in Pharo 1.4: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. ((Smalltalk at: #ConfigurationOfGlamoroust) project version: #development) load: 'GT-Inspector' -- www.tudorgirba.com "Live like you mean it."

July 21, 2012

Re: [Pharo-users] The opposite of encodeForHTTP

by Davide Varvello

Right, I seconded urlEncoded and urlDecoded Davide Norbert Hartl wrote > > IMHO that would worsen the problem :) > > encodeForHTTP is not a good name. The encoding is defined for URLs and has > nothing to do with HTTP. It is mostly called "url safe encoded" or just > "url encoded". Doing it similar as base64 I would propose > > urlEncoded > urlDecoded > > or > > urlSafeEncoded > urlSafeDecoded > > my 2 cents, > > Norbert > > Am 19.07.2012 um 21:47 schrieb StÃ©phane Ducasse: > >> Let us fix it and propose a decodeFromHTTP method >> >> Stef >> >> On Jul 18, 2012, at 2:02 PM, Davide Varvello wrote: >> >>> Thanks Sven, >>> I was looking for String>>decode..whatever... with no luck :-) >>> Cheers >>> >>> -- >>> View this message in context: >>> http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4640510.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >> >> > -- View this message in context: http://forum.world.st/The-opposite-of-encodeForHTTP-tp4640491p4641004.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 21, 2012