01:29 <zarvox> => Meteor 1.4 is available. Update this project with 'meteor update'.

01:30 <zarvox> it's happening! :D

14:51 <mrdomino> might be interesting to have https://guacamole.incubator.apache.org/ ported some day

16:31 <mrdomino> also http://easyappointments.org/

16:33 <asheesh> Oh my gosh that looks awesome.

16:33 <asheesh> Good gollly.

16:36 <mrdomino> yeah it looks like it might be an easy-ish port

16:36 <mrdomino> and then all they need is caldav support...

16:37 <mrdomino> i'd love to offer appointment slots via sandstorm instead of my current hokey google calendar solution

16:41 <dwrensha> what's missing in caldav support?

16:41 <dwrensha> I though Radicale worked fine

16:46 <mrdomino> dwrensha: i meant easyappointments needs caldav

16:46 <mrdomino> afaict they only do google calendar sync

16:46 <mrdomino> though this is after a very cursory search (i grepped for dav)

16:46 <dwrensha> oh i see

17:23 <mrdomino> asheesh: quick sandstorm-for-work question. can feature keys be moved from one instance to another, assuming they're not ever active on two instances at once?

17:23 <mrdomino> (or anyone else who knows but i figured it might be an asheesh question)

17:25 <asheesh> mrdomino: Yes totally works A-OK like that

17:25 <mrdomino> rad

17:25 <asheesh> (There's not any phone-home logic so it's "only" a ToS violation to move them)

17:25 <asheesh> I can add a note to the for-work docs on that, why not, one sec

17:25 <asheesh> I mean "only" a ToS violation if the key is on multiple machines!

17:25 <asheesh> Moving is not a violation of anything!

17:25 <mrdomino> (i just recently set up an on-site instance on a physical box.)

17:27 <asheesh> Ooh

17:27 <mrdomino> i suppose i might at some point set up our network's DNS to point to a dnsmasq exposing sandstorm via local IP, to make it actually work when the internet is down...

17:30 <asheesh> mrdomino: https://github.com/sandstorm-io/sandstorm/pull/2286 would this have helped you, out of curiosity, and/or is it a reasonable place to leave an answer to the question you asked?

18:54 <beelzabub> I had a question about the implementation of the cap'n'proto RPC mechanism. Is there any documentation?

18:56 <asheesh> Hi beelzabub

18:56 <beelzabub> My understanding of the pipeline mechanism is that the client establishes a pipeline request that the server keeps alive until the client tells it to discard. Seems like it's a security hole whereby the client can easily request the server to use up all available memory. I'm sure I'm missing something though

18:57 <asheesh> https://capnproto.org/rpc.html is the docs, plus any comments in the source.

18:57 <asheesh> The DoS vector is I suppose possibly possible; I recommend filing a bug against https://github.com/sandstorm-io/capnproto to get a conclusive answer.

18:57 <zarvox> beelzabub: take a look at "Is it safe to use Cap'n Proto RPC with a malicious peer?" in https://capnproto.org/faq.html

18:58 <zarvox> (to wit: "At this time, the RPC layer is not robust against resource exhaustion attacks, possibly allowing denials of service.")

18:58 <asheesh> Ah hah, cheers

18:59 <beelzabub> Thanks for the FAQ pointer. I had read it before & completely forgot about it. I'm not sure about the "at this time" wording. Is there some theoretical way to address that without completely breaking pipelining?

19:00 <beelzabub> Seems like the resource exhaustion attack would always be possible

19:00 <beelzabub> Because the server can't let go of any promised responses the client could theoretically reference in the future...

19:02 <zarvox> kentonv would be the right person to answer your question, but he's on vacation this week

19:11 <TC01> I'm working on a small sandstorm application. Do I need to do something special in terms of permissions in order to allow a user to upload a file to it (e.g. http POST)?

