[00:20:05]
<ilarioq> Bonjour! Est ce que l'application uMap est encore disponible ? Oui selon le site web de uMap mais je la trouve pas dans le site yunost. Merci bcp.
[00:23:23]
<Aleks (he/him/il/lui)> y'a https://github.com/YunoHost-Apps/umap_ynh mais qui est un peu en travaux ces derniers jours je crois, je sais plus ce qu'il en est vraiment
[01:16:06]
<ilarioq> Aleks (he/him/il/lui): merci
[06:32:02]
<y4suke> Dans les diagnostics mail, j'ai cette erreur :
Votre IP ou domaine XXX est sur liste noire sur Spamhaus ZEN. La raison de la liste noire est : "Listed by CSS, see https://check.spamhaus.org/query/ip/XXX" Après avoir identifié la raison pour laquelle vous êtes répertorié sur cette liste et l'avoir corrigée, n'hésitez pas à demander le retrait de votre IP ou de votre domaine sur https://www.spamhaus.org/zen/
Quelle est la bonne résolution ? Désactiver l'ipv6 pour le mail ?
[06:59:40]
<@err404:matrix.numericore.com> Non, il y a un formulaire à remplir sur le site spamhaus, à refaire chaque année
[07:01:42]
<@err404:matrix.numericore.com> Je ne comprends pas pourquoi les gens ont tendance à vouloir désactiver ipv6 alors que la plupart du temps les problemes viennent de l'ipv4 public avec du NAT
[07:05:26]
<y4suke> C'est le formulaire que j'ai en premier dans le message d'erreur, n'est-ce pas ?
Mais comme je n'ai rien fait pour corriger, je mets quoi dans "Please provide details on how and when the issue was resolved" ?
[09:17:08]
<@err404:matrix.numericore.com> je ne sais pas, je ne fais pas d'email, donc je laisse spamhaus faire de la merde avec nos ip résidentielles, en laissant spamhaus sans rien faire on se prend un malus dans la note pour la detection des spams, c'est tout
[11:56:40]
<m606> Le NAT peut poser pb pour l'envoi d'emails spécifiquement?
[12:42:38]
<2plig> Hello (and merry Christmas) everyone. If someone here has some knowledge, I'd like help in understanding some things about NGINX. I am looking into this issue of Calibre-Web on Ynh. https://github.com/YunoHost-Apps/calibreweb_ynh/issues/160.
Basically, Auth in case of OPDS with Calibre-Web app does not work. This is what the logs say, in this case:
```
WARN {cps.usermanagement:56} OPDS Login failed for user "" IP-address: xxx.xxx.xxx.xxx
```
So, no matter what user and pw you try to auth with, to Calibre Web, the user looks like empty string.
The only way to use OPDS as of now is to allow anonymous browsing (in which case, the only security you have is on the network layer, e.g. a VPN, if you have any).
I'm trying to understand how it can happen.
[12:51:55]
<2plig> I know that CW uses this Flask plugin for auth https://pypi.org/project/Flask-HTTPAuth/. This is how this lib is getting the credentials from request. https://github.com/miguelgrinberg/Flask-HTTPAuth/blob/main/src/flask_httpauth.py#L75
```
def get_auth(self):
auth = None
if self.header is None or self.header == 'Authorization':
auth = request.authorization
if auth is None and \
'Authorization' in request.headers: # pragma: no cover
# Flask/Werkzeug versions before 2.3 do not recognize any
# authentication types other than Basic or Digest, so here we
# parse the header by hand
try:
auth_type, token = request.headers['Authorization'].split(
None, 1)
auth = Authorization(auth_type)
auth.token = token
except (ValueError, KeyError):
# The Authorization header is either empty or has no token
pass
elif self.header in request.headers:
# using a custom header, so the entire value of the header is
# assumed to be a token
auth = Authorization(self.scheme)
auth.token = request.headers[self.header]
# if the auth type does not match, we act as if there is no auth
# this is better than failing directly, as it allows the callback
# to handle special cases, like supporting multiple auth types
if auth is not None and auth.type.lower() != self.scheme.lower():
auth = None
return auth
```
[12:57:56]
<geoma https://eticadigital.cl> Bonjour! I have a backdrop module (CiviCRM) that needs bcmath. I have installed bcmath through `apt install php-bcmath`, but it still isn't available. Do I have to edit a php.ini file or something like that?
[12:59:33]
<orhtej2> > <@geoma:matrix.org> Bonjour! I have a backdrop module (CiviCRM) that needs bcmath. I have installed bcmath through `apt install php-bcmath`, but it still isn't available. Do I have to edit a php.ini file or something like that?
Phpsomeversion-bcmath
[13:00:20]
<2plig> Is there anything the Nginx is doing in case of Ynh that would cause these headers to become empty or not present at all?
Just for additional context: I tested this behaviour with two OPDS clients (Yomu and Thorium(. The user who originally reported this bug - reported it in Koreader. So I am quite assured that the clients are forming the header correctly. Also, for me this bug first appeared some time in the summer/spring 2024, until then the OPDS auth was working well.)
[13:00:34]
<orhtej2> Php8.4-bcmath
[13:00:58]
<2plig> Is there anything the Nginx is doing in case of Ynh that would cause these headers to become empty or not present at all?
Just for additional context: I tested this behaviour with two OPDS clients (Yomu and Thorium). The user who originally reported this bug - reported it in Koreader. So I am quite assured that the clients are forming the header correctly, it seems not likely that multiple clients would have the same problem. Also, for me this bug first appeared some time in the summer/spring 2024, until then the OPDS auth was working well.)
[13:01:06]
<orhtej2> Based on php from package: https://github.com/YunoHost-Apps/backdrop_ynh/blob/bc5c61cbaf1d3e0e89e560bb31c528f69825efd0/manifest.toml#L60
[13:02:10]
<2plig> Is there anything the Nginx is doing in case of Ynh that would cause these headers to become empty or not present at all?
Just for additional context: I tested this behaviour with two OPDS clients (Yomu and Thorium). The user who originally reported this bug - reported it with Koreader. So I am quite assured that the clients are forming the header correctly, it seems not likely that multiple clients would have the same problem. Also, for me this bug first appeared some time in the summer/spring 2024, until then the OPDS auth was working well.)
[13:02:10]
<orhtej2> > Hello (and merry Christmas) everyone. If someone here has some knowledge, I'd like help in understanding some things about NGINX. I am looking into this issue of Calibre-Web on Ynh. https://github.com/YunoHost-Apps/calibreweb_ynh/issues/160.
> Basically, Auth in case of OPDS with Calibre-Web app does not work. This is what the logs say, in this case:
> ```
> WARN {cps.usermanagement:56} OPDS Login failed for user "" IP-address: xxx.xxx.xxx.xxx
> ```
> So, no matter what user and pw you try to auth with, to Calibre Web, the user looks like empty string.
> The only way to use OPDS as of now is to allow anonymous browsing (in which case, the only security you have is on the network layer, e.g. a VPN, if you have any).
> I'm trying to understand how it can happen.
Ynh eats authorization header
[13:02:34]
<orhtej2> there's a switch to disable that behavior
[13:02:44]
<orhtej2> needs to be fixed in package
[13:05:22]
<2plig> Is there a reason why? Security implications? (I guess if the connection is not encrypted and someone is MITMing, they will have the header anyway, since the client transmits it...)
[13:16:20]
<2plig> I think I found the relevant doc https://doc.yunohost.org/en/dev/packaging/advanced/sso_ldap_integration/, but I am a bit confused:
- in the table https://doc.yunohost.org/en/dev/packaging/advanced/sso_ldap_integration/#sso-integration it says that the basic auth header will be passed to the application.
- but below the table it says to set `protect_against_basic_auth_spoofing -v false` (and then reload ssowat config and nginx)
[13:19:31]
<2plig> And I still don't totally understand the the attack scenario that this setting is trying to prevent. The table says
> Protected over header injection from clients (a client try with a request to override the header and be logged in with a different user)
and this is "No" for basic auth.
But if Bob is trying to do this attack, Bob will have to know Alice's credentials to start with. Then he could just log in as Alice and do what he wants.
[13:20:35]
<2plig> And I still don't totally understand the the attack scenario that this setting is trying to prevent. The table says
> Protected over header injection from clients (a client try with a request to override the header and be logged in with a different user)
and this is "No" for basic auth.
But if Bob is trying to do this attack, Bob will have to know Alice's credentials to start with. Then he could just log in as Alice (through the web sso, for example) and do what he wants.
[13:21:53]
<2plig> And I still don't totally understand the the attack scenario that this setting is trying to prevent. The table says
> Protected over header injection from clients (a client try with a request to override the header and be logged in with a different user)
and this is "No" for basic auth.
But if Bob is trying to do this attack and pretend he is Alice, Bob will have to know Alice's credentials to start with. Then he could just log in as Alice (through the web sso, for example) and do what he wants.
[13:36:00]
<2plig> Also, this is more for curiosity: I am currently using Nextcloud, with WebDAV and Subsonic APIs. Both work with Basic Auth, and I never had to set this switch myself, as far as I remember. The installation scripts, as far as I can see, do not set this setting anywhere. But there is this line in manifest: https://github.com/YunoHost-Apps/nextcloud\_ynh/blob/18abdaf81f41c376db689a3ea6fcae33d304d1cc/manifest.toml#L120
```
[resources.permissions]
main.url = "/"
api.url = "re:__DOMAIN__\\/.well-known\\/.*"
api.auth_header = false
```
Does it do the same?
[13:37:13]
<2plig> Also, this is more for curiosity: I am currently using Nextcloud, with WebDAV and Subsonic APIs. Both work with Basic Auth, and I never had to set this switch myself, as far as I remember. The installation scripts, as far as I can see, do not set this setting anywhere. But there is this line in manifest: https://github.com/YunoHost-Apps/nextcloud\_ynh/blob/18abdaf81f41c376db689a3ea6fcae33d304d1cc/manifest.toml#L120
```
[resources.permissions]
main.url = "/"
api.url = "re:__DOMAIN__\\/.well-known\\/.*"
api.auth_header = false
```
Does it do the same? If not, how does this work in Nextcloud's case?
[13:38:19]
<2plig> Don't get me wrong - I am very grateful for advice. :) I just want to understand, exactly what protection I am switching off, before I switch it off.
[14:49:08]
<orhtej2> sorry, was on mobile.
- `api.auth_header` - yunohost will by default on SSOWat level (somewhere in Nginx internals) add/replace `Authorization` header with `Authorization: Basic user:base64_of_plaintext_password` if you're logged in, hence the proxied app will get basic authorization level as if you've logged in as current YNH user with current password. This setting, when set to false, disables this behaviour
- if the above is false YNH will strip `Authorization` header altogether. This can be turned off by setting the aforementioned `protect_against_basic_auth_spoofing` and regenerating ssowat config. Do this if the app you're setting up relies on client passing `Authorization` header
[14:50:22]
<orhtej2> so for Nginx we pass user:pass to provide SSO functionality as Nextcloud uses LDAP as identity provider, but disable this functionality for well-known path because of reasons (IDK why)
[14:50:41]
<orhtej2> 2plig: ^
[14:51:54]
<orhtej2> as for the issue with calibre-web the package should disable `Authorization` stripping for relevant path(s)
[14:53:23]
<orhtej2> cf [this Castopod fixup](https://github.com/YunoHost-Apps/castopod_ynh/pull/193/files)
[15:17:01]
<geoma https://eticadigital.cl> Ok. Will try. Thanks!
[15:33:50]
<geoma https://eticadigital.cl> I tried installing php8.2-bcmath because with `php -v` I get I am using v 8.2, but it says it is already installed. Should I install another version? how to know which one?
[15:40:59]
<orhtej2> > <@geoma:matrix.org> I tried installing php8.2-bcmath because with `php -v` I get I am using v 8.2, but it says it is already installed. Should I install another version? how to know which one?
Php 8.4 as this is what backdrop is using
[15:41:47]
<orhtej2> You can check from app shell what php version the app is using
[17:22:49]
<2plig> orhtej2 wait, so, what happens if api.auth_header=True, but protect_against_basic_auth_spoofing is also true? SSOWat will set the header, and then strip it? :)
[17:30:04]
<2plig> Because my understanding is that for non-well-known paths (like for example `yunohostinstance.domain/nextcloud/remote.php/dav/files/USERNAME`) this is precisely the situation. (api.auth\_header is not false, and protect\_against\_basic\_auth\_spoofing=false is not set anywhere).
[17:41:41]
<2plig> It would make sense if this did not work for Nextcloud Webdav, and also did not work for Calibre-web OPDS.
[17:41:56]
<2plig> Because my understanding is that for non-well-known paths (like for example `yunohostinstance.domain/nextcloud/remote.php/dav/files/USERNAME`) this is precisely the situation. (api.auth\_header is not false, and protect\_against\_basic\_auth\_spoofing=false is not set anywhere).
It would make sense if this did not work for Nextcloud Webdav, and also did not work for Calibre-web OPDS.
[17:43:24]
<2plig> Because my understanding is that for non-well-known paths (like for example `yunohostinstance.domain/nextcloud/remote.php/dav/files/USERNAME`) this is precisely the situation. (api.auth\_header is not false, and protect\_against\_basic\_auth\_spoofing=false is not set anywhere).
It would make sense if this did not work for Nextcloud Webdav, and also did not work for Calibre-web OPDS. Because calibreweb_ynh is also the same (they are not setting either option anywhere).
[17:51:16]
<geoma https://eticadigital.cl> Sorry, What is app shell?
[17:53:42]
<2plig> run `yunohost app shell APP_ID`, this drops you into a shell session in the app's install dir
[17:53:53]
<2plig> run `yunohost app shell APP_ID`, this drops you into a shell session in the app's install dir and its environment/user/etc
[17:54:53]
<2plig> run `yunohost app shell APP_ID` (you can get the id from `yunohost app list`), this drops you into a shell session in the app's install dir and its environment/user/etc
[17:56:58]
<2plig> run `yunohost app shell APP_ID` (you can get the id from `yunohost app list`), this drops you into a shell session in the app's install dir and its environment, user, etc
[17:57:19]
<2plig> run `yunohost app shell APP_ID` (you can get the id from `yunohost app list`), this drops you into a shell session in the app's install dir and its environment, etc and you run the commands as the app user
[18:05:32]
<geoma https://eticadigital.cl> Wow! Great to know. Thanks!!
[18:09:37]
<eric_G> I can' see any permission set for Rspam (doesn't seem to have any `system_user` set in the manifest) -> https://github.com/YunoHost-Apps/rspamd_ynh/blob/master/manifest.toml
[18:11:53]
<eric_G> added it to [helper v2.1 version](https://github.com/YunoHost-Apps/rspamd_ynh/pull/29/changes#diff-06ac558c9cfca9e31a9a235f18d98e6d0c3bfee8bee0088108a29f2c60b318e3R53) but I am not sure about it...
[18:11:56]
<Aleks (he/him/il/lui)> hmyeah it's not a webapp so it doesnt need any permission or whatev
[18:12:23]
<Aleks (he/him/il/lui)> and the system user is created by the .deb or something
[18:13:02]
<eric_G> ah! so I can't use `ynh_config_add` ...
[18:14:58]
<Aleks (he/him/il/lui)> merf i suppose that's why the install script uses cp instead of ynh_config_add
[18:16:01]
<Aleks (he/him/il/lui)> (and anyway the config files probably need to be owned by root or something)
[18:16:02]
<eric_G> with `cp` I had this error -> https://ci-apps-dev.yunohost.org/ci/job/14937
[18:17:37]
<Aleks (he/him/il/lui)> that issue is from `ynh_config_add_logrotate`
[18:18:10]
<Aleks (he/him/il/lui)> meaning uuuuh ynh_config_add seems to work ?
[18:18:35]
<Aleks (he/him/il/lui)> ah no it was still `cp` in that version
[18:19:17]
<Aleks (he/him/il/lui)> so hmmm apparently `ynh_use_logrotate` in helpers 2.0 was working but not `ynh_config_add_logrotate` in 2.1 merf
[18:20:28]
<2plig> Aleks (he/him/il/lui) - since you're here and I saw you commented on this topic on some older forum posts for other apps. Do you maybe understand what kind of attack scenario the basic-header-stripping behavior in ssowat was supposed to prevent? The comments in code describe it in quite strong terms https://github.com/YunoHost/SSOwat/blob/dev/access.lua#L259
```
-- 5. CLEAR USER-PROVIDED AUTH HEADER
--
-- Which could be spoofing attempts
--
-- Apps can opt out of the auth spoofing protection using the setting
-- 'protect_against_basic_auth_spoofing' set to false if they really need to,
-- but that's a huge security hole and ultimately should never be done...
```
[18:23:37]
<Aleks (he/him/il/lui)> the attack it's meant to prevent is if an attacker tries to spoof the authorization header, by hitting the server with a crafter HTTP request, something along the lines of
```
curl -H "Authorization: <base64(alice:)>" https://domain.tld/...
```
with `<base64(alice:)>` being the base64 encoding of "alice" and "empty string" separated by `:` which is how the basic auth header thingy works, and in some scenarios, the app would just blindly trust this info from the client (in this case a malicious one who is not actually alice) hence disaster
[18:24:22]
<2plig> hold up, there are apps that receive the basic auth header... and do not do any password check? wtf?
[18:24:31]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[18:24:39]
<eric_G> yes, commenting `ynh_config_add_logrotate` solves the issue...
[18:25:22]
<2plig> I mean, the "wtf" is not targeted at you, rather at the developer of such an app who I cannot imagine
[18:25:51]
<eric_G> but, that is not a fix. 😶🌫️
[18:27:16]
<Aleks (he/him/il/lui)> yes, but it's not as simple as "the app should do the password check", some apps do support SSO-integration but not LDAP, so they wouldnt know how to check the password, and you could argue that they shouldnt even need to, because, technically, the SSO purpose is also to externalize the "authentication / authorization" mechanism from the app, such that the authentication happens elsewhere (where it's centralized), and then the app just needs to receive the info of "who is the authenticated user" and to be able to trust this info somehow
[18:28:15]
<Aleks (he/him/il/lui)> so the point is that the middleware (SSOwat) should drop any incoming `Authorization` header from the client, such that only the middleware (SSOwat) sets this info, and therefore can be trusted by the app
[18:28:16]
<Aleks (he/him/il/lui)> but
[18:28:36]
<eric_G> permissions for log rotation v2 -> https://github.com/YunoHost/yunohost/blob/b91ab52deb47b942572790cc4b4b36b4b15ec365/helpers/helpers.v1.d/logrotate#L102-L105
[18:29:03]
<Aleks (he/him/il/lui)> in some cases, some apps do rely on "legit" cases where the client is expected to set the Authorization header itself, such as webdav thingies at least ... i think, not sure, i don't have clear picture of those use cases exactly
[18:29:18]
<eric_G> v2.1 -> https://github.com/YunoHost/yunohost/blob/b91ab52deb47b942572790cc4b4b36b4b15ec365/helpers/helpers.v2.1.d/logrotate#L47-L48
[18:40:38]
<2plig> Okay, the scenario is clear - thanks for explanation. And I also understand now after reading below in the SSOWat code, that the header that is being injected is not the user/pw but just the user (and the pw is dash). But then, I wonder why Calibre logs
```
WARN {cps.usermanagement:56} OPDS Login failed for user "" IP-address: xxx.xxx.xxx.xxx
```
- wouldn't it be the correct username, but with wrong password?
[18:45:27]
<2plig> or, in case of the request not from the browser (where there is session cookie) - it cannot tell who the user is (after having stripped the auth headers) and assumes him to be empty?
[18:46:37]
<Aleks (he/him/il/lui)> uuuh yes i suppose ? That would be consistent with the `for user ""` but usually the software would check that the user info is not empty before trying to check for auth or something idk
[18:46:41]
<Aleks (he/him/il/lui)> (i don't know the context)
[18:50:22]
<2plig> Oh yeah there is handling for this in Calibre-Web (the context in brief is that OPDS protocol auth does not work in calibre web ynh app, the GH issue is inactive, and I wanted to dig deeper into why this is going on). Getting no user is consistent with throwing the error that would cause this log entry before any password checks even take place.
[18:50:43]
<2plig> Oh yeah there is handling for this in Calibre-Web (the context in brief is that OPDS protocol auth does not work in Calibre-Web ynh app, the relevant GH issue is inactive, and I wanted to dig deeper into why this is going on). Getting no user is consistent with throwing the error that would cause this log entry before any password checks even take place.
[19:27:55]
<2plig> (and similarly to calibre, SSOWat would not have any cookie to get the headers from)
[19:28:56]
<2plig> I guess the only question remaining, for me at least, (sorry for repeating myself) is how Nextcloud's webdav works, as the ` protect_against_basic_auth_spoofing` is not set anywhere in https://github.com/YunoHost-Apps/nextcloud\_ynh as far as I can see
[19:34:09]
<Aleks (he/him/il/lui)> ah yes, i forgot about that bit
[19:34:16]
<Aleks (he/him/il/lui)> if you want to be horrified...
[19:34:29]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/src/app.py#L2043-L2060
[19:34:48]
<Aleks (he/him/il/lui)> and then line 2070
[19:37:38]
<2plig> ...oh
[19:37:46]
<2plig> well that would explain it :)
[19:38:51]
<2plig> I had a feeling that there was some kind of "special treatment" for nextcloud as it is a huge suite of stuff, but I was looking for it in ssowat repo.
[19:46:45]
<2plig> Anyway, thank you for the explanations Aleks (he/him/il/lui) !
When I was researching this permission, I stumbled on https://forum.yunohost.org/t/questions-about-protect-against-basic-auth-spoofing-security/32039, where someone was also asking for an explanation, and it went unanswered. Do you mind if I paste your explanation of the attack scenario there?
[19:54:17]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[23:41:04]
<geoma https://eticadigital.cl> it worked! thanks!!!