[01:13:49]
<Yunohost Git/Infra notifications> App gitlist stays at level 1 in job [#15642](https://ci-apps.yunohost.org/ci/job/15642)
[01:46:33]
<Yunohost Git/Infra notifications> App glitchsoc failed all tests in job [#15643](https://ci-apps.yunohost.org/ci/job/15643) :(
[03:58:21]
<Yunohost Git/Infra notifications> App gossa rises from level 7 to 8 in job [#15646](https://ci-apps.yunohost.org/ci/job/15646) !
[05:29:13]
<Yunohost Git/Infra notifications> App grav failed all tests in job [#15650](https://ci-apps.yunohost.org/ci/job/15650) :(
[06:54:52]
<Yunohost Git/Infra notifications> App guacamole failed all tests in job [#15653](https://ci-apps.yunohost.org/ci/job/15653) :(
[10:01:31]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @mrtpcet opened [issue #99](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99): Error when I update from 2022.07.31a-ynh1 to 2023.04.04a-ynh1
[10:25:51]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99#issuecomment-1551137649) on [issue #99](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99) Error when I update from 2022.07.31a-ynh1 to 2023.04.04a-ynh1: Do you have proper logs?
[10:27:19]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99#issuecomment-1551137649) on [issue #99](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99) Error when I update from 2022.07.31a-ynh1 to 2023.04.04a-ynh1: Do you have proper logs? also, do you have extra plugins installed?
[12:30:34]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @mrtpcet [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99#issuecomment-1551306416) on [issue #99](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/99) Error when I update from 2022.07.31a-ynh1 to 2023.04.04a-ynh1: Here are the logs : https://paste.yunohost.org/raw/wirivosije And print screen of my plugins folder : [image](https:/...
[12:51:09]
<john> Has ynh_install_composer been removed? I'm looking at the movim package (it is at 0.19 and they have an open PR for 0.20) and it fails on that not existing anymore?
[12:52:43]
<Aleks (he/him/il/lui)> i'm thinking it was never added to the official helpers if i remember correctly ?
[12:54:28]
<john> Maybe they relied on the experimental ones?
[12:54:46]
<Aleks (he/him/il/lui)> ah my bad it is definitely part of yunohost official helpers
[12:55:31]
<john> ah ok
[12:56:00]
<Aleks (he/him/il/lui)> 188935 INFO DEBUG - + sudo -u movim ynh_install_composer --phpversion=8.0 --workdir=/var/www/movim
188935 INFO DEBUG - sudo: ynh_install_composer: command not found
[12:56:03]
<Aleks (he/him/il/lui)> hmyeah
[12:56:42]
<john> yeah, that's what I'm looking at
[12:56:45]
<Aleks (he/him/il/lui)> so the issue is that the usage of sudo (or ynh_exec_as which is a wrapper for sudo) makes it so that the function doesnt exists in the sudo scope
[12:57:12]
<john> do they even need to use sudo in that context? isn't the appdir owned by the app user?
[12:57:19]
<Aleks (he/him/il/lui)> because if you define a function `foo`, you can't simply call `sudo foo`, because `sudo` prefixes a command (which must exist in $PATH), not a function
[12:57:35]
<john> yeah, so they've got a different path when they run sudo
[12:58:05]
<john> sudo -E preserve environment iirc
[12:58:33]
<john> I'll have a look and see if they can do without the sudo stuff though, it'd be nice to have movim 0.20 for the omemo support
[12:59:49]
<Aleks (he/him/il/lui)> but using composer as non-root is a good idea ... imho we should maybe add a new option like `--run-as-app` or idk in the helper
[13:00:51]
<john> the composer helper or the ynh_exec_as helper?
[13:02:10]
<Aleks (he/him/il/lui)> the appdir is owner by the app user, yes, probably, but doesnt change the fact that running composer as root is not recommended (and in fact it ain't recommended to run any complex command as root at all, cf for example npm or pip ;P)
[13:02:18]
<john> sorry if i'm interrupting you at work btw :D
[13:02:30]
<john> heh yeah
[13:02:49]
<john> does composer have options like pip does for `--user` to install?
[13:03:06]
<john> (this from the category of "questions i could google" I guess)
[13:28:40]
<Aleks (he/him/il/lui)> meh not sure what's happening but i received your messages 2 or 3 times ...
[13:28:49]
<Aleks (he/him/il/lui)> maybe the xmpp bridge acting up
[13:29:59]
<Aleks (he/him/il/lui)> i'm not sure what is meant by "preserve the environment" (is sudo -E eco-friendl ? ;P), imho "the environment" ususually refers to the set of bash variables
[13:30:20]
<Aleks (he/him/il/lui)> but functions or aliases are not part of the environment
[13:30:21]
<Aleks (he/him/il/lui)> but could be wrong, that's a subtle one
[13:38:52]
<john> hmm, might be once for every client? and yeah i meant the environment variables bash cares about, not the trees :D
[14:10:01]
<john> this is what I mean:
https://www.sudo.ws/docs/man/1.8.13/sudo.man/#E
so if this line:
https://github.com/YunoHost/yunohost/blob/ea24fca91f4f8b1f34e544087fd9b4a7007a12e0/helpers/user#L186
was this instead something like this:
```
ynh_sudo_helper=$(declare -f somefunction)
sudo -E -u "$user" bash -c "$ynh_sudo_helper; $@"
```
then I *think* it would work - somefunction would have to be whatever function was being invoked as an argument to ynh_exec_as
[14:11:22]
<john> I'm not sure off the top of my head if somefunction would just be $1 or something, I forget how tokenisation works with bash functions vs executables
[14:13:27]
<Aleks (he/him/il/lui)> yeah that might work but that's kinda convoluted
[14:14:11]
<Aleks (he/him/il/lui)> it'd be better to invest energy in modifying the official composer helpers in https://github.com/YunoHost/yunohost/blob/dev/helpers/php
[14:14:13]
<john> no argument here, it definitely is
[14:14:30]
<john> I'll take a look
[14:20:11]
<john> I don't see anything here that would need sudo, to be honest:
https://github.com/YunoHost/yunohost/blob/dev/helpers/php#L522
[14:20:41]
<john> unless I'm being naive, but it installs to $workdir
[14:21:20]
<john> I'm on my work laptop atm but will have a look later and see if it works by just.. removing `ynh_exec_as` from the command
[14:21:30]
<john> that'd be the nicest solution if it works
[14:23:16]
<Aleks (he/him/il/lui)> i don't know why you are confused by the fact that it installs in $workdir 😅 .. If i am user `root` and i `cd /home/john` (home-folder of john ... owner by john) then `touch foobar`, this creates a file `foobar` owned by root, even if I'm in john's home, and even john won't be able to delete that file which is in his own home
[14:23:45]
<Aleks (he/him/il/lui)> not saying that's what composer do, i'm just illustrating the fact that the user that runs a command has no relation with the owner of the working dir
[14:23:58]
<john> maybe I'm being slow, but my point is that you don't need to be root to install to $workdir right?
[14:24:33]
<Aleks (he/him/il/lui)> but in fact in the case of Movim, it would probably be okay to run composer as root ... I'm guessing that somebody tried to run the whole thing with `ynh_exec_as` because when you look at the install log, Composer complains about being ran as root
[14:24:41]
<Aleks (he/him/il/lui)> yes
[14:25:15]
<john> right, so if everything can live in $workdir including composer itself, then root isn't needed, and that means ynh_exec_as isn't needed?
[14:25:46]
<john> if I'm being stupid just say 😅
[14:25:50]
<Aleks (he/him/il/lui)> you don't need to be root, it's "just" that a yunohost install/remove/upgrade/whatever script is ran as root, so when you want to run as non-root, you have to actively use stuff like `ynh_exec_as` / `sudo -u` 😬
[14:26:00]
<john> ahhhh
[14:26:06]
<john> I assumed it was defaulting to the user, not to root
[14:26:09]
<john> that's why I was confused
[14:26:22]
<Aleks (he/him/il/lui)> ah :D
[14:26:59]
<john> so in this case it'd make sense for composer stuff, which doesn't need root, to do its own sudo -iu <app user> or similar, within the composer functions, since otherwise ynh_exec_as has to have clunky stuff in it
[14:27:15]
<Aleks (he/him/il/lui)> (but in the future™ packaging v3™ coming soon™ between now and 2050, the plan is to run the bulk of scripts as non-root, though we'll see how actually feasable that is 😅)
[14:27:42]
<john> and I'd guess ynh_exec_as is accessible from within ynh_composer_* so the right place for it is there, rather than in the install script
[14:27:48]
<john> hah, cool
[14:28:58]
<john> so in this case I think what needs doing is: use ynh_exec_as from within ynh_composer_*, and change the movim scripts to not use ynh_exec_as from install/etc
[14:29:32]
<john> although that does stand a chance of breaking existing installs if root owned files are being updated by a suddenly-not-root composer command
[14:29:41]
<john> stuff is hard :D
[14:30:02]
<Aleks (he/him/il/lui)> yeah ... unfortunately we gotta be safe and keep backward compatibility etc
[14:30:09]
<Aleks (he/him/il/lui)> that's always what takes 80% of development time >_>
[14:30:19]
<john> no doubt :/
[14:30:42]
<john> I guess the movim install script could just drop ynh_exec_as and then chown at the end..
[14:30:56]
<john> or not chown at all, as long as everything is readable by the movim user
[14:30:56]
<Aleks (he/him/il/lui)> that's why I would rather add an option like `--non-root` in the existing `ynh_install_composer` and `ynh_composer_exec` (called by ynh_install_composer) and add some ugly-but-simple `if [[ $non_root -eq 1 ]]` etc
[14:31:13]
<john> that seems reasonable
[14:31:21]
<john> I guess keeping defaults the same makes sense
[14:31:42]
<john> OK, cool - well, I'll bother the movim maintainer with a PR now :D thanks
[14:32:28]
<Aleks (he/him/il/lui)> > <john> or not chown at all, as long as everything is readable by the movim user
yeah, i mean, again it probably works right now if you just run composer as root .. but what we're trying to fix or "secure" here is : what if there's a security issue inside the composer bin itself and some third-party code can exploit that to run arbitrary command, injecting a rootkit with no priviledge escalatin needed because composer is being run as root
[14:33:23]
<Aleks (he/him/il/lui)> we're not trying to make movim work, we're trying to make the install secure against security issues inside composer that could be exploited when ran as root ;P
[14:33:32]
<john> hah
[14:33:51]
<john> is there a reason why composer can't be installed system wide from debian?
[14:33:57]
<john> again, probably a naive question
[14:34:05]
<Aleks (he/him/il/lui)> dunno
[14:34:36]
<john> that might be a nicer solution than vending it, maybe
[14:34:50]
<Aleks (he/him/il/lui)> nowadays people are kind of super bored about debian packaging because it's overly complex and it's simpler for devs to assume that some sysadmin will be able to run `curl|bash` anyway
[14:35:03]
<john> heh yeah, I know that feeling :/
[14:35:30]
<john> not to mention the fact debian packages get kind of ancient by the time a new release enters change freeze
[14:35:38]
<john> or even by the end of change freeze in some cases :(
[14:36:26]
<Aleks (he/him/il/lui)> yeah and then if you want to be outside of debian's cycles you gotta maintain your own repo, which people gotta add a GPG key for, etc
[14:36:34]
<john> yeah
[14:36:48]
<Aleks (he/him/il/lui)> and apparently there are several composer versions
[14:37:09]
<Aleks (he/him/il/lui)> some apps may still use version 1, some other version 2, ...
[14:37:29]
<Aleks (he/him/il/lui)> Contemporary Sysadmin Is A Mess, episode 2948472
[14:38:15]
<john> heh, it really is :(
[14:38:28]
<john> I wonder if they're packaged in the fpm repos ynh uses
[14:38:32]
<john> I'll take a look
[14:38:55]
<john> it'd be nice if they had composer-x-php-y or something like that
[14:39:10]
<john> seems hopeful though :D
[14:41:39]
<john> (I've assumed they're third party repos/packages, apologies if I've missed the obvious and you've spent ages on them :D )
[14:44:24]
<Aleks (he/him/il/lui)> nah nevermind it's not like all this stuff is the most obvious thing ever, it's legitimately confusing, between the yunohost helper paradigm, the way composer works, the subtleties of bash/sudo etc...
[14:48:12]
<john> not the first time I've worked things out by grepping codebases and quizzing people though so it is fine, but yeah it is kinda confusing
[14:48:20]
<john> most projects are in my experience
[14:48:53]
<john> the more moving parts and history, the harder it is to work out - it is inevitable really
[14:50:21]
<john> it still works amazingly well, I've mothballed a few years of trying to make nextcloud a HA OIDC provider for dovecot in containers in favour of ynh
[14:51:18]
<john> nextcloud HA was the most awkward bit of that setup, followed closely by making the OIDC provider app work
[14:57:16]
<Aleks (he/him/il/lui)> > <john> the more moving parts and history, the harder it is to work out - it is inevitable really
yeah and the inevitable head scratching during hours, wondering why something is implemented in some way, "there's probably a good reason!", and more often than not there's no reason at all, somebody just randomly yolo-designed it this way 10 years ago
[14:57:39]
<Aleks (he/him/il/lui)> or something was supposed to be corrected during the 5 layers of refactoring related to a piece of code, but somehow it was forgotten about
[14:58:25]
<john> lol, yeah
[14:58:39]
<john> all normal parts of development, I deal with it at work too :D
[14:58:50]
<john> although I have more license to break things at work
[14:58:55]
<Aleks (he/him/il/lui)> which is why the more time passes, the more I apply the rule of "if I can't figure out why something is done this way after 30 minutes or grepping the code or git history, I throw it away and watch what stuff break" ;P
[14:59:04]
<john> hahah
[14:59:09]
<john> entirely reasonable :D
[15:00:41]
<john> looking at the composer docs it appears that latest stable is for php 7.2+ - are there any ynh apps known to use earlier versions of php? I'd infer that composer's stable version is probably fine if not
[15:01:00]
<john> (and if so, weep into a randomly selected bash script)
[15:02:16]
<john> predictably debian is way behind - composer 2.0 (seemingly not even the 2.2 LTS version) rather than anything close to latest (eg, 2.5.x)
[15:02:39]
<john> anyway, I'll try this later and see how it goes :D
[15:03:12]
<Aleks (he/him/il/lui)> uuuh yeah that goes beyond my knowledge i think haha, i'm not super familiar with composer
[15:03:18]
<john> me neither :D
[15:03:23]
<john> I'll experiment and report my findings
[15:03:31]
<john> when i'm off my work laptop prison