- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Port of Cryptography to Pharo

by Mariano Martinez Peck

2009/5/23 John McIntosh <johnmci(a)smalltalkconsulting.com> > Ok, in the past I've built the DES plugin for the macintosh. > However I should point out that Cryptography should NOT be made part of > the base VM. > I didn't understand you. Cryptography uses several plugins, not only DES. Are you talking Cryptography in general or just DES? In addition you said the Cryptography should not be included in the base VM. Did you wanted to say base image ? Greetings, Mariano > Why? Well the USA government then wants you to fill out export paperwork if > you are USA company or selling product thru the USA that someone that > doesn't live in the USA could buy. An example of this is when you submit > apps to the Apple iPhone app store, then you are asked if the product > includes any encryption and if you have done the paperwork. > > Yes I know this is a irksome rule, but people should be aware of the > implications. > > 2009/5/23 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Did someone commit any kind of magic to Pharo core orCryptography packge ? >> I just prepared a latest image to start working on it but I see only 3 red >> tests. Those are: testDES, testDES2 and testDSASigninAndVerifying. >> >> And all of them fail because of the same problem: a primitive has failed. >> The primitive is >> >> primCookKey: aByteArray mode: flag to: cooked >> <primitive: 'primitiveDESCookKey' module: 'DESPlugin'> >> ^ self primitiveFailed >> >> I look here: http://code.google.com/p/pharo/wiki/VMPluginOverview but I >> didn't found it. I don't have that plugin in my Exupery VM. >> >> Perhaps downloading VMMaker and try to generate the plugin is a good idea >> but I never even download VMMaker haha >> >> Anyway, is this important? >> >> Cheers, >> >> Mariano >> >> >> >> >> >> On Fri, May 22, 2009 at 1:42 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: >> >>> Stef, >>> >>> I proposed that a while ago, but there was a stunning lack of response. >>> The offer is still good however; I'd welcome a group effort to tackle it. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: >>> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane >>> Ducasse >>> Sent: Friday, May 22, 2009 9:55 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Port of Cryptography to Pharo >>> >>> Hi guys >>> >>> Why don;t you join forces and create a Cryptography package which work >>> for pharo and for you. >>> Mariano I still would love to know the method of integer that are missing >>> >>> Stef >>> >>> On May 22, 2009, at 4:47 PM, Jan van de Sandt wrote: >>> >>> > Hello, >>> > >>> > I faced the same problem with Cloudfork-AWS. This project required the >>> > Cryptography package for generating the signatures using SHA and for >>> > generating MD5 hash values. >>> > >>> > When I had problems loading the package in Pharo and I learned that >>> > the package was no longer maintained I copied the classes I required >>> > to a Cloudfork package. I needed the MD5, SHA1 and SHA256 classes. I >>> > renamed them to CFMD5, CFSHA1 and CFSHA256, I also prefixed all the >>> > methods in the required class extensions with cf. For example >>> > ThirtyTwoBitRegister>>cfBitShift: anInteger. You can use a simular >>> > approach for Glorp. >>> > >>> > Jan. >>> > >>> > PS: Another dependency of Cloudfork is a HTTP client. I'm now >>> > playing around with the CurlPlugin, this plugin works very well. >>> > Things like supporting https become real easy >>> > >>> > 2009/5/22 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> > >>> > >>> > On Fri, May 22, 2009 at 9:18 AM, Ramiro Diaz Trepat < >>> ramiro.diaz.trepat(a)jpmorgan.com >>> > > wrote: >>> > I'm really sorry to hear it is no longer being maintained. >>> > It was a necessary package to connect to properly set up Postgres >>> > databases, that requiere sending password hashes with SHA-1. We >>> > will probably face this kind of need when interacting with the >>> > outside world in general. >>> > >>> > Yes. That's why I saw it. I am trying to make Glorp to work in >>> > Pharo, but as you know Glorp in Squeak only works with Postgres. And >>> > the native postgres driver requieres cryptography package when you >>> > use md5 :( >>> > >>> > Just for now, I disable md5 from my postgres and use "password" auth- >>> > method. With this, cryptography is not needed. However, this is not >>> > an option in a production enviorment. >>> > >>> > Cheers, >>> > >>> > Mariano >>> > >>> > >>> > It was a fantastic package, I wonder why the maintainers droped it. >>> > I suppose maintaining crypto frameworks up to date, with no >>> > vulnerabilities, is a lot of work. >>> > Sorry for venting out my sadnes to the list. >>> > Cheers >>> > >>> > r. >>> > >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: >>> pharo-project-bounces(a)lists.gforge.inria.fr >>> > ] On Behalf Of StÃ©phane Ducasse >>> > Sent: 22 May 2009 11:08 >>> > To: Pharo-project(a)lists.gforge.inria.fr >>> > Subject: Re: [Pharo-project] Port of Cryptography to Pharo >>> > >>> > Ok I thought the cryptology package was working well and maintained. >>> > >>> > Stef >>> > >>> > On May 22, 2009, at 11:58 AM, Schwab,Wilhelm K wrote: >>> > >>> > > Agreed: I mentioned both curl and OpenSSL - we should embrace both. >>> > > AFACT, the cryptography package is a thing of the past, and we >>> > > should look to active projects. Tell me where I'm wrong, please. >>> > > >>> > > Another reality, fair or not: if we were to take on the enormous >>> > > burden of maintaining the cypto package, there would always be >>> > > questions about security holes we left open. The same will be true >>> > > of OpenSSL, but there is (not always fair) credibility in numbers >>> > > widely known projects. There will be would-be users of Pharo who >>> > > will want OpenSSL for its reputation, and who would question a home- >>> > > grown solution. >>> > > >>> > > Bill >>> > > >>> > > >>> > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: >>> pharo-project-bounces(a)lists.gforge.inria.fr >>> > > ] On Behalf Of Fernando olivero >>> > > Sent: Friday, May 22, 2009 4:20 AM >>> > > To: Pharo-project(a)lists.gforge.inria.fr >>> > > Subject: Re: [Pharo-project] Port of Cryptography to Pharo >>> > > >>> > > >>> > > Just a comment, >>> > > >>> > > you could use the new AlienFFI framework to comunicate with curl. >>> > > Or reify any C library you want in Pharo. >>> > > >>> > > Fernando >>> > > >>> > > >>> > > On May 22, 2009, at 5:04 AM, Schwab,Wilhelm K wrote: >>> > > >>> > >> The most recent post on the crytography mailing list starts out as >>> > >> follows: >>> > >> >>> > >> Since the Cryptography Team doesn't exists anymore, the >>> > >> Cryptography package is not maintained by anyone. The SSL >>> > >> implementation doesn't allow easy debugging, you can't just turn on >>> > >> logging to see what's happening. Following the state machine >>> > >> transitions should give you the answer why the handshake isn't >>> > >> succeding. It might be related to certificates or TLS->SSL3 >>> > >> fallback. If I were you, I would go with curl. >>> > >> I think it is time to write a wrapper around open SSL in addition >>> > >> to looking at the curl plugin. Trying to write cryptography code >>> > >> from scratch and get and keep it right is a huge effort, and pretty >>> > >> avoidable, and IMHO, better avoided by letting others do the job. >>> > >> Ever read Sun Tzu? >>> > >> >>> > >> Bill >>> > >> >>> > >> >>> > >> >>> > >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: >>> pharo-project-bounces(a)lists.gforge.inria.fr >>> > >> ] On Behalf Of Mariano Martinez Peck >>> > >> Sent: Thursday, May 21, 2009 8:51 PM >>> > >> To: Pharo Development >>> > >> Subject: [Pharo-project] Port of Cryptography to Pharo >>> > >> >>> > >> I don't know if there is anyone of the developers of the package >>> > >> Cryptography but is someone is willing to do the port of it to >>> > >> Pharo? Most tests are break and it seems not to work because lots >>> > >> of Cryptography methods where in classes like SmallInteger and >>> > >> these methods were removed in Pharo. >>> > >> >>> > >> Regards, >>> > >> >>> > >> Mariano >>> > >> <ATT00001.txt> >>> > > >>> > > _______________________________________________ >>> > > Pharo-project mailing list >>> > > Pharo-project(a)lists.gforge.inria.fr >>> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > This email is confidential and subject to important disclaimers and >>> > conditions including on offers for the purchase or sale of >>> > securities, accuracy and completeness of information, viruses, >>> > confidentiality, legal privilege, and legal entity disclaimers, >>> > available at http://www.jpmorgan.com/pages/disclosures/email. >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2009

