leeola has quit [Quit: Connection closed for inactivity]
afuentes has quit [Ping timeout: 240 seconds]
griff_ has quit [Quit: griff_]
griff_ has joined #sandstorm
jemc has quit [Ping timeout: 264 seconds]
harish_ has quit [Ping timeout: 268 seconds]
griff_ has quit [Quit: griff_]
jemc has joined #sandstorm
jemc has quit [Ping timeout: 246 seconds]
Zarutian has quit [Quit: Zarutian]
mrdomino has quit [Remote host closed the connection]
mrdomino has joined #sandstorm
jemc has joined #sandstorm
griff_ has joined #sandstorm
<isd>
Is bridgeConfig *only* used by sandstorm-http-bridge? the comments in the boilerplate sandstorm-pkgdef.capnp are slightly ambiguous about this; there's some language re: integration into the shell.
griff_ has quit [Quit: griff_]
harish_ has joined #sandstorm
harish_ has quit [Ping timeout: 260 seconds]
efishta has quit [Remote host closed the connection]
efishta has joined #sandstorm
jemc has quit [Ping timeout: 246 seconds]
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
xet7_ has joined #sandstorm
xet7 has quit [Ping timeout: 256 seconds]
pie____ has quit [Ping timeout: 240 seconds]
afuentes has joined #sandstorm
Telesight has joined #sandstorm
cevi has quit [Quit: ZNC 1.6.4+deb1+b1 - http://znc.in]
cevi has joined #sandstorm
yeehi1 has joined #sandstorm
yeehi has quit [Ping timeout: 256 seconds]
_whitelogger has joined #sandstorm
yeehi_ has joined #sandstorm
eternaleye has quit [Remote host closed the connection]
JonTheNiceGuy has quit [Remote host closed the connection]
srenatus[m]1 has quit [Remote host closed the connection]
M-hrjet has quit [Remote host closed the connection]
hannes[m] has quit [Write error: Connection reset by peer]
johndoe123[m] has quit [Read error: Connection reset by peer]
gillisig has quit [Remote host closed the connection]
nolan_d has quit [Remote host closed the connection]
indoleringmatrix has quit [Write error: Connection reset by peer]
thejohnhenry[m] has quit [Write error: Connection reset by peer]
thekyriarchy has quit [Write error: Connection reset by peer]
davidar has quit [Remote host closed the connection]
wakest has quit [Remote host closed the connection]
simonv3 has quit [Read error: Connection reset by peer]
yeehi1 has quit [Ping timeout: 260 seconds]
hannes[m] has joined #sandstorm
dwrensha has quit [Quit: Lost terminal]
harish_ has joined #sandstorm
uppermgmt has joined #sandstorm
dwrensha has joined #sandstorm
gillisig has joined #sandstorm
indoleringmatrix has joined #sandstorm
nolan_d has joined #sandstorm
thekyriarchy has joined #sandstorm
thejohnhenry[m] has joined #sandstorm
M-hrjet has joined #sandstorm
simonv3 has joined #sandstorm
wakest has joined #sandstorm
JonTheNiceGuy has joined #sandstorm
srenatus[m] has joined #sandstorm
eternaleye has joined #sandstorm
davidar has joined #sandstorm
JulianFoad[m] has joined #sandstorm
johndoe123[m] has joined #sandstorm
Zarutian has joined #sandstorm
griff_ has joined #sandstorm
<Zarutian>
how does current capnproto implementations handle pointers of the form 0x0000 000E FFFF FFFD ? are there any deferencings done in tight loops?
<Zarutian>
dereferencings*
samba_ has joined #sandstorm
samba_ has quit [Quit: WeeChat 1.7]
griff_ has quit [Quit: griff_]
jemc has joined #sandstorm
Zarutian has quit [Ping timeout: 246 seconds]
xet7_ has quit [Quit: Leaving]
<dwrensha>
Zarutian: what does that pointer represent?
<dwrensha>
I think we need to agree on endianness...
<dwrensha>
I guess it's a list with a single element that points back to itself
<dwrensha>
(I would write that as [0xfd, 0xff, 0xff, 0xff, 0x0e, 0x00, 0x00, 0x00] )
<dwrensha>
I know that at least the C++, Java, and Rust implementations do this.
griff_ has joined #sandstorm
yeehi1 has joined #sandstorm
yeehi_ has quit [Ping timeout: 264 seconds]
yeehi1 has quit [Ping timeout: 240 seconds]
<isd>
dwrensha the Go implementation does as well.
<isd>
(as does the very-WIP-no-timeline haskell implementation I'm working on occasionally)
xet7 has joined #sandstorm
jemc has quit [Ping timeout: 240 seconds]
griff_ has quit [Quit: griff_]
jemc has joined #sandstorm
xet7 has quit [Ping timeout: 268 seconds]
TMM has joined #sandstorm
<TMM>
hi all! Is this the correct place to ask some questions related to capnproto?
Zarutian has joined #sandstorm
<dwrensha>
TMM: yes, this is a good place
<TMM>
Thanks! I'm trying to decide on an RPC system for 'semi-trusted' components. I was wondering if capnproto was suitable for that. Basically different parts of the application dealing with different aspects of the service will run as separate processes where they will try to parse external requests.
<TMM>
I was wondering if capnproto would be suitable in such a scenario, the website suggests to not use capnproto for non-trusted inputs.
<TMM>
All messages will be constructed by code internal to the same project but if a sandboxed worker does get hijacked somehow it's possible someone could start to send arbitrary messages
<TMM>
If someone got really lucky and managed to do a remote code exploit I mean
<maurer>
TMM: So, there are two pieces here:
<maurer>
1.) Capnproto itself does not authenticate the contents or origins of messages - if you want that, you're going to need to wrap capnproto (e.g. in a TLS tunnel)
<maurer>
2.) Capnproto has not undergone a formal security review. Nobody thinks there's a big problem with it, but it hasn't had as many eyes looking at it as say, protobuf has, or an official audit performed on a given revision
<maurer>
tl;dr It's probably fine; authenticate the channel along which your messages are bing sent
<TMM>
right, initially it'll all be unix sockets between seccomp() isolated processes
<TMM>
but when I add network capability I should add TLS then
<maurer>
Unix sockets should be fine, that performs its own kind of authentication
<maurer>
but my point is that if it's listening on the network, a given sandstorm rpc reply has little to no protection from being a spoofed reply
<maurer>
(i.e. don't try to use capnproto to authenticate itself, this almost certainly won't do what you expect)
<TMM>
What about the actual messages themselves? Is there any thoughts on the parsing? If someone does achieve remote code execution in say the 'user request parser' can I be relatively confident that the content of a message being sent isn't going to cause further damage on the parser of the receiving side?
<TMM>
or is this the exactly the thing that hasn't really been investigated?
<dwrensha>
parsing of messages is designed to be robust agains malicious input
<maurer>
TMM: That's designed to be secure, but hasn't been officially audited
<maurer>
It's probably more secure than most random rpc systems you'll find
<maurer>
but hasn't been audited
jemc has quit [Ping timeout: 260 seconds]
<TMM>
for me it's a bit of a tossup between capnproto rpc and onc rpc
<TMM>
onc rpc is just such a pain in the ass to setup for others because nobody in their right mind runs portmap these days
<dwrensha>
TMM what languages will you need support in?
<TMM>
C++ only for now, but I expect others may want to use different languages to interface with the core apis eventually
<TMM>
for capnproto I can probably get away with just the idl, for onc rpc I'll probably have to provide a c library and some swig files
<TMM>
I don't think there are 'rpcgen' programs for other languages than C
jemc has joined #sandstorm
<maurer>
I mean, despite all the other disclaimers, if you're writing a new piece of software, in C++, I'd reccomend capnproto as an RPC mechanism
<maurer>
IMO it's far more likely that you'll have a bug in your own code than that you'll descover a sec vuln in the sandstorm message reading code :P
<TMM>
sounds reasonable
<Zarutian>
the question is, do you actually need the code to be written in C++? Why not in a more memory safe language such as Rust or C#?
jemc has quit [Ping timeout: 240 seconds]
<TMM>
I dislike C#'s runtime, and I don't know enough Rust to do this project
<Zarutian>
You could go with Vala too
<TMM>
my current plan is to implement everything in C++ and then replace bits with rust as I get better at it
<TMM>
particularly the bits that deal with user input
<TMM>
on a sidenote: how robust is capnproto's json handling? I see that there are function to both serialize to json as well as from json
<maurer>
I've not read that portion of the code so I can't really comment
rolig has quit [Ping timeout: 246 seconds]
rolig has joined #sandstorm
<TMM>
Is there anything in capnproto that you really shouldn't do?
<TMM>
'worst practices' if you will? :)
<TMM>
I've used protobuf quite a bit
<TMM>
if that helps
<kentonv>
hmm
<kentonv>
well, modifying a message in-place can cause problems
<TMM>
Is there any way to wait on outstanding rpc calls in a O(1) manner?
<simpson>
TMM: The thing that comes foremost to mind for me is (accidentally) encoding capabilities as regular data on the wire instead of using the RPC support that Capn offers.
<simpson>
It's easy to avoid once you have the capability model in your head, but if you're used to C++ then a bit of unlearning might have to happen first.
Zarutian has quit [Quit: Zarutian]
<TMM>
simpson, do you have an example of doing it wrong?
<simpson>
TMM: Only by analogy. It happens so often (in other systems usually) that it's hard to pin down single good examples. What usually happens is that an FD or crypto key or password gets treated as a plain int or string and gets sent over the wire as such.
<TMM>
simpson, oh, you mean adding authentication information to the messages is a bad idea?
<simpson>
TMM: No, I mean that letting data be exfiltrated is a bad idea. It's important to figure out which data you do and don't want to share across the wire and to mark it as such.
<TMM>
I guess I can signal on completion of a promise through an fd ?
<kentonv>
TMM, I think what simpson is getting at is: Often in regular RPC systems, when you introduce the remote party to a new object, you do so by sending an object ID
<kentonv>
and then the remote party, when it wants to tell you to do something to that object, sends the ID back
* simpson
really needs to write a 2017-era intro to cap theory
<TMM>
ah, you don't send the whole object?
<simpson>
Exactly.
<kentonv>
in Cap'n Proto you should not send an ID, but rather send a capability
<kentonv>
Cap'n Proto supports object references as a first-class type
<TMM>
ok, I'll look at it
<kentonv>
semantically it behaves similarly to sending an object ID but it's cleaner and there's a bunch of useful additional properties
<kentonv>
TMM, not sure what you meant by "wait on outstanding RPC calls in an O(1) manner"
<kentonv>
do you mean like how epoll is O(1) vs. select() which is O(n)?
<TMM>
yeah
<TMM>
I don't want to have to iterate over all outstanding rpcs
<kentonv>
Cap'n Proto RPCs use the KJ event framework which does not even let you iterate like that. :)
<simpson>
Then reify them and deliver messages to them as events. I think that the Capn RPC layer already does some of this.
<kentonv>
the KJ event loop uses epoll under the hood
<TMM>
I'm intending to plug a RPC client to a libmicrohttpd event based httpd server
<TMM>
but I don't want to block on the httpd server side
<kentonv>
TMM, you may need to do a bit of work to adapt the KJ event loop to play nicely with an external event loop in the same thread
<TMM>
maybe I'll just suspend the connection and resume it from a lambda
<kentonv>
only the first part of the file is relevant, but it is ~630 lines which is not trivial
<TMM>
that will also work
<TMM>
oh wait, if I'm in kj's event loop it may not work actually
<TMM>
mhd also has its own event loop
<kentonv>
a hackier but possibly easier approach might be to use a basic (non-I/O) KJ event loop which you only ever tell to "run until empty". Then implement kj::AsyncIoStream directly in terms of some external I/O mechanism. Whenever an I/O event comes in, queue the necessary KJ events and run-until-empty, then go back to your regular event loop.
<TimMc>
kentonv: I don't know the first thing about protobuf or Cap'n Proto, but the above suddenly makes me understand *why* you might want a capabilities system attached to a serialization library. (At some point I'll have an excuse to read up on this stuff, maybe use it...)
<simpson>
TimMc: Admittedly we come at it from the other direction, first supposing that cap-safety is desirable, and then reasoning from there about the design of serializers in cap-safe systems.
<TimMc>
Thanks! Interesting stuff even from a skim.
<simpson>
I was reading this last night; I'm finally at the point in my Capn implementation where I need to figure out how surgeons and serializer kits work.
<TMM>
MHD has an 'external select' feature, I may be able to use that as well
<TMM>
implement the whole main loop in KJ and have it call MHD