Well, I can see you all waited for me to go on vacation for one week
before going hog-wild on the Cryptography package!  :)

I mostly like the simple split that's been done; so we won't run into
the same problems we did 5 years ago when Cryptography was split.
However, a couple of questions:

First, why rename the package to "Crypto?"  The quality of the package
is worth the original full name, "Cryptography".

Second, I wonder about the semantics of "Core" vs. "Extra".  This
ambiguity was part of the issue with the original breakup of the
Cryptography package by the Cryptography team years ago that led to
its re-integration into one big package.

For example, PasswordSaltAndStretch could be considered a "core" smart
thing to do with all passwords.  It's small and simple.  So why
shouldn't be part of the "core"?  Keyholder could be considered for
core for the same reasons.

That would leave just those obsolete ciphers left in Extras and,
therefore, an opportunity to reduce the ambiguity of the package name;
"Cryptography-Obsolete" ???

 - Chris


> 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.

#destroy is implemented on several byte-based objects to wipe out a
sensitive key bytes immediately after use, so that it won't hang
around exposed in memory or, worse, get saved into the image.