<mixedemotions>
Hi i need a little help setting up sandstorm on my own server
<mixedemotions>
Im running sandstorm on proxmox and im behind a vpn
<mixedemotions>
I can get the server to start
<asheesh>
Hi mixedemotions
<asheesh>
That's great!
<asheesh>
What is the question, then? :)
<mixedemotions>
the first question is how do i get it to start after the install and what port should i open and im using pfsense for a router but its in a separate box
<mixedemotions>
I did get the link after it installed
<asheesh>
By default, port 443 and 80; optionally, 6080, 30025
<mixedemotions>
thanks but when i check the status it says not running
<mixedemotions>
I see that but i dont get a fail it installs perfectly fine
<asheesh>
Interesting. Can you do 'sudo modprobe fuse' from the Sandstorm machine, and tell me if it gives you any error message?
<mixedemotions>
modprobe: ERROR: ../libkmod/libkmod.c:507 kmod_lookup_alias_from_builtin_file() could not open builtin file '/lib/modules/4.2.6-1-pve/modules.builtin.bin'
<asheesh>
So I think this is a problem with your hosting provider, and I don't fully understand the info on that forum thread.
<mixedemotions>
im behind a vpn
<mixedemotions>
plus the server is in my house
<asheesh>
I have to run in a moment, but if you're willing to email support@sandstorm.io so that I don't lose you, then that's great.
<asheesh>
Also, if you're willing to wait a few days, I can probably add a workaround to Sandstorm to overcome this issue, and then you can 'sudo sandstorm update' and then you would get the new code.
jacksingleton has joined #sandstorm
<asheesh>
Yay hi jacksingleton fwiw I'm in Workshop Cafe w/ another meetup denizen, though heading out in 30 min or so.
<mixedemotions>
i can wait this is my DIY project
<asheesh>
Cool (-: also, what is the contents of /opt/sandstorm/var/log/sandstorm.log ?
<asheesh>
Basically, do you have this line?
<asheesh>
sandstorm/run-bundle.c++:1122: failed: mount("/dev/fuse", "dev/fuse", nullptr, MS_BIND, nullptr): No such file or directory
<mixedemotions>
nope thats not in the log
OOCoder has joined #sandstorm
<asheesh>
Fascinating. Is there some kind of FUSE-related error, out of curiosity?
jacksingleton has quit [Ping timeout: 248 seconds]
jacksingleton has joined #sandstorm
wolcen has quit [Ping timeout: 244 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
<dlitz>
ocdtrekkie, asheesh, kentonv: Thanks (re: the TTRSS Androd client stuff). I'm not a huge fan of TTRSS anyway, but I'm collecting ideas about how a Sandstorm SDK for Android might work, and how to make it really simple.
<dlitz>
Looking at this, it might not be a bad idea to have some way for developers to support configuration via Sandstorm without necessarily having any code with the word "sandstorm" in their app.
wolcen has joined #sandstorm
<dlitz>
maybe some sort generic intent that opens up the app's config screen and pre-fills some fields. "Sandstorm support" would just become "bearer token authentication".
<dlitz>
I wonder about the security of that, though.
<kentonv>
dlitz: the official ownCloud mobile clients work with Davros with no Sandstorm-specific code, and many CalDAV apps work with Radicale...
<kentonv>
they use HTTP basic auth, though. We do prefer bearer tokens if possible.
<dlitz>
kentonv: I'm talking UI, here. I've configured DAVical with Radicale, and the experience is absolute crap.
<kentonv>
yeah...
<kentonv>
I'd like to support something where you scan a QR code
<dlitz>
I did it with QR codes and a barcode reader, but I had to scan two separate codes, and configure the barcode reader to disable its history; and it still leaks the token onto the clipboard.
<dlitz>
I wouldn't be surprised if it ended up in the system log, too
<kentonv>
interesting
<kentonv>
we could make the token single-use, exchanged for a long-term token, though the receiving app would have to support that
<dlitz>
I'd much prefer to see something OAuth2-like, where Sandstorm presents a QR code that's basically a one-time token, and then something on the phone uses that to make a separate API call to get the real token.
<kentonv>
OAuth has some precedent for that
<dlitz>
lol, exactly
<kentonv>
haha
<kentonv>
fwiw we also want Sandstorm to directly support being the provider end of an OAuth flow
<kentonv>
where Sandstorm will actually direct the user through a powerbox flow
<kentonv>
to choose the capability to grant
<dlitz>
That makes sense to me, at least at first glance.
<kentonv>
down side of using that directly is that the app would have to know in advance the URL of the Sandstorm server
Zertrin has quit [Ping timeout: 248 seconds]
Zertrin has joined #sandstorm
<dlitz>
Isn't there some OAuth spec that's supposed to replace the OpenID flow, or something? (I really haven't kept up with either.)
<dlitz>
I feel like OpenID jumped the shark when they started talking about "XRI"s. That said, I still run my own OpenID provider.
<kentonv>
the login flow Sandstorm uses with Google and Github is OAuth
<kentonv>
basically you request "basic profile details" as an oauth scope.
<dlitz>
Right, but Sandstorm has to have Google and GitHub pre-configured, which I think was your point.
<kentonv>
I think Google's oauth authentication flow is also called "OpenID Connect" in their docs
<kentonv>
IIRC
<kentonv>
unfortunately every OAuth API provider wants all clients to pre-register themselves, which kind of sucks for self-hosting usability.
<kentonv>
especially in Google's case where the UI is awful
OOCoder has joined #sandstorm
<dlitz>
Yeah
OOCoder has quit [Client Quit]
jacksingleton has quit [Ping timeout: 248 seconds]
<dlitz>
So another thing I was thinking of, wrt having a Sandstorm Android app, would be to allow users to log in using the app itself.
<dlitz>
Basically, the Sandstorm login page could show a one-time-use QR code iin it, and then the app would connect and authenticate the web session that way, similar to what WhatsApp Web does.
jadewang has joined #sandstorm
<kentonv>
I'm not sure I'm following...
<dlitz>
Well, right now, if I want to log into Sandstorm, I have to delegate my trust to Google or GitHub or the really-painful-to-use email login method.
<kentonv>
ah
<dlitz>
Presumably the lack of password authentication is by design (good idea: passwords suck)
<dlitz>
I really just want to pick up my phone and scan a QR code, or something like that.
jadewang has quit [Ping timeout: 240 seconds]
<kentonv>
there was an experiment to do Google login that way like 5 years ago, I think
<dlitz>
Yeah, I don't think it would have made sense for Google 5 years ago, or maybe even now. The biggest problem is still recovering your identity when you lose your phone.
<dlitz>
On the other hand, everyone's solution today seems to be to fall back on either a phone number or email.
<kentonv>
Note that we have a requirement that Sandstorm identities be "global", such that multiple sandstorm servers can independently authenticate you and agree on who you are, so that grains can be transferred between servers without losing track of users
<kentonv>
so, for instance, username/password login (where the usernames aren't email addresses) would never work on Sandstorm because usernames are not global
<dlitz>
Hm, I haven't played with the grain-transferring feature yet. I didn't even remember seeing it anywhere in the interface.
<dlitz>
It doesn't seem like a big problem, though.
<kentonv>
there's a "download backup" button in the top bar, and then you can upload to a different server
<kentonv>
if you transfer, say, a rocket.chat grain this way, on the new server, it will still know who everyone is
<kentonv>
Sandstorm has separate concepts of "accounts" and "identities"
<pdurbin>
kentonv: am I allowed to have more than one global identity within Sandstorm?
dcb has quit [Quit: dcb quit]
<kentonv>
an "identity" is globally-authenticatable. An "account" is a collection of grains. You use an identity to log into an account.
<kentonv>
pdurbin: yes
<kentonv>
on the account settings page, you can add additional identities
<kentonv>
I suppose we could also make it possible to add login methods that aren't identities, but you would always need to have at least one identity on your account, which give you a way to recover if you loose your login token.
<kentonv>
(at least one identity would be required also so that you have an identity to act as when you enter grains)
dcb has joined #sandstorm
<dlitz>
I don't really see how this would be a problem for app-based login. Basically, my phone would be my identity (or hold multiple identities), which would probably be some kind of uuid or public key fingerprint.
<kentonv>
dlitz: that technically works, but if you lose your phone you lose all your data.
<dlitz>
(An Android app could probably also attach the Google identity, but it'd be optional so I'm ignoring that for now.)
<dlitz>
If I lose my GitHub account or my Google account or my domain name, it's the same problem.
<kentonv>
how would you lose your GitHub or Google account?
<pdurbin>
lose control of it
<kentonv>
Google and GitHub have teams who can help you recover from hijackings.
<dlitz>
Well, if my house burned down and I had access to neither my passwords nor my bank account, my email domain would lapse.
<kentonv>
your registrar has people who can help you with that
<dlitz>
The solution that everyone's using is simply to bind multiple identities together. "Recovery email addresses" and the like. As far as I can tell, Sandstorm already does this, so I really don't see how this is special.
wolcen has quit [Ping timeout: 244 seconds]
<dlitz>
On mobile, everything is tied to your phone number, which is extremely easy to lose if you lapse on your payments.
<dlitz>
and it works
<kentonv>
it is far more common to lose your phone than to lose your phone number
<dlitz>
If I'm self-hosting, I *always* have a way to recover anyway.
<kentonv>
but this is about federation that works across other people's servers as well
<kentonv>
yes, Sandstorm supports multiple identities on an account, but when other people share grains with you they share to a specific one of your identities
<kentonv>
anyway, as I said, we could conceivably support login mechanisms that aren't identities, but I'm wary about calling a phone an identity.
<kentonv>
I do want to support "public key as identity" at some point, but with the assumption that anyone using it knows how to keep backups of their public key
OOCoder has joined #sandstorm
<dlitz>
tbh, it might not make sense for a hosting provider that doesn't want a lot of support overhead, but for a paranoid self-hoster like me, it's really attractive.
<dlitz>
From a technical perspective, I think if "email address" as an identity can work, so can this.
<dlitz>
Like, if identity is being passed around between servers, the other servers can't trust it anyway. It's really "email address attested by <server>". One could just as easily substitute a phone number or a public key or anything else into that.
<kentonv>
it's always "email address attested by the server on which the grain is running"
<dlitz>
Ok, so it sounds like one could just as easily plug in a Twilio account and do phone number verification, like literally everyone on mobile does.
<dlitz>
So we'd do like WhatsApp or Signal, pretty much exactly.
<kentonv>
absolutely
<dlitz>
Of course, I would probably turn that feature off, since I can always ssh as root into the server, but I'd probably leave it on by default if I were designing the app.
<kentonv>
All I'm saying is I don't want to put any user in a position where if their phone breaks, they've permanently lost access to data on Sandstorm. The solution is either (a) use this only as a login mechanism but not an "identity", or (b) make this be one way to authenticate public-key-as-identity, and set the expectation that the user will keep backups of their private key.
<dlitz>
Anyway, would you be opposed to merging a feature like that, if I actually sat down and designed & implemented it?
<pdurbin>
can Sandstorm help you recover from a phone hijacking? :)
<dlitz>
I've been thinking of doing "mobile-first" Sandstorm+Android as a hobby project, but it would be pretty discouraging if I did all the work and then you were opposed on principle, like the ttrss guy
<dlitz>
(No promises, though. You shouldn't block on me if you haven your own plans, but it seems like so far it hasn't been a priority for you folks.)
neynah has joined #sandstorm
<kentonv>
I'd love it if you worked on this. The way to avoid wasted work is to have a design proposal we can review before implementation. I'm sure we can come up with something that works -- I'm certainly not objecting to the whole idea, just saying there should be certain safeguards in place.
<kentonv>
FWIW, public key authentication is something we've promised in the past but haven't gotten to yet, and it seems like it could form the basis of this.
<dlitz>
I don't know if I can promise a design proposal: adhd---some kinds of structured writing can be prohibitively time-consuming for me, plus I'm very, very new at design, and I'm learning Android development as I go, too. I'm much better with IRC, and I'm more likely to tinker with it for a while and then make a proof-of-concept. :)
<dlitz>
In any case, I'm not looking for a promise that you'll merge any particular pull request. More just if you like the idea, in principle.
<dlitz>
My expertise is more in crypto and back-end systems, but lately I'm bored with that and want to do some more user-centered mobile stuff. But of course the crypto chops will come in handy for something like this. :)
<kentonv>
dlitz: I have (mild) ADHD too, so I understand. I don't need structure, just a general idea of what you have in mind. This IRC conversation has already provided a lot of that, so maybe that works.
<dlitz>
oh, haha, awesome. :)
frigginglorious has joined #sandstorm
frigginglorious has quit [Client Quit]
jadewang has joined #sandstorm
neynah has joined #sandstorm
frigginglorious has joined #sandstorm
dcb has quit [Quit: dcb quit]
<dlitz>
Yeah, I was undiagnosed until I was in the middle of burning out in SF on a work visa a couple of years ago, so I'm back in Canada until I figure out how to manage it better. :/
<dlitz>
This is one of the better ideas I've had for personal projects that might hold my interest, and I'd like to be kept in the loop about Android stuff if possible, but I tend to have long periods where I just become unavailable, so I don't want my interest to end up making me a defacto gatekeeper (like what happened with PyCrypto, unfortunately).
<kentonv>
dlitz: The main idea I've had regarding an android app is that it could be a hub for other Android client apps to discover your Sandstorm server. We don't currently have anyone working on it, though.
<kentonv>
but I'd like other Android apps to be able to make a Sandstorm powerbox request as an intent, to which this app would respond
dcb has joined #sandstorm
<maurer>
kentonv: Yeah, speaking of contributions, I don't know when github pings, but I've got everything-but-the-tests done I think, so the code itself should be ready for review
<kentonv>
maurer: github only pings when you comment. Could you add a comment so that it's in my mailbox? :)
<dlitz>
kentonv: tbh, I haven't quite wrapped my head around the security model behind intents on Android, or what the Powerbox UI really does or how it would be useful on Android. This will probably happen soon-ish.
<maurer>
kentonv: done
<kentonv>
dlitz: to be fair, the powerbox isn't really ready yet in the main web interface
<kentonv>
should become clearer once it is
<dlitz>
In the short-medium term, I'm less interested in deep integration with Android apps, and more interested in just basic connectivity between Android client apps and Sandstorm grains, and possibly the identity management stuff.
<kentonv>
but basically it's a picker interface. So the rocket.chat app could say "I need to know what rocket.chat server to connect to", and then the Sandstorm powerbox would give you a list of your rocket.chat grains (including ones shared with you) to choose from and then return a token to the requesting app.
<dlitz>
Oh, yeah, that's definitely along the lines of what I'm thinking.
<dlitz>
although I also want it to work via webkeys/QR codes even if the "Sandstorm app" isn't actually installed (but rather, the app itself ships the SDK, kind of how Facebook does it)
<kentonv>
key difference between powerbox and a typical OAuth flow is that OAuth tends to assume that the requester knows exactly which thing it is trying to access and the user only needs to choose yes/no, whereas the powerbox expects that there are multiple answers (e.g. if you have multiple grains) and it's the user's job to choose one
frigginglorious has quit [Quit: frigginglorious]
<kentonv>
yes, I agree, we should implement QR-code-based coupling without the need for a separate app
<kentonv>
that's something that's high on our priority list, actually
<kentonv>
for the short term
<dlitz>
I'm still very new at Android stuff, but I wonder about the security+freedom interaction of passing credentials in intents.
<kentonv>
what do you mean?
<dlitz>
My understanding is that the Android intend security model works based on, basically, the public keys of whoever signed whichever apps
<kentonv>
yeah that's unfortunate
<dlitz>
or, alternatively, any app can service any intent
<dlitz>
so, if apps implicitly trust the Sandstorm app, then whoever has the private key corresponding to the well-known public key of the Sandstorm app, basically has root on everything Sandstorm
<dlitz>
From what I understand, that's less of a problem if every app ships its own copy of the auth-related stuff
frigginglorious has joined #sandstorm
<dlitz>
So I've been considering both options: App-ful & App-less, and I probably won't have an answer until I get further along in understanding how this all works.
<kentonv>
well, I'd expect that the Sandstorm project would take ownership of the app and sign releases... and you could say that we already have root on all things Sandstorm by virtue of being the ones that write and review the code.
<dlitz>
No, that's not true at all.
<dlitz>
Honestly, I'm not okay with that, philosophically.
<kentonv>
hmm, I guess I'm not understanding
<dlitz>
There's a big difference between what you might put into tht app itself, and what someone malicious can do if they ever get your private key
<dlitz>
and Android certificates are *forever*
<dlitz>
so if that private key leaks, the whole ecosystem is permanently screwed
<kentonv>
Android has no strategy for key rotation?
<dlitz>
None whatsoever.
<dlitz>
From what I can tell, having third-party apps embed some Sandstorm public key is a non-starter
<kentonv>
that's surprising. Sandstorm itself has a mechanism for app key revocation and replacement.
<dlitz>
Android's package manager is essentially self-signed certs and TOFU, and they punted on key management.
<dlitz>
it has some advantages, but basically if you want to change keys, you have to get every user to change to a different app name
<dlitz>
I mean, they have to install a different app
<dlitz>
I wasted a weekend just trying to get my app-signing key onto a smartcard, to no avail.
<dlitz>
I haven't yet looked at how Facebook does it. Their security model is simpler (if their key leaks, it only gives you access to Facebook, in theory, and if their key leaks, I imagine they have the resources to manage some expensive workaround)
<dlitz>
I imagine I can figure out some good solution, but I'll have to spend some more time understanding how all the pieces work, first.