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

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by Nicolas Cellier

2011/5/14 <mkobetic(a)gmail.com>: > "Miguel CobÃ¡"<miguel.coba(a)gmail.com> wrote: >> But the performance is an issue. And I think that there was a discussion >> several years ago that lead to choice a plugin instead of the >> all-smalltalk code (independently of the queality of the smalltalk >> code). Also a point was made about the maintainability of the smalltalk >> code with respect to a library of the underlying OS, with respect to >> CERT issues and 0-day exploits. given the few resources in the community >> for simpler (relative to crypto) projects like *completion, RB and so, I >> think is a wise decision to use the proved, tested and maintained OS >> libraries through a plugin part of the standard VM. Of course, the >> smalltalk implementation can be used as a fallback for platforms where a >> plugin isn't available. > > These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here. > > The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SS…) > I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas > Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)? > > Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-). > > My 2c, > > Martin > > >

May 13, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by mkobetic＠gmail.com

"Miguel CobÃ¡"<miguel.coba(a)gmail.com> wrote: > But the performance is an issue. And I think that there was a discussion > several years ago that lead to choice a plugin instead of the > all-smalltalk code (independently of the queality of the smalltalk > code). Also a point was made about the maintainability of the smalltalk > code with respect to a library of the underlying OS, with respect to > CERT issues and 0-day exploits. given the few resources in the community > for simpler (relative to crypto) projects like *completion, RB and so, I > think is a wise decision to use the proved, tested and maintained OS > libraries through a plugin part of the standard VM. Of course, the > smalltalk implementation can be used as a fallback for platforms where a > plugin isn't available. These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here. The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SS…) Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)? Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-). My 2c, Martin

May 13, 2011

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

by mkobetic＠gmail.com

"Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: > Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary > serializer similar to Parcels. More info in > http://rmod.lille.inria.fr/web/pier/software/Fuel > > For the moment, we are using the "classic" streams we want to give it a try > to XStreams. My knowledge on streams is very little, so if someone can give > me a hint I would really appreciate it. > What I want to do right now is an adaptor of XStreams to classic stream. I > mean, I want to create custom subclasses of XTFileWriteStream and > XTFileReadStream that implements the same API from classic streams that we > use in Fuel. And the implementations of such methods will do just a "self > something" where something is the way of doing that in XStreams. I'd also recommend generic wrapper for any kind of Xtream rather than subclassing specific terminal. In VW the usual way to create the classic streams is via #readStream or #writeStream, so I'd add something like: XTReadStream>>readStream ^XTClassicReadStream on: self XTWriteStream>>writeStream ^XTClassicWriteStream on: self The "classic" guys would then implement the classic API by invoking Xtreams API on their source/destination. You can even subclass those from the classic ReadStream and WriteStream to possibly inherit some behavior and only implement some core part of the protocol. > So, the following is the protocol we use in Fuel for streams, and what I > would love to know is the associated way to do it it XStreams. The left is > classic streams, and after the "->" it is XStreams: > > *Reading:* > > nextNumber: -> ?? > nextPutAll: -> write: > nextStringPut: -> ?? > nextPut: -> put: > nextNumber:put: -> ?? > nextWordPut: -> ?? > > *Writing: > * > nextNumber: -> ?? > next: -> read: It's not as simple, there can be subtle differences. For example in VW it should be something like: next: anInteger ^[ source read: anInteger ] on: Incomplete do: [ :incomplete | IncompleteNextCountError new parameter: incomplete count; raiseRequest ] > nextString -> ?? > next -> get Again, in VW it would be more like: get ^[ source get ] on: Incomplete do: [ :incomplete | EndOfStreamNotification raiseRequest ] > nextWord -> ?? For the specialized element types (Number, String) you can pretty much copy the classic implementations (or even inherit them). Alternatively they seem to fall into a category that we call "interpreting" in Xtreams. What we have is primarily focused on interpreting bytes as various C-types (short, long, float, double,....) for which we have convenient primitives in VW, but the concept can certainly be extended further (the interpretation definitions are pluggable). Unfortunately this part wasn't ported yet from VW. For quick overview you can peek at the end of http://code.google.com/p/xtreams/wiki/Transforms. There's also general marshaling stream available on VW side (built on top of the interpreting streams) which might be helpful example of how one can approach this type of problem with Xtreams. HTH, Martin

May 13, 2011

[Pharo-project] We are still small, don't worry

by Mariano Martinez Peck

Taking the latest PharoCore 1.3 and doing "ScriptLoader new cleanUpForProduction" (mostly cleanUps and tests removal ) Gives me a 6.9 MB image. So we are quite good. Cheers -- Mariano http://marianopeck.wordpress.com

May 13, 2011

Re: [Pharo-project] Adding "Extended Search" to OB context menu

by Mariano Martinez Peck

