00:00 <abliss> Ian Denhardt: I just noticed that your "hello oauth" app ( https://github.com/zenhack/hello-sandstorm-oauth/releases/download/v0/hello-sandstorm-oauth-0.spk ) doesn't seem to work any more. Is it expected to?

00:00 <isd> That's news to me.

00:00 <abliss> When loading the grain, I get 403 errors trying to load rpc.mjs, http.mjs, and main.mjs from https://ui-mumble.sandstorm.rapidraven.com

00:01 <isd> Is that a standalone grain?

00:01 <abliss> no, i just redacted the hex

00:02 <isd> Ah.

00:03 <isd> Just tried it, still works for me.

00:03 <abliss> it's possible that i've somehow borked my server in changing domains... but other grains seem to work

00:03 <isd> Anything interesting in the logs?

00:04 <abliss> nope, nothing from the logs. it isn't obvious to me whether sandstorm is throwing the 403 or the grain's internal http server

00:04 <abliss> but neither sandstorm.log nor grain log speak of it

00:07 <abliss> oh, if i directly request main.mjs in its own tab, it loads. so i wonder if this 403 is being manufactured by my chrome for some iframe-related reason

00:10 <isd> Anything in the browser console?

00:11 <isd> Hm, I'm using firefox. Let me see if it still works with chromium

00:11 <abliss> just complaints about the 403s.

00:11 <abliss> It's also possible that my chrome, version 69, is just too old to handle JS modules

00:12 <abliss> yeah, that seems to be it. it works on my phone with a newer chrome. Dang.

00:13 <abliss> I knew when they EOLed my Chromebook Pixel 2013 (despite bragging when it was launched how it would be an evergreen laptop, getting faster with age instead of slower) that this day would eventually come.

00:13 <isd> Yeah, works for me in chromium too

00:13 <abliss> sorry for wasting your time.

00:13 <isd> It's cool

00:14 <isd> fwiw, I don't think there are many live sites on the web shipping modules to browsers -- everybody minifies and bundles stuff. But since it's a demo I wanted to keep the build pretty simple

00:15 <isd> Time to move it over to a real distro?

00:16 <abliss> yeah, maybe. i'll be sad to say goodbye to ChromeOS. I really like its fast boot and suspend/resume, and its solid drivers

00:17 <abliss> I have an ubuntu chroot under crouton, so i guess I can install the latest chrome there and use it when I need bleeding-edge stuff, and stick with chromeos's chrome for older stuff. but those days are obviously numbered.

00:26 <JacobWeisz[m]> Chrome is still supported on like any Windows PC that originally shipped with Windows 7, which could all be on the latest Windows 10 release for free. I love the irony that Google supports ancient Windows devices far better than their own.

00:28 <JacobWeisz[m]> I think a customer's 2007 Mac can no longer run the latest Chrome now? But I am 100% baffled that anyone ever thought making browser updates dependent on specific hardware models was okay.

00:30 <JacobWeisz[m]> Hardware EOLs ending browser security updates is worse than Android even.

00:32 <abliss> Yeah, I feel quite the sucker for having shelled out like $1400 and believed all the lies. It's been a delightful piece of kit, but being unable to browse the web after only 7 years is pretty embarrassing

00:42 <JacobWeisz[m]> What's the downsides to going full Crouton?

00:50 <JacobWeisz[m]> I'd be worried about even general web activity on a browser 21 releases behind.

00:51 <JacobWeisz[m]> Chrome is on like 80 or 81 now or something? I guess that's 11 or 12 releases behind.

01:04 <kentonv> I think Crouton is the thing where you run Linux in a chroot inside ChromeOS, which I don't recommend. There's another option where you actually install stock Linux on the device, which I did for a while.

01:16 <JacobWeisz[m]> Ah, that's what I was thinking of.

01:17 <JacobWeisz[m]> I still have an i5 Chromebox I got from Google I/O years ago I was tempted to try to put Linux on. It's old but would still be serviceable with a real OS.

01:17 <JacobWeisz[m]> I think it's a second gen i5?

01:17 <kentonv> one problem with installing stock linux is that if you ever let the battery run out, then it "forgets" that it's in legacy-boot mode and you can't boot your OS anymore... there's a way to repair it using a specially-crafted recovery USB stick

01:18 <kentonv> I think not all chromeos devices support legacy boot so you'd have to look it up for chromebox

01:19 <JacobWeisz[m]> I did a little research about the hardware dev mode switch it has hidden in its Kensington lock port, but I never got around to trying it.

01:20 <JacobWeisz[m]> And I definitely recall the thing about ChromeOS devices resetting themselves to stock if the clock battery died.

01:22 <kentonv> well there's two things that could happen... forget that it's in legacy boot mode, and forget that it's in dev mode. The latter would be catastrophic as it would then wipe the drive. Luckily that flag is apparently saved in flash.

01:22 <kentonv> and yeah on some devices it's a physical switch

01:22 <kentonv> (dev mode)

01:22 <JacobWeisz[m]> XE300M22-A02US is the one I have somewhere taking up space.

01:26 <JacobWeisz[m]> I found https://www.extremetech.com/computing/132300-unleash-your-chromebox-how-to-dual-boot-ubuntu-linux-on-your-chrome-os-device/2 which is about this device. Do wonder how many links for scripts and downloads are likely to still be valid after all this time though.

01:54 <TimMc> I saw a presentation on trying to use a Chromebook as a Linux computer (for pentesting, in this case) and it was... pretty grim.

02:22 <kentonv> yeah as I like to say, it's surprisingly bad at running Linux for a device that runs literally nothing else.

15:36 <JacobWeisz[m]> Ian, can you skim #3317 when you get a chance? I want to get it out of the way before I work on the SSL page.

15:49 <isd> Yeah, I'll have a look soonish.

15:49 <isd> I almost have sandstorm building with asan, finally.

15:50 <isd> the node capnp tests are failing because asan is complaining about leaks that originate from somewhere inside v8.

16:03 <isd> Actually that might actually be in our code. Need to stare at it a bit more.

17:51 <isd> I kinda suspect the "leak" is basically asan being too stupid to understand v8's GC; I bet node is (sensibly) exit()ing without bothering to free() everything being managed by the GC.

18:10 <abliss> have you managed to reproduce the corruption?

18:10 <isd> Haven't gotten asan-instrumented sandstorm to start yet

18:10 <isd> It built!

18:10 <isd> ...but

18:11 <abliss> i'm worried that even if you get it running, the corruption will turn out to be on a codepath that we don't commonly execute.

18:12 <isd> node dies on startup. Really I don't want asan in the frontend, just the backend, but getting the build system to do that seems ...not fun

18:12 <isd> I already had to patch bits of the ekam rules to get this far

18:13 <isd> abliss: I suspect that's the case, but my hope is we can ask the user who is hitting it to try the asan build and get a more useful error from them...

18:14 <isd> But we might also get lucky and it's something that we do hit during normal execution, it just doesn't manifest in a way that causes obvious problems...

18:14 <isd> I also built with GCC because I couldn't get it working with clang, so if it's some optimization sensitive thing it may just not manifest with the different compiler...

18:15 <isd> I wish sandstorm's backend was just written in something memory safe.

18:19 <isd> I really would like to kill ekam's interceptor.so somehow. That wasted a fair amount of my time today.

18:21 <isd> asan really doesn't want other libraries loaded before it.

18:23 <isd> Ug, I think I'd have to do two separate builds of capnp to have instrumentation in capnp but not node-capnp

18:29 <abliss> I've been thinking about our discussion the other day, and about what it would mean to do keybase / keys.pub / other key management in sandstorm. what if one grain stored a private key with no way to export it, only offering to sign/decrypt messages through powerbox requests? then you could have a bitcoin wallet or an e2ee chat app where the grain that does all the tricky UI and network access had no possibility of exposing

18:29 <abliss> your key. (Ideally, sandstorm would first gain the ability to encrypt grain storage at rest, but you could also perhaps just mount an ecrypted fs at /opt/sandstorm) ... is this a dumb idea?

18:30 <abliss> could you possibly even use nested inline iframes to have an e2ee chat appear totally seamless?

18:31 <JacobWeisz[m]> I don't think we want to be in the protecting private keys game at this juncture.

18:32 <abliss> because of the risk of the sandstorm shell itself getting hacked?

18:33 <abliss> if you were going to start from the assumption that someone wanted to store some private keys online in a webapp, so they could use a nice friendly crypto wallet or e2ee chat app (and, by observation, this seems to be something that people want to do) wouldn't this be a pretty good way (comparatively) to do that? I mean, once sandstorm gets one of those professivonal security audits like e.g. coinbase / gemini get

18:35 <abliss> i need to read up more on how offer iframes actually work... i'm wondering if a e2ee chat app could have a "type your message here" box which is actually an offer iframe from the message-signing grain, and each line in the "incoming messages" pane is actually an iframe from the message-decrypting grain

18:36 <JacobWeisz[m]> The need for a professional security audit is a big one. And yeah, that encrypted storage hasn't been a big focus for us yet.

18:39 <JacobWeisz[m]> I feel like we're probably pretty far from it. And we don't need people's private keys to verify app authors.

18:43 <abliss> true... it might be nice to have a webapp for signing packages (and posting identity proofs) but probably most potential app authors are comfortable with CLI crypto and key-management anyway? And I guess there's not much point in being able to easily send an encrypted message to an app author (which the author can then easily decrypt and read on their self-hosted instance)?

18:50 <JacobWeisz[m]> I think the only time we'd need a message to app authors to be encrypted is transmitting info about a vulnerability or transferring an app publishing key.

18:50 <JacobWeisz[m]> Those are rare enough events being able to do it on a web app isn't super critical.

23:44 <vertigo_38> Big thanks for the 265 release, it installed flawlessly on my system!

23:54 <JacobWeisz[m]> Glad to hear!

23:55 <JacobWeisz[m]> Sorry about the bug, though hopefully the refactoring is going to enable some awesome stuff to come. :)