[squeak-dev] Cryptography in trunk (Re: [Cryptography Team] Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

Rob Withers reefedjib at gmail.com
Sat Aug 28 18:34:33 UTC 2010


(my message seems to have gotten lost....resending)

--------------------------------------------------
From: "Andreas Raab" <andreas.raab at gmx.de>
Sent: Saturday, August 28, 2010 11:42 AM
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Subject: [squeak-dev] Cryptography in trunk (Re: [Cryptography Team]
Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

> (changed subject for better tracking)
>
> On 8/28/2010 3:59 AM, Rob Withers wrote:
>> Done. The following packages are in the Inbox:
>>
>> CryptoCore
>> CryptoCoreTests
>> CryptoExtras
>> CryptoExtrasTests
>> CryptoCerts
>> CryptoCertsTests
>>
>
> 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.

Andreas,

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

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?

Cheers,
Rob
 




More information about the Squeak-dev mailing list