[e-lang] Fwd: Chat with kpreid at waterpoint.org
Thomas Leonard
tal at it-innovation.soton.ac.uk
Thu Sep 17 10:11:33 EDT 2009
Hi Mark,
That's good to hear. Will the new version be backwards-compatible? How
stable is the protocol?
One thing that is slightly bothering me is that it doesn't seem to use
SSL/TLS. I found this page:
http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
but it is dated 1998. I think I will have a hard time trying to convince
people that E's custom system is secure / will be updated if problems
are found. It would make my life easier if I could just say it uses the
Java SSL libraries for transport layer security.
Anyway, thanks for a wonderful language! I'm surprised it seems so
little-known.
On Fri, 2009-08-28 at 21:53 -0700, Mark Miller wrote:
> Thomas, Kevin & I would like to thank you from prodding us into a
> breakthrough simplification of CapTP prodded by your first question.
> After the following chat, Kevin & I continued with a verbal
> conversations whose insights we will be writing up at
> <http://wiki.erights.org/wiki/The_lost_resolution_bug_isn%27t>. The
> punch lines of these insights are:
>
> * We decide that the Lost Resolution Bug
> <http://www.erights.org/elib/equality/passing-rules.html#lost-resolution>
> is a feature, not a bug ;). For reasons we did not previously
> appreciate, this cannot ever be fixed, even with the WormholeOp
> <http://www.erights.org/elib/distrib/captp/WormholeOp.html>.
>
> * Since we no longer plan to ever solve the Lost Resolution feature
> ;), we no longer have any need for SwissHashes in the CapTP protocol.
> SturdyRefs still need SwissNumbers of course. But object that are only
> ever exported as live references no longer even need to be assigned
> SwissNumber, also greatly reducing our hunger for new entropy.
>
> * We also no longer have any need for Far3Desc or WormholeOp. They are
> currently stubbed out. They should simply be removed.
>
> * ConstMaps may have keys that are pass-by-proxy objects. Lost
> Resolution means that a ConstMap containing far refs as keys, sent to
> a third vat, will arrive as a promise that only resolves to a ConstMap
> once it's keys become settled again. This requires an ability to
> effectively to a whenSettled, which can mostly be coded in E. But one
> problematic case to be explained and examined (non-transparent
> potentially unsettled selfless objects) may require a new primitive.
>
>
> ---------- Forwarded message ----------
> From: kpreid at waterpoint.org <kpreid at waterpoint.org>
> Date: Fri, Aug 28, 2009 at 8:52 PM
> Subject: Chat with kpreid at waterpoint.org
> To: erights at gmail.com
>
>
> 7:10 PM kpreid: hello?
> me: hi!
> 7:15 PM kpreid: Any topics?
> It's that time of the week again.
> 7:16 PM me: I know. I was going to look at the recent e-lang thread
> tonight. I saw there were questions for me.
> kpreid: ok
> ________________________________
> 16 minutes
> 7:33 PM kpreid: BTW, you have an IM status of "I am MarkM's status"...
> me: Yes, actually, that's my status' status.
> ________________________________
> 16 minutes
> 7:50 PM me: On the first question for me, from looking at the
> E-on-Java implementation, it seems the swissHash is is only used for
> the bad old EProxyResolver sameness comparison.
> What is it used for in your captp implementations?
> 7:52 PM kpreid: It is, in fact, not used. But since my captp
> implementation is not well-tested especially on 3party stuff we should
> not rely on that.
> Remember, my captp has never been actually used to communicate between vats.
> me: Not even your captp on E-on-CL?
> 7:53 PM kpreid: Right.
> me: ok. I'll look at the 3-party stuff some.
> 7:54 PM (vaguely) I do think I remember thinking it was needed there.
> kpreid: I think my captp assumes that since it's *New*FarDesc futhre
> refs will be to the same object.
> That is, only one proxy will be constructed.
> 7:56 PM me: for 2 parties only, I'm confident that's correct.
> 8:00 PM http://www.erights.org/javadoc/net/captp/jcomm/CapTPConnection.html#getLookup%28org.erights.e.elib.tables.ConstList,java.lang.String,java.math.BigInteger,java.math.BigInteger,java.lang.Object%29
> 8:01 PM Only relevant in a system like your in which the lost
> resolution bug has been fixed.
> kpreid: I HAVE NOT FIXED LOST RESOLUTION.
> me: s/your/yours/
> kpreid: I have only an idea about it.
> me: Ah.
> Still, only relevant in such a system. Stubbed out in E-on-Java.
> 8:02 PM kpreid: OK, relevant how?
> 8:03 PM OK, I seepartly. Far3desc is only used if WormholeOp is
> available, right?
> me: VatB needs to unserialize the Far3Desc into a resolved reference
> immediately, before hearing back from VatB.
> Yes.
> kpreid: Ah, so it has a swiss number which it looks up by the hash
> 8:04 PM me: I don't think that's the issue.
> If VatB already has a far ref to Carol on VatC, then VatB knows
> Carol's swissHash but not her swissNumber.
> 8:05 PM However, the Far3Desc arriving from VatB has to unserialize
> into the same far ref that vatB already has.
> kpreid: I was thinking that when VatB gets the Far3Desc, it hashes
> the number and looks up the hasj in its own table.
> 8:06 PM me: Far3Desc has a swissHash, not a swissNumber.
> kpreid: Right, but you can hash the num to get the hash.
> 8:07 PM me: But in the live 3-party protocol, no one is assumed to
> know the number, just the hash.
> kpreid: OK, I was confused...I thought getLookup used a SwissNumber
> But I see it does get a hash.
> 8:08 PM So where's the problem?
> Ah, the nonce should be sufficient?
> Oh. The swissHash is used to make sure identities are coherent, perhaps?
> 8:09 PM me: The nonce is sufficient to establish access once vatB
> talks to VatC. The swissHash is used to ensure identities are coherent
> immediately on arrival of the Far3Desc in VatB.
> 8:11 PM Nonce's grant access. SwissNumbers grant persistent access.
> SwissHashes grant ability to claim sameness, for example, for a
> capabilities-as-keys comparison based service on VatB.
> kpreid: SwissNumbers don't grant persistent access in general.
> The 3-vat protocol uses swiss numbers, doesn't it?
> me: This may be a bad design -- the swissHash may be granting more
> access than it should. But that's what I was thinking.
> 8:12 PM kpreid: Well, swissnumber says you have access to the object.
> And you can compute the shash from the snum. So the snum shouldn't be
> authority-to-claim-to-be.
> me: No. Not since we switched to the nonce/table-based protocol.
> kpreid: the shash, I meant
> me: Yes, but only for Far3Desc. Promise3Desc doesn't carry a shash.
> 8:13 PM kpreid: Well, but that's wrong.
> me: Why?
> kpreid: I shouldn't be able to spoof an identity by knowing the hash...
> by knowing the snum (which implies knowing the shash) I mean
> 8:14 PM me: Why not?
> ________________________________
> 5 minutes
> 8:20 PM me: I think this is a really important question. Even if you
> have a half baked objection, please voice it because it may lead to a
> genuine flaw. I am worried about this issue -- it's the "This may be a
> bad design" I mention above.
> kpreid: Access to an object does not imply authority to be an object
> This is the swisshash/swissbase distinction.
> I mean, swissnum/swissbase.
> 8:21 PM me: Swissbase = authority to be the object.
> SwissNum = authority to access the object.
> 8:22 PM SwissHash = designation without authority -- the object's
> identity without access to it.
> 8:23 PM The hard question that got me started on this: What is
> serialized when you send a DisconnectedRef?
> kpreid: You yourself said "SwissHashes grant ability to claim sameness"
> 8:24 PM me: A DisconnectedRef should be somehow comparable to a far
> ref to the same object, but it shouldn't give access to that object.
> 8:25 PM This also dates from before the proxy revolution, when I think
> DisconnectedRefs and live FarRefs to the same object actually compared
> as the same. Perhaps the whole thing needs to be rethought in light of
> our more principled remote sameness story.
> 8:27 PM kpreid: I remember this discussion.
> FarRefs and Disc.Refs are not equal.
> 8:28 PM As long as you have a connection from you (say VatA) to VatB,
> there is only one connection.
> So there is only one far ref, and it turns into a DisconnectedRef.
> me: Yes indeed it does need to be rethought. The newly arriving
> Far3Desc cannot unserialize into a far ref that's the same as a
> preexisting one, because if the nonce lookup fails, the arriving
> farRef will break whereas the preexisting one won't.
> kpreid: (Only one far ref per remote object, I mean)
> 8:29 PM If you later reconnect, you get a Far ref which is not the
> same as the previous Disconnected ref
> This scheme has all the properties we want, I believe.
> 8:30 PM Wait, what's wrong with the arriving ref broken, provided it
> is unconnected rather than disconnected?
> After all, the nonce lookup failed = protocol error
> me: So here's the problem. Say we fixed the comm delay problem
> causing the lost resolution bug. I don't care whether we fix it by
> WormholeOp or otherwise.
> 8:31 PM At the moment a Far3Desc arrives from VatA, VatB does not yet
> know whether the non-lookup will succeed. What does VatB create in the
> meantime for delivery to Bob?
> 8:32 PM s/non/nonce/
> kpreid: Why does it not know?
> me: Requires a round trip to VatC that hasn't happened yet.
> kpreid: Oh, I see.
> Thinking.
> 8:34 PM So the problem is that VatA tells VatB about a VatC object
> that may not even exist.
> Yes?
> ...that VatB doesn't know about already.
> 8:35 PM me: If vatB actually doesn't know about it, then there's no
> problem, since there's no preexisting far reference that creates the
> sameness dilemma.
> 8:36 PM If VatB doesn't already know alleged carol, then VatB can
> immediately create a fresh far ref to deliver to Bob. It'll break once
> the round trip completes, but that's ok.
> 8:38 PM kpreid: OK, that makes sense. That process doesn't require a
> swisshash at all, right?
> We just lookup the nonce on VatC, and VatC can send an ImportDesc if
> VatC already sent it out meantime.
> 8:39 PM Oh, but if VatB knows it...
> me: exactly. that's the problem
> kpreid: ponders
> 8:40 PM OK, answer this question alone: Given that VatB knows Carol,
> how does VatA securely identify the existing B-ref-to-Carol in talking
> to VatB, in ignorance of B's knowledge of Carol?
> 8:41 PM me: The present answer is the swissHash. "SwissHashes grant
> ability to claim sameness"
> 8:42 PM kpreid: OK, by "claim sameness" you mean something unobvious.
> You mean "ability to claim I have the ref you have" apparently
> me: yes
> 8:43 PM kpreid: It sounds like "ability to claim my ref is the same as
> some other ref"
> me: Again, this may be a bad design. I am worried about it.
> yes.
> kpreid: Please find better terminology
> me: Please help me do so ;)
> 8:46 PM Perhaps the right answer is to just kill Far3Desc and the need
> for swiss hashes in captp, and just live with the lost resolution bug,
> even if we were to do something WormholeOp-like.
> kpreid: Don't give up yet...
> 8:47 PM Got skype?
> me: I think so. Lots of computer reconfig. But let's try.
> 8:48 PM kpreid: I don't hear you.
> me: I can hear you
> 8:52 PM Skype just told me "connection lost"
> kpreid: Me too
>
>
--
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP
Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk
More information about the e-lang
mailing list