ocdtrekkie__ has quit [Remote host closed the connection]
mnutt_ has joined #sandstorm
<digitalcircuit>
How'd you notice that pull request so quickly, kentonv? :)
ocdtrekkie_ has joined #sandstorm
aeviator_ has joined #sandstorm
aeviator has quit [Ping timeout: 265 seconds]
aeviator_ has quit [Ping timeout: 258 seconds]
isd has quit [Ping timeout: 240 seconds]
jemc has quit [Ping timeout: 258 seconds]
Aurelius_Home has quit [Ping timeout: 244 seconds]
Aurelius_Home has joined #sandstorm
lukexj has quit [Ping timeout: 264 seconds]
frigginglorious has quit [Quit: frigginglorious]
pie_ has quit [Ping timeout: 250 seconds]
<DanC_>
I just did a fresh curl-bash dev install on Ubuntu 16.04. I got "local.sandstorm.io’s server DNS address could not be found." and a bunch of "l: Unable to connect to Upstart:" stuff
<DanC_>
halp?
<DanC_>
systemd says it's running
<DanC_>
`dig local.sandstorm.io` shows no A records. but not NXDOMAIN; it says NOERROR
<DanC_>
doesn't dnsmasq just go straight to the root servers and look up the NS record for .io and sandstorm.io?
<kentonv>
I don't think you're allowed to do that
<DanC_>
how else would it work? where does dnsmasq look for a "next hop"?
<kentonv>
generally your ISP provides a DNS server
<DanC_>
yeah, but not competently
<DanC_>
and again, how would dnsmasq find it?
<kentonv>
maybe DHCP
<DanC_>
dhcp is running on my desktop which is on the behind-the-NAT LAN. It can't see my ISP's DHCP
<kentonv>
the dnsmasq home page makes multiple references to the fact that it connects to your upstream DNS server, i.e. the one from your ISP. Mentions you may need to configure it.
<kentonv>
in any case, the reason I ask is because some incompetent DNS administrators feel the need to filter out names that resolve to 127.0.0.1, thinking it is some sort of security risk
<DanC_>
I can't find any relevant configuration. /etc/dnsmasq.conf is all comments
<kentonv>
well... how does dnsmasq know your network gateway, etc.?
<DanC_>
there must be some network-manager magic...
<DanC_>
why would dnsmasq want to know my network gateway? all it needs to do is send UDP packets via the kernel, no?
<DanC_>
I guess I don't see any configuration that shows the root servers either. hm.
<kentonv>
is it not also your DHCP server? It would need to know what gateway to advertise to clients.
<kentonv>
also how is your desktop's network interface configured?
<kentonv>
your NAT router doesn't respond to DHCP?
<DanC_>
no, my router is my DHCP server
<DanC_>
i.e. yes
<kentonv>
oh, you said: "dhcp is running on my desktop which is on the behind-the-NAT LAN. It can't see my ISP's DHCP"
<DanC_>
so maybe dnsmasq asks the router.
<kentonv>
I guess you meant client
<DanC_>
so maybe dnsmasq asks the router via DHCP
<kentonv>
so your desktop DHCPs to your router who DHCPs (or PPPs) to your ISP and that's where it got the DNS config
<DanC_>
I think I told the router to use 8.8.8.8 and 8.8.4.4
<kentonv>
ah, then you're using Google's servers
<kentonv>
but they resolve local.sandstorm.io just fine, so that's weird
<kentonv>
your router may be proxying, and may be incompetent
<DanC_>
it's running dd-wrt. hm.
<DanC_>
let's try dig @router...
<DanC_>
indeed, hosed.
<kentonv>
maybe someone working on dd-wrt thought this was a good policy to enforce
<DanC_>
tell me why it's incompetent to do so?
<kentonv>
it's one of those security dunning-krugerisms. It _sounds_ fishy for a host to resolve to 127.0.0.1 so people block it, but doing so doesn't actually accomplish anything security-wise.
<DanC_>
ah... it would only screw up same-origin if some origin that resolved to a bad guy's machine also somehow resolved to 127.0.0.1 ... which is possible, with mulitple A records, no?
<kentonv>
I mean, analogously, why can't I have my domain also sometimes map to Google's IPs and then hijack Google?
<DanC_>
um. I actually don't know. It seems like you could.
<kentonv>
I guess the thinking is that a service exposed on localhost might make the incorrect assumption that external web sites in the user's browser cannot interact with it
<kentonv>
but that assumption is broadly wrong
<kentonv>
any web site can send requests to localhost if it wants
<DanC_>
"Reject (and log) addresses from upstream nameservers which are in the private IP ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. " -- http://www.dd-wrt.com/phpBB2/viewtopic.php?p=509683
<DanC_>
so... it looks like there might be a knob to flip.
<kentonv>
yeah
<DanC_>
though /etc/hosts seems more dirt simple and reliable
<DanC_>
anyway... do you want this problem noted in the sandstorm docs?
<kentonv>
actually another thing you can do is use "localhost" instead of "local.sandstorm.io"
<kentonv>
These days, most browsers map *.localhost to localhost
<kentonv>
we should probably make that the default
<kentonv>
back when I created local.sandstorm.io, support for *.localhost wasn't as widespread
<DanC_>
yeah... seems like fewer moving parts.
<kentonv>
ok I guess now that I think more about it, basically the reason to block external domains from resolving to internal or local IPs is if you believe services exposed on internal or local IPs might fail to take the precautions that public-internet web services must.
<DanC_>
"Creating /home/connolly/.sandstorm to hold developer keys." <- I wish more apps would tell you when they do that. atom ended up using ~2GB in my home directory. I like to store only my own work in my home directory
<kentonv>
for example if an internal IP responds to all requests directed its way without paying attention to the Host header, and it replies with possibly-secret information, then yeah, you could maybe pull a same-origin trick to read that info from an external site.
<DanC_>
I had this argument with David Barohn at a W3C meeting some decades ago...
<DanC_>
I took the position that intranet services should be just as careful as internet services and not rely on browsers to protect them. Turns out to be sorta naive.
<DanC_>
that is: browsers can do a lot of good in mitigating access to such services
<DanC_>
though same-origin is a nightmare... if only I had listened to the HP espeak folks when they came calling. AAAAAARGGH
<DanC_>
instead of SOAP we would have had a capabiilty system.
<DanC_>
(I didn't listen to the SOAP folks either; I hid in a corner and let others handle the web services foo)
<DanC_>
(I am an accomplice to the XML Schema nightmare, though. If only I had listened to Paul Grosso...)
<kentonv>
man, XML... so popular for like three years and then poof, gone.
<DanC_>
well, gone like COBOL is gone. That is: not.
<kentonv>
of course
<kentonv>
but AFAICT absolutely no one proposes new data formats in XML anymore.
<DanC_>
nope.
<kentonv>
it's funny how XML was a "simplification" of SGML yet grossly overcomplicated compared to JSON. One would think that tech would get more complicated over time but the most popular tech actually gets simpler.
<DanC_>
OTOH, JSON is somewhat more complicated than s-expressions
<DanC_>
but it probably hits a sweet spot
<kentonv>
it matches well with the data structures we program against
<kentonv>
records and lists
<DanC_>
and JSON atoms are simpler than lisp atoms.
<DanC_>
strings, numbers, null. NOTHING ELSE
<DanC_>
oops... booleans
<kentonv>
though I'd say using a human-readable encoding is still overcomplicated. :)
<DanC_>
well, having an ecoding that very closely matches perl/python/ruby data literals is quite nice.
<DanC_>
I mean... bson is there, but not widely used
<kentonv>
BSON has all the disadvantages of JSON together with all the disadvantages of binary encoding
<DanC_>
how did we get here? enough philosophy.
<kentonv>
:P
<DanC_>
`vagrant-spk vm up` is on its way...
<DanC_>
aaand /home fills up
<DanC_>
who told you you could put a VM in my home directory, virtualbox?! grr
* DanC_
is winning now, after applying a patch noted there
<zarvox>
\o/
<DanC_>
looks like I don't need to mutate sandstorm/debian-jessie64 after all: "This box can work with multiple providers! ..."
<DanC_>
==> box: Successfully added box 'sandstorm/debian-jessie64' (v8.2.1) for 'libvirt'!
<DanC_>
"The forwarded port to 6080 is already in use
<DanC_>
on the host machine."
<DanC_>
it's in use by sandstorm
<DanC_>
am I doing it wrong?
<zarvox>
the vagrant-spk VM will run sandstorm inside of the VM
<zarvox>
You can stop Sandstorm on the host while you run the VM
<zarvox>
It's true that it's a little goofy, but remember on Windows and OSX you can't run Sandstorm on the host
<DanC_>
==> default: Downloading Sandstorm version 179...
<DanC_>
`vagrant-spk vm up` stopped. I think it won.
<zarvox>
yay.
<DanC_>
PolicyKit blurb on HOWTO-libvirt.md reminds me... PolicyKit uses javascript... I wonder if that can be used to do capability style stuff. I think I looked into it and decided no, but maybe it was just "no, I don't want to fight through the documentation to figure it out"
<DanC_>
ah.. the "port to 6080 is already in use" failure mode is documented on packaging-tutorial/
<DanC_>
as is enough info to be more confident that it won
<DanC_>
is there a durability story for sandstorm? with google drive, I'm pretty sure they store my data redundantly.
<DanC_>
hmm... when I do "New showcase" it just spins
<zarvox>
Sandstorm stores grain data at /opt/sandstorm/var/sandstorm/grains
<DanC_>
rephrase: is there a durability story for oasis?
<zarvox>
Oh. Oasis runs on Google Compute Engine, with Google's block storage.
<zarvox>
So it is replicated.
<DanC_>
ok. and the encryption-at-rest story is "coming soon"?
<zarvox>
Soon™ by which I actually mean probably not on the roadmap for several months at least
<zarvox>
you can use full-disk encryption or filesystem encryption if you're self-hosting
<DanC_>
I'd rather not self-host
<DanC_>
oh... and is the powerbox likely to be able to share across sandstorm services?
<DanC_>
maybe powerbox isn't quite the relevant thing
<zarvox>
if you're using Oasis, then the question of "who has the keys to unlock the storage to make things actually useable" arises
<DanC_>
the story I read so far is: only while your grain is running will the cryptfs be mounted
<zarvox>
sure, but who has the key to the cryptfs?
<DanC_>
and I somehow thought the keys were on the client side, but now that I think about it, that doesn't make sense
<DanC_>
there's no way to get tahoe-like properties, I suppose.
<DanC_>
harrumph. "new showcase" is still spinning. I was so close!
<zarvox>
Okay, I'm going to guess the issue is DNS on *.local.sandstorm.io
<DanC_>
ah.
<zarvox>
Each grain runs on a randomly-generated subdomain, all of which should resolve to 127.0.0.1 for the development VM
<DanC_>
so my /etc/hosts hack won't work there
<zarvox>
Sadly no.
<zarvox>
You could try doing `vagrant-spk vm ssh` and changing the VM's /opt/sandstorm/sandstorm.conf to use localhost and *.localhost in place of local.sandstorm.io and *.local.sandstorm.io?
<DanC_>
gotta cut dd-wrt out of the loop, then...
<DanC_>
"Hi! I'm PHP!"
<DanC_>
sandstorm.conf worked
<zarvox>
hooray!
<zarvox>
perhaps we should make that the default if it works on Windows and OSX and Linux and all the browsers alike
Telesight has joined #sandstorm
<DanC_>
so... I have a node.js app that downloads financial transactions. So far, it gets passwords from the gnome desktop keystore.
<DanC_>
to run on sandstorm, I'm thinking about letting it lease passwords for a week or two, with the release renewed by TOTP
<DanC_>
oh... what's the oasis policy on outgoing http?
<DanC_>
"For outbound network access for now, apps can request various specific network protocols like HTTP and SMTP using a short-term hack called HackSessionContext."
Telesight has quit [Quit: Leaving.]
jemc has quit [Ping timeout: 250 seconds]
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
afuentes has joined #sandstorm
biotim has quit [Ping timeout: 252 seconds]
Telesight has joined #sandstorm
aeviator has joined #sandstorm
lukexj has joined #sandstorm
mnutt_ has joined #sandstorm
mnutt_ has quit [Ping timeout: 250 seconds]
Telesight has quit [*.net *.split]
ThePurgingPanda has quit [*.net *.split]
[d__d] has quit [*.net *.split]
dograt has quit [*.net *.split]
ThePurgingPanda has joined #sandstorm
dograt has joined #sandstorm
Telesight has joined #sandstorm
[d__d] has joined #sandstorm
xet7_ has quit [Ping timeout: 276 seconds]
NwS has joined #sandstorm
pie_ has joined #sandstorm
pie_ has quit [Changing host]
pie_ has joined #sandstorm
jsilence has left #sandstorm [#sandstorm]
frigginglorious has joined #sandstorm
warren has quit [Ping timeout: 240 seconds]
warren has joined #sandstorm
tantalum has joined #sandstorm
_whitelogger has joined #sandstorm
warren has quit [Ping timeout: 255 seconds]
warren has joined #sandstorm
NwS has quit [Quit: See you in Isla de Muerte!]
Triplefox has quit [Quit: No Ping reply in 180 seconds.]
<asheesh>
Oh, now I see that you mention this in scrollback, kenton :)
<asheesh>
Anyway, morning all. : )
<asheesh>
DanC_: w/r/t etc/hosts: You can implement a similar dnsmasq hack if you like, but anyway :)
<asheesh>
DanC: If you want Tahoe-like properties, you could do something in the client. :) Arguably that's how SandPass's encryption should work. Someone did make a half-done zerobin (client-side encrypted pastebin) package. A downside is that the server can always backdoor the client, unless you increase your client-side defenses by using e.g. a browser addon.