-
Notifications
You must be signed in to change notification settings - Fork 13
Rebuild package with Sandstorm 0.168 #14
Comments
Ack. I'll try to get to this tonight. |
Out of curiousity, how are you enforcing that people update their grains? And is this a control that I have as a self-hoster? |
AFAIK, there's no way to force people to upgrade their grains. And it'd be scary to me to be using a Sandstorm server where the admin could. Arguably the Sandstorm server, which the admin can update, should be able to prevent buggy apps from killing the whole server, and people having buggy apps causing themselves problems are their own problem if they don't update. |
Yeah, that makes sense. I was thinking more about the previous time where
it did affect the server's security, but in both these cases the right
answer is to update the server.
Should there be a sandstorm-apps-announce for devs in case they need to
rebuild their apps?
|
In the super short term, it looks like Kenton's just telling app authors directly with apps that are heavily affected by it. Which in the short term works but inevitably won't scale. I think sandstorm-dev@ is probably the right list for Sandstorm to announce issues that may affect apps? I'm not sure there's the regularity to require a separate channel, and at least at the moment, most app devs supporting Sandstorm are probably in it? Though I suppose if that list gets too popular and the number of app authors is too large, that will eventually also fail to scale, and a separate announcement list will be warranted. Speaking of "sandstorm-apps-announce", I want a feed for app updates being published to the app market. |
@zombiezen In theory our security model does not assume a trusted sandstorm-http-bridge, so we don't need a way to force updates. In the shorter term, we have a lot of work to do to keep app resource usage bounded, so runaway resource usage can in fact "DoS" the whole server. In general this has not been a problem because there is no incentive for anyone to attack Sandstorm in this way. That said, we are implementing hard fixes as well; for example, 0.167 implemented additional hard flow control at the Cap'n Proto level, so an app can no longer flood the Sandstorm shell process with requests even if it wants to. That said, apps using older sandstorm-http-bridge will still see their own memory usage explode on large downloads, possibly causing the app to be OOM-killed. That is ultimately the app's problem. This memory corruption bug, of course, only hurts the app, not the system. |
Rebuilt with 0.169 and uploaded to App Market. |
Sorry to do this again.
Unfortunately, the sandstorm-http-bridge in version 0.166 has a subtle memory corruption bug. It's possible to observe the bug by refreshing FileDrop's frame repeatedly -- eventually, the app totally stops responding to requests and has to be restarted using the topbar reload button. (Note that this bug is not exploitable for RCE.)
This bug has been fixed in v0.168, which I just pushed now (run
sandstorm update
if you don't have it yet).The text was updated successfully, but these errors were encountered: