On 06/29/10 22:36, Rob Withers wrote:
Hi David,
I am CCing the squeak-dev list.
I had tried to contact Ron over the weekend, since he is the admin for the SqueakSource Cryptography package. I needed to add you as a member of the Crypto team. That's right, you are a member now. I didn't hear from him so the email address may be bad. We'll see if we hear from him in the future. I hope so.
Do you have the link to the Crypto mailing list?
Yes, do we move this discussion there?
I agree we should do this in public. I would suggest the squeak-dev list.
We may have several "forks" and/or subsequent work done from the root package.
The root package for SSL is in the Monticello repository http://www.squeaksource.com/Cryptography, but it may not be the latest. I think that the SSL package there is the latest...Whoa! I just checked again and new SSL packages were inserted 2 days ago. The latest there used to be SSL-rww.4.mcz and now there is a SSL-jrd.12.mcz.
Yes, I copied the mods from the croquet-source repo. SSL was easy as there were no forks. jrd.12 is the version I am using and it is working pretty well. I did have some intermittent failures when I was first moving to Squeak4.1 but those might have been due to errant versions of the Cryptography package. I will do a fresh build and verify this version.
The root package for Cryptography is in the same repository, but it is less clear which is the latest and greatest. There is a mixture of version numbers. I am using Cryptography-cmm.13.mcz. All tests pass except for a Rindael test and an X509 test (due to bad validity dates).
I know there is packages in http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like the ones now in the Cryptography repository above. The Cryptography packages in Contributions look like they are also in the Cryptography repository, but mixed up with other work. In Contributions, there is the sequence of packages:
Cryptography-RJT.10.mcz (the root package) Cryptography-jrd.11.mcz Cryptography-jrd.12.mcz Cryptography-mtf.13.mcz
These are interwoven with other packages in the Cryptography repository, with the same version numbers.
Right, there are several forks to be reconciled. FWIW I am running mtf.13 as none of the versions from the original Cryptography repo had ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this version fails CryptoX509Test>>testSignatureValidation (as well as the Rindael test you mentioned). I am hoping the harvesting from the other forks will take care of this.
At this point all of the croquet-source versions are in their rightful place in the Cryptography project on SqueakSource. The SqueakSource project contains no license information. It would be a very good idea to assign a license so that all contributions to this repo are automatically assigned that license. I think Ron needs to guide this process as this is his baby. At the very least Ron and all other contributors need to be asked to accept whatever license is selected or we will have to re-write those portions. I am happy to try to track everyone down but not without making sure Ron is receptive to this.
David
-------------------------------------------------- From: "C. David Shaffer" cdshaffer@acm.org Sent: Wednesday, June 30, 2010 12:11 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org; "Ron Teitelbaum" Ron@USMedRec.com; "Squeak Cryptography" cryptography@lists.squeakfoundation.org Subject: [squeak-dev] Re: Cryptography
On 06/29/10 22:36, Rob Withers wrote:
Hi David,
I am CCing the squeak-dev list.
I had tried to contact Ron over the weekend, since he is the admin for the SqueakSource Cryptography package. I needed to add you as a member of the Crypto team. That's right, you are a member now. I didn't hear from him so the email address may be bad. We'll see if we hear from him in the future. I hope so.
Do you have the link to the Crypto mailing list?
Yes, do we move this discussion there?
We can discuss in one or both. Your choice. I think the most visibility will be from discussing it on squeak-dev.
I agree we should do this in public. I would suggest the squeak-dev list.
We may have several "forks" and/or subsequent work done from the root package.
The root package for SSL is in the Monticello repository http://www.squeaksource.com/Cryptography, but it may not be the latest. I think that the SSL package there is the latest...Whoa! I just checked again and new SSL packages were inserted 2 days ago. The latest there used to be SSL-rww.4.mcz and now there is a SSL-jrd.12.mcz.
Yes, I copied the mods from the croquet-source repo. SSL was easy as there were no forks. jrd.12 is the version I am using and it is working pretty well. I did have some intermittent failures when I was first moving to Squeak4.1 but those might have been due to errant versions of the Cryptography package. I will do a fresh build and verify this version.
Ah, excellent. I also have SSL-jrd.12.mcz loaded.
I have one class in SSL that I use in SqueakElib. When I load both, it rips it from one location and places it in another (different categories). Stéphane Ducasse has pointed me to metacello (http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-fo...), which is a package management system. It allows one to load dependent packages. You might want to look into it.
The root package for Cryptography is in the same repository, but it is less clear which is the latest and greatest. There is a mixture of version numbers. I am using Cryptography-cmm.13.mcz. All tests pass except for a Rindael test and an X509 test (due to bad validity dates).
I know there is packages in http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like the ones now in the Cryptography repository above. The Cryptography packages in Contributions look like they are also in the Cryptography repository, but mixed up with other work. In Contributions, there is the sequence of packages:
Cryptography-RJT.10.mcz (the root package) Cryptography-jrd.11.mcz Cryptography-jrd.12.mcz Cryptography-mtf.13.mcz
These are interwoven with other packages in the Cryptography repository, with the same version numbers.
Right, there are several forks to be reconciled. FWIW I am running mtf.13 as none of the versions from the original Cryptography repo had ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this version fails CryptoX509Test>>testSignatureValidation (as well as the Rindael test you mentioned). I am hoping the harvesting from the other forks will take care of this.
I need to fix the X509 error.
At this point all of the croquet-source versions are in their rightful place in the Cryptography project on SqueakSource. The SqueakSource project contains no license information. It would be a very good idea to assign a license so that all contributions to this repo are automatically assigned that license. I think Ron needs to guide this process as this is his baby. At the very least Ron and all other contributors need to be asked to accept whatever license is selected or we will have to re-write those portions. I am happy to try to track everyone down but not without making sure Ron is receptive to this.
It was understood that we were doing work under the MIT license. It was open development for anyone's use. I set the license in the Cryptography repo.
Rob
David
Hello,
Here I am. Very nice to see some movement on cryptography. Let me know if there is something I can do to help.
Rob it is very nice to hear from you. I hope you are doing well. Please feel free to run with the Cryptography Team if you have time. I'll try to pay a bit more attention.
All the best,
Ron Teitelbaum
-----Original Message----- From: Rob Withers [mailto:reefedjib@yahoo.com] Sent: Wednesday, June 30, 2010 2:10 PM To: The general-purpose Squeak developers list; Ron Teitelbaum; Squeak Cryptography Subject: Re: [squeak-dev] Re: Cryptography
From: "C. David Shaffer" cdshaffer@acm.org Sent: Wednesday, June 30, 2010 12:11 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org; "Ron Teitelbaum" Ron@USMedRec.com; "Squeak Cryptography" cryptography@lists.squeakfoundation.org Subject: [squeak-dev] Re: Cryptography
On 06/29/10 22:36, Rob Withers wrote:
Hi David,
I am CCing the squeak-dev list.
I had tried to contact Ron over the weekend, since he is the admin for the SqueakSource Cryptography package. I needed to add you as a member of the Crypto team. That's right, you are a member now. I didn't hear from him so the email address may be bad. We'll see if we hear from him in the future. I hope so.
Do you have the link to the Crypto mailing list?
Yes, do we move this discussion there?
We can discuss in one or both. Your choice. I think the most visibility will be from discussing it on squeak-dev.
I agree we should do this in public. I would suggest the squeak-dev list.
We may have several "forks" and/or subsequent work done from the root package.
The root package for SSL is in the Monticello repository http://www.squeaksource.com/Cryptography, but it may not be the latest. I think that the SSL package there is the latest...Whoa! I just checked again and new SSL packages were inserted 2 days ago. The latest there used to be SSL-rww.4.mcz and now there is a SSL-
jrd.12.mcz.
Yes, I copied the mods from the croquet-source repo. SSL was easy as there were no forks. jrd.12 is the version I am using and it is working pretty well. I did have some intermittent failures when I was first moving to Squeak4.1 but those might have been due to errant versions of the Cryptography package. I will do a fresh build and verify this version.
Ah, excellent. I also have SSL-jrd.12.mcz loaded.
I have one class in SSL that I use in SqueakElib. When I load both, it rips it from one location and places it in another (different categories). Stéphane Ducasse has pointed me to metacello (http://gemstonesoup.wordpress.com/2009/08/25/metacello-package- management-for-monticello/), which is a package management system. It allows one to load dependent packages. You might want to look into it.
The root package for Cryptography is in the same repository, but it is less clear which is the latest and greatest. There is a mixture of version numbers. I am using Cryptography-cmm.13.mcz. All tests pass except for a Rindael test and an X509 test (due to bad validity dates).
I know there is packages in http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like the ones now in the Cryptography repository above. The Cryptography packages in Contributions look like they are also in the Cryptography repository, but mixed up with other work. In Contributions, there is the sequence of packages:
Cryptography-RJT.10.mcz (the root package) Cryptography-jrd.11.mcz Cryptography-jrd.12.mcz Cryptography-mtf.13.mcz
These are interwoven with other packages in the Cryptography repository, with the same version numbers.
Right, there are several forks to be reconciled. FWIW I am running mtf.13 as none of the versions from the original Cryptography repo had ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this version fails CryptoX509Test>>testSignatureValidation (as well as the Rindael test you mentioned). I am hoping the harvesting from the other forks will take care of this.
I need to fix the X509 error.
At this point all of the croquet-source versions are in their rightful place in the Cryptography project on SqueakSource. The SqueakSource project contains no license information. It would be a very good idea to assign a license so that all contributions to this repo are automatically assigned that license. I think Ron needs to guide this process as this is his baby. At the very least Ron and all other contributors need to be asked to accept whatever license is selected or we will have to re-write those portions. I am happy to try to track everyone down but not without making sure Ron is receptive to this.
It was understood that we were doing work under the MIT license. It was open development for anyone's use. I set the license in the Cryptography repo.
Rob
David
On 07/01/10 19:37, Ron Teitelbaum wrote:
Hello,
Here I am. Very nice to see some movement on cryptography. Let me know if there is something I can do to help.
I've merged all of the forks, I think. I do have a couple questions but I'll come back to those later. Rob suggested creating a Metacello configuration for people to use to load things. That is priority #2 for me...right after the merge.
David
I'm calling Cryptography-rww.16 the "trunk" version. The only branch that has changes that aren't in the trunk looks like the "cmm" branch. Below is a summary of the change logs from that branch. It started from RJT.6 and moved linearly to cmm.13.
Among these changes are:
1) cmm.12 which fixed an Undelcared var and needs to be applied to the trunk
2) cmm.11 which drops extensions to ThirtyTwoBitRegister which were absorbed in Squeak3.11 and are also present in 4.1. Do we want to continue to include them in Cryptography package? My suggestion is to move them from Cryptography to CryptoThirtyTwoBitRegisterExtensions which will only be loaded in pre-Squeak3.11 images. I don't know anything about Metacello yet but maybe we can make it smart enough to load these in older images.
3) cmm.8 contains #destroy in ElGamalKeyGenerator and String which are not in trunk. The only user of the former is DiffieHellman which provides no path to send destroy to the generator unless it is sent by a third party (df generator destroy). Methods are untested.
4) cmm.9 which adds a species check in ASN1Object>>=. This change is not in the trunk but there are no tests that fail as a result of its absence. Chris: do you remember your motivation for adding this?
For now I'll fix "1" and await feedback on others.
David
Summary of cmm branch changes:
cmm.7 changes: ****not in trunk
- Added ElGamalKeyGenerator>>#destroy to clean-up in-memory secrets. - Removed faulty optimization of Fortuna>>#nextInt:. Now inherits slower but correct one from superclass.
cmm.8 changes: ****not in trunk
- Added String>>#destroy and HashFunction class>>#doubleHashMessage:.
cmm.9 changes: ****not in trunk
- Fix for ASN1Object>>#=.
cmm.10 changes: **** fixed in trunk
- Fixed syntax error in SHA1>>#hashInteger:seed:.
cmm.11 changes: **** not in trunk
- For Squeak 3.11. Removed methods from ThirtyTwoBitRegister which 3.11 absorbed. This allows this package to load into 3.11 without causing a dirty System package.
cmm.12 changes: **** not in trunk --- NEEDS TO BE DONE IN TRUNK
- Removed methods referring to old 'Picker' classVar. It was changed to a class-inst var.
Note: class-inst var is in RandomGenerator
cmm.13 changes: At least partially in trunk. Too many changes to verify but most seem to have been converted in trunk.
- FixUnderscores
Thanks for taking care of this David. Comments inlined:
- cmm.11 which drops extensions to ThirtyTwoBitRegister which were
absorbed in Squeak3.11 and are also present in 4.1. Do we want to continue to include them in Cryptography package? My suggestion is to move them from Cryptography to CryptoThirtyTwoBitRegisterExtensions which will only be loaded in pre-Squeak3.11 images. I don't know anything about Metacello yet but maybe we can make it smart enough to load these in older images.
Well, legacy apps still using 3.9 probably don't want to upgrade to the latest Cryptography before upgrading to Pharo or Squeak 4.1+..
I've read about Metacello, but not yet taken the time to get deeply into it. My sense is that we don't need it to solve this issue. Simply a more generic package for the purpose of backward compatibility, i.e., a "Crypto3.9Compatibility" package, could house these extnesions?
Still, I'd bet if you just merged my version, the removal of these extensions from Crypto, and do nothing else, there will be no complaints.
- cmm.8 contains #destroy in ElGamalKeyGenerator and String which are
not in trunk. The only user of the former is DiffieHellman which provides no path to send destroy to the generator unless it is sent by a third party (df generator destroy). Methods are untested.
Please include these important changes. ElGamalKeyGenerator is used directly by *clients*, who call #destroy. After generating a ElGamal key pair and safely encrypting and saving it, it is important to then destroy the generator so that its sensitive numbers aren't accidently left hanging around in the image..!
These changes are essential, they should be merged.
DiffieHellman uses ElGamalKeyGenerator for a different purpose (authentication)..
- cmm.9 which adds a species check in ASN1Object>>=. This change is
not in the trunk but there are no tests that fail as a result of its absence. Chris: do you remember your motivation for adding this?
Yes, of course, very bad breakage. Any class implementing #= must allow for the possibility that the comparand will not be of the same type. Virtually every #= implementation in the system does this.
A simple test:
self deny: (ASN1ObjectId fromString: '1.3.6.1.5.5.7.8.5') = Object new
fails.
For now I'll fix "1" and await feedback on others.
Thanks again, Chris
cryptography@lists.squeakfoundation.org
-
C. David Shaffer -
Chris Muller -
Rob Withers -
Ron Teitelbaum