Lukas. I did a little experiment. It is "working" here. I attach changeset. Two things I am not sure: 1) if I should implement OBTextSelection >> methodSourceWithIt self subclassResponsibility 2) If I should define a shortcut or not Cheers Mariano On Mon, May 9, 2011 at 5:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I am not asking a question. I am just saying that the new OB does not > use the default menu of the Pharo text editor anymore. Like this > developers have full control and can use OB outside a Smalltalk > context. In fact there are already many browsers (CodeCritics, > Changes, Diff, Versions, Bytecode, Comments, etc) where most of the > default menus don't make sense. > > So for you this means that you need to contribute that functionality > in terms of an OBCommand; or use the old keybinding that still is > passed to the text editor as long as OB doesn't reuse it otherwise. > > Lukas > > On Monday, 9 May 2011, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Mon, May 9, 2011 at 1:57 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > > > Sure, that can be done. > > > > The point is that the RB code menu is fully implemented in OB now. > > > > Thanks Lukas. I am not sure if you understand my question. I am not doing > anything at all with RB. So I don't see how this is related to do a right > click in the code pane. > > I attach two screenshots, "oldOB" and "newOB". What I am asking is to > have the "extended search" or the "method soruce with it" from "oldOB". > > > > thanks in advance > > > > Mariano > > > > Previously OB just used the menu provided by Pharo, what caused all > > kinds of problems. "Method source with it" was never an operation > > backed by OB. > > > > Lukas > > > > On 9 May 2011 11:46, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Hi Lukas, > >> > >> do you think it would be possible to use what is currently selected in > >> the code pane to set the default value of the 'Refactor -> Search > >> code' window? > >> > >> > >> ---------- Forwarded message ---------- > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Date: Mon, May 9, 2011 at 10:56 AM > >> Subject: Re: [Pharo-project] Adding "Extended Search" to OB context menu > >> To: Pharo-project(a)lists.gforge.inria.fr > >> > >> > >>> Have you tried 'Refactor -> Search code' ? > >> > >> Thanks Damien. But that's something completely different. What I want > >> to do is to select text, right button, method source with it. That's > >> all. > >> > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> "Lambdas are relegated to relative obscurity until Java makes them > >> popular by not having them." James Iry > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

May 13, 2011

Re: [Pharo-project] http://source.lukas-renggli.ch seems down?

by Alexandre Bergel

Ok, thanks for the info Marcus, Alexandre On 13 May 2011, at 17:16, Marcus Denker wrote: > > On May 13, 2011, at 11:08 PM, Alexandre Bergel wrote: > >> Can it be restarted please? >> > > The problem is that the network operator is down... > > see http://code.google.com/p/pharo/issues/detail?id=4218 > > We should really t hink hard about redundancy... > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 13, 2011

Re: [Pharo-project] http://source.lukas-renggli.ch seems down?

by Marcus Denker

On May 13, 2011, at 11:08 PM, Alexandre Bergel wrote: > Can it be restarted please? > The problem is that the network operator is down... see http://code.google.com/p/pharo/issues/detail?id=4218 We should really t hink hard about redundancy... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 13, 2011

[Pharo-project] http://source.lukas-renggli.ch seems down?

by Alexandre Bergel

Can it be restarted please? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 13, 2011

Re: [Pharo-project] Problem in OBCmdCreateCategory (and probably Rename...)

by Lukas Renggli

I cannot reproduce the problem. What image are you using? Lukas On 13 May 2011 16:14, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > I'M not sure how to send patches and so we go. > > the execute implementation of the above class give an error > while Â calling self categories sorted > > Set does not understand ordered is the message. > > Well Â I hacked it like this: > execute > Â Â Â Â | categories category before | > Â Â Â Â categories := self categories asOrderedCollection sorted. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^^^^^^^^^^^^^^^^^^^ > Â Â Â Â category := OBCompletionRequest new > Â Â Â Â Â Â Â Â assisted: true; > Â Â Â Â Â Â Â Â collection: categories; > Â Â Â Â Â Â Â Â prompt: 'Add Category'; > Â Â Â Â Â Â Â Â signal. > Â Â Â Â category isNil ifTrue: [ ^ self ]. > Â Â Â Â before := requestor children > Â Â Â Â Â Â Â Â at: requestor selection + 1 > Â Â Â Â Â Â Â Â ifAbsent: [ nil ]. > Â Â Â Â target organization > Â Â Â Â Â Â Â Â addCategory: category > Â Â Â Â Â Â Â Â before: (before isNil > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ before name ]). > Â Â Â Â self > Â Â Â Â Â Â Â Â select: (target categoryNodeNamed: category) > Â Â Â Â Â Â Â Â with: requestor announcer > > Probably bad as hell but "it works" > > Regards > Friedrich > > -- Lukas Renggli www.lukas-renggli.ch

May 13, 2011

Re: [Pharo-project] SqueaSource is Down

by Fabrizio Perin

Ok i removed the files with a Cyrillic name that were causing the problem. Now the project "Krestianstvo" in not in the repo anymore. The files are on the desktop of macamis. If the owner wants the files ask Jorge to sent them to him. I will be in holiday for 2 weeks without internet connection. Thanks to lukas i also added a check that simply verify if the file name is valid, if it is ss save the files otherwise not. Cheers, Fabrizio 2011/5/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > It will change soon. > > What we could do is to use the gemstone based squeaksource running at > gemstone > but I'm sure that if we invade it people will be happy. > > Stef > > > ... and they changed the passwd so I can not do anything. > > > > I feel very unprofessional now. > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > >

May 13, 2011