00:01 <ocdtrekkie> It seems to work, even though you would assume it shouldn't. Can I assume Sandstorm doesn't care about an app's own CSP or Frame Options requests?

08:52 <ccx^xmpp> kentonv: It's not the webserver that is "delivering" certificates. It's completely separate tool. And now that that tool doesn't need to serve HTTP for validation it can run without needing any special integration layer, just input path to the periodically refreshed cert and you're done.

16:58 <kentonv> ocdtrekkie, Sandstorm doesn't pass through those headers from the app. Instead, it sets its own values for the headers. I don't foresee any need for it to pay attention to what the app sets, so I think it's unlikely that it ever will.

17:00 <kentonv> ccx^xmpp, in order for Let's Encrypt to give you a wildcard cert, you have to prove that you control DNS by setting a DNS entry. All I'm saying is that Sandstorm can't automate this, but you can of course perform the process manually and then use those certs with Sandstorm.

17:04 <ccx^xmpp> kentonv:

17:04 <ccx^xmpp> sorry; misclick

17:06 <ccx^xmpp> But yeah. My point was that there's no point in making that as there are tools already that do just that.

18:25 <TimMc> Major security update for Etherpad, but might not be critical for Sandstorm package: http://blog.etherpad.org/2018/04/07/important-release-1-6-4/

18:26 <TimMc> First vuln is in newer version; second I think is irrelevant (uses sqlite?); third pre-empted by existing access control. Does that seem right?

18:40 <ocdtrekkie> kentonv: Fun fact: Previous functionality of Sandstorm, the last activity date didn't update when the API was accessed, now it does.

18:40 <ocdtrekkie> I actually think this is an improvement, but I figured I'd point it out.

18:42 <ocdtrekkie> TimMc: Sounds about right. And of course, the extent of damage one can do in an Etherpad grain is... that grain, so only really public Etherpad grains might have to be worried.

18:44 <TimMc> There aren't enough details there to evalute the risk from a public-read etherpad grain assuming the first two vulns *were* in play, though.

18:45 <ocdtrekkie> Hmm, yeah, it's possible you'd need edit access to exploit it, in which it wouldn't matter at all.

18:48 <ocdtrekkie> Wekan 0.80 is approved on Sandstorm. (I approved Firefly III 4.7.2.2 yesterday.)

18:48 <ocdtrekkie> WordPress is updated on the experimental market, but I haven't gotten the go-ahead yet to approve it.

19:09 <TimMc> RCE in Sandstorm grains is still an issue, despite the containerization.

19:10 <ocdtrekkie> Sure, if it is exploitable, it could serve malware to other users it's shared with, presumably.

19:23 <TimMc> Or get out of the container.

19:23 <TimMc> Container breakouts aren't unheard of, and an attacker may have some in their private stash.

21:45 <kentonv> TimMc, based on the announcement it seems like Sandstorm is not affected by any of the three vulnerabilities, though I wish they'd give more detail on the bugs so that I could tell for sure

21:51 <ocdtrekkie> While a fresh Etherpad build would be nice, it is probably worth waiting. The new build has gotten a lot of bugs reported, including data loss.

21:51 <kentonv> good to know

22:20 <sandworm> hello. i try to install sandstorn on my container. is there a way to turn that off? "Press enter to accept defaults. Type 'no' to customize. [yes]"

22:22 <sandworm> this is what i got so far https://pastebin.ca/raw/4013002

22:22 <sandworm> i try to run an unattended installation

22:23 <sandworm> $HOSTNAME contains my FQDN

22:44 <sandworm> If you need support for non-sandcats full-server unattended installs,

22:44 <sandworm> please file a bug...

22:44 <sandworm> *sigh*

22:59 <ocdtrekkie> Well, he left and gave us no way to contact him.

23:00 <ocdtrekkie> But installing Sandstorm inside containers doesn't generally work.

23:00 <kentonv> I think he answered his question

23:00 <kentonv> by reading the script

23:00 <kentonv> comments in the script

23:01 <ocdtrekkie> I am just thinking that is not going to be his only problem.

23:41 <TimMc> kentonv: Yeah, it didn't seem too concerning to me either, and a quick search of the diff since the last etherpad release didn't turn up any clues.