00:00 <isd> ocdtrekkie, abliss : re the baby app/csrf problem: sandstorm blocks referer entirely.

00:01 <isd> I don't know if it's going to be possible to get django's stock csrf protection to work in that context.

00:02 <abliss> we shoudl be able to just turn it off though right?

00:02 <abliss> where it = django's csrf protection

00:03 <isd> that would work, yes.

00:03 <abliss> i'm trying that now

00:04 <isd> It would also obviously defeat the protection mechanism

00:04 <abliss> yeah but i'm guessing sandstorm probably has some protection htat makes it irrelevant

00:04 <isd> We should avoid guessing :P

00:05 <isd> Let me dig up a thing, hang on

00:10 <abliss> i'm pretty confused why it doesn't repro inside `vagrant-spk dev` though.

00:11 <isd> https://github.com/sandstorm-io/sandstorm/pull/2588

00:12 <isd> We should do some investigation and merge something similar to that

00:12 <isd> (though that pr itself is too bitrotten to salvage -- the code it touches has been rewritten in C++)

00:12 <abliss> yeah, i was just toying with that code earlier today, looking at CORS issues with riot/matrix

00:12 <abliss> i don't think the null-origin issue is the problem here though?

00:13 <isd> No, the problem is just that the app isn't seeing the headers it wants

00:13 <abliss> https://github.com/sandstorm-io/sandstorm/blob/06cbeb8636828c90fdd92ae98140d87b6ae6ac03/src/sandstorm/gateway.c%2B%2B#L327

00:13 <isd> But if we could solve that it would probably be safe to just say "disable it" since we'd be doing the protection ourselves, and as long as the app doesn't abuse GET requests to have side effects, it'd be fine.

00:15 <isd> That's weird that it works in dev mode though.

00:32 <abliss> Ian Denhardt: is it normal that whenever i touch gateway.c++ I have to re-run the giant "building meteor frontend" step?

00:33 <isd> Yeah. It'd be nice if we could tweak the build to avoid that.

00:35 <abliss> how long does it take on your box?

00:39 <isd> Not that long. haven't actually measured. Long enough to notice, but not looking at my watch

00:41 <abliss> i'm hoping that deleting one line should fix the app: https://github.com/babybuddy/babybuddy/blob/17ed16bc8b046761959ef538ff1f063cafa79904/babybuddy/settings/base.py#L61

00:41 <abliss> still slowly downloading an entire buster box in order to test it

00:43 <isd> I spent a big chunk of last year working on designing and my own programming language. Hacking on that was such a breath of fresh air: no bloated VMs, no shuffling data between incompatible APIs, just actually working on the interesting problem.

00:43 <isd> *and implementing

00:44 <isd> (I haven't dropped the project completely, but it's taking a back seat to sandstorm)

00:45 <abliss> i see it as a kind of schwartzschild radius for programmers. once the brain capacity gets beyond a certain number, the programmer tends to begin inventing their own programming language and/or OS and/or instruction set, and thereafter never produces anything worthwhile to the outside universe. glad you've managed to return from that event horizon.

00:46 <isd> Hah.

00:46 <abliss> e.g.: lars bak, rob pike

00:49 <isd> I happen to think there's value in PL/systems work. But I think it's the nature of stuff further down the stack that that value is more abstract.

00:50 <isd> Funny you should throw pike in there, after all the complaining about build times.

00:51 <isd> Working on sandstorm core makes me really miss Go's toolchain.

01:25 <ocdtrekkie> isd: I am not sure how current it is, but these suggestions claimed that commenting out that middleware wasn't enough: https://stackoverflow.com/questions/16458166/how-to-disable-djangos-csrf-validation

01:25 <ocdtrekkie> It includes some tips including a short custom middleware to do it, which might be useful for abliss.

01:26 <ocdtrekkie> If Django does this by default and it breaks apps in Sandstorm, we should probably definitely build a stack or document the fix thoroughly.

01:27 <isd> It seems like the remaining csrf checking shouldn't be a problem though, as I think it should still work

01:27 <isd> We're not blocking the csrf token, just the referer header

01:28 <isd> So that's actually better, since it means we're not ripping out the security entirely, just the bit that breaks the app

