<Jassu>
Just a quick question. Is there a way to allow outgoing HTTPS requests for a specific grain by the admin without needing to fix the app package itself?
<Jassu>
In this specific case, I'd like to get the WeKan board outgoing webhooks working, but the app itself does not support requesting the permissions as it should.
<JacobWeisz[m]>
Unfortunately, no. The sandbox model is pretty strict. Even pre-Powerbox, apps had to use a Sandstorm-specific API to make a request.
dustyweb has joined #sandstorm
<JacobWeisz[m]>
Probably the "easiest" way to add outgoing requests would be Ian's http proxy, which handles making requests on the app's behalf, but it still has to be included in the app package and set as an HTTP proxy for the app.
<Jassu>
Jacob Weisz: So it's not just about not having a permission, but also that the outgoing HTTP / HTTPS must be done in some very specific way from inside the app?
<JacobWeisz[m]>
That's correct. Every app that makes outgoing requests requests a capability to do so from Sandstorm over Cap'n Proto, and then uses that capability for subsequent requests.
<JacobWeisz[m]>
The proxy above automates all of this, so you don't have to make heavy code changes to the app, but yeah, something inside the app package has to request and store those network capabilities.
Mitar has joined #sandstorm
xet7 has joined #sandstorm
abliss has left #sandstorm ["User left"]
strugee has quit [Ping timeout: 256 seconds]
<TimMc__>
Hmm, what's the Matrix channel bridged to this room?
TimMc__ is now known as TimMc
<TimMc>
isd: Heads up, I'm reducing my funding tier now that Github's matching is over.
<Jassu>
There seems to be no addresses given to this portal room, which implies that people have just joined the channel using the bridge.
<TimMc>
I'm new to Matrix (I'm running my own homeserver now) so I'll have to figure out what that means. :-)
<Jassu>
It means !aRcBmpdoLgPiGSOVNq:matrix.org this is the ID of the room as nobody has aliased it.
<TimMc>
Hmm. I might not be able to join from my homeserver, which is incompletely implemented (dendrite).
<TimMc>
That's OK, I'll just stay on IRC. :-)
<Jassu>
Well. You’ll have to talk to the irc integration.
<Jassu>
Ummm...
<Jassu>
Was this on freenode?
<isd>
I bridged #sandstorm:matrix.org, but I think several of us had already joined the freenode bridging.
<Jassu>
Oh
<Jassu>
Yeah, this is the same room, but for some reason I cannot see that alias for the room.
<isd>
Yeah, I imagine it doesn't do an exhaustie search for aliases.
<Jassu>
The alias should be part of the room state actually. Which is a bit weird in this case.
<Jassu>
I cannot check the room version from the mobile client apparently. Meh.
<isd>
re: http, blanket internet access is something we really try to discourage granting. The proxy will request access to each host at first use, so it doesn't rely on a blanket up-front grant, but it means the user has to be there to approve it.
<isd>
I wrote it for ttrss originally, where this is pretty workable since it happens when the user adds a feed, though the extra prompt is a little annoying.
<isd>
Also, it does require a bit of work to integrate with an app, but much less than getting the app to use sandstorm's APIs directly everywhere. But also, worse integration...
<isd>
In an ideal world, we'd have apps that were written with Sandstorm in mind, but that's obviously a very labor intensive thing to make happen...
<Jassu>
Yeah. I know the reasoning is sound. The problem comes with apps that lack features because there’s no support built in for it.
<Jassu>
And from user’s perspective... I either have a way to tell the system that this specific grain must be allowed, or I install the application somewhere else.
<isd>
I don't know much about wekan's internals. Maybe xet7 has a better idea of what it would take to make this work.
<isd>
...or just punt on using it, or port it, which are my approaches depending on how invested I am :(
<Jassu>
Because it’s not feasible to start being a developer to get an app working. :p
<Jassu>
But I could go and run some commands as root on the sandstorm instance to ”break” the model to get over the limitation. Even for only a specific grain as needed.
<isd>
It definitely sucks now. The approach really only makes sense assuming we someday get to "good support" -- but I worry that if we make an easy way to just bypass everything, we'll end up with a world where sandstorm's phone-home protection is meaningless in practice, because every app asks for over-broad permissions :/
<JacobWeisz[m]>
Wekan app integration is both better than most but probably worse than it should be, because Sandstorm developers used to contribute integration to Wekan, but now it's just maintained from that point.
<JacobWeisz[m]>
A lot of the webhook like functionality did not exist in Wekan at that time.
<isd>
(I know xet7 also does feature prioritization for Wekan on a contract basis sometimes...)
<Jassu>
Nope. It should not be for apps to ask for over broad permissions. But rather an admin of the sandstorm instance to be able to override the protection for a specific grain.
<JacobWeisz[m]>
That may be a significant more work than you may think, since Sandstorm apps don't actually speak HTTP.
<Jassu>
Mm. Well, then there are no easy way around it.
<isd>
Yeah, that would actually be a lot of work. apps are launched in a network namespace, so it's not just a "permission denied" somewhere that we can toggle.
<isd>
We'd have to write a bunch of plumbing to make it possible.
<Jassu>
Yeah. I get it.
<isd>
Anyway. I'm sympathetic, but it's not an easy situation :/
<JacobWeisz[m]>
The downside to making a platform really secure by default is that making anything accessible is a fair amount of work. But it's also... like really secure. Tradeoffs.
<isd>
(One of the nice things about capabilities in theory is they actually making composition & security really work well, but that requires everything to be built around them, so when you have a bunch of legacy code it ends up being a pain instead)
<JacobWeisz[m]>
I do wonder how much would be entailed in Wekan adding Ian's proxy though... I kinda imagine it's not insane.
<isd>
I can't imagine it would be that hard.
<JacobWeisz[m]>
Biggest roadblock might be meteor-spk... How much hacking around that would be needed to also launch the proxy?
<isd>
Also probably not to hard to deal with; if nothing else you could just have wekan itself launch a process on startup if its running in Sandstorm.
<isd>
xet7: ^
<Jassu>
I know very well the usual curse of building security. But a platform without content is a platform without users... and without users there’s hardly any need for the platform. :/
<isd>
(I assume he's afk if he hasn't noticed the other mentions so far, but...)
<Jassu>
Working with security stuff is probably why I like the concept so much though.
<isd>
Yeah... but it's work either way, and I'd rather invest the effort into integrating apps "correctly"
<Jassu>
Yeah, totally.
<isd>
A lot of it is just a question of manpower; we had 3 full time developers for a couple years, and the basic PoC powerbox was basically the last thing they built before the business side of things disappeared... then a long period of dormancy, and these days I'm like 90% of the labor for the project. I probably should spend a bit more time on app maintenence & packaging; most of what I've done is either new apps or platform
<isd>
development. Some of it's also been internal stuff that isn't super visible, but important long term (ironically, in some cases trying to make it even harder to get to the outside world as there were a few escape hatches put in place before the powerbox was built -- and I fear if we don't remove those before it's too late we won't be able to. But it kinda sucks for users in the short term)
<Jassu>
Yeah. I used sandstorm like years ago for being able to give some interms more flexibility for their projects & fiddling around. And this week I set it up again for a easy to use collaboration & information sharing for some 30+ people team or random people that participated in a cyber defence exercise. I was quite surprised that the etherpad was still at the same version than back then, and pasting content to it was still
<Jassu>
broken. WeKan board worked well though, except the lack of webhooks that would’ve been quite a nice addition to keep up on things.
<Jassu>
But in general when it comes to developing security centric products, I feel that the important factor is actually understand how much the world would have to change around you for your idea to be useful. I’ve hit my head into this wall quite many times along the way. ;)
<isd>
I think out of date apps is less about the world changing around us and more about spending time keeping them up to date.
<Jassu>
Nono. The relevant perspective here is that you need to change how the apps work in order to accomodate them in your platform. So this is the factor of world needing to change to make your tech useful.
<isd>
The initial pass is likely to be much more work than subsequent updates, since (1) more bitrot to deal with in general, and (2) a lot of really old apps predate vagrant-spk, and so their build (if it's even documnted) is much more ad-hoc.
<Jassu>
Eg, if everyone started developing for Sandstorm, then you have zero effort, BUT you made a HUGE change to the world around you.
<isd>
Sure. But it is a question of degree. There's a pretty broad class of apps where the degree is "not that much actually," but we need to package & keep those apps up to date.
<isd>
There are of course others where network access is more central, and it's going to be a much bigger pain.
<Jassu>
Yup. If the work is somewhat equal to how much effort distros have to do for packaging, then you’d be golden.
<isd>
Anyway, I have some errands to run. Later.
<Jassu>
So, without really knowing the deep down things of the platform, I would think if there were any pieces or abstractions that you could push to those frameworks people use to develop stuff? Something that makes everyone there a little bit safer maybe, but also builds direct benefit for you for future app packaging.
<isd>
There are a couple bits of this, e.g. there's a meteor package that integrates meteor's auth system with Sandstorm, which is used by some apps. And somebody wrote a similar thing for django. I definitely think pushing stuff into tooling is a good idea in general.
<isd>
Off I go.
griff_ has joined #sandstorm
<xet7>
For Wekan outgoing webhooks and sending email, it's just looking where that Wekan code is, checking isSandstorm, and using Sandstorm specific APIs to make HTTP request for outgoing webhook that sends JSON to URL, and for email, similar Sandstorm API call
<xet7>
For Wekan permissions at wekan/sandstorm*.js, I still have not yet figured out how to properly add every grain user to Wekan board member permissions when there is many boards in one grain
<xet7>
I did sometime add some translations to Sandstorm code, but I have not yet read enough Sandstorm code and docs that I could figure out how Sandstorm permissions work
<xet7>
And only in newly greated Wekan grains, creator of Wekan grain have Admin permission. To some older Wekan grains, some users do not have Admin access
<xet7>
I did sometime think of code that would allow every Sandstorm user to be Admin user of Wekan grain, but that change was reverted
<xet7>
Also I'm currently doing Teams/Organizations, I don't know would they map in any way to Sandstorm permissions, or will they stay per-Wekan grain only
<xet7>
For API, I think currently only export board API works at Sandstorm, other API does not work with Sandstorm grain API key
<xet7>
Sometime I tried to enable more API, but I could not figure out why other Wekan api calls did give permission denied errors
<xet7>
it could be related to API only being usable with password login
<xet7>
I also don't know how long Wekan will stay with Meteor web framework, it seems that Meteor loads too much Javascript and minimongo content to browserside, that makes slow user experience.
<xet7>
It could be that sometime in future I just run most Javascript at serverside
<xet7>
and have less content at browserside
<xet7>
I'll see how it goes with these speed optimizations to Wekan
<xet7>
Is there some way, that when there is Django website and Meteor app (like Wekan) in iframe, Meteor app would detect being in iframe and automatically login? Similarly like at Sandstorm Wekan automatically logins?
<xet7>
Although, Wekan getting away from Meteor could be wishful thinking. Depends if I get it working. Or, I'll just find a way to optimize speed enough with Meteor.
<xet7>
Usually when I try something else than Meteor, code examples don't work at all, syntax has changed, etc etc
<isd>
xet7: I believe there is a django auth plugin somewhere for Sandstorm.
<isd>
Do you really mean "detect when running in an iframe" as opposed to running as a sandstorm app?
<isd>
(Does Wekan use the Sandstorm auth meteor package?)
<xet7>
Non-sandstorm, normal Django website
<xet7>
and standalone Wekan in iframe
<isd>
What's your use case for this then?
<xet7>
After logging into Django website, automatic login to Wekan
<isd>
Ah, you want to use two frameworks and integrate their auth together.