Re: [Pharo-project] More relicensing

by Lukas Renggli

> I'm stills doubtful about asFloatD/E/Q. I've never used these methods either, but they are part of the ANSI Standard. I think that having an accurate coverage of the standard is central to Pharo, even if this is not used from within Pharo itself. > Anyone has the ANSI Standard > specification? Ask Google. There is a draft of revision 1.9 online. I don't know if there are newer versions. Probably not. > I don't want to look at the old code to implement the new > and from the message names isn't clear to me what is supposed to do. #asFloatD/E/Q is the same as #asFloat. This is only meaningful for Smalltalk that support floats of different sizes. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 24, 2009

Re: [Pharo-project] can you give feedabck to alain on preference cleaning

by Alain Plantec

Igor Stasenko a Ã©crit : > 2009/5/22 Alain Plantec <alain.plantec(a)free.fr>: > >> Igor Stasenko a Ã©crit : >> >>> annotation pane is very useful thing. This is first thing i turning >>> on, when start using new image. >>> >>> >> Hi Igor, >> >> how do you makes it work on old browser. It is never updated. >> However, It is well implemented by OB, and works very well with it. >> So the question is can I remove it from old browser (from the core). >> We can keep OB implementation and introduce an OB specific setting for it. >> >> > I'm using OB in Pharo, so removing this from old browsers doesn't > hurts much, i guess :) > ok, OB will not be touched. Thank for your feedback Igor. Cheers Alain > >> Regarding the old browser, It is very badly implemented and introduces >> very dirty dependences. >> See pieces of code below. >> We hare removing etoy or bookmorph for the same reasons. >> >> CodeHolder>>refreshAnnotation >> "If the receiver has an annotation pane that does not >> bear unaccepted edits, refresh it" >> (aPane := self dependents >> detect: [:m | (m inheritsFromAnyIn: #('PluggableTextView' >> 'PluggableTextMorph' )) >> and: [m getTextSelector == #annotation]] >> ifNone: []) >> ifNotNil: [:aPane | aPane hasUnacceptedEdits >> ifFalse: [aPane update: #annotation]] >> >> other "cool" pieces of code: >> PluggableTextMorph>>accept >> .... >> ok := self acceptTextInModel. >> ok == true >> ifTrue: [self setText: self getText. >> self hasUnacceptedEdits: false. >> (model dependents >> detect: [:dep | (dep isKindOf: PluggableTextMorph) >> and: [dep getTextSelector == #annotation]] >> ifNone: []) >> ifNotNilDo: [:aPane | model changed: #annotation]]. >> ... >> PluggableTextMorph>>cancel >> self setText: self getText. >> self setSelection: self getSelection. >> getTextSelector == #annotation >> ifFalse: [(aPane := model dependents >> detect: [:dep | (dep isKindOf: PluggableTextMorph) >> and: [dep getTextSelector == #annotation]] >> ifNone: []) >> >> >> ifNotNil: [:aPane | model changed: #annotation]] >> >> Cheers >> Alain >> >>> 2009/5/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>>> http://code.google.com/p/pharo/issues/detail?id=810 >>>> Especially for the annotation panes in the old browser. >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > >

May 24, 2009

[Pharo-project] testing morphs

by Tudor Girba

Hi, I am looking for a testing framework or something similar that would allow me to write tests for Morphic-based user interfaces (for example to allow me to simulate pressing on buttons and to check state of morphs). Can anyone point me to one? Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

May 24, 2009

Re: [Pharo-project] More relicensing

by Gabriel Cotelli

Ok, I would try to rewrite then BlockContext>>argumentCount Character class>>codePoint: Character>>codePoint and the following: 'DictionaryTest' >> testOccurrencesOf 'DictionaryTest' >> testIncludesAssociationNoValue 'HeapTest' >> testAdd 'HeapTest' >> testFirst 'HeapTest' >> testSortBlock 'HeapTest' >> testHeap 'HeapTest' >> testDo 'HeapTest' >> testRemove DependentsArray size I'm stills doubtful about asFloatD/E/Q. Anyone has the ANSI Standard specification?, I don't want to look at the old code to implement the new and from the message names isn't clear to me what is supposed to do. Thanks, Gabriel On Sun, May 24, 2009 at 4:35 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > BlockContext>>argumentCount > > Character class>>codePoint: > > Character>>codePoint > > Number>>asFloatD > > Number>>asFloatE > > Number>>asFloatQ > > > > In the last Pharo-Dev there's no senders of that methods. > > Can I remove them? Or there's something else I should check? > > These methods are all part of the ANSI standard. Seaside requires the first > 3. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by Gabriel Cotelli

Hi Stef, On Sun, May 24, 2009 at 4:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi gabriel > > I checked your code and what would be good is to do the following: > > Float class>>one > could be > ^ 1.0 That was the first thing I do... but later i noticed that the code would remain the same that the older... If it's not a problem I changed that again to this implementation. > > > It would be nice if nicolas could have a look at them before I push > them in the release stream > > Then it would be good to profile a bit them because with numbers it > would be good to have > the fastest we can. > > Stef > > > > On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > > > Hi, > > > > I re-implemented > > Number>>reciprocal > > Float>>reciprocal > > Fraction>>reciprocal > > Fraction>>one > > Integer>>one > > Float>>one > > > > so now are license clean. > > > > I push the changes on Pharo-Inbox (I hope, if I do the right > > procedure) and open the Issue 843 in the tracker. According with the > > instructions in the "How to contribute" wiki page I need to change > > the state of issue to "Fixed", however I can't find that option. > > Maybe I need to be a member of the project in google code?... > > > > Just in case find attached the.cs and Monticello packages generated. > > Please somebody must review the changes.. > > > > Thanks, > > Gabriel > > <MonticelloPackages.zip><RelicensingNumberRelated. > > 1.cs>_______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2009

[Pharo-project] BytecodeAgnosticMethodNode ???

by Carlos Crosetti

while evaluating | table1 | table1 := GridMorph withColumns: #(one two). table1 addNewRow: #('uk' 'london'). table1 openInWorld. got a DNU notifier with BytecodeAgnosticMethodNode(Object)>>doesnotUderstand: #geherate Compiler>>evaluate:in:to:notifying:iffail:logged: what`s that??

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by Nicolas Cellier

Oh, If my blessing is required, then I would do what anyother would do: - look at tests results, - then at implementation. I see ZeroDivide exceptions are raised. They are raised a little later with different stack depth and different dividend, but I don't know specifications about that. I see implementation is simple and hard to attack (in a hacker's POV). So please proceed and include this changes. And post a copy of the .cs at http://bugs.squeak.org/view.php?id=6989 Just one remark about tests: self assert: Float one = 1.0. might be completed with: self assert: Float one isFloat. But personnally, I would not even include this in tests because I don't really care of #one specification: IMO, this is an implementation detail, not a usefull API, and has few value per se. The essential reason for that behavior, and that should be in tests is: self assert: (2.0 raisedTo: 0.0) = 1.0; assert: (2.0 raisedTo: 0.0) isFloat. I also see this test is missing, but behavior is correct: self should: [SmallInteger maxVal + 1 / 0] raise: ZeroDivide. Last, there are some IEEE 754 behaviors I will always find surprising, like (0.0 raisedTo: Float infinity) and the like - see http://bugs.squeak.org/view.php?id=6781 , but that was not the subject :) Don't know if we should write tests to document that behaviour... Nicolas 2009/5/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi gabriel > > I checked your code and what would be good is to do the following: > > Float class>>one > could be > ^ 1.0 > > It would be nice if nicolas could have a look at them before I push > them in the release stream > > Then it would be good to profile a bit them because with numbers it > would be good to have > the fastest we can. > > Stef > > > > On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > >> Hi, >> >> I re-implemented >> Number>>reciprocal >> Float>>reciprocal >> Fraction>>reciprocal >> Fraction>>one >> Integer>>one >> Float>>one >> >> so now are license clean. >> >> I push the changes on Pharo-Inbox (I hope, if I do the right >> procedure) and open the Issue 843 in the tracker. According with the >> instructions in the "How to contribute" wiki page I need to change >> the state of issue to "Fixed", however I can't find that option. >> Maybe I need to be a member of the project in google code?... >> >> Just in case find attached the.cs and Monticello packages generated. >> Please somebody must review the changes.. >> >> Thanks, >> Gabriel >> <MonticelloPackages.zip><RelicensingNumberRelated. >> 1.cs>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2009

[Pharo-project] Could not load VMMaker in 10315

by StÃ©phane Ducasse

Hi I did ScriptLoader loadFFI Then loaded VMMaker-dtl.122 Then proceeded when asked about klatt. And I got Cannot compile -- stack including temps is too deep what did I miss? Stef

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by StÃ©phane Ducasse

Hi gabriel I checked your code and what would be good is to do the following: Float class>>one could be ^ 1.0 It would be nice if nicolas could have a look at them before I push them in the release stream Then it would be good to profile a bit them because with numbers it would be good to have the fastest we can. Stef On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > Hi, > > I re-implemented > Number>>reciprocal > Float>>reciprocal > Fraction>>reciprocal > Fraction>>one > Integer>>one > Float>>one > > so now are license clean. > > I push the changes on Pharo-Inbox (I hope, if I do the right > procedure) and open the Issue 843 in the tracker. According with the > instructions in the "How to contribute" wiki page I need to change > the state of issue to "Fixed", however I can't find that option. > Maybe I need to be a member of the project in google code?... > > Just in case find attached the.cs and Monticello packages generated. > Please somebody must review the changes.. > > Thanks, > Gabriel > <MonticelloPackages.zip><RelicensingNumberRelated. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2009