frigginglorious has quit [Ping timeout: 255 seconds]
FredFredFred has joined #sandstorm
FredFredFred_ has quit [Ping timeout: 260 seconds]
jemc has quit [Ping timeout: 268 seconds]
harish has quit [Ping timeout: 240 seconds]
aundro has joined #sandstorm
aundro has left #sandstorm [#sandstorm]
harish has joined #sandstorm
leeola has joined #sandstorm
digitalcircuit has quit [Ping timeout: 260 seconds]
digitalcircuit has joined #sandstorm
jemc has joined #sandstorm
thekyriarchy has quit [Changing host]
thekyriarchy has joined #sandstorm
gharris has joined #sandstorm
<gharris>
Is there any documentation about optimizing Sandstorm? I can't seem to find anything.
Telesight has joined #sandstorm
<dwrensha>
gharris: what do you mean by "optimizing"?
leeola has quit [Quit: Connection closed for inactivity]
Telesight has quit [Quit: Leaving.]
frigginglorious has joined #sandstorm
<gharris>
dwrnesha: Aren't there adjustments to be made to things like available memory and the like?
frigginglorious has quit [Remote host closed the connection]
isd has joined #sandstorm
<dwrensha>
Sandstorm is known to consume hundreds of MBs of memory. I don't think there's much a system administrator could do about it.
<dwrensha>
gharris: or maybe you are speaking from a developer's perspective? Like how can we improve Sandstorm to make it more efficient?
<isd>
simpson: there's no "canonical" transport for capnproto, but just doing TLS is a common recommendation. Can work over any reliable transport.
<simpson>
isd: Okay. Foolscap uses TLS client certs to pin identities; is there anything similar for Capn?
<isd>
"identities" run somewhat counter to the whole capability based approach
<isd>
what you'd probably do is construct your bootstrap interface to provide the security properties you want.
<simpson>
Sorry, I don't mean identity. I'm trying to remember how Foolscap does this.
<isd>
You also could just use client certs, handle authentication/authorization with TLS, and then just have the capnp server "trust" that the client is authorized to talk to the bootstrap interface.
<isd>
I'm not actually familiar with Foolscap?
<simpson>
It's Perspective Broker on steroids. There's only a couple users left, notably Tahoe-LAFS, and I'm doing research on a possible new Capn API for Tahoe.
* isd
looks up Perspective Broker
<simpson>
CapTP -> Perspective Broker -> Foolscap -> regret, more or less.
<isd>
:P
<simpson>
Okay, so IIUC what happens is that Foolscap establishes a "tub" (like an E vat, kind of) and gives it a TLS cert. The tub IDs itself using the hash of the cert.
<isd>
What I'd reach for not knowing more about your application: just do the widespread TLS thing, where the client verifies the server's identity, but not vice-versa. Then, have your server's bootstrap interface be something with a method like: getCap @0 (token :Data -> obj :RealInterface);
<simpson>
So whenever you connect to a tub over TLS, you can check the TLS client cert's hash to verify that you're talking to the tub that the FURL (SturdyRef) told you to use.
<isd>
Where "RealInterface" is the actual service you're exporting.
<isd>
and token is some suitable credential, maybe a cryptographically random 128-bit number or such that's stored in a DB server side.
<simpson>
Hmm. I suppose that that might work, but it would require us to change our cap diagrams quite a bit. Right now you don't need anything other than a SturdyRef to join a Tahoe grid.
<isd>
Depending on your application, you may have more specialized ways of doing things that are sensible.
<simpson>
We just want CapTP. Capn is modern CapTP.
<isd>
I mean, that token basically is a SturdyRef
<simpson>
Yeah, I guess. I'm just anticipating that I won't be winning hearts and minds if we're regressing on our TLS setup.
<simpson>
OTOH who actually uses TLS client certs, right~
<isd>
Do you mean you want to be able to have one SturdyRef to access a whole cluster?
<simpson>
Well, yes. Right now, you have one "introducer" SturdyRef, and it gives you access to an entire Tahoe grid of storage servers.
<simpson>
In the future, I have plans to build some Monte daemons, and Monte comes pre-equipped with its own vat machinery, so I'll probably be integrating some variant of this into the Monte language directly too.
<isd>
Ah.
<isd>
Would be nice if the level 3 stuff was implemented; that's really what you want here.
<isd>
(in rpc.capnp)
<simpson>
Yes. We're eventually going to go all the way to level 4, and we'll contribute upstream as needed. Right now I'm in the guts of the compiler, like always.
<isd>
:P
<simpson>
If y'all happen to be at PyCon, warner and I will be around to discuss this at more length. Look for the guy with lots of hair and a shirt that says "LET ME TELL YOU ABOUT OBJECT CAPABILITY SECURITY".
<isd>
:P
<isd>
But yeah, a natural way to do this (given level 3 support) is just to set RecipientId = domain name, and use both client and server TLS certs
<simpson>
Yeah, that's something good to explore later. Certainly, given the Internet's topology, it's reasonable that you might not be able to make three-vat handshakes unless both of the "server" vats have a public name.
<simpson>
isd: Thanks, this is good food for thought.
<isd>
You're welcome.
<isd>
Could also use something like noise with RecipientId = (host, port, static public key)
<isd>
Avoids the key distribution question.
<simpson>
In Foolscap/Tahoe, we're used to just popping the keys into the SturdyRefs.
<simpson>
e.g. URI:CHK:nlipf2ej2gd2c3op4otj2yaaky:g4wgcat7gsuj6tyrfvqxc6ivmc6s2y3m524wipqyn5nkgweww4uq:3:10:1540
<isd>
Worth reading about. I like what I see from the spec. kentonv has expressed that he thinks noise is a good thing to use down the line.
metaphysician has quit [Quit: Bye.]
yeehi has joined #sandstorm
Telesight has joined #sandstorm
<gharris>
dwrensha: No, from a SysAdmin perspective. I've got four users on a VM with 8 GB of RAM with extremely sporadic usage. One user logs in and the EtherCalc grain never loads. A day later, same scenario, and everything pops up like lightning. Nothing in the logs.
<dwrensha>
8GB should be enough
<dwrensha>
kentonv was investigating some memory leaks
<dwrensha>
gharris: did you check which process was the memory hog?
<dwrensha>
'sudo sandstorm restart' might help if you've run out of memory