kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 265 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
frigginglorious has quit [Client Quit]
<JacobWeisz[m]> I mean I kinda hope we can still upgrade the database, but Iunno how easy that update script is...
<isd> I haven't looked.
<isd> But it looks like Jason's fork was forked from some mirror on GitHub... the upstream project self-hosts their repo.
<isd> and said fork was last updated in 2010
<isd> whereas the app package was updated in 2016
<isd> So... has the sandstorm ttrss package ever done a database migration?
<isd> ...yeah, looking at the commit long I don't the actual TTRSS version has ever been updated.
<isd> All of the updates have just been packaging stuff.
<isd> commit log
<abliss> Any interest in using WebAuthn as a login mechanism to Sandstorm? I bought a shiny new yubikey5 to play with.
<JacobWeisz[m]> I imagine that'd be a good login method to add.
<JacobWeisz[m]> Question: Would multiple Sandstorm servers see any sort of common identifier for the same YubiKey?
<abliss> my understanding of webauthn is extremely thin, but my impression is no, they wouldn't, unless they coordinated with some backend relying party that would distribute a common identifier (like google login)
<abliss> I just tried the webauthn.io demo (https://github.com/duo-labs/webauthn.io) and it's a pretty smooth experience (android + chrome + usb yubikey5). i choose my own login handle, and register by touchig the key. later i can login by typing the same login handle and touching the key again.
<JacobWeisz[m]> Because of course, apart from internal org auth methods like LDAP and SAML, all Sandstorm login methods present Sandstorm a common identifier between servers, which presumably we may wish to use for federation.
<abliss> (i wonder if there's a way to skip the login handle. it doesn't seem like it should be necessary, and it's annoying to make the user invent one, make sure it's unique from all others, and then remember it)
<abliss> https://webauthn.bin.coffee/ seems to have a login flow that works with my key and doesn't require me to provide a userid (perhaps it's just choosing a random one for me). very smooth.
<abliss> dang, i take it back, resident keys seem to not work on my particular combination of device + OS + browser
<isd> Could we just use some function of the public key itself as the user ID?
<abliss> if you aren't using resident keys, the user still has to type some kind of identifier in order for the server to look up the record
<abliss> with resident keys, the server's URL gets passed to the token to discover the credential (i think)
<abliss> (if we assume the user has an email address that they want to tie to the account, that can be the username, which is probably fine for all practical purposes. but i like the idea of being able to login without ever typing anything.)
<isd> One thing that zarvox brought up in that issue is that right now all of the login options leave sandstorm with an email address it can use to send notifications. It would be a shame to lose that guarantee
<isd> Ok, maybe I was wrong about the ttrss updates; there's a good amount of stuff pulled in from upstream that's not there in the thing Jason's repo is forked from. That's good.
<isd> Builds, launches the UI, but network stuff doesn't work yet. Obviously that will require more hacking.
<isd> So TTRSS had two CVEs in 2017. Neither one affects Sandstorm.
<JacobWeisz[m]> Always fun to see
<JacobWeisz[m]> Especially since I'm using a package from 2016
<isd> I think I have a strategy for geting ttrss to use the powerbox that shouldn't be too bad.
<abliss> api sessions can't invoke powerbox right? i often subscribe to new feeds through the mobile client.
<isd> Right. Wouldn't really work without the sandstorm UI available
<isd> ...as sandstorm has no way of prompting you
<abliss> yeah. someday it would be cool to have a dedicate sansdtorm app that could receive a push notification and pop open a powerbox ui on my phone.
<isd> Neat idea.
<isd> Want to open an issue for it?
<isd> Also: rather than a dedicated mobile app, might make more sense to just use the pwa stuff mobile browsers support
<isd> We already do the bare minimum to get add to home screen working, but we could do further integration.
<JacobWeisz[m]> I would be loathe to waste our limited resources on native OS code.
<isd> ...though meteor has a cordova backend, so there's that I guess.
<isd> But I am still most keen doing pwa stuff. Sandstorm is already pretty good on mobile browsers.
kentonv has quit [Quit: Leaving]
kentonv has joined #sandstorm
<abliss> should those two ttrss CVEs go onto sandstorm's list of security nonincidents?
<isd> First someone should confirm more rigoriously than I did whether they're exploitable.
<isd> (Though I'm pretty sure they're not)
vertigo_38 has quit [Ping timeout: 256 seconds]
vertigo_38 has joined #sandstorm
<JacobWeisz[m]> How major were they? I have to imagine we have mitigated way more CVEs than we're bothering to monitor across all the apps.
<JacobWeisz[m]> I hesitate to over-list?
<isd> I don't think it's important to go crazy with that page either.
<isd> The sql injection doesn't work because we have ttrss configured in single-user mode, so the vulnerable page doesn't exist.
<isd> The xss doesn't seem to work either, though I'm a little fuzzier on exactly how we're blocking it, but it seems like some kind of common sense same-origin restriction. I'd want to stare at that and understand the exact mechanics though.