01:28 <isd> +1 to having a django stack that sorts all this out for the developer.

13:25 <abliss> having a weird vagrant-spk problem. /tmp/ is not a tmpfs, just a directory on /, which is mounted read-only, so nothing works. anyone seen this?

13:26 <abliss> ah, nevermind, halting-restarting the vm seems to have fixed it

13:49 <abliss> is there some easy/quick way to check out the repo for someone's sandstorm app which uses vagrant-spk, and build my own spk of it? with gitweb i ended up spending several hours chasing crypto keys around, surely because i was doing something wrong

14:02 <abliss> alternately, has anyone gotten vagrant-spk's sandstorm instance to do SSL? I know i went halfway(?) down that rabbit hole a while back

14:02 <abliss> and ended up giving up and fallng back to spk, which does not seem like an option now since babybuddy requires pipenv which doesn't even seem to exist on my distro

14:37 <ocdtr_web> abliss: Why were you chasing crypto keys around?

14:38 <ocdtr_web> For one, you can vagrant-spk keygen to rekey the app: https://docs.sandstorm.io/en/latest/developing/publishing-apps/#double-check-your-app-id

14:39 <ocdtr_web> The pgp-signature and all is completely optional, so you should be able to clear those out entirely.

14:50 <ocdtr_web> Is it possible to include with Sandstorm's dev mode option the ability to set up HTTPS with a self-signed localhost certificate? That we could then have vagrant-spk export out to the host machine and let you choose to trust in your browser?

14:58 <abliss> it's definitely possible, just needs someone to glue it all together

15:00 <ocdtr_web> I'd want support for self-signing to come from Sandstorm's side, we don't want vagrant-spk having to setup a Nginx server or something. (And ideally we need to move further away from depending on people establishing reverse proxies for common things, it's a huge configuration pain point.)

15:01 <ocdtr_web> There's also plausibly the discussion that an internal corporate environment might be fine with a self-signed cert that can be trusted by their internal domain. But for now, I would mostly just think if we do a -d install with dev accounts, we should self-sign localhost.

15:10 <abliss> yeah, curretnly i think sandstorm's built-in support for terminating SSL may be hardwired to only support sandcats. but it shouldn't be too hard to do self-signed (or bring-your-own-cert)

15:12 <ocdtr_web> I recall functionality added to rewire a custom cert into it, but it never got any UI.

15:12 <ocdtr_web> I'll look for it.

15:13 <abliss> if sandstorm allows you to inject a custom cert, then the vagrant-spk wrapper can handle the self-signing, which might be a faster way to get off the ground

15:30 <ocdtr_web> I can't find it, but I recall there being a way to do so.

15:31 <ocdtr_web> It was something hacky like injecting it into the mongodb.

15:33 <ocdtr_web> Found!

15:33 <ocdtr_web> https://groups.google.com/forum/#!searchin/sandstorm-dev/https$20mongo%7Csort:date/sandstorm-dev/Nu1QetSgvj4/rKnGR8-sBAAJ

15:33 <ocdtr_web> I'm going to open an issue for creating a UI for it.

15:37 <ocdtr_web> I think it also qualifies as a bite-size issue, because the technical functionality is already there.

16:36 <abliss> general Q about the vagrant-spk flow. Assuming a python app which needs a bunch of pip/venv/virtualenv stuff, but no actual compiling once code is changed, shouldn't the setup.sh have the downloading-dependency stuff, and the build.sh be essentially empty? babybuddy has it all in build.sh and each run of 'vagrant-spk dev' seems to take forever

16:38 <ocdtr_web> Maybe ask why he moved it, there is a commit where he did.

16:38 <ocdtr_web> The general difference between setup.sh and build.sh, is short of running vagrant-spk vm provision, which reruns global-setup and setup, setup.sh only ever runs once.

16:39 <ocdtr_web> Presumably your installs of dependencies could/should happen in setup.sh, but if you wanted to update those dependencies when you're working on the app, you might want to update them in build.sh.

16:40 <abliss> (nice job finding the mongo commands to setup custom SSL . should be pretty easy to have vagrant-spk set that up, assuming thre's some easy way for the vagrant python to talk to the mongodb inside the vm. otherwise, we'll have to add a UI, like parsing out filenames from sandstorm.conf)

16:41 <ocdtr_web> I feel we should probably prioritize some UI for that, reverse proxy setups probably count as a significant pain point.

16:41 <abliss> agreed

16:41 <ocdtr_web> And I'd still ideally have Sandstorm configure the localhost cert on a -d install. Presumably the scripting for doing this from vagrant-spk would be kludgey.

16:41 <abliss> you're right that it should be bite-sized. maybe i can try to tackle it (no need to learn meteor for this one)

16:42 <ocdtr_web> I mean, presumably you can more or less copy some other admin panel setting as an example of how to do it within the Meteor framework.

16:43 <abliss> hallelujah! at long last i've managed to get the CSRF issue reproducing over SSL in a dev enviroment. just in time, it seems, for it to have already been solved. (i'm still very perplexed why it works on http and fails on https)

16:43 <ocdtr_web> abliss: It's a design choice on Django's part.

16:44 <ocdtr_web> They feel the protection is meaningless if you can MITM anyways.

16:44 <ocdtr_web> "vagrant-spk ssh sandstorm mongo db.insert" should basically be possible, but it'd be all the same issues described in Kenton's issue, we'd likely have to assign variables and such to bypass the mongo command's length limits.

16:44 <abliss> do you have a link to that rationale? it sounds crazy to me.

16:46 <ocdtr_web> https://security.stackexchange.com/a/96139 and the linked https://groups.google.com/forum/#!msg/django-developers/IgWK2vEePtY/R1r3Im4x3UMJ

16:47 <ocdtr_web> (FYI, I do not understand nine-tenths of this topic, I have just spent a bunch of time digging around for links.)

16:51 <abliss> Thanks. I was missing this detail: " a cookie set on HTTP by the domain can also be read by HTTPS on the same domain"

16:52 <abliss> i guess in this case the "Cross-Site" request forgery just means crossing from the HTTP site to the HTTPS site

16:53 <ocdtr_web> Well, this has at least been a very fun exercise in "what pain points should we address for app developers".

16:54 <ocdtr_web> And hopefully we'll have a fixed version of the SPK soon. :D

17:03 <abliss> if i'm grasping it right, and assuming https sandstorm installs set the HSTS flag, it should be fine to bypass/deactivate the check (i think)

17:16 <abliss> chris points out that https://pypi.org/project/django-sandstorm/ is out of date. any volunteers to get in touch with the maintainer there ? Lyre Calliope maybe?

17:37 <ocdtr_web> Answers the question of if any Sandstorm apps use Django.

17:37 <ocdtr_web> Contact Otter did.

17:38 <ocdtr_web> I know phildini dropped support for Sandstorm on it quite a ways ago. My guess is he wouldn't mind someone taking that package over?

17:53 <ocdtr_web> I sent a private toot his way.

19:04 <ocdtr_web> https://github.com/sandstorm-io/sandstorm/pull/3214 is the Docs PR to pair with https://github.com/sandstorm-io/vagrant-spk/pull/260

19:05 <ocdtr_web> If people are using old VMs and then try to follow the tutorial, they may run into an issue, but I think the answer there is to tell people to 'upgradevm' as it is, which will fix this and other bitrot simultaneously.

19:27 <ocdtr_web> Ultimately, this is one of those changes that "the sooner we do it the less people will run into an issue from it" I think. But we should probably try to get more messaging into vagrant-spk dev itself that tells you what port it's on. I think that might need to be done in SPK actually.

19:36 <ocdtr_web> Issue for that is here: https://github.com/sandstorm-io/sandstorm/issues/3215

21:33 <CaptainCalliope> > chris points out that https://pypi.org/project/django-sandstorm/ is out of date. any volunteers to get in touch with the maintainer there ? Lyre Calliope maybe?

21:33 <CaptainCalliope> @abliss:matrix.org What's the ask?

21:34 <ocdtr_web> I tooted phildini already.

21:35 <CaptainCalliope> Oh! What's your Mastodon?

21:37 <ocdtr_web> @ocdtrekkie@mastodon.social

21:38 <ocdtr_web> I am not super active on Mastodon at present, but phildini is an instance admin in the fediverse world so it's a good place to get a hold of him. :)