<aldeka>
phildini, zarvox: fwiw, if you decide to use a CSS preprocessor, I'd advise Sass over Less; while I've used Less much more and happen to prefer its syntax, Sass has the larger community and integrations and so forth so it's what I would pick for new projects.
<aldeka>
</unsolicited-advice>
<zarvox>
aldeka: Sass has a Ruby dependency last I saw whereas Less was usually implemented in JS (or PHP) - is that still the case?
<aldeka>
There's a C implementation of Sass now iirc
<aldeka>
Preprocessors' nesting features also brings some sort of namespacing to CSS. Admittedly not as strictly as inline/JS-based styling, and nesting hell is also a thing to avoid, but.
<aldeka>
It is a feature I have greatly enjoyed.
<paulproteus>
++
<zarvox>
Hrm, I'm not finding sassc packages in Fedora or Debian. Might have to upstream something to make that smooth for contributors, or vendor in libsass or something.
<paulproteus>
Or we can submit them to Fedora and Debian!!???!
<paulproteus>
I also am not particularly motivated to do that but could become motivated to do so, if someone told me it was a really good idea.
<aldeka>
^_^
<paulproteus>
I'm mostly a vaguely interested observer at the moment and am pretty happy to do whatever people tell me is actually a good idea in terms of web frontend stuff.
<kentonv>
There is a meteor package for less. If there is one for sass as well, great. If not, that's a really huge reason to prefer less since when doing front-end development we really want Meteor handling the build so it can auto-update.
<kentonv>
could work. Note that the "less" package is part of meteor core, whereas this appears to be a third party. We should investigate quality.
<kentonv>
googling shows some complaints that it's an older version of sass
<kentonv>
that is, it's based on "libsass" which is not compatible with the latest versions of sass, or something
* aldeka
nods
<kentonv>
but we'll look closer at both before deciding.
<aldeka>
Depends on whether you need those features or not. I rarely use anything outside of nesting, variables, and mixins.
<aldeka>
Sticking w. the meteor-environment tool is a reasonable thing to do. And less is great :)
<kentonv>
Hmm, I guess less doesn't have nesting? That does seem pretty nice to have.
<aldeka>
It does!
<kentonv>
oops, never mind
<kentonv>
misread something
<kentonv>
ok, anyway, will investigate later
<aldeka>
I had some trouble making a dev recompile loop deal w. less for a couple projects, all of the jekyll + less integrations are clownshoes
<aldeka>
but it makes sense that jekyll community would have better support for the ruby-based tool.
<kentonv>
zarvox: I doubt it's currently a good use of our time to switch to React. Maybe in the distant future, when our server is no longer Meteor-based and when we have lots of spare time (hah).
<kentonv>
zarvox: I also think that having all HTML and CSS in a Javascript file could make it a lot harder for, say, non-programmer designers to make edits. But to be fair I haven't used React so don't know exactly how hard that gets.
<kentonv>
I also think that while the HTML structures of two different components are usually unrelated, the styling is very related. Hence why I'm thinking CSS should be in one package that sits on top of everything else.
<aldeka>
"it depends"
<kentonv>
Like, if the Sharing window and the Powerbox window are supposed to look stylistically similar, then I wouldn't want them each defining their own style. So either they need to both depend on some shared style library, or the shared stylesheet sits on top.
erikoeurch has quit [Ping timeout: 246 seconds]
<kentonv>
phildini: regarding server-side rendering, I actually really really like the fact that Meteor pulls only static resources over HTTP with all dynamic data coming over WebSocket. It makes it really easy to apply caching/CDN, and it simplifies authentication since it only has to happen once per long-lived WebSocket.
<fkautz>
should also work really well with http2, although... it remains to be seen how caching looks with http2 encrypt everything :x
<fkautz>
kentonv: do you know if there are any provisions for caching proxies on http2? local caching is still trivial :p
<kentonv>
fkautz: Well, I mostly think about CloudFlare here, and the way they work is they just sign a new cert for your domain with their private key and serve whatever they want.
<kentonv>
Because they can.
<fkautz>
oh interesting
<fkautz>
that is really cool and scary :p
<paulproteus>
Agreed.
<kentonv>
they actually do have a feature where you can insist that they not use their own keys, and that they not hold your keys, wherein their server will negotiate with your keyserver during SSL setup to produce a session key.
<kentonv>
which is pretty cool, but in practice not many people care
<paulproteus>
Like one MITM per session rather than a massive MITM
<kentonv>
one MITM with cooperation with the upstream server, yes
<kentonv>
I guess then you can pin your keys but still use cloudflare
<kentonv>
key pinning is terrifying, though
<fkautz>
yea, most end users will likely not care... i can't think of a good solution to this problem though... it's a pity there is no easy way for the main server to transiently trust another key
<fkautz>
like... sign another key and browser then trusts requests for x seconds from that domain for a given url mask
<fkautz>
then cloudflare would not need the ability to MITM because you can say serve everything from cdn.mydomain.com/.*\.png
<fkautz>
that matches that mask
<kentonv>
fkautz: Arguably the only difference between what you describe and their "keyless ssl" is that the former would only need to call back every N seconds while the latter is every session
<fkautz>
another benefit is you wouldn't need to share that secret with each connection and you could scope the request :p
gopar has joined #sandstorm
<fkautz>
still, that's really nifty
<kentonv>
fkautz: I think either way you can only scope by hostname; scoping by URL pattern will have a lot of issues.
<kentonv>
but that's fine, it's easy to put all your static content on a separate host
<fkautz>
my main complaint was around them being able to sign arbitrary hosts with their own key :p
<kentonv>
fkautz: Well, you have to direct your DNS to them first. And I think Globalsign does the actual signing, and it's probable that they check the DNS first.
<kentonv>
so you do actually have to be a cloudflare user, I think
<fkautz>
so similar to letsencrypt then
<kentonv>
fkautz: More accurately, letsencrypt is similar to how cert signing APIs from CAs have worked all along, except free. :)
<fkautz>
:)
jadewang has quit [Remote host closed the connection]
dcb has joined #sandstorm
jadewang has joined #sandstorm
dcb has quit [Ping timeout: 264 seconds]
mnutt_ has joined #sandstorm
<mnutt_>
I was looking into porting something approximating dropbox to sandstorm. what would be the best granularity as far as creating sandstorm documents? I would imagine people would want to share individual files with one another, but if I were using sandstorm’s sharing model it would involve creating potentially tens of thousands of sandstorm docs. Would creating sharable directories as sandstorm docs be better?
<mnutt_>
also, has anyone else started looking into something like this before?
jadewang has quit [Remote host closed the connection]
gopar has quit [Quit: Leaving]
<kentonv>
mnutt_: I can see use cases both for single-file and directory-tree variants. I'd say you should do what you think you'd want to use. :)
<kentonv>
dropbox replacements are a common topic but I don't think anyone has actually built or ported one yet
<kentonv>
note that a single-file grain would be a really easy app to write from scratch
<mnutt_>
alright, cool. with single-file, is there a way to generate a token that works across multiple files, or would the sandstorm tokens be per-file?
<mnutt_>
it looks like right now webkeys are per-sandstorm doc, so I may start out with a directory approach and see where it goes from there. because integrating with a desktop client doesn’t really work if every file needs its own auth.
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
dlitz has quit [Remote host closed the connection]
dlitz has joined #sandstorm
keturn has quit [Ping timeout: 264 seconds]
<paulproteus>
mnutt_: re: dropbox clone: I like sparkleshare and Syncthing
<paulproteus>
I'm excited about Syncthing in particular, and I would be honored to assign myself to you as mentor for porting either of those.
<paulproteus>
You may be asleep, given time zones, but I'd be extremely happy to chat more.
<paulproteus>
What I would love to see first, fwiw, would be a package that contains the Syncthing Web UI + the syncthing backend working, and then we could figure out together how to connect the existing Syncthing apps to it.
<paulproteus>
The develoeprs in #syncthing on freenode seem to be at least gently positive toward the idea.
<paulproteus>
Anyway, I'm asheesh@sandstorm.io and would be extremely happy to spend time this week+month helping with anything you need, so I hope you'll send me an email!
jadewang has joined #sandstorm
<mnutt_>
paulproteus: that sounds interesting, I hadn’t seen syncthing before. I was actually looking into something like owncloud, as its webdav sync protocol would be pretty easy to hook up to the http bridge.
<paulproteus>
I'm happy with either! I vaguely like that SyncThing is focused on just the one use-case of file sync, so no one will get confused trying to use OwnCloud Contacts in a file sync app, but either way.
<paulproteus>
It'll be your app; you can totally pick. : D
<mnutt_>
but while mirall (the desktop sync client, built in qt) is pretty good, there’s way too much going on with owncloud itself for me to take on porting it, and I haven’t written php in many years. so I have a node-based backend port working and syncing with mirall in single-user mode, just working on how to hook it up to sandstorm.
jadewang has quit [Ping timeout: 255 seconds]
<paulproteus>
Nice, mnutt_
* paulproteus
reads about mirall
<paulproteus>
When you say "node-based backend port" working, do you mean there's a node-based codebase that is compatible with mirall?
<paulproteus>
And that you have a package of that for Sandstorm?
<paulproteus>
FWIW I think WebDAV needs some verbs we may not allow yet in sandstorm-http-bridge, but we can add them.
<paulproteus>
verbs like HTTP verbs
<paulproteus>
For Syncthing, the protocol is some raw TCP thing, so you'd have to patch clients to speak their TCP protocol layered over Sandstorm HTTP. But I think that wouldn't be "that" hard.
<paulproteus>
What I would really do is try to make a package + patch one client to show it works, and then show the Syncthing upstream team that this would be really great to support as a protocol revision.
<mnutt_>
amazingly, someone wrote a straight port of the php webdav server to node, and it was fairly simple to use it to build something that acts like the owncloud backend. It uses some php endpoints, but everythign seems to work.
<paulproteus>
Wow.
<paulproteus>
It's, like, ownCloud Minus ownCloud
<paulproteus>
Have you heard of Garfield Minus Garfield?
<paulproteus>
It's like that.
<mnutt_>
hah, yeah
<paulproteus>
Is there a web UI for viewing your files, then?
<paulproteus>
Also BTW are you using vagrant-spk?
<mnutt_>
there isn’t yet, I’m working on that next after I get the client-based sync working
<paulproteus>
If you do use it, I can very easily review any packaging you create, since vagrant-spk packages can be rebuilt by others.
<paulproteus>
Also how did we get so lucky to have someone as motivated as you to drop by? : D
keturn has joined #sandstorm
<mnutt_>
I actually came to the docs in a roundabout way and ended up setting up vagrant on its own and using spk from there; is there an advantage to using vagrant-spk over spk directly?
<paulproteus>
The main advantage is that it'll be possible for other people (e.g. me) to view the packaging scripts, so I can give feedback easily.
<mnutt_>
ah ok, I’ll switch to that
<paulproteus>
Another advantage is that upstream (the app authors) can merge the .sandstorm/ directory and so you don't have be all isolated from the community.
<mnutt_>
great
<paulproteus>
You'll find that you have to use the "DIY" stack and that it'll be very slightly clunky for node stuff; sorry about that in advance, and you have my commitment to help you out with any questions.
<paulproteus>
The docs for vagrant-spk are I think reasonably good so you should be OK. I'm just being a little harsh on myself.
<paulproteus>
"myself" since I co-wrote those docs. Sorry if I'm rambly.
<mnutt_>
no problem, thanks! it’s been pretty smooth so far
<mnutt_>
and as far as how I showed up here, I’ve been really interested in p2p for a long time, and have been disappointed as p2p has seemed to become less viable over time due to everything moving to mobile or at least laptops, which aren’t always on. (and ipv6 not helping, either) The epiphany was that at least in the short term it’s enough to own your data, even if you don’t physically own the server it’s on. So I’m real
<mnutt_>
excited about sandstorm.
<paulproteus>
: D
<mnutt_>
alright, it’s 3am here so I’m going to call it quits for the night, but thanks for the pointers. I’ll definitely drop a link in here once I have something working in the next few days.
<paulproteus>
Okay, well it's bed time for me. I'll check in again with you in a bit.
<paulproteus>
mnutt_: I see we think alike (-:
<paulproteus>
Feel free to bug me here or by email if things don't make sense with vagrant-spk.
<mnutt_>
thanks! later
<paulproteus>
*also* please send me an email now so I know your email address, so I can ping you in a week if you get lost or something! If you're willing.
<paulproteus>
asheesh@sandstorm.io + good night!
pouledodue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
pouledodue has joined #sandstorm
erikoeurch has joined #sandstorm
erikoeurch has quit [Client Quit]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 255 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
mort___ has joined #sandstorm
mort___ has quit [Client Quit]
mort___ has joined #sandstorm
jadewang has joined #sandstorm
pouledodue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jadewang has quit [Ping timeout: 265 seconds]
pouledodue has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
decipherstatic has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 248 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
_iwc has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
erikoeurch has joined #sandstorm
erikoeurch has quit [Ping timeout: 264 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
ecloud has joined #sandstorm
mnutt_ has quit [Quit: mnutt_]
erikoeurch has joined #sandstorm
mnutt_ has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
<erikoeurch>
Does the Sandstorm Paperwork app intentionally disallow users from creating a collection (a notebook collection)? Clicking that button does nothing, but there are no errors
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 255 seconds]
mort___ has quit [Ping timeout: 246 seconds]
mcpherrin has joined #sandstorm
decipherstatic has joined #sandstorm
jadewang has joined #sandstorm
<paulproteus>
erikoeurch: I think that JJ made a packaging decision to disable that, but if so, it should be reflected in the UI.
<paulproteus>
This is all to say: I don't know, and if I were you, I would file a bug against the Paperwork package by finding the github link on the Sandstorm app list.
<erikoeurch>
okay, I'll file a bug report
<paulproteus>
Awesome. (-:
dlitz has quit [Ping timeout: 264 seconds]
dlitz has joined #sandstorm
* paulproteus
moves some docs around.
dlitz has quit [Ping timeout: 252 seconds]
dlitz has joined #sandstorm
maurer_ has joined #sandstorm
<erikoeurch>
paulproteus, are the grain sharings links and webkeys supposed to be barely visible (dark blue on black)?
<zarvox>
I would love it if they were more readable.
mort___ has joined #sandstorm
<erikoeurch>
I was thinking I'd report it as an issue
<erikoeurch>
perhaps that's unnecessary though?
jparyani_letscha has quit [*.net *.split]
[d__d] has quit [*.net *.split]
DanC_ has quit [*.net *.split]
maurer has quit [*.net *.split]
mnutt__ has joined #sandstorm
joshbuddy has joined #sandstorm
<paulproteus>
erikoeurch: Please do report as an issue!
<paulproteus>
Totally a Sandstorm bug IMHO.
<erikoeurch>
Done!
dlitz has quit [Ping timeout: 264 seconds]
<erikoeurch>
Is it not possible to add labels to an issue if I'm not the owner of the repository?
<erikoeurch>
In Github
dlitz has joined #sandstorm
<paulproteus>
Correct, I believe.
mnutt__ has quit [Read error: Connection reset by peer]
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
erikoeurch has quit [Ping timeout: 246 seconds]
erikoeurch has joined #sandstorm
jadewang has quit [Ping timeout: 256 seconds]
bb010g has quit [Quit: Connection closed for inactivity]
<kentonv>
dwrensha: when I try to upload a theme to Wordpress, I get prompted for FTP credentials? O.o
<dwrensha>
eek
<kentonv>
"To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host."
<dwrensha>
yeah, I've seen the error
<kentonv>
I'm having trouble imagining what this could even mean, outside of Sandstorm.
<kentonv>
but a user is asking about it so I'm trying to figure out what to tell them
<dwrensha>
OK, I've reproduced the problem on Oasis
<dwrensha>
it doesn't happen on my personal server
<kentonv>
is it Oasis-specific?
<kentonv>
weird
<dwrensha>
works on Alpha too
<dwrensha>
This is mysterious, but not too surprising to me...
<dwrensha>
I think the same error comes up if you try to upload a plugin when running `spk dev`
<kentonv>
ok, filing issue
<dwrensha>
so I guess it's filesystem-related, somehow?
<kentonv>
I don't think the filesystem on Oasis should be visibly different, but I suppose there could be obscure subtle differences
<dwrensha>
I'll look into
<dwrensha>
it
<kentonv>
k
<dwrensha>
my suspicion is that it's a timing issue... if something takes too long, then the FTP thing comes up as a fallback
<kentonv>
hmm, well, if it turns out Oasis is visibly different somehow, then I'll consider it a bug in Oasis. But if it's timing, then that's probably a bug in the app.
<zarvox>
kentonv: you were curious about nginx memory usage: about 2% of an example PHP/mysql/nginx grain's unsharable memory is nginx's (1.2MB)
<zarvox>
(the RSS fraction is about 7%, at 7MB)
<zarvox>
for comparison, node in the etherpad package sits at 110MB
<zarvox>
ditto ethercalc
<zarvox>
I think we correctly share mapped libraries of multiple grains of the same app at present, so I'm going to claim that the memory hit there is small
jadewang has quit [Remote host closed the connection]
<ocdtrekkie>
What do i have to do for a purple shirt?
jadewang has joined #sandstorm
<kentonv>
zarvox: great, that sounds fine then
<paulproteus>
i,i one floppy disk of RAM per nginx
<kentonv>
ocdtrekkie: email Jade and remind her of your address. :)
<paulproteus>
++
<paulproteus>
(or heck email me asheesh@sandstorm.io and save Jade the back-and-forth)
<kentonv>
dwrensha: Where does the username in the gitweb offer template come from?
<dwrensha>
random bits from the client
<dwrensha>
they are entirely for the client
<dwrensha>
git crendential helpers use the username to distinguish different passwords
<kentonv>
I guess the random username I received looks suspiciously like a qwerty user bashed the keyboard, but that's just a coincidence? :)
<dwrensha>
well, I *did* do the lazy thing and only use lowercase ascii characters
<kentonv>
in my case the letters are almost entirely from the qwerty home row. :)
<dwrensha>
try reloading, they will be different
<kentonv>
yep
<kentonv>
The new template is a lot nicer than the old instructions but I think it would be great to give users something they can copy/paste directly into their terminal.
<kentonv>
at actual "git clone" command
<dwrensha>
to have an actual git clone, we would need a repo name
<dwrensha>
I suppose we could read it from the grain title
<kentonv>
hmm
<dwrensha>
(without a repo name, git clone will name the directory after the URL)
<kentonv>
you could use "my-repo" or something as a placeholder
<kentonv>
well, this is exactly why we need an example because users aren't going to know that intuitively. :)
<paulproteus>
++ re: actual git clone
<kentonv>
also some instructions on how to set up the credentials helper would be great, so that they don't think they need to retype their password on every action
<dwrensha>
there are many credential helpers to choose from!
<paulproteus>
(I thought they're auto-configured by git!)
<paulproteus>
(If not, sad.)
<kentonv>
well give the easiest example and users who actually care will know to use their own. :)
<dwrensha>
the very easiest thing would be not to use a credential helper at all, and to jam the password into the URL
<dwrensha>
but I don't want to encourage that
<kentonv>
yeah, that's probably no good.
<dwrensha>
the second-easiest thing would be to suggest `git config credential.helper store`
<paulproteus>
I was hoping we would encourage people to jam the password into the URL for now, since everything else is so much harder.
<dwrensha>
which stores the password on disk at `~/.git-credentials` with owner-only read permissions
<paulproteus>
Presumably .git/config also is 0600 though? (/me checks)
<paulproteus>
(Wow, nope, seems like it's 0644 on my laptop for the Sandstorm repo I cloned, at least.)
<dwrensha>
yep, that's what I've observed too
<kentonv>
yes, and people could easily accidentally serve up their whole .git over HTTP
<dwrensha>
also, if the password is in the URL, then it is printed to the console every time that git the git client hits the server
<kentonv>
like you can tell that sandstorm.io is served from a git repo: https://sandstorm.io/.git (but we don't actually serve the contents because nginx assumes dotfiles are private, I guess)
<paulproteus>
"All I want" is something I can copy-paste into a terminal. (aka all I want is a pony for christmas.)
<paulproteus>
BTW going through and moving these docs has the somewhat absurd upside that I now have read all the docs for sure.
<zarvox>
paulproteus: thanks for your heroic effort to migrate all the docs!
<paulproteus>
(-:
<dwrensha>
grr. I can never remember whether the PHP function I want is error_log() or log_error().
<dwrensha>
for the record, it's error_log()
<XgF>
dwrensha: Because PHP
<XgF>
Where some functions were nmaed to ensure a good bucket distribution when using "strlen" as a hash function
<XgF>
(seriously)
maurer_ is now known as mauer
mauer is now known as maurer
mort___ has quit [Quit: Leaving.]
mort___ has joined #sandstorm
<zarvox>
hrm, requests to alpha-api appear to come from 10.240.0.0 to grains, when they send X-Sandstorm-Passthrough: address. Perhaps we need to tell nginx to pass on the X-Real-IP header?
<paulproteus>
"obviously" the Sandstorm admin dashboard should show a big red (X) if you don't have X-Real-IP coming in.
<zarvox>
Well, unless you're exposed to the outside network, in which case you can reliably detect goodness, but if you're connecting from your internal network you can't be sure that things are bad if you get an RFC1918 remote address
<zarvox>
(like, no reverse proxy present)
<dwrensha>
is oasis wedged?
<dwrensha>
I can't open a grain or install an app
<kentonv>
eek
<kentonv>
ok, so somehow the front-end was wedged
<kentonv>
I think we saw this happen on alpha or demo recently as well?
<paulproteus>
demo
<kentonv>
restarting node fixed it
<kentonv>
I checked before-hand on FDs and there weren't too many open
<zarvox>
wonder how it got into that state
<paulproteus>
I was going to try to load-test it but definitely have not yet.
<kentonv>
we now know that it was definitely node and not the back-end that was wedged, fwiw
<zarvox>
yay, probably not a bug in our code?
<kentonv>
zarvox: no, it's almost certainly our bug. :P
<kentonv>
the behavior was as if the cap'n proto link to the back-end had stopped responding.
<dwrensha>
I've been doing a lot of uploading test wordpress spks
<kentonv>
or perhaps, began responding very slowly
<kentonv>
it looks like one request did get through in the middle
<dwrensha>
... maybe the bug is in the installer code
<kentonv>
no one installs anything on demo, though
<zarvox>
did you get a look at CPU load, or a stacktrace?
<kentonv>
zero CPU load
<kentonv>
note that node was still running, it's just that requests from it to the back-end were being super-slow
<dwrensha>
aha, so I found the thing that breaks wordpress on oasis
<dwrensha>
it's file ownership
<dwrensha>
the read-only app files are owned by user 65534
<dwrensha>
and the grain storage is owned by user 1000
<kentonv>
ah, yes
<dwrensha>
and since they don't match, wordpress decides that it shouldn't write
<dwrensha>
I think I can easily override this behavior in wp-config.php
<zarvox>
Presumably we could also make the read-only app files owned by user 1000?
<kentonv>
zarvox: we could, but it would mean eliminating a defense-in-depth measure
<kentonv>
I would like different grains to run as different UIDs
<kentonv>
but the package files have to be owned by a specific UID
<zarvox>
ahhh, but can't you still do that with uid_map? or does that break?
<kentonv>
uid_map cannot make two different UIDs look like the same UID
<zarvox>
is the defense-in-depth measure having grains run as UIDs that are not those owning the files in the sandbox?
<zarvox>
I'm not sure exactly what the contours of this are
<dwrensha>
If we're going to keep this behavior in blackrock, I think we should always do it, so as to avoid the kind of bug I'm seeing ehre
<kentonv>
The defense-in-depth measure is having different grains run as different UIDs. The per-grain mutable storage is owned by the UID that runs the grain. The package content is owned by something else.
<kentonv>
this means that if a method is discovered for a grain to interfere with processes outside of the sandbox owned by the same UID, they won't work on Oasis
<kentonv>
unfortunately on single-machine Sandstorm where we don't own the machine, it's much more difficult to do this, because the grain files on-disk would have to be owned by a variety of UIDs
<kentonv>
hmm, we could easily make `spk dev` report a different UID for its files.
<zarvox>
I was hoping there would be a mount option like vfat's "uid=" that we could use on a per-mount-namespace basis to make it so each grain only sees one UID on the FS, but they're different from the outside
erikoeurch has quit [Ping timeout: 246 seconds]
<zarvox>
but looking over the man pages suggests this isn't a thing for FSes with native posix ACLs
<kentonv>
we would specifically need it on bind mounts
<kentonv>
there are probably all kinds of security issues, though
<kentonv>
I suppose we could ask Eric Biederman to think about it
<zarvox>
kentonv: reporting a different UID in `spk dev` adds another delta between dev mode and prod mode, which are things that I'm hoping to reduce, if at all possible
<zarvox>
I suppose that at present, there's a delta between dev and on-blackrock prod, though, so it wouldn't be a regression per-se.
<kentonv>
zarvox: it adds a delta between dev mode and Sandstorm, but removes a delta between dev mode and Blackrock
<kentonv>
this at least means that developers can test both ways locally
<zarvox>
I'd rather remove the delta between blackrock-prod and sandstorm-prod, as seen by the grain.
<kentonv>
I think that this particular issue is likely rare
<kentonv>
zarvox: yes I'd prefer that too but that's not apparently an option without new kernel features
<zarvox>
the other option is dropping the defense-in-depth measure unless sandstorm can support it too
<kentonv>
I think the defense-in-depth measure is important.
<kentonv>
particularly on Oasis where there are many different users, possibly malicious
<zarvox>
Okay. I think that developers having confidence that things will work in production the same way they worked in dev is important too. Tradeoffs.
<paulproteus>
Does this mean "chown 1000 *" in a Sandstorm package file becomes wrong? If so, sad panda.
<paulproteus>
Actually ignore me.
<kentonv>
paulproteus: that never would have worked since it's a read-only filesystem
<dwrensha>
Yay, with `define('FS_METHOD', 'direct');` the issue goes away.
<paulproteus>
I meant in the build scripts, but yeah, ignore me, I'm going to read more carefully before saying anything further.
<dwrensha>
I do suspect this is a rare problem
<zarvox>
Fair 'nuff.
<paulproteus>
The OLPC approach to this is to create a libnss module that creates app-specific UIDs, fwiw.
<paulproteus>
And then on app install, chown the files.
<kentonv>
paulproteus: the problem is that each _grain_ should have a different UID while sharing the same app files.
<paulproteus>
I see, interesting.
dlitz has quit [Quit: No Ping reply in 180 seconds.]
<paulproteus>
You could maybe play games with hard links and chown?
<paulproteus>
Nope, hard link chown changes the original file too. nm.
dlitz has joined #sandstorm
<kentonv>
I guess all we need to simulate the behavior on Sandstorm is for the packages to be owned by a UID other than the server user
<kentonv>
but I think that requires a bunch of complication, and certainly wouldn't work for servers that run without any root privs
<paulproteus>
I like the idea of `spk dev` reporting the fake UID, fwiw.
<zarvox>
right, and uid_map doesn't help because even in your userns you still only have one rootns UID
<paulproteus>
Doesn't help with self-hosted Sandstorm (but honestly if self-hosted Sandstorm doesn't have root, I'm OK with it acting a little different, I think).
<paulproteus>
That is, doesn't help with self-hosted Sandstorm *running apps* rather than *spk dev*-ing apps.
<zarvox>
I also have this dream of not needing spk dev's fuse layer to run apps in devmode, and adding the fake UID seems like something that will be difficult to replicate otherwise