[08:34:55]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @Thatoo commented on issue #317 Keeweb doesnt work: issue persists after update to nextcloud 25 but the fix still works. https://github.com/YunoHost-Apps/nextcloud_ynh/issues/317#issuecomment-1375266462
[08:36:55]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @Thatoo commented on issue #451 cant scan files: @kay0u /home/administrateur/media/stockage Is my external hard drive where I store all Yunohost backup. Of course nextcl... https://github.com/YunoHost-Apps/nextcloud_ynh/issues/451#issuecomment-1375268154
[10:14:21]
<florent> The package linter says the license fields of the manifest should be the same as upstream.license. I thought this field was the licence of the package
[10:15:15]
<florent> Do you confirm that I can make write in the LICENCE file a different licence for the package than the upstream code?
[10:26:45]
<Aleks (he/him/il/lui)> the LICENSE file is the license of the package yes
[10:27:08]
<Aleks (he/him/il/lui)> but both entries in manifest are the upstream license
[10:27:44]
<Aleks (he/him/il/lui)> i dont remember the full story of why they are duplicated
[10:35:40]
<florent> The linter says it is transitional and the duplication should be removed in the v2 of the manifest
[10:35:46]
<florent> Thanks for your answer :)
[10:36:52]
<florent> BTW, if I am the maintainer of the package, may I just run the package_check locally and not rely on the CI?
[10:37:12]
<florent> I don't know if you request anything when before merging from testing to master
[10:38:03]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Add missing logos https://github.com/YunoHost/apps/commit/e54cc291af40e0fe74214fd782f484e239736e6d
[10:38:04]
<Yunohost Git/Infra notifications> [apps] @ericgaspar created new branch logos
[10:38:34]
<Yunohost Git/Infra notifications> [apps] @ericgaspar opened pull request #1586: Add missing logos https://github.com/YunoHost/apps/pull/1586
[10:42:54]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Create elasticsearch7.png https://github.com/YunoHost/apps/commit/385f4d8d9b4bf344ae3e72fe076931963f8d75e5
[10:51:28]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Create qr.png https://github.com/YunoHost/apps/commit/06aab20a912a9b75b02d52d86bc5fe541d2f2279
[10:55:00]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Create petrolette.png https://github.com/YunoHost/apps/commit/cb86d8c85d5c32bada08aa065fbe2d0be87c33b3
[11:10:17]
<Yunohost Git/Infra notifications> [apps] @fflorent opened pull request #1587: Add loki logo https://github.com/YunoHost/apps/pull/1587
[11:10:28]
<Aleks (he/him/il/lui)> > I don't know if you request anything when before merging from testing to master
usually people run the dev ci
[11:10:49]
<Aleks (he/him/il/lui)> but feel free to use your own package check instance, that saves CI time for others ;P
[11:27:27]
<Yunohost Git/Infra notifications> @selfhoster1312 forked apps to selfhoster1312/apps: https://github.com/selfhoster1312/apps
[11:28:14]
<Yunohost Git/Infra notifications> [apps] @selfhoster1312 opened pull request #1588: Add reverseproxy_ynh to catalog https://github.com/YunoHost/apps/pull/1588
[11:28:26]
<selfhoster1312> ^ submitted PR to add reverseproxy_ynh to apps catalog
[11:29:01]
<selfhoster1312> sorry to ask again: what's the recommended way to provide binaries for install in a package when upstream does not provide binary builds?
[11:29:08]
<selfhoster1312> is there a debian repo for yunohost i can submit packages to?
[11:29:11]
<selfhoster1312> (or nix/guix repo?)
[11:30:14]
<Yunohost Git/Infra notifications> [apps] @selfhoster1312 commented on issue #1588 Add reverseproxy_ynh to catalog: Unrelated, but why is redirect_ynh in publishing category? Should it not be in systems_tools/network too? https://github.com/YunoHost/apps/pull/1588#issuecomment-1375489971
[11:30:35]
<tituspijean> selfhoster1312 have you run the dev CI? It does not look like it. 😕 It would be nice to have an idea of the app level before saying it's `working`.
[11:31:05]
<selfhoster1312> i was afraid because i already have libvirt and LXC configured here and README says it might conflict :(
[11:31:15]
<selfhoster1312> i'll try on another machine, give me a few minutes :)
[11:32:00]
<tituspijean> IIRC I suggested you to create a PR and use the keywords ("!testme"), that's one of the perks of transferring the repo to our org 😉
[11:36:00]
<selfhoster1312> !testme in PR name? or in comment?
[11:36:21]
<Yunohost Git/Infra notifications> [apps] @selfhoster1312 edited pull request #1588: testme Add reverseproxy_ynh to catalog https://github.com/YunoHost/apps/pull/1588
[11:37:16]
<tituspijean> selfhoster1312 create a PR with some modifications, then add a comment to the PR with `!testme` as content
[11:37:48]
<selfhoster1312> sorry so you mean a PR on the package repo ?
[11:37:53]
<selfhoster1312> not on the apps PR?
[11:38:08]
<tituspijean> in the package yes. Example: https://github.com/YunoHost-Apps/flarum_ynh/pull/206
[11:38:33]
<selfhoster1312> thanks i'll do that
[11:43:40]
<tituspijean> > <selfhoster1312> sorry to ask again: what's the recommended way to provide binaries for install in a package when upstream does not provide binary builds?
Regarding this, we do have a repo for custom built packages, but it is not documented at all (and I would personally not be able to make it run right now)...
Alternative: eric_G used to use Github's releases to store compiled binaries for example: https://github.com/YunoHost-Apps/galene_ynh/releases/tag/v0.6.1 and https://github.com/YunoHost-Apps/galene_ynh/pull/95/files
[11:51:00]
<selfhoster1312> i do not feel very comfortable pulling binaries from github to every yunohost instance using a package
[11:51:05]
<selfhoster1312> that sounds like security disaster waiting to happen ^^
[11:52:08]
<tituspijean> then let the yunohost instance build the binaries 🙂
[11:52:13]
<selfhoster1312> a yunohost guix channel would be great to allow reproducibility and source/binary distribution on many architectures
[11:52:38]
<selfhoster1312> yes that's what i do on my instance but i can't imagine raspberry pi compiling 200+ rust crates xD
[11:52:46]
<selfhoster1312> (i use X86 4 cores)
[11:53:42]
<tituspijean> true 😛
Deploying a new service brings the issues of resources/maintenance/costs though
[11:54:14]
<selfhoster1312> soooooooo package_check fails with Unsupported version 0 of Verneed record
[11:54:24]
<selfhoster1312> which apparently is a common bug in snap
[11:55:01]
<selfhoster1312> i'll wait to see what yunorunner says :)
[11:55:51]
<selfhoster1312> about the binary distribution for yunohost personally i don't care about the tech used... a simple debian repo is good enough for me, but i see use in this
[11:56:08]
<selfhoster1312> it's happened to me before running yunohost on raspi to run out of RAM trying to compile a package (was it invidious? don't remember)
[11:57:02]
<tituspijean> I'm completely with you on this. 🙂
[11:58:03]
<selfhoster1312> i see yunorunner takes a lot of time... where is it running? can i donate hardware to make it faster?
[12:00:36]
<selfhoster1312> (not that i have money to donate, but i have a few older quad-core 1U servers i could donate, and i can even host for free for a few months but can't promise for more time)
[12:19:04]
<Yunohost Git/Infra notifications> [package_check] @selfhoster1312 commented on issue #117 Add script to run package check via Vagrant in a VirtualBox: I tried your PR and got the following output: ./run_package_check.sh repos/reverseproxy_ynh/ Package check: repo... https://github.com/YunoHost/package_check/pull/117#issuecomment-1375544928
[12:39:32]
<Yunohost Git/Infra notifications> [apps] @ericgaspar approved pull request #1588 testme Add reverseproxy_ynh to catalog https://github.com/YunoHost/apps/pull/1588#pullrequestreview-1240420696
[12:39:41]
<Yunohost Git/Infra notifications> [apps] @ericgaspar merged pull request #1588: testme Add reverseproxy_ynh to catalog https://github.com/YunoHost/apps/pull/1588
[12:39:41]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 2 commits to master: https://github.com/YunoHost/apps/compare/af811e389130...e42f14676f47
[12:39:45]
<Yunohost Git/Infra notifications> [apps/master] Add reverseproxy_ynh to catalog - selfhoster1312
[12:39:48]
<Yunohost Git/Infra notifications> [apps/master] Merge pull request #1588 from selfhoster1312/reverseproxy testme Add reverseproxy_ynh to catalog - Éric Gaspar
[12:40:15]
<Yunohost Git/Infra notifications> [apps] @ericgaspar approved pull request #1587 Add loki logo https://github.com/YunoHost/apps/pull/1587#pullrequestreview-1240421659
[12:40:23]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 2 commits to master: https://github.com/YunoHost/apps/compare/e42f14676f47...5c8f622f15de
[12:40:23]
<Yunohost Git/Infra notifications> [apps] @ericgaspar merged pull request #1587: Add loki logo https://github.com/YunoHost/apps/pull/1587
[12:40:28]
<Yunohost Git/Infra notifications> [apps/master] Add loki logo - Florent
[12:40:32]
<Yunohost Git/Infra notifications> [apps/master] Merge pull request #1587 from fflorent/add-loki-logo Add loki logo - Éric Gaspar
[12:40:36]
<tituspijean> ¯\_(ツ)_/¯ well it's merged 😅
[12:44:18]
<selfhoster1312> i won't complain :P
[12:45:31]
<selfhoster1312> how does yunohost permissions difference users and groups? in API i see both with same syntax/structure
[12:45:51]
<selfhoster1312> do i need to query the groups API to check if a group exists with that name? if not consider it's user?
[12:55:00]
<Aleks (he/him/il/lui)> > <selfhoster1312> sorry to ask again: what's the recommended way to provide binaries for install in a package when upstream does not provide binary builds?
some people also host stuff on https://build.yunohost.org/apps/ but it's not very practical because then we have to share ssh access etc ... ultimately it would be nice to engineer some workflow such that we can build and host binaries on our own infra as opposed to github
[12:56:16]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/issues/issues/1851
[12:59:48]
<Aleks (he/him/il/lui)> > <selfhoster1312> i see yunorunner takes a lot of time... where is it running? can i donate hardware to make it faster?
https://i.imgflip.com/76tzvm.jpg 👀
[13:00:14]
<Aleks (he/him/il/lui)> (hell, back in my days there was no CI ! We tested the app on our local instance and yoloreleased a new version)
[13:00:54]
<Aleks (he/him/il/lui)> then everything changed when the fire nation attacked
[13:01:16]
<tituspijean> 👍️
Let's have a bot monitor the commits to `testing`, stage and release the builds, update the app.src files and run yunorunner 🚀
easypeasy, easier said than done....
[13:01:46]
<Aleks (he/him/il/lui)> but release the build *where* ;P
[13:02:05]
<Aleks (he/him/il/lui)> and build *how* ;P
[13:04:44]
<Aleks (he/him/il/lui)> the future CI building artifacts be like https://www.youtube.com/watch?v=Tb75RjpvBIk
[13:36:11]
<selfhoster1312> Aleks[m]: thanks for info but does not answer my question if donating hardware can be useful :P
[13:37:28]
<selfhoster1312> for build.yunohost.org have you considered running a guix channel? it sounds like it's perfect for that kind of usecase: build from source, multiple arch, reproducible builds, binary distribution...
[13:37:57]
<Aleks (he/him/il/lui)> i forgot what's the current story about the ci-apps-dev hardware, i think we may have enough, but we could decide to increase the number of workers
[13:38:23]
<Aleks (he/him/il/lui)> new hardware is cool, but usually the bottleneck is volunteer energy to setup and maintain it
[13:38:40]
<Aleks (he/him/il/lui)> i doubt anybody has any experience with guix here
[13:39:10]
<Aleks (he/him/il/lui)> maybe it's great but personally i don't know anything about it
[13:40:05]
<selfhoster1312> re hardware: i can set it up but i can make no promise of availability in the long term so it's only a good offer if the CI keeps working when less runners are offline (i can promise free hosting until mid-march after that all bets are off :))... but i have no idea what it takes to maintain your CI infra
[13:40:10]
<Aleks (he/him/il/lui)> and i'm skeptical about reproducability when the thing involve `npm install` ;P But maybe I don't know what's to be understood by reproducibility
[13:41:40]
<selfhoster1312> Aleks[m]: good point, the reproducible packaging story for npm/pip/cargo is bad (though cargo is less bad)... i was thinking the usecase was for binary compiling but you're right there's other from-source processing to do for some packages
[13:41:57]
<selfhoster1312> (but i hope anyone crazy enough to develop javascript projects publishes pre-built artifacts :P)
[13:42:51]
<Aleks (he/him/il/lui)> yeah there are some similar story with `pip` I think ... like I think there's at least one or two apps where the packager ended up pre-building the venv because `pip install` was compiling a shitload of stuff locally
[13:43:30]
<selfhoster1312> so just tell me if the hardware donation / hosting interests you i can get it up and running rather quickly (but on HDD only unless i find NVME + PCIe/NVME adpater)
[13:45:04]
<Aleks (he/him/il/lui)> it's such a mess, it's really feel like the compute ecosystem went backward since 2000~2010 somehow, like at some point people ~solved the whole distribtution thing with prebuilt binaries like in Debian etc, you could run epic thing on low-end hardware, and nowadays it's like "wow you want to deploy a 3-page static webapp ? I hope you have 16 GB RAM to run `npm install` and `npm build`, but first let me tell you have the 5 layers of meta-tooling you're gonna need to install the proper npm version"
[13:45:18]
<selfhoster1312> (but if just increasing workers would prevent a few big tasks from blocking the queue, that's good)
[13:45:46]
<Aleks (he/him/il/lui)> the other day, one app had this epic bug during `npm install`(?) because some dependency was trying to .... run python2 code
[13:45:51]
<selfhoster1312> hahahaha that's also my (bad) feeling about packaging these days... "just docker these things up and let the magic break everything"
[13:45:56]
<Aleks (he/him/il/lui)> </rant>
[13:47:27]
<Aleks (he/him/il/lui)> has yes docker like "shit went so complicated we decided to add an entire layer of containerization on top of everything because we can't be bothered to try to create an ecosystem of consistent stuff that can cohabit together on the same system" ... which is another thing Linux distributions solved back in the days but we forgot about
[13:47:52]
<selfhoster1312> (i find it crazy that the task for peertube runs since 10am, but i guess if you run virtualization on virtualization on HDD and have to npm build stuff inside of that without a local cache of packages..........)
[13:49:16]
<Aleks (he/him/il/lui)> pepperidgefarmremembers.jpg
[13:49:18]
<selfhoster1312> Aleks[m]: if you haven't read about nix/guix, i really recommend you look it up ; it's a REALLY elegant and modern way to solve these packaging issues by using pure functions and hashing the inputs to name the output (so different versions of stuff can coexist)
[13:49:43]
<Aleks (he/him/il/lui)> i think i know the general idea but yeah so far i never tried to really dig it up
[13:50:23]
<selfhoster1312> i wouldn't recommend it for ALL cases (UX is still sub-par compared to apt) but for distributing packages of various languages on multiple arch it's the best i found so far :)
[13:52:18]
<selfhoster1312> packaging peertube be like: https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/peertube/default.nix (single file)
[13:52:45]
<selfhoster1312> (this specific example only supports x86_64 :s)
[13:58:18]
<selfhoster1312> newbie question: how can my (public) app know if a user is logged-in? when the app is public client can apparently override auth-user header oO
[13:59:35]
<Aleks (he/him/il/lui)> not sure what you mean ?
[14:00:57]
<selfhoster1312> i want to make new homepage for yunohost with different content for logged-in users (unread mail counter)
[14:01:12]
<selfhoster1312> when i make the app all-users i rely on SSOWat to set auth-user header and it works
[14:01:34]
<selfhoster1312> when i make app visitors, i can just curl -H 'auth-user: admin' and app reads i'm logged in as admin (because it reads from headers)
[14:01:58]
<Aleks (he/him/il/lui)> 👀
[14:02:26]
<Aleks (he/him/il/lui)> i think apps are expected to reauthenticate users using the base64 password thingy provided by ssowat
[14:03:20]
<selfhoster1312> i see there's a SSOWat hash in a different header, can i find the key/salt somewhere to verify that it was "signed" by SSOWat and it's not a user pretending?
[14:03:28]
<selfhoster1312> (is there a docs page i missed about this SSO topic?)
[14:04:39]
<Aleks (he/him/il/lui)> whatisdoc,babydonthurtmenomore.mp3
[14:04:41]
<Aleks (he/him/il/lui)> nah the doc regarding sso/ldap is uh probably non existent
[14:04:53]
<Aleks (he/him/il/lui)> or maybe there's something in the doc idk, probably outdated
[14:05:19]
<Aleks (he/him/il/lui)> > <selfhoster1312> i see there's a SSOWat hash in a different header, can i find the key/salt somewhere to verify that it was "signed" by SSOWat and it's not a user pretending?
i dont think you wanna do that, i think apps reauthenticate the user on LDAP
[14:05:23]
<Aleks (he/him/il/lui)> but not very practical
[14:06:04]
<selfhoster1312> could we maybe erase user-provided SSO headers in base nginx config? then SSOWat can readd them if authenticated
[14:06:12]
<selfhoster1312> this way i can rely on HTTP headers for auth without dealing with LDAP :P
[14:07:01]
<Aleks (he/him/il/lui)> rereading the code
[14:07:18]
<Aleks (he/him/il/lui)> i mean SSOwat injects the basic auth header, and this in turn make nginx define special headers according to the auth header if i remember correctly
[14:10:29]
<selfhoster1312> from what i read helpers.lua injects those additional headers (email, auth-user...)
[14:11:21]
<selfhoster1312> (defined in SSOWAT config)
[14:13:16]
<selfhoster1312> https://github.com/YunoHost/SSOwat/blob/dev/helpers.lua#L411
[14:13:36]
<Aleks (he/him/il/lui)> yeah im not sure if these are really used
[14:13:58]
<selfhoster1312> i was planning to use email, for what it's worth :P
[14:14:04]
<selfhoster1312> (and auth-user ofc)
[14:24:21]
<Aleks (he/him/il/lui)> thinking intensifies
[14:26:48]
<selfhoster1312> it's fairly straightforward to remove client headers from nginx, however the problem is we need to read ssowat conf, so easiest would be a special ssowat directive for public sites
[14:27:20]
<selfhoster1312> something like access_by_lua_file /usr/share/ssowat/noauth.lua
[14:27:44]
<Aleks (he/him/il/lui)> not sure what you need to read ssowat conf for ?
[14:27:46]
<selfhoster1312> ah wait, actually ssowat/access.lua is run even for public apps
[14:27:57]
<selfhoster1312> Aleks[m]: to get the list of additional headers to unset
[14:28:00]
<selfhoster1312> (not just Authorization)
[14:28:16]
<selfhoster1312> let me try to hack something 8)
[14:28:36]
<Aleks (he/him/il/lui)> i mean yeah we can remove this from inside the lua code
[14:28:44]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Update vpnclient.png https://github.com/YunoHost/apps/commit/9a75a4f6987eca98fd62530faf845d8280ecb862
[14:37:46]
<selfhoster1312> ok i got a patch
[14:38:49]
<selfhoster1312> (let me run some tests)
[14:51:03]
<selfhoster1312> Aleks[m]: https://github.com/YunoHost/SSOwat/pull/209
[14:51:33]
<selfhoster1312> tested YOLO style with curl -H 'auth-user: admin' https://example.com/publicapp ;)
[14:51:43]
<selfhoster1312> (where the publicapp prints the auth-user header)
[14:53:28]
<selfhoster1312> also it would be nice if SSOWAT prefixed all headers... just to be sure we're not clearing headers used by apps :D (but that would be breaking change)
[14:59:16]
<Aleks (he/him/il/lui)> 😬
[15:40:45]
<Aleks (he/him/il/lui)> selfhoster1312: what language are you uing for your app though btw ?
[15:40:55]
<selfhoster1312> rust
[15:41:20]
<selfhoster1312> i'd like it to cross-compile nice and have strong types so rust/ocaml is sort of only options (except haskell but i'm not ready for that XD)
[15:42:04]
<selfhoster1312> javascript/python ecosystem is so messsed up :'( the base language is not bad but then you try to import libraries and... *BOOM*
[15:42:20]
<Aleks (he/him/il/lui)> so is it like a daemon with reverse proxy through nginx ?
[15:42:24]
<selfhoster1312> yup
[15:43:16]
<selfhoster1312> the idea is it can run two modes: build for a static page identical for all users, serve for a HTTP server that you reverse proxy and can serve different templates depending on user/permissions
[15:43:48]
<selfhoster1312> at first i wanted to make a yunohost panel theme but that was trouble... i want full noscript support :P
[15:43:58]
<Aleks (he/him/il/lui)> in that case i would say the canonic way of fetching the user would be to have `proxy_set_header X-Remote-User $remote_user;` in your nginx config
[15:44:11]
<Aleks (he/him/il/lui)> and then you can check the valu of the X-Remote-User header
[15:44:29]
<Aleks (he/him/il/lui)> `$remote_user` is a special nginx var filled with the user from the Basic Auth header
[15:45:08]
<selfhoster1312> hmmmmm that's true i didn't think about it thanks
[15:45:13]
<Aleks (he/him/il/lui)> (like i'm kinda skeptical apps really use those funky additional header thingies)
[15:46:09]
<selfhoster1312> (skeptical that we SHOULD use it at all? or that anyone does yet?)
[15:46:47]
<Aleks (he/him/il/lui)> both
[15:46:55]
<gredin67> > <@gredin67:matrix.fdn.fr> do you find it cleaner to initialize config panel settings through getters
> https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/f0b9772e47d537f79f06a1633a4c85cbf94d06c0/scripts/config
> or with direct initialization like here
> https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/expose-config-panel/scripts/install#L56-L76
> see also the discussion here
> https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/expose-config-panel/scripts/install#L56-L76
UP https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/pull/74
[15:47:54]
<selfhoster1312> Aleks[m]: personally i find it great that a backend app can access more info than simply username without binding to LDAP
[15:48:05]
<selfhoster1312> i love LDAP but it's overkill to expose it to backend apps for simple queries...
[15:48:50]
<selfhoster1312> my favorite would be if there could be special socket(s) for yunohost API without auth based on UNIX permissions
[15:49:21]
<selfhoster1312> but if you strongly recommend i use yunohost API instead i'll do that... i'm just not a fan of storing my root password in a config file somewhere
[16:04:26]
<Aleks (he/him/il/lui)> hmmm
[16:05:14]
<Aleks (he/him/il/lui)> > <selfhoster1312> Aleks[m]: personally i find it great that a backend app can access more info than simply username without binding to LDAP
yes it's "cool" but cool doesnt mean useful ;P I mean I like the YAGNI principle and it seems that those additional headers are pretty yagni
[16:05:27]
<Aleks (he/him/il/lui)> your use case is kinda specific I think because if i remember correctly you're basically implementing a custom portal
[16:06:07]
<Aleks (he/him/il/lui)> and for that case, the "backend" is yunohost itself (or the LDAP db) and it's indeed not designed at all for this
[16:06:37]
<selfhoster1312> true... but at the same time i have a lot of apps relying on header auth via nginx/SSO and if i want to migrate them to yunohost forking them and implementing LDAP support in all them is not great ^^
[16:06:51]
<Aleks (he/him/il/lui)> hence why we want to basically rewrite ssowat (or delete 66% of it) and have a proper "user API" from which a user can query its own info through a rest/json api
[16:07:23]
<Aleks (he/him/il/lui)> > <selfhoster1312> true... but at the same time i have a lot of apps relying on header auth via nginx/SSO and if i want to migrate them to yunohost forking them and implementing LDAP support in all them is not great ^^
yes but LDAP is standard though
[16:07:37]
<Aleks (he/him/il/lui)> i mean we already have too much homemade stuff in yunohost, and clearly I hate LDAP but many upstream do implement it
[16:07:44]
<selfhoster1312> it's standard but ideally i don't want all apps i run to have access to user passwords :-/
[16:08:01]
<selfhoster1312> if they don't support header auth (like jellyfin) i go for LDAP but otherwise i'd rather have ONE backend have access to passwords not 20 :P
[16:08:27]
<Aleks (he/him/il/lui)> do you really need the password though ? (i dunno)
[16:08:44]
<selfhoster1312> i don't, but to bind LDAP i need password right?
[16:10:22]
<selfhoster1312> i don't like that on my yunohost server all apps receive a copy of the password and i have to authenticate again... it makes for GREAT attack surface, just find one vuln app and you just pwned 100% other services... proper SSO cleanly separates apps on the other hand so one pwned app can't mess with users on other apps
[16:11:11]
<selfhoster1312> (it's two separate problems: from what you told me SSOWat sends base64 password to all apps, and that i have to manually login on some apps even when i'm logged in in SSOWat)
[16:11:33]
<Aleks (he/him/il/lui)> nah you can bind anonymously
[16:12:24]
<selfhoster1312> (we're probably not going to find an elegant solution to "auth" problems right here right now but if there's a longer discussion sometimes i'd like to take part)
[16:12:59]
<selfhoster1312> err... then i get access to what? everything ? do you have an example of anonymous binding? i didn't see this in yunohost docs
[16:13:45]
<Aleks (he/him/il/lui)> we're talking two or three different things but yeah
[16:13:59]
<selfhoster1312> yeah so many related questions/topics, sorry
[16:15:33]
<Gérard Collin> > <selfhoster1312> i don't like that on my yunohost server all apps receive a copy of the password and i have to authenticate again... it makes for GREAT attack surface, just find one vuln app and you just pwned 100% other services... proper SSO cleanly separates apps on the other hand so one pwned app can't mess with users on other apps
Don't you have oauth standard for that? At least for web apps
[16:16:01]
<selfhoster1312> Gérard Collin: yes, OAUTH, SAML, KERBEROS, OpenID Connect, Shibboleth... so many standards to fix this problem ^^
[16:16:14]
<selfhoster1312> the problem is not all apps support one or more of these so you need a solution that supports A BUNCH
[16:17:45]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/conf/slapd/config.ldif#L158-L163
[16:17:57]
<Aleks (he/him/il/lui)> apparently anything able to bind to LDAP can read everything I guess
[16:18:22]
<Aleks (he/him/il/lui)> i guess there's no really super secret info in the LDAP DB
[16:18:36]
<selfhoster1312> oh, nice
[16:18:46]
<selfhoster1312> i mean not nice from security pov but nice for me ^^
[16:19:20]
<selfhoster1312> so i guess LDAP is my auth-less yunohost API after all ;)
[16:21:26]
<Aleks (he/him/il/lui)> of course one could want something much finer like "app $foo can only access to a specific list of user and attributes" but in terms of threat model it's kinda meh .. i mean the primary stuff is to prevent the threat model of "app $foo gets pwned and can escalate to root or steal private data outside of its scope"
[16:24:15]
<Aleks (he/him/il/lui)> > <selfhoster1312> (it's two separate problems: from what you told me SSOWat sends base64 password to all apps, and that i have to manually login on some apps even when i'm logged in in SSOWat)
yes that part could definitely improved and it's "not that hard" except, as always, the legacy™
we could have a flag in the app manifests to switch between "no SSO at all" (=> no sso auth info sent at all), "user header only" (=> only send the name of the logged in user which should be the major case) and "full auth info" (=>username+password)
[16:24:48]
<Aleks (he/him/il/lui)> but let me double check the fact that the app does obtain the full basic auth header
[16:24:54]
<selfhoster1312> i just checked it does :)
[16:25:06]
<selfhoster1312> but yes that kind of switch makes sense
[16:30:53]
<Aleks (he/him/il/lui)> @_@
[16:39:09]
<selfhoster1312> ^^
[16:45:40]
<Gérard Collin> > <selfhoster1312> the problem is not all apps support one or more of these so you need a solution that supports A BUNCH
these solutions exist (like this one: https://forgerock.github.io/openam-community-edition/) however it may be too big for self hosting. Let me check if we have a lightweight one
[16:50:12]
<selfhoster1312> also: keycloak, ory suite, authelia...
[16:50:26]
<selfhoster1312> i had some keycloak in the past it was ok, can't say it was lightweight or easy but worked fine
[16:50:59]
<selfhoster1312> nowadays i'd be tempted to try kanidm but i didn't have time yet : https://github.com/kanidm/kanidm
[16:51:42]
<selfhoster1312> it's a OAuth/OpenID Connect provider but also provides LDAP gateway for interop
[16:52:50]
<selfhoster1312> >
[16:52:51]
<selfhoster1312> Kanidm aims to have the features richness of FreeIPA, but without the resource and administration overheads
[16:53:14]
<Aleks (he/him/il/lui)> the main issue is not really finding the right tool, the main issue is finding somebody who wants to work on this and handle all the legacy questions
[16:56:37]
<selfhoster1312> if we provide a LDAP gateway, is there something more to handle than yunohost core and SSOWat?
[16:57:02]
<selfhoster1312> (maybe answering that question is the hard work itself)
[16:57:50]
<selfhoster1312> anyway sorry for taking us so off-topic i'll get back to writing my app :)
[16:58:05]
<tituspijean> > FreeIPA
Best kind of beer.
[16:58:14]
<Aleks (he/him/il/lui)> what's an LDAP gateway ?
[16:58:48]
<selfhoster1312> Aleks[m]: kanidm supports many protocol, it acts as a LDAP server/gateway so apps which login via LDAP can still do it, even though it's not TECHNICALLY a full LDAP server
[16:59:07]
<selfhoster1312> (precisely because of usecases like "legacy" stuff we're discussing right now :P)
[16:59:23]
<Aleks (he/him/il/lui)> i mean ultimately devil is always in the detail ... sometime you can draft stuff being drunk in a bar, and then you start actually trying to implement it and you realize how much of a mess it is
[17:00:14]
<Aleks (he/him/il/lui)> like, in it's current state, the whole SSO is super tight-coupled to the user portal frontend, so there's much refactor to do just to be able to plug a different middleware
[17:00:33]
<Aleks (he/him/il/lui)> and then there is cross-domain authentication (which i'm not even sure still works)
[17:01:16]
<Aleks (he/him/il/lui)> uuugh, replacing the LDAP server ? nope nope nope
[17:01:38]
<selfhoster1312> cross-domain auth is sort-of solved by either/both HTTP header auth and Oauth/OpenID Connect, right? (isn't that a cookie-specific thing?)
[17:04:46]
<selfhoster1312> (i've never tried SSO on multiple domains ^^")
[17:04:51]
<Aleks (he/him/il/lui)> https://i.imgflip.com/76uyu7.jpg
[17:08:20]
<Aleks (he/him/il/lui)> i mean if you think it's simple, be my guest and try making a POC that works with just a couple yunohost apps while not breaking major stuff (eg not having a completely different user portal that the current one)
[17:08:55]
<Aleks (he/him/il/lui)> and you'll quickly be like "uh i don't even know where to begin" and i'll be like "uh really you don't ?! <sarcasm>" 😅
[17:09:28]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯ not that i want to discourage you but be ready
[17:13:32]
<selfhoster1312> i don't think it's simple but i'd like to give it a try sometime :)
[17:13:44]
<selfhoster1312> (but other priorities !)
[17:22:17]
<Gérard Collin> > <@Alekswag:matrix.org> the main issue is not really finding the right tool, the main issue is finding somebody who wants to work on this and handle all the legacy questions
You're right
[17:24:38]
<Gérard Collin> > <selfhoster1312> Kanidm aims to have the features richness of FreeIPA, but without the resource and administration overheads
Seems nice. There is already a packaged ldap server that can support openId and saml and other stuff: https://lemonldap-ng.org. It's directly supported by debian
[17:26:18]
<Aleks (he/him/il/lui)> ... yes ... lemonldap ... fun fact yunohot 1.x or 2.x was based on lemon ldap ...
[17:27:03]
<Aleks (he/him/il/lui)> i'm not sure why it got replaced by SSOwat, I'm guessing that it's because Yunohost (as a project) wanted to have a fully custom portal and you don't have that much freedom in lemonldap
[17:28:20]
<selfhoster1312> i heard good things about lemonldap but never tried it.. guess i have to add this to my todolist ^^
[17:57:14]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @alexAubin commented on issue #478 Folders shared publicly empty when connected with SSO: (I confirm that the custom permission with --auth_header="false" should be the right way to address the issue) https://github.com/YunoHost-Apps/nextcloud_ynh/issues/478#issuecomment-1376027604
[18:25:53]
<Yunohost Git/Infra notifications> @jlevesy forked example_ynh to jlevesy/grafana_prometheus_ynh: https://github.com/jlevesy/grafana_prometheus_ynh
[18:46:19]
<rodinux[m]> Hello, I prepare next release for garradin_ynh, the links and sources changed a little because the name is chnaged to paheko... I don't know how we can little by little migrate the name of garradin_ynh to paheko_ynh, without breaking... Doesn't matter for now but it may be later necessay... ???
[18:46:55]
<rodinux[m]> *necessary
[19:05:43]
<Aleks (he/him/il/lui)> there are some special helpers to help migrating an app to a new name
[19:07:13]
<Aleks (he/him/il/lui)> and it's important to do this properly to prevent confusion on the long term
[19:08:43]
<Aleks (he/him/il/lui)> cf for example : https://github.com/YunoHost-Apps/gitea_ynh/blob/master/scripts/upgrade#L72
[19:08:58]
<Aleks (he/him/il/lui)> or similar stuff in `bitwarden` <-> `vaultwarden`
[19:09:12]
<Aleks (he/him/il/lui)> or `spip` <-> `spip2`
[19:09:48]
<rodinux[m]> ljf: réu CHATONS ??
[19:10:10]
<Aleks (he/him/il/lui)> if i remember correctly basically you should probably create a new repo with the new name
[19:10:31]
<Aleks (he/him/il/lui)> and then existings user should explicitly upgrade their app (garradin) with the url (`-u`) of the new paheko_ynh repo
[19:11:01]
<Aleks (he/him/il/lui)> but i never wrote this myself so i don't know if that's still the recommended workflow and what hicups to expct
[19:46:23]
<rodinux[m]> ok... thanks Aleks (he/him/il/lui) perhaps I will need your help later to do that...
[22:21:28]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to logos: Create tiki.png https://github.com/YunoHost/apps/commit/23bc7a5a31cabdd208afc2a2930926f59d0122a6
[22:51:39]
<gredin67> is this true? https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/pull/74#issuecomment-1376402838
[22:51:39]
<Aleks (he/him/il/lui)> uuuh not sure what's the question
[22:52:19]
<Aleks (he/him/il/lui)> but yes you can manipulate yaml files with python, that's "trivial", dunno if that's the question
[22:59:01]
<gredin67> the question is can we handle YAML sequences with yunohost settings (helpers) and with the config panel :D
[22:59:55]
<gredin67> or (where) do we have to parse manually?
[23:02:12]
<gredin67> basically having a `__FOOBAR__` which is a YAML sequence of values, and parse it as a yaml list
[23:02:13]
<gredin67> basically having a `__FOOBAR__` which is a YAML sequence of values, and parse it as a python list
[23:06:41]
<Aleks (he/him/il/lui)> 🤔
[23:08:31]
<Aleks (he/him/il/lui)> i mean ljf thought about it
[23:08:31]
<Aleks (he/him/il/lui)> config panel support list of tags or stuff like this
[23:08:32]
<Aleks (he/him/il/lui)> but devil is in the details
[23:08:34]
<Aleks (he/him/il/lui)> but surely you can always write a custom getter/setter for this
[23:09:09]
<Aleks (he/him/il/lui)> such as reading the yaml with python, modifying whatever you want, and redumping the yaml file
[23:17:11]
<gredin67> and `ynh_app_setting` should support getting setting a python list I guess ?
[23:19:00]
<Aleks (he/him/il/lui)> hmmm
[23:19:05]
<Aleks (he/him/il/lui)> i'm not sure
[23:19:06]
<Aleks (he/him/il/lui)> i doubt it does
[23:19:24]
<Aleks (he/him/il/lui)> we add special bits of logic for the "protected_urls" stuff back in the days
[23:32:36]
<ljf> tags are registered into app settings via coma separated value (in a string i think)
[23:33:18]
<ljf> i know it's not the best if you want to edit yaml list