raoulzecat has quit [Remote host closed the connection]
<maurer>
Out of curiosity, is there a reason people couldn't have 'account recovery tokens' or something like that? I'm hearing a number of stories these days about people getting locked out of their google accounts
<maurer>
whether it's the one I linked earlier due to a sketchy spreadsheet, or a friend of mine (who actually works at google) who got an account suspended by the magical learning anti-hax thing because they decided he didn't own his account
<maurer>
It seems like if you're going to self-host a service, it'd be nice to be sure that you are also not locked to an auth system that is the very one people might be trying not to depend so much on
<dwrensha>
maurer: that should be possible to implement by hooking into Meteor's "resume" login service
<dwrensha>
the server admin would generate a resume token and give it to the user, who would then call `Meteor.loginWithToken()`
<kentonv>
maurer: You can add a second login identity to your account for redundancy.
wolcen_ has quit [Ping timeout: 260 seconds]
<zarvox>
So, I seem to have a thing which will run builds, but it reports build status to the merge commit ID rather than to the commit that is the head of the pull request's branch. Despite the source at https://github.com/jenkinsci/ghprb-plugin appearing to do the correct thing.
NwS has quit [Ping timeout: 250 seconds]
neynah has joined #sandstorm
frewsxcv has joined #sandstorm
<zarvox>
Progress. Now Jenkins sets the status on the wrong commit for anything I specifically say "set build status" on, but does it for the correct commit at the end of the build.
<zarvox>
This is annoying because it fails to show that the build is in progress, but will at least eventually show the build result on the PR in question.
funwhilelost has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kecors has quit [Quit: Leaving]
jadewang has quit [Remote host closed the connection]
<axx_>
that gets reasonable, still annoying to pay for certs in 2016, but a lot cheaper
M-eternaleye has quit [Remote host closed the connection]
<phildini>
I have a strange feature request, feel free to tell me to file it somewhere else: Right now my app has a button to make a trello card from the contact you're looking at. It would be nice if, for the sandstorm version, I could have that button launch something that would a) check if you have wekan installed b) if not, ask if you want to install it and c) add
<phildini>
a card to wekan the same way the trello integration works.
M-eternaleye has joined #sandstorm
<phildini>
Ideally, this would all happen in client-side JS-land, as well.
<phildini>
I realize this is a potentially massive request, but I could enumerate more uses for this type of flow. Feel free to ask me to file this somewhere else, happy to do so.
jon1012 has quit [Ping timeout: 265 seconds]
<asheesh>
phildini: That is totally what we want the Powerbox interaction to work like, so we're working on it.
<maurer>
phildini: I'm not one of the core devs, and I don't think sandstorm has this yet, but I think this is in the list of things a powerbo e;f:b
<asheesh>
what maurer said
<asheesh>
I should say, this is *a* valid powerbox interaction.
<phildini>
coool. put this on the list of features (as well with the ability to get paid) that will make me even more of a sandstorm-vangelist.
<maurer>
phildini: I will say you can evidently embed a button to install wekan right now
<maurer>
phildini: but communicating to it isn't supported yet aiui
|jemc| has joined #sandstorm
<phildini>
yeah... I kind of want Sandstorm to just "take care of this". Like, my ideal interaction is more my app saying "hello sandstorm! please let the user choose a todo app for me to create a task in". I think wekan is _awesome_, but it seems more standstorm-ethos to just have the app say "I want this type of thing" and then let the user choose, and sandstorm
<phildini>
takes care of the middeware.
<asheesh>
Yup.
<asheesh>
++
<maurer>
Yeah, that sounds like what powerbox is supposed to do in the medium term
<asheesh>
a dark and sandstormy todo list
<maurer>
I don't think it's there yet
<phildini>
I await it's existence with excitement!
asmyers has joined #sandstorm
tobald has quit [Quit: Ex-Chat]
<asheesh>
phildini: FWIW if you want to enumerate some of these flows in bug reports, that would be useful, to keep our eyes on the prize, and so that we can close those bugs when not only does it exist, but it's documented.
<asheesh>
I'm eating leftovers from a 4x recipe I made.
<asheesh>
Caramelizing onions is slow work, and I should see if it can really be done in a slow cooker.
<asheesh>
I am pretty happy with how reasonably inexpensive it is, too.
M-eternaleye has quit [Remote host closed the connection]
Salt has quit [Read error: Connection reset by peer]
NwS has joined #sandstorm
jadewang has joined #sandstorm
maurer has quit [Quit: WeeChat 1.3]
jadewang has quit [Ping timeout: 260 seconds]
maurer has joined #sandstorm
axx_ has quit [Ping timeout: 240 seconds]
synchrone has quit [Ping timeout: 240 seconds]
funwhilelost has joined #sandstorm
wolcen_ has joined #sandstorm
jacksingleton has joined #sandstorm
<jacksingleton>
does sandstorm do anything that would limit exploitability of the glibc getaddrinfo vuln?
<jacksingleton>
also, good morning :)
jadewang has joined #sandstorm
<asheesh>
jacksingleton: Yes!
<asheesh>
I could write a blog post about it.
<asheesh>
(1) Apps can't get an IP route to a DNS server, so they can't be exploited this way.
<asheesh>
(2) The shell can be *possibly*, I need to check, but we'll presumably ship an update that will get to everyone within 48h and then the bug will go away.
<asheesh>
(3) Apps can maybe abuse the shell via the vulnerability, though; not totally sure.
<asheesh>
(since they can call httpGet() on something malicious; I haven't verified that codepath)
<maurer>
asheesh: Wait, do you not use system glibc?
paroneayea has quit [Ping timeout: 250 seconds]
<asheesh>
(if you feel fancy, you could write a blog post about your analysis) : P
<asheesh>
maurer: I believe there'se a glibc in the "Sandstorm bundle" and we don't use system glibc.
<maurer>
T_T
<asheesh>
I also believe this breaks the sysadmin's nss customizations.
<maurer>
Yes, yes it does
<asheesh>
I need to double-check a few of the above claims, but that's off the top of my head.
<maurer>
The other problem with it is that it means that sysadmins can do the things that normally protect them against this
<maurer>
(e.g. the song and dance I'm doing right now where I bump all my glibcs to patched)
<asheesh>
Right, yeah.
<maurer>
and sandstorm won't be protected, because it shipped its own
<asheesh>
I was thinking about that this morning.
<asheesh>
OTOH we're ahead of *most* people's patching schedules.
<asheesh>
Just not yours. : P
<maurer>
Really? You expect that most people will wait 48 hours on a getaddrinfo codexec vuln?
jadewang has quit [Ping timeout: 264 seconds]
<asheesh>
Maybe we should auto-build updates based on Debian stable security updates... or something like that.
* maurer
grumbles about this being why you aren't supposed to ship your own deps
<asheesh>
Well I think most people won't update for a year or so. But it depends on the context. Docker-type situations, I expect it to take people a week or so, since they have to bump every container.
<asheesh>
My personal Debian server... honestly I hadn't really thought about it much, and so I was probably going to update it by accident in about a month when I run 'apt-get install' to get something else and see an update notification.
Tasqa has quit [Quit: WeeChat 1.0.1]
<asheesh>
Meanwhile I'm all jumping at Kenton to ship a new Sandstorm build.
<sknebel>
Is there an app wishlist somewhere? Both to maybe add stuff and to find things that might be interesting to learn packaging ;)
<maurer>
asheesh: My understanding of this bug is that if you control any canonical dns server, and you can get someone to make a dns request via getaddrinfo, you can escalate
<maurer>
First bit is not a huge hurdle
<maurer>
Second bit can be done via convincing someone to click a link
<maurer>
a year seems like a long time to wait on that kind of thing
<asheesh>
Or sending them an email and getting clamav to scan it, or something.
<maurer>
Sure
<maurer>
Or in some cases, trying to ssh to them and convincing ssh it needs to look you up to check rdns = forward dns
<maurer>
Iono, it seems so exploitable that the notion of people not upgrading for a year seems weird
<asheesh>
maurer: I agree, for people who are actually fully-awake sysadmins. But I am honestly pretty half-awake as a rose.makesad.us (personal server) maintainer.
<kentonv>
do you know how I can jump the line and get this package?
<asheesh>
kentonv: Also "obviously" we should do pristine Sandstorm builds from debian stable not unstable. I can write some scripts for that if you want.
<kentonv>
asheesh: Your "Also" implies there was a previous message but I didn't receive it
<maurer>
(this is why people are suposed to use jessie)
<maurer>
(so that there is a security archive available to them)
jacksingleton has quit [Ping timeout: 250 seconds]
<dwrensha>
what? it takes longer to update unstable than stable?
<kentonv>
yeah so at the time we designed our build process, "stable" was wheezy which was impossibly old
<asheesh>
Ya
<maurer>
dwrensha: Yes
<maurer>
dwrensha: Debian has their main repos
<maurer>
dwrensha: then a special set of "security" repos
<maurer>
security repos can have new packages on them in minutes, and are meant for emergency things like htis
<maurer>
the main repos may take hours to sync, but are better suited to mass package serving
<maurer>
stable has a specific team making sure packages for this kind of thing push quickly
<kentonv>
this seems to make Debian a poor choice for anyone who wants security and also reasonably-current software
jacksingleton has joined #sandstorm
<asheesh>
Yes, agreed, kentonv. (still waiting for my apt-get update from ftp.us.debian.org to double-check unstable; I ran out of disk space on my last check.)
<maurer>
kentonv: I think debian's argument here is basically "You can't have security with unstable"
<asheesh>
And yeah, I think Debian stable is often new enough to work well enough.
<asheesh>
Not if you're a project doing cutting edge kernel things, but otherwise.
edunham has left #sandstorm [#sandstorm]
<jacksingleton>
fwiw when I got up early to patch my Debian box I didn't think about sandstorm packaging it's own libc even though I do now remember learning that in the past
<kentonv>
jacksingleton: on the other hand, if Sandstorm is the only thing running on the box, then you wouldn't have to worry about patching at all, since we take care of it.
<maurer>
kentonv: One answer, which I used to do, is to run stable by using apt-pinning to prefer stable, but also have the other repos available for special cases
<maurer>
kentonv: Also, as far as sandstomr autopatching, no offense, but I trust debian to find out about and respond quickly to security problems far more than I'd trust the sanstorm developers
<maurer>
kentonv: if only because they have a team dedicated to doing it and a historical track record
<asheesh>
Which is why I think it's smart to automatically notify kentonv that our release bot has auto-built a new Sandstorm package from Debian stable security updates, when a Debian stable security update happens, and then let Kenton thumbs up/thumbs down it, then release it.
<asheesh>
Which requires someone writing a bot that watches debian security updates and doing builds, but yeah.
<kentonv>
maurer: Problem is that not only does Debian have to notice, but you personally have to notice and go apt-get upgrade. With Sandstorm we don't want server owners to have to take any action.
<asheesh>
Another difficulty with my proposal is that there's still a ~24h delay for Sandstorm, since update pings are daily.
<maurer>
kentonv: You can install the unattended-upgrades package for debian
<asheesh>
You could imagine an optional pingback mechanism where we can tell all the Sandstorm servers, "hey, go check yourself in the next 30 minutes, randomly distributed."
<jacksingleton>
kentonv: understood. in my case nginx needed to be patched anyway but I do understand
<maurer>
kentonv: I dunno, I'm not against there being a "standalone" mode for sandstorm, I'm just increasingly troubled by the lack of a non-standalone mode
<jacksingleton>
asheesh: to be clear, apps cannot resolve domain names even going through sandstorm?
<asheesh>
An app like Tiny Tiny RSS can ask Sandstorm to do an httpGet. Let me go read that code to see if it uses glibc gethostbyname.
<asheesh>
"obviously" we need "seccomp filtering, but for libc"
<kentonv>
the lookup will happen in node which does use glibc, yes
<asheesh>
Yeah, it gets delegated to Meteor Http.request or Https.request, which uses glibc.
<kentonv>
DNS TXT lookups don't use glibc, though (for web publishing)
<asheesh>
per shell/server/hack-session.js jacksingleton if you want to read, too
<kentonv>
I wonder if I can set up a debian-jessie vagrant box and do a release before Debian Unstable updates
<asheesh>
: D
<asheesh>
Seems likely, honestly.
<jacksingleton>
asheesh: got it, thanks
<asheesh>
kentonv: Hm, I think I have 2.21-8 available now in ftp.us.debian.org
<asheesh>
maurer: Yeah, I agree that building the result would work OK, but if kentonv is going to create a Debian stable-based release process now, motivated by this issue, then I do think that's strictly better.
<maurer>
(yeah, I'm just trying to list the available options)
<asheesh>
bd
<kentonv>
well, I do have concerns that changing the base OS of the release on a short schedule is risky
<asheesh>
That is a reasonable thing to be concerned about!
<asheesh>
You could "just" do that build as maurer said: 'apt-get source -b glibc' and then install the resulting packages.
<asheesh>
And then we can migrate to something based on stable at our earliest convenience, or not, if we decide not to.
<kentonv>
can you walk me through that step-by-step?
<asheesh>
Absolutely.
<asheesh>
sudo apt-get -b source glibc/unstable
<asheesh>
Make sure this gives you version 2.21-8 ; it does give me that.
<asheesh>
(I can do that walkthrough here or elsewhere, fwiw.)
<kentonv>
here seems fine
<asheesh>
This will download the "source packages" ("apt-get source") and do a "build" ("-b").
<kentonv>
I have 19 minutes before zurich meetup Q&A, btw
<asheesh>
After like 10 minutes, you will have *.deb files that you can use to upgrade your own system.
<kentonv>
um error
<kentonv>
W: Can't drop privileges for downloading as file 'glibc_2.21-8.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
<kentonv>
E: Sub-process dpkg-source returned an error code (1)
<asheesh>
OK, so do instead:
<asheesh>
cd /tmp
<asheesh>
cd $(mktemp -d build.XXXXXXX)
<asheesh>
apt-get source glibc/unstable
<asheesh>
(this will do the download as non-root, which hopefully *will* succeed) (also I've never seen that error)
<kentonv>
ok I have a source directory
<maurer>
asheesh: It sounds like he was doing this in a directory inaccessible by the apt user
<asheesh>
sudo apt-get build-dep/unstable # this downloads all build-time dependencies of the glibc source package, does need sudo
<asheesh>
cd glibc-*
<asheesh>
dpkg-buildpackage
<maurer>
asheesh: Do you not mean sudo apt-get build-dep glibc/unstable?
<asheesh>
sudo apt-get build-dep glibc/unstable # typo fix by maurer!
<kentonv>
ok I am building a package
<asheesh>
Great. To actually do an upgrade, you can turn that directory into an apt source, or you can eyeball things.
<kentonv>
can't I dpkg -i ?
<asheesh>
Eyeballing things is pretty OK in this case. Start by doing: 'sudo dpkg -i libc6_*.deb' and then it'll tell you if it needs other dependent packages.
<asheesh>
Yeah, that's what I mean by eyeballing things. You may wish not to install every one of the binary packages that get built by this process.
<asheesh>
In which case, you'd use your own eye to figure out which packages you want to choose to install.
<asheesh>
"dpkg -l" can be handy for this, too.
<kentonv>
ugh so many files to compile (even at -j16)
<maurer>
Yeah, I know, I had to do that for my nixops machine this morning while I waited for the cache to update
<maurer>
took a bit of time, but that was also on my laptop
<asheesh>
(a) I just realized I can try ftp.debian.org, not ftp.us.debian.org. Testing that, not that it matters anymore, but might be useful for the future.
<asheesh>
(b) I... maybe can SSH into the machine with the data and copy it off, since I'm a DD...
<kentonv>
if I can get an official package to use I'd much prefer that
<kentonv>
ftp.debian.org seems to have the same set of packages
<asheesh>
One thing that's clear to me is that I should enhance that page with tips on how to protect yourself if you're running sid/testing.
<zarvox>
two other notes: security.debian.org might have different rules than ftp-master, and the update package is definitely available for jessie, since I just patched my server
<zarvox>
or is the installability thing just an issue because people are running testing or sid?
<asheesh>
Crucially the "Sandstorm build machine" is running testing/sid.
<maurer>
zarvox: Yeah, we went over this a bit ago :). Debian stable receives very timely updates, unstable (which is where bundles come from) get ~1day updates
<zarvox>
ahhh, right
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
xet7 has joined #sandstorm
<zarvox>
I kinda wish we had a hermetic, reproducible build environment for our official packages
notevil has quit [Quit: Leaving]
<asheesh>
zarvox++
<maurer>
zarvox: *muttering about nix ensues*
<kentonv>
my build failed so hopefully the official packages show up any moment...?
jacksingleton has quit [Ping timeout: 240 seconds]
<kentonv>
asheesh: my build failed with "dpkg-buildpackage: error: failed to sign .dsc and .changes file". Do I need to specify a PGP key somewhere?
<asheesh>
That's not an important failure.
<asheesh>
Your build succeeded, but it can't sign the build with the author's key, but you typically still have *.deb files.
<asheesh>
s/author's key/packager's key/
<kentonv>
I don't see any .deb files
<asheesh>
Hmm.
<asheesh>
Are they in ../ ?
<kentonv>
indeed
<asheesh>
Great.
<asheesh>
Dinstall start: Tue Feb 16 19:52:05 UTC 2016 (1455652325)
<kentonv>
asheesh: gpg --verify Release.gpg Release doesn't work: "gpg: Can't check signature: public key not found"
<synchrone>
kentonv: I just have a banking sysadmin friend asking what's sandstorm performance, and I figure the best way to answer his question is to give Oasis statistics
<synchrone>
like, it can host such and such grains requiring that and that resources
<asheesh>
kentonv: add that to sources.list and you can jump the line, and it's already signed by the main Debian archive.
joshbuddy has joined #sandstorm
<asheesh>
I can't think of a particular reason for you to remove this from your sources.list, fwiw, in the future.
<asheesh>
Also hi synchrone , nice to see you here again.
neynah has quit [Client Quit]
<synchrone>
hi there :)
neynah has joined #sandstorm
<kentonv>
synchrone: Well, Oasis uses extra code to distribute load across a cluster of machines, which means it can handle a lot more load than the self-install version can.
<kentonv>
synchrone: Eventually we plan to release that as a product called "Sandstorm Enterprise"
rustyrazorblade has joined #sandstorm
<kentonv>
synchrone: for single-machine Sandstorm, the number of users it can handle is mainly limited by RAM. Each concurrent user will use a few hundred megs, probably (depends on what apps they run).
<kentonv>
I guess it's more accurate to say that each running grain will use RAM. The amount varies widely depending on the app, but 100MB is a good rule of thumb.
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kentonv>
so with, say, 32GB RAM, you should be able to run 320 grains simultaneously, minus a few due to overhead of Sandstorm itself
mnutt has joined #sandstorm
<kentonv>
so you can scale up to hundreds of users with enough hardware, but if you need to support thousands of users then you'll probably want Sandstorm Enterprise (which powers Oasis).
<synchrone>
yeah, i see with my one grain node process takes like 128MB of ram plus 55MB for mongo
<kentonv>
* hundreds of *simultaneous* users
<asheesh>
kentonv: ^ did you see my sources.list note?
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
synchrone has quit [Ping timeout: 240 seconds]
greg-g has joined #sandstorm
<greg-g>
hola!
<kentonv>
hi
<greg-g>
I am using a sandstorm install on my good buddy asheesh's server ;), and when I try to send an invitation from etherpad to add collaborators, I get a "failed to send to <email addresses>" message
<greg-g>
then I go to the view of who has access and they show up there
<greg-g>
either A) it did send and the error message is wrong, or B) it didn't and those emails shouldn't be listed on the who has access list
<kentonv>
asheesh probably doesn't have SMTP configured.
<greg-g>
yeah, that was my assumption
<greg-g>
so then B :)
<kentonv>
if the sharing was by-identity (the names auto-completed to people already on the server), then those people do now have access (it'll show up in their grain list)
<kentonv>
if it was by-link, though, then they won't have received the link
<greg-g>
new people
* greg-g
nods
<greg-g>
I can create a link per person, just more clicking
<kentonv>
you can delete those links, and then create a new link using the "get sharable link" tab, which will work without SMTP
* greg-g
nods
<greg-g>
yep
<greg-g>
is the issue of them showing up on the who has access list even though the email didn't send worth while to address/report officially?
<kentonv>
I would argue that we shouldn't offer the "send an invite" dialog if SMTP isn't gconfigured
<kentonv>
so then it wouldn't come up
<greg-g>
even better
<greg-g>
I like the way you think :)
<greg-g>
alright, I'm passed my moment of impasse, toodaloo
mnutt has joined #sandstorm
mnutt has quit [Read error: Connection reset by peer]
mnutt_ has joined #sandstorm
xet7 has joined #sandstorm
rustyrazorblade has joined #sandstorm
funwhile_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tdfischer has quit [Ping timeout: 256 seconds]
<asheesh>
Heh. Yes. My server in fact does not have SMTP configured. Hi greg-g (-:
<greg-g>
:)
kpettit has joined #sandstorm
tdfischer has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
<kpettit>
I'm doing a initial sandstorm setup on my own server. Root domain and wildcard point to my server. But after I change sandstorm.conf to my new subdomain the web won't respond.
rustyrazorblade has quit [Quit: rustyrazorblade]
<kentonv>
kpettit: you mean, it responds correctly under one domain but not the new one?
<kpettit>
This is my current config. http://pastebin.com/yjcyNbpJ I've never set one of these up before so I'm not sure what i'm doing wrong
<kpettit>
during the setup it gave it the myname.sandcasts.io which worked. I wanted to setup google and github logins but those were going to bind to that URL, so I wanted to get my own domain before that.
<kentonv>
It looks like you still have it configured for HTTPS. You'll need to set up a reverse proxy like nginx, since Sandstorm doesn't have certificates for your domain
<kentonv>
that said I'm not sure why it fails to respond entirely. I'd expect a certificate error.
<kentonv>
oh
<kpettit>
This is out of the box. Haven't done more than run bash install script and go to the URL. Then I changed it to my domain
<kentonv>
you need to remove SANDCATS_BASE_DOMAIN if you aren't using sandcats
<kpettit>
ohh so you have to setup SSL
<kpettit>
ok.
<kentonv>
right, Sandstorm only has built-in support for SSL on Sandcats. For anything else, you'll need to make your own arrangements.
funwhile_ has joined #sandstorm
<kpettit>
ouch ok.
<zarvox>
We should still show that the feature exists for discoverability, but I agree that the tab should perhaps be disabled by default if no SMTP server is configured.
<zarvox>
(re: send an invite dialog)
<kentonv>
kpettit: yeah sorry, there's no such thing as free wildcard SSL for arbitrary hosts. We can only provide it under sandcats.
<kentonv>
:/
<zarvox>
I feel pretty strongly that you should have SMTP configured though. Email is basically required to have a good experience overall.
<kpettit>
can you create self generated SSL certs?
<kpettit>
ok. well guess i'll skip that part for now. thanks for the help.
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kentonv>
kpettit: FWIW, setting up Google and Github login with your domain won't prevent you from changing domains later. You'll need to reconfigure them, but the existing users will remain valid.
mnutt has joined #sandstorm
funwhile_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
funwhile_ has joined #sandstorm
rustyrazorblade has joined #sandstorm
isd has quit [Read error: Connection reset by peer]
isd has joined #sandstorm
<mrdomino>
dwrensha: it seems as though people in the contributor role can't chat in groovebasin. is that an accident or is chatting == controlling the stream in groove basin's permissions?
<dwrensha>
hm. that sounds wrong
<dwrensha>
oh, you mean the new "contributor" role, of course
<mrdomino>
yes
<dwrensha>
which cannot control the currently playing stream
<mrdomino>
yeah
<mrdomino>
just bumped most of my mrdomino radio links to it since i finally got sick of people getting on and making the "i'm the only one listening" assumption
<zarvox>
FYI, I'm going to go break Jenkins again for a bit
<mrdomino>
d'oh, ok
<mrdomino>
i sorta want to go through there and mess with some stuff. sweet that it's all in one place like that.
<dwrensha>
Perhaps it would make sense to add a 'chat' permission. If that happens upstream I would happily update the Sandstorm manifest to account for it.
rustyrazorblade has joined #sandstorm
nwf has quit [Quit: WeeChat 1.3]
isd has quit [Ping timeout: 256 seconds]
frigginglorious has joined #sandstorm
nwf has joined #sandstorm
<dwrensha>
oh hey I got a new libc on Ubuntu 15.10