15:00 <Gan964> o/

15:01 <ocdtrekkie> Hello!

15:01 <Gan964> Hello!   Taking a look at sandstorm.   Have a few questions.

15:03 <Gan964> I am not seeing that sandstorm has an android app, but that the individual apps inside of sandstorm do,  how would I manage this?   Can I connect to sandstorm apps (like rocketchat) on my mobile devices with no problem?

15:04 <Gan964> Also, I want to learn a little bit more about the security.

15:04 <ocdtrekkie> So Rocket.Chat support is very very out of date, the app won't talk to it.

15:05 <Gan964> Is there more documentation on the security than what I see on the features page?

15:05 <ocdtrekkie> But generally, apps that support mobile clients will have a way to generate API keys to connect to them. TinyTinyRSS is a good example: In settings, it has a Mobile tab which will generate connection details for almost any TTRSS compatible app.

15:06 <ocdtrekkie> The https://docs.sandstorm.io site has some more details on the model, I believe.

15:07 <ocdtrekkie> Going to be driving for the next half hour and then I am happy to answer any additional questions about security or apps or whatever.

15:08 <Gan964> No problem!  Thank you!

15:32 <ocdtrekkie> And I'm back around

15:38 <Gan964> Security wise, How is the data stored on the server?   is that determined by the individual apps,  or is it encrypted by sandbox?

15:43 <Gan964> Reading about CrypTag

15:46 <ocdtrekkie> Currently Sandstorm does not do any storage encryption itself. Some apps choose to. (Sandpass is another one which has it's own encrypted storage, KeePass-based.) And obviously you could implement storage encryption in the host OS.

15:46 <ocdtrekkie> There's been ideas before about GPG-based login and encrypted storage that the server admin can't access, but that isn't something Sandstorm currently does anything like.

15:48 <Gan964> Ok.

15:57 <Gan964> If you don't mind, can you link a tutorial on best way to go about storage encryption on a lamp stack (ubuntu 20.04) ?

15:59 <ocdtrekkie> That would be the sort of thing I would definitely ask someone else. =) I am relatively good at working with Sandstorm itself and it's applications, but I'm not super well versed in Linux overall.

18:02 <isd> For the encryption thing, yeah, apps just get an unencrypted directory to themselves, and can do whatever they want with the filesystem. It's important to be explicit about the threat model with this stuff; what are you looking to achieve wrt. encryption?

18:34 <xet7> Gan964: You could start VM that has full disk encryption disk install: https://github.com/wekan/wekan-snap/wiki/Many-Snaps-on-LXC

18:35 <xet7> Gam964: But it depends is that useful

18:35 <xet7> Gam964: For lamp stack, you could look does MySQL or MariaDB has any database encryption options

18:37 <xet7> Gam946: If you would like to store encryption passwords in PHP file, you could use PHP Encoder to obfuscate PHP files https://www.ioncube.com/php_encoder.php

18:38 <xet7> Gam946: PHP has some functions for encrypt/decrypt

18:39 <isd> :/

18:41 <xet7> If in LAMP stack M can be MongoDB, then newest MongoDB 6 has database encryption options, searching encrypted database, and Enterprise unfriendly license

18:41 <xet7> And so nice Javascript query language

18:41 <xet7> ;)

18:42 <xet7> Not that old-fashioned SQL ;)

18:42 <isd> I mean it's really important to step back and work out what you're trying to achieve here. I think a lot of folks are implicitly coming to this with a thread model of "I don't want the server operator to see the data I store in grains" which is actually really hard to achieve: You can maybe do it if the grain is only accessed via a mobile app, but if you're using a browser then in order to actually use anything it needs to be decrypted... by

18:42 <isd> software that the server controls. So to an extent you're screwed :/

18:43 <isd> There are some things you can do for other threat models, but it's important to pin down what threat model you're actually using.

18:44 <xet7> And mobile browsers and operating systems (iOS/Android) have all kinds of telemetry etc

18:52 <ocdtrekkie> I mean particularly for Sandstorm, encrypted at rest would be relatively useful, if your server operator isn't explicitly evil and trying to retain the ability to break into your grains.

18:54 <ocdtrekkie> I imagine a scenarios that if I have to present a key to my server to start the grain, but they don't normally store it, and then the FBI compels my server operator to try to capture data, there's a LOT they would not be able to dig through, and have to hope I decided to open.

19:08 <blowfist> has there also been talks about using TLS certificates as an authentication medium for sandstorm too? Something similar as what we can use on libera to login.

19:13 <blowfist> also, I was under the impression that sandstorm used websockets. That kind of technology should at least help towards the goal of having data decrypted by the client.

19:14 <xet7> blowfist: Sandstorm and Wekan are made with Meteor, that uses websockets, but I would think it is not related to encryption.

19:14 <xet7> also RocketChat is made with Meteor

19:15 <xet7> TLS is what encrypts between webbrowser and server

19:16 <xet7> at serverside files are not encrypted

19:17 <xet7> it depends on each app what is visible when not logged in, and when logged in

19:27 <blowfist> in theory, TLS could be used for encryption and also authentication, I can't find precise pages explaining it but I remember reading that it is possible. At the bare minimum, we can use self signed TLS certificates for this too, like what we can use with libera to eliminate passwords

19:28 <blowfist> xet7: for libera, you have to generate your own TLS certificate and then copy past the fingerprint to libera's nickserv. That's grossly what is required to activate this feature

19:28 <blowfist> copy paste*

19:30 <xet7> I do use SSL and SASL at libera IRC

19:30 <Ryuno-KiAndrJaen> There's something like client certificates, but from what I've heard its UX is bad

19:33 <blowfist> Ryuno-KiAndrJaen: I'm trying to find articles on this but can't find any that explains it simply yet

19:34 <blowfist> the ideal way would be for browsers to support an authentication method similar to openssh's use of asymmetric keys

19:37 <blowfist> and even more, the public key is used to encrypt data that only the specific private key can decode, so the client's data could be made to be decrypted only by the client (of course a mix of symmetric keys would need to be used with the asymmetric ones because you can't encrypt much bytes with a public asymmetric key alone)

20:03 <ill_logic> zenhack: will you be making a showing at LibrePlanet?

20:06 <isd> ill_logic: wasn't planning on it.

21:28 <Gan964> xet7,  awesome,  thank you!

21:29 <Gan964> So funny story,  I am running a cheap hosted VM, was trying to use LUKS to encrypt a disk,   but the VM did not have enough memory.    Took me a good chunk of the day to figure that out

21:31 <Gan964> I could get more ram,  but it gets expensive

21:32 <Gan964> encrypted at rest would be the goal

23:28 <TimMc> Gan964: On my home server, I have a LUKS partition, and then LVM on top of that in order to have snapshotted backups.