(my message seems to have gotten lost....resending)
From: "Andreas Raab" <***@gmx.de>
Sent: Saturday, August 28, 2010 11:42 AM
To: "The general-purpose Squeak developers list"
Subject: [squeak-dev] Cryptography in trunk (Re: [Cryptography Team]
Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)
Post by Andreas Raab
(changed subject for better tracking)
Post by Rob Withers
Thanks, Rob. I did a quick check and it's pretty close to what I was
thinking in terms of structure (although I would rename CryptoCerts to
just Certificates but that's a minor issue). As for inclusion, I *think*
we should probably include CryptoCore and CryptoExtras in trunk but not
the certificates package. My reasoning here is that people usually need
the key crypto algorithm and cert handling usually goes together with
other things (like SSL etc) and should probably be loaded when that is
loaded. This is also partly why I would prefer a package Certificates
because it would mean that the "Cryptography" stuff (Crypto-Core,
Crypto-Extras, Crypto-Tests) is in trunk, whereas the Certificate and SSL
package remain in the Cryptography repository on SqueakSource. But I'd
like to hear other opinions on this.
Also, I've checked the CryptoCore package and we'll need to do something
about the extensions at some point. Several of them are reasonable (in
fact, I like some of them very much like ByteArray bit manipulation which
is extremely useful and should be part of the regular BA protocol) but
some of them are duplicates (ByteArray unsignedLongAt:) and others are
just obscure (String destroy etc). However, except from the conflicts we
probably don't have to address these in the first round.
I am glad this is moving forward. A few questions come to mind.
1) What should be the final package naming? I chose CryptoCore, etc. You
think CryptoCerts should be Certificates. Bert and Colin had suggestions
for Crypto-Core and Tests (I especially like Colin's suggestion). I have
renamed the packages here to Crypto-Core, etc, but not Certificates yet
(which has extension protocol cat name changes), but I have not pushed them
to Inbox. Given final naming, I can push to Inbox and you can clean out old
stuff. So what's the final naming decision?
2) Are there packages in trunk that are not built in the trunk image? If
not, where do alternate packages live? I wonder where Certificates will end
3) I published SSL to Inbox. Same question as #2.
4) Certificates. Perhaps better suited to its own thread. Currently used
by SSL's SSLCertificateStore, which is an in-memory certificate store of
certificates and their private keys and root CA certificates. I do not
recall the level of support to passing certificate chains. Several topics
here. Should we establish a persistent Squeak certificate store, where we
have a key database file, encrypted, and a cert database file not encrypted?
Kinda like NSS. We could apply for a Squeak CA certificate from Verisign or
someone and then have a way to allow Squeakers to apply for a signed cert
from the Squeak CA. (generate CSR from local certStore, submit for Cert,
...) Does this help your SqueakSSL stuff? Thoughts on all I have written?