Monday, March 27, 2023
dev@conference.yunohost.org
March
Mon Tue Wed Thu Fri Sat Sun
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 19
20
21
22
23
24
25
26
27
28
29
30
31
   
             

[07:12:43] <autra> > <@Alekswag:matrix.org> Docker is basically the same thing except it runs only a single process

To be more precise, it *can* run several processes, and a lot do, but the focus is on single "service", whatever you put behind this :-)
[07:13:10] <autra> > <@ericg:matrix.org> are users being hacked everyday?

well, I had customers who got hacked, but it wasn't related to docker ;-)
[07:13:46] <autra> if you are low profile (not much of an interest), your threat model is more or less bots
[07:14:19] <autra> and the way you protect against it: good passwords, firewalls, not doing stupid stuff (which can be easy to do, no judgement here)
[07:16:11] <autra> one customer got hacked because they use to put lines with "trust in their postgresql pg_hba.conf for the postgres user (basically allowing login without password). They did put an ip filter, but they made a mistake with the mask: instead of <ip>/32 (a sigle ip), they put <ip>/0 (the whole internet). So you could login as superuser without password from the whole internet 😆
[07:16:18] <autra> not docker related!
[07:19:24] <autra> that being said, docker does give you a layer of protection sometimes. For instance, some months/years ago, one version of gitlab was vulnerable to bitcoin miners. Some instances were compromised, and people were pretty happy when the code only executed in the docker context (who knows what it could do beside mining?). It saves them a lot of trouble...
[11:43:44] <Yunohost Git/Infra notifications> [tartiflette] @kay0u pushed 1 commit to master: Update appcatalog.py Use the catalog v3 ([f718e5be](https://github.com/YunoHost/tartiflette/commit/f718e5be53ac40bab1dff2d7fe20196e290baa89))
[11:46:10] <tituspijean[m]> Both an advantage/drawback of the forge decentralization: https://forum.yunohost.org/t/cannot-install-app-libreqr/24228
(we are less susceptible to large forges downtimes, but more susceptible to smaller player downtimes here and there)
[13:02:13] <Aleks (he/him/il/lui)> > <@autra:trancart.eu> one customer got hacked because they use to put lines with "trust in their postgresql pg_hba.conf for the postgres user (basically allowing login without password). They did put an ip filter, but they made a mistake with the mask: instead of <ip>/32 (a sigle ip), they put <ip>/0 (the whole internet). So you could login as superuser without password from the whole internet 😆

that kind of stuff sounds exactly like the reason people should stop it with the old adminsys paradigm of "tweak all the config files by hand" ... there's simply too many things that can go wrong, this not a job for humans, this is a job for machines
[13:06:07] <autra> > <@Alekswag:matrix.org> that kind of stuff sounds exactly like the reason people should stop it with the old adminsys paradigm of "tweak all the config files by hand" ... there's simply too many things that can go wrong, this not a job for humans, this is a job for machines

In my opinion the answer is merge requests and peer reviews (for the config file itself), then automated development tools, but that might be what you mean?
[13:08:26] <Aleks (he/him/il/lui)> i mean using "standardized stacks" like YunoHost, Kubernetes, Ansible playbooks, whatever, or yes, "git-ops" workflow, but modifying stuff manually in production usually means it's not versionized or anything, and therefore you are the only one being aware of what was tweaked and why
[13:10:19] <Aleks (he/him/il/lui)> and I also mean "reinventing the wheel" such as nginx ciphers etc, it's just absolutely wtf that so many people cook their own thing instead of having a standard ... In programming, it's just unacceptable to be like "oh yeah I'm gonna reimplement my own security lib", yet in system administration it's perfectly fine and almost recommended to do all this "by hand"
[13:10:25] <Aleks (he/him/il/lui)> with the stupid argument of "if it breaks, you'll know how to fix it" ... like, yeah, why don't you code your own kernel then ...
[13:11:50] <Aleks (he/him/il/lui)> and even writing nginx config snippets ... once you know about the damn path-traversal issue, it's just plain spook
[14:02:38] <Yunohost Git/Infra notifications> [install_script] @alexAubin pushed 1 commit to main: Boring hack because sometimes dbus is not started/enabled ... ([66153444](https://github.com/YunoHost/install_script/commit/66153444b2ff596f1788f65bd55b9e84d3d451b3))
[17:58:46] <Yunohost Git/Infra notifications> [yunohost] @alexAubin merged [pull request #1630](https://github.com/YunoHost/yunohost/pull/1630): fix i18n panel+section names
[17:58:47] <Yunohost Git/Infra notifications> [issues] @alexAubin closed [issue #2165](https://github.com/YunoHost/issues/issues/2165): Config_panel not able to display Internationalization properly
[17:58:47] <Yunohost Git/Infra notifications> [yunohost] @alexAubin pushed 2 commits to dev ([1b2fa91ff02d...8b1184f11b28](https://github.com/YunoHost/yunohost/compare/1b2fa91ff02d...8b1184f11b28))
[17:58:48] <Yunohost Git/Infra notifications> [yunohost] @alexAubin deleted branch fix-cp-titles
[17:58:48] <Yunohost Git/Infra notifications> [yunohost/dev] fix i18n panel+section names - axolotle
[17:58:52] <Yunohost Git/Infra notifications> [yunohost/dev] Merge pull request #1630 from YunoHost/fix-cp-titles fix i18n panel+section names - Alexandre Aubin
[18:00:39] <Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.1.15+202303271800 for bullseye/unstable/all ...
[18:02:14] <Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.1.15+202303271800 for bullseye/unstable/all.
[18:35:30] <Yunohost Git/Infra notifications> [yunohost] @alexAubin pushed 1 commit to dev: appsv2: Add documentation about the new autoupdate mechanism for app sources ([63981aac](https://github.com/YunoHost/yunohost/commit/63981aacf9941ac779f437e57844d0bf8d1a0daf))
[18:38:33] <Yunohost Git/Infra notifications> [yunohost] ✖️ Pipeline [#819410397](https://gitlab.com/yunohost/yunohost/-/pipelines/819410397) canceled on branch dev
[18:45:46] <Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.1.15+202303271845 for bullseye/unstable/all ...
[18:46:12] <Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.1.15+202303271845 for bullseye/unstable/all.
[21:24:01] <Yunohost Git/Infra notifications> [issues] @Cuthbert1337 labeled :space_invader: bug on [issue #2179](https://github.com/YunoHost/issues/issues/2179): Uptime Kuma WebSocket Error
[21:24:01] <Yunohost Git/Infra notifications> [issues] @Cuthbert1337 opened [issue #2179](https://github.com/YunoHost/issues/issues/2179): Uptime Kuma WebSocket Error
[21:24:47] <Yunohost Git/Infra notifications> [issues] @ericgaspar edited [issue #2179](https://github.com/YunoHost/issues/issues/2179): Uptime Kuma WebSocket Error
[21:25:53] <Yunohost Git/Infra notifications> [issues] @Cuthbert1337 edited [issue #2179](https://github.com/YunoHost/issues/issues/2179): Uptime Kuma WebSocket Error
[21:35:28] <Yunohost Git/Infra notifications> [issues] @Cuthbert1337 edited [issue #2179](https://github.com/YunoHost/issues/issues/2179): Uptime Kuma WebSocket Error