Last updated at 11:43 pm UTC on 10 January 2006
For the sake of confidence in this work, please use this page to write KryptOn critique.
First, the code you give in "Establishing secure interactions" does not work:
myNodeKit node export
MakoSecurityManager current import
MakoSecurityManager current keyring
Neither method (#export, #import, #keyring) are implemented anywhere in sight. So how does one establish secure interactions? Not to mention that without this step everything that follows is moot.
My apologies, I am ashamed doing this out of order (posting before verifying). I saw the issue and it is now corrected. If you try the top-version on SqueakSource of "KryptOnTesterLoader", which includes the MakoTestCase, I promise it will work this time. Thanks for your patience.
Actually, what is confusing is that you have a download of the repository on the wiki here and I expected that to work (and it does not even now). How about removing that zip file alltogether?
(I have decided to reply directly underneath each question rather than batching them at the end).
The only reason it is on the swiki was to try to conform to US export requirements and serve as the as the reference for the required "TSU NOTIFICATION". I apologize for it still not working from there, I will look into that during the next week. Until then, please use the SqueakSource version which is one-click loadable (after loading Cryptography 0.3 from SqueakMap).
More issues: First, I changed the order of two paragraphs so that for first-time users the order is correct, e.g., now it says "if this is the first time do X" and then "do Y" instead of "do Y" and later "... unless this is the first time you do it, in which case do X" - otherwise it gets confusing if you follow the steps (which said "do Y").
But anyway, I got as far as the import and now I'm at a loss: As the next step it says
MakoSecurityManager current keyring
but I don't know how to get to the "remoteNodeJustImported" - #import does not answer anything and so far you've only shown how to create new nodes (createNodeKit:) not how to access existing ones. What now?
(Thanks for flipping the generate/create node order, that makes sense).
There is a category in MakoKeyring called "experimental" which offers #nodeWithId:, but it is in this category because I acknowledge "node access" needs some refinement. The Node id's are not unique, only their UUID's are, so #nodeWithId: is insufficient. Rather than implement something wrong, the method you are really needing is simply missing at this point because I don't know what it is just yet.
The intent was for the burden to be on the KryptOn-client program to present the available local and remote nodes through its own UI and then issue a call to #use: local toAccess: remote. Therefore, one suggestion is a simple pair of accessors:
^ allKits collect: [ : each | each node ]
^ accessors collect: [ : each | each remote ]
The KryptOn-client program should present the human-consumable #id of each node, but should also make the UUID available to reconcile duplicate id's. How does this sound?
And while I'm at it, a few comments on code issues: First, given that MakoSecurityManager is a MaSingleton, I presume it is invalid to create new managers like here:
mgrA := MakoSecurityManager new.
mgrA generateKeyringFor: 'alice'.
nodeKitA := mgrA createNodeKit: 'alice'.
mgrB := MakoSecurityManager new.
mgrB generateKeyringFor: 'bob'.
nodeKitB := mgrB createNodeKit: 'bob'.
Is this correct? If so, why? It would be great for testing.
In addition, are there any plans to remove the current heavy dependencies on Magma? I thought Magma would be using KryptOn and not the other way around - the reason I'm looking at KryptOn is to see whether we'd be interested in using it for Croquet but with that fat dependency on Magma (there are 45! categories with "Ma " after loading the full thing) it is extremely unlikely that we'd buy into that dependency.
Yes, it is currently a Singleton but I am open to improving that. As I was working out the main design, I didn't have the capacity to figure out how the user could easily manage having multiple facades, keyrings, import/export directory's, etc. I am open to ideas..
For MakoTestCase, I implemented #switchTo: to "switch" from Bob to Alice. It actually helped my own comprehension of the tests as I wrote them (i.e., see #testCapabilities) because, upon switching to Alice, it mimics the isolation she has from Bob's objects, helping assure the tests aren't "working" due to erroneously accessing objects she wouldn't have in her own image.
The dependency is on Ma object serialization, not Magma. KryptOn needs simple serialization services for envelopes and import/export, so Ma is probably overkill. Using SmartRefStream would allow removal of most or all of the "Ma" packages, I will look into this.
My only question for SmartRefStream is "will its coupling to Squeaks object-format (please correct me if I'm wrong about this) ever hurt?" Ma uses first-class buffers offering a logical representation of Squeaks object types, so it might (for me, "definitely") be easier to upgrade existing keyring files to Squeaks new object file format. But this concern might be premature and unwarranted..