01:55 <griff_> I did some googling and there is a few vectors. 1. Phishing by changing the opener to a site that looks like the original. 2. If you know the opener location (not possible in sandstorm) you can trigger a hashchange.

02:04 <isd> But it doesn't look like the opener can be changed? How would you do that?

02:04 <isd> I guess what I'm trying to pin down is: somehow were are mitigating this and I don't understand the details.

02:04 <griff_> You can send postMessage to opener so if there are any bugs or way to exploit that (GMail had a bug like that) you got an attack. I think generally if window.open is used opener should be set to null unless it is actually needed since that prevents problems like this. I don’t know if you can set parent of an iframe to null but that might relevant for apps that have iframes with user content or previews since they might be able t

02:04 <griff_> nap the app iframe and have it do phising.

02:04 <griff_> You can write to opener.location

02:04 <griff_> You can’t read opener.location though

02:06 <isd> Aha, so you can; thought I'd tried that but I may have tried to assign to opener directly or something.

02:07 <griff_> If you know what opener.location is. Say you know it is http://google.com you can set opener.location to http://google.com#i-am-evil and that will trigger a hashevent in opener

02:08 <isd> If I pop open the javascript console and do window.open(...) from the grain's iframe, and then try to do window.opener.location = ... in the new tab, it throws an exception.

02:09 <isd> This does not happen if I call window.open() from the sandstorm UI (outside of the iframe)

02:09 <griff_> Hmm

02:09 <isd> so maybe there's some additional restrictions on iframes.

02:09 <isd> I've only tried this in firefox.

02:10 <griff_> That is the other thing. The mitigations are browser specific. So that attack may be prevented by firefox but work in Safari

02:13 <isd> Same thing happens in chromium

02:15 <griff_> And Safari

02:16 <griff_> Så that attack is prevented. Nice to know

02:25 <isd> Would make sense to check i.e./edge too (ocdtrekkie?), and I'm curious as to how old this mitigation is; would someone have been vulnerable using a browser from 2017?

02:26 <isd> I'd like to know what the exact rules are here, and if they're standardized or just widely implemented the same way.

03:08 <kentonv> isd https://html.spec.whatwg.org/#allowed-to-navigate

03:13 <kentonv> hmm those rules seem way too loose though