19:12 <TC01> that step seems to fail when I run inside of sandstorm but succeed when not done in sandstorm, so I'm suspicious

19:26 <dwrensha> beelzabub: seems like it should be possible to protect against such attacks

19:27 <dwrensha> maybe we could allow an RPC server to specify a limit on the number of entries in its answer table

19:28 <dwrensha> if the client tries to send more than that number of requests without sending Finish messages, the server could return an exception

19:28 <dwrensha> forcing the client to send Finishes if it wants to make more Calls

19:29 <dwrensha> by the way, https://github.com/sandstorm-io/capnproto/blob/master/c%2B%2B/src/capnp/rpc.capnp is probably the best resource to read to understand the protocol

19:31 <dwrensha> beelzabub: actually, this recently-added crude flow-control mechanism could help too: https://github.com/sandstorm-io/capnproto/commit/538a767e04f11b8135fc086314c0250724cac148

19:34 <asheesh> Hi TC01 !

19:34 <TC01> asheesh: hello :)

19:34 <asheesh> TC01: I wonder if you're running into an issue where CSRF headers are being dropped by Sandstorm.

19:35 <asheesh> If so, the simplest answer is to disable the CSRF protection, since the per-session subdomain can do some CSRF protection.

19:35 <asheesh> Having said that,

19:35 <asheesh> we can add CSRF headers that you need to the Sandstorm whitelist, if that does end up being what you're running into.

19:35 <TC01> asheesh: oh, possibly. let me see what happens when I turn that off :)

19:38 <asheesh> Great!

19:49 <TC01> hm... I'm actually not sure that's the problem; this is not currently sophisticated enough to implement CSRF protection (I think, although I could be wrong). I basically just have a minimally modified version of this flask example http://flask.pocoo.org/docs/0.11/patterns/fileuploads/ right now

19:50 <zarvox> oh, could be that your upload folder isn't writeable

19:50 <TC01> https://paste.fedoraproject.org/395977/69562586 is the code: the intention was to write something that sits in front of https://github.com/robertjanetzko/LegendsBrowser and execute it with what a user uploads

19:52 <asheesh> Yeah, I have no idea what the home dir is. I guess the homedir is /var so it maybe ought to work.

19:52 <zarvox> Looks like you'd need ~/.local/share/legendsbrowser-flask to exist and be writeable.

19:52 <TC01> yeah; I had to manually set /var as HOME in sandstorm configuration in order to make things work

19:52 <asheesh> I wonder if the redirect is what's failing instead.

19:52 <asheesh> Also, wow, this is really cool.

19:52 <zarvox> are you explicitly creating those other folders in launcher.sh or something like that?

19:53 <zarvox> if not, they don't exist, and when you try to upload, flask will probably try to write a file in a folder that doesn't exist and get an error instead

19:53 <asheesh> https://docs.sandstorm.io/en/latest/developing/troubleshooting/ " a HTTP redirect away from the Sandstorm server. Sandstorm blocks that redirect"

19:54 <TC01> zarvox: I am, yeah (and also the python script tries to make them when first ran if they're not there), so I don't think that should be the issue

19:54 <asheesh> Per https://docs.sandstorm.io/en/latest/developing/path/ , there is no stable base domain, but you can redirect to a path rather than a URL containing a domain, in case that helps.

19:54 <asheesh> TC01: https://docs.sandstorm.io/en/latest/developing/debugging/

19:54 <TC01> asheesh: ...ah. that sounds like it might be the culprit then

19:54 <asheesh> I'm curious if you can use the debugging feature to call the relevant Python code from inside a grain, and see if there's an exception.

19:55 <zarvox> oh hmmmm that sounds plausible

19:55 <TC01> oh neat, I didn't know about enter-grain (I've been vagrant-spk sshing in to look at the sandbox)

19:55 <zarvox> line 105 seems to be "return redirect(lburl)" where lburl is by default http://127.0.0.1:58881 (which would be a different origin)

19:58 <TC01> zarvox: in theory, this is meant to run behind a reverse proxy to rewrite that (I think this is doable, anyway...), but I would think the file would actually get uploaded first if that were the issue

19:58 <TC01> it does not seem to, though

19:58 <TC01> maybe I'm wrong about the order things would execute in, though?

19:59 <asheesh> No I think you're spot-on about that.

19:59 <zarvox> is the reverse-proxy inside the grain, or outside of Sandstorm?

19:59 <asheesh> I share zarvox's concern the directory hasn't been mkdir'd.

20:00 <asheesh> AFK a little but will read scrollback in half an hour or so.

20:00 <TC01> inside the grain; my launcher.sh spawns the flask application in the background and then runs apache

20:07 <TC01> so, I just tried having launcher.sh not spawn the flask code and only the reverse proxy, and then vagrant-spk enter-grain and run the flask script manually. it does not seem to cause a crash, just outputting "127.0.0.1 - - [26/Jul/2016 20:06:05] "POST / HTTP/1.1" 500 -" (after a subsequent GET 200)

20:13 <TC01> but, at least this way will let me debug a bit more

20:31 <asheesh> Error 500 sounds like your grain log should tell you more!

20:36 <TC01> interesting... I upgraded flask (the Fedora package was only 0.10) and reconstituted the vm. Now I get a traceback when trying to access request.files with the helpful message "IOError: [Errno 28] No space left on device"

20:37 <TC01> the grain log just has this to say:

20:38 <TC01> AH00557: httpd: apr_sockaddr_info_get() failed for sandbox

20:38 <TC01> AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message

20:38 <asheesh> Used up all space in /tmp maybe

20:38 <asheesh> This is because /tmp is a small tmpfs.

20:38 <asheesh> You can use /var/tmp as a different temp dir.

20:39 <asheesh> I guess I should fix vagrant-spk to use TMPDIR=/var/tmp and then clean it up on grain launch.

20:40 <asheesh> Related, we could show an alert to the grain owner if the grain is in dev mode and /tmp is full.

21:01 <TC01> aha!

21:01 <TC01> it works, or rather, fails differently now

21:21 <TC01> hm. now Java is failing to run properly in my grain ("/usr/lib/jvm/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory")

21:22 <TC01> This may be a consequence of me using Fedora as the basis for my grain instead of Debian? I know Fedora uses alternatives to load Java (I'm not sure how Debian does it)

21:27 <asheesh> That's normal, due to ...

21:27 <asheesh> https://groups.google.com/forum/#!msg/sandstorm-dev/aXANGBt7BSA/TdXHmHFBAwAJ

21:28 <asheesh> I want to get around to writing a Java vagrant-spk platform stack that embeds all this knowledge but I haven't yet, but the info is all there at least.

21:28 <asheesh> TC01: ^ thanks for being patient!

22:30 <TC01> asheesh: thanks! that makes it work :)

22:31 <TC01> I need to fix the reverse proxy, which I will do tomorrow (not everything is getting proxied correctly), but the whole thing sort of works!

23:08 <ocdtrekkie> jparyani: I'm going to PR the TTRSS mobile app settings page probably soon. I worked with a Windows dev to get his UWP app working with Sandstorm's TTRSS on both mobile and desktop. (His desktop app is vastly nicer to use than the TTRSS web interface.) And based on the troubleshooting I did with that, I'm hoping to figure out why the Android app from F-Droid wasn't working, and if it's possible to make it work as well.

23:09 <jparyani> ocdtrekkie: awesome!

23:39 <ocdtrekkie> Dealing with how much I hate my Android to test the Android apps.

23:41 <ocdtrekkie> I decided now that I am not using it anymore, I will give up trying to prevent it from updating to worse versions of Android, because I'm sick of having to put it in airplane mode while I kill the system update process on it.

23:54 <asheesh> TC01: : D