04:41 <isd> Yeah, I'm staring at those and don't understand why it blocks this (though I'm glad it does). It seems like it should if we were setting sandbox flags on the iframe but I don't think we are.

04:42 <isd> So I don't know whether my reading is wrong or browsers are just more strict than what the spec says, or there's some other verbiage somewhare that's relevant.

04:42 <isd> In other news: I'm very excited about the fix to davros's upload button

13:42 <JacobWeisz[m]> Ian, I stopped using Edge a while ago, but Microsoft has replaced Edge with a Chrome fork, so Chrome testing and Edge testing are basically one in the same now.

13:43 <JacobWeisz[m]> Firefox and Safari run the last remaining independent browser engines separate from the evil empire.

15:16 <xet7> Edge is in a very wide use at corporations. Some were very happy when I fixed Wekan to work at Edge. Also Wekan Microsoft Store app at Win10 desktop uses Edge for Wekan window, based on Wekan PWA. I don't know when Chromium Edge based PWA will become possible.

15:18 <xet7> I have spent many hours to increase Wekan browser support to this many browsers https://github.com/wekan/wekan/wiki/Browser-compatibility-matrix and I plan to keep Wekan working on those browsers, and add more fixes.

15:20 <xet7> If possible, sometime add support for even more browsers. I would like to support browsers that do not have Javascript enabled or implemented at all.

15:46 <JacobWeisz[m]> Yeah, if you embed inside a UWP app or whatever, legacy Edge is still there for now. But probably not much longer, Microsoft is probably going to switch everything to a Chromium-Edge-based-Electron thing.

15:47 <JacobWeisz[m]> As an enterprise IT admin, many vendors tell us we must use Chrome to get support. We use Firefox internally but we ended up pushing the new Edge quicker so that we have it for said troubleshooting.

15:48 <JacobWeisz[m]> Thankfully companies seem to accept the new Edge as a viable basically-Chrome, so we were able to finish removing all Google Chrome installs from our network.

17:44 <isd> I keep forgetting edges is just chromium now.

20:09 <xet7> new edge is chromium + many changes, like google-specific stuff removed and ms-specific stuff added, optimizations, etc

20:12 <griff_> Has anybody tried running sandstorm in a docker container?

20:16 <blowfist> griff_: I'm running sandstorm in my own custom container (which is made using shell scripts)

20:16 <blowfist> griff_: sandstorm requires the user namespace to work

20:17 <xet7> blowfist: Are your scripts open source and at some public repo?

20:17 <blowfist> xet7: yeah, it's on github : https://github.com/nniro/jailTools/

20:18 <xet7> I don't know are user namespaces available inside docker or snap

20:20 <isd> griff_: there's a thing in the docs somewhere about how to do it. It needs to be a privileged container though, so you don't really get any scurity benefits on top of what Sandstorm already provdies (though if docker is your prefered workflow for deploying stuff it may make sense anyway)

20:20 <blowfist> I think in more recent linux versions, user namespaces can be cascaded

20:21 <blowfist> but as isd mentionned, you most likely require privileges to run sandstorm, all namespaces can only be created by root unless you use the user namespace

20:21 <griff_> isd: Yeah I forgot to google first. I just wanted to use it for app dev work so priviliged is not really a problem

20:24 <griff_> I was looking at docker-spk and thinking about if it was possible to just use that, Docker for Mac and sandstorm in a container to develop apps. But the thing is I really want access to spk dev which docker-spk doesn’t have.

20:24 <isd> griff_: See also https://github.com/zenhack/docker-spk, though that's for using docker to build apps, rather than to run sandstorm.

20:24 <isd> Derp, totally scanned passed your last comment.

20:25 <isd> Yeah, getting spk dev to work would be useful. It wouldn't be that hard, but it's a bit of work since right now docker-spk doesn't use raw spk at all; it has its own implementation of package signing etc.

20:26 <isd> ...but, I also kinda want to get away from the 'slurp stuff off the filesystem' thing that spk dev does.

20:27 <griff_> isd: doesn’t spk dev just update sandstorm-files?

20:28 <JacobWeisz[m]> It generates sandstorm-files by detecting use by the running dev grain.

20:28 <isd> yeah, so you do have a trace of what's included, but it's still kinda awkward.

20:28 <JacobWeisz[m]> spk pack uses the sandstorm-files list, I imagine.

20:30 <isd> Anyway. One of these days nix-spk will be a thing.

20:30 <JacobWeisz[m]> Could we develop an off switch for spk's auto-detection, such that if you want to manually specify everything, you can while still using spk? This would also be a useful mode for vagrant-spk enter-grain, where you simply don't want to modify the file list.

20:30 <griff_> isd: Well I can help with that. I use Nix and NixOS almost exclusively

20:32 <isd> I'm thinking of building on top of the new flakes system; it's still experimental but as it stabalizes I think it will make for a much better experience. And I really want to have a standard way of having people include random helper daemons and stuff in their packages, flakes seem like a good way to manage that.

20:33 <griff_> isd: in the long run yes. But right now I use https://github.com/nmattia/niv for all things

20:34 <isd> But the first pass I think is "just" a thin wrapper that calls nix build etc. and uses nix-store -qR to figure out what to pack.

20:35 <isd> Will have to have a look at that. If there's a blessed solution in the pipline though my inclination is to build on that, rather than have to migrate down the line.

20:40 <griff_> isd: Niv is mostly for locking nixpkgs and other github dependencies and it only touches 2 files: nix/source.json and nix/sources.nix so don’t wait for perfection while there is a usable alternative that works right now. The blessed solution has been in the pipeline for close to 2 years. And while it will be great when it arrives niv is the minimal simply solution that most are using.

20:46 <griff_> isd: My most advanced project setup with Nix looks mostly like https://github.com/griff/whitelist it builds a jekyll site each week and runs update scripts for rubygems and nixpkgs each week that make PR’s.

20:50 <JacobWeisz[m]> I still think docker-spk needs a place in docs so people know it exists and how to use it.

20:50 <JacobWeisz[m]> Though, do we have any apps in the market actually built with it yet?

20:56 <isd> Not sure; I know Ross played with it but I don't think he actually pushed anything

20:57 <isd> Jan Jambor was trying to make it work for wordpress, but he kinda disappeared before it happened.

20:59 <JacobWeisz[m]> I rely heavily on existing apps as examples when packaging, so I think at least one published app using a given dev tool is probably somewhere we should get.

21:00 <isd> Yeah. There's an examples/ directory in the repo that has a basic python app in it, but "real" apps would be nice.