| lordievader | Good morning | 08:55 |
|---|---|---|
| MJCD_ | hey all | 09:49 |
| MJCD_ | i'm still on a CLI based quickmenu style thing | 09:49 |
| MJCD_ | a basic gui that probably implements menu.lst or w/e | 09:49 |
| MJCD_ | but for the command line, there were many pre-windows things like this | 09:50 |
| MJCD_ | searching it I only really find "install xorg" | 09:50 |
| MJCD_ | and that's not at all what i'm after | 09:50 |
| thelounge7666 | I'm still having an issue where systemd-networkd will not re-aquire an IP address if the link goes down, even after restarting the service. only a reboot works. any thoughts? | 11:53 |
| === genii_ is now known as genii | ||
| rbasak | ahasenack: do we understand enough about bug 1865900 to mark it Triaged? I think we do? | 17:42 |
| ubottu | bug 1865900 in apache2 (Ubuntu) "apache 2.4.29-1ubuntu4.12 authentication with client certificate broken" [Undecided,Incomplete] https://launchpad.net/bugs/1865900 | 17:42 |
| teward | rbasak: mind if I take a look at that? | 17:46 |
| teward | because i've been doing client auth stuff regularly currently and might be able to provide insight/debugs | 17:46 |
| teward | on ${MULTIPLE_SOFTWARE_ENDPOINTS) | 17:46 |
| teward | rbasak: is it possible that the issue isn't Apache side? (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1834671 is linked by mdeslaur) | 17:47 |
| ubottu | Launchpad bug 1834671 in firefox (Ubuntu Eoan) "TLSv1.3 client certificate authentication with renegotiation unsupported in browsers" [Undecided,Fix released] | 17:47 |
| rbasak | teward: indeed | 17:53 |
| rbasak | I just wanted it out of Incomplete status :) | 17:53 |
| teward | rbasak: well if the issue is $CLIENT and not $SERVER then it's Invalid for Apache | 17:54 |
| teward | not Triaged. | 17:54 |
| teward | unless i'm missing something? | 17:54 |
| teward | (has Apache2 been rebuilt against OpenSSL 1.1.1?) | 17:54 |
| sdeziel | teward: yes, rebuilt after having TLS 1.3 support backported to Bionic | 17:55 |
| ahasenack | rbasak: just saw your ping now | 18:24 |
| ahasenack | teward: I think it's not an apache issue, unless we are willing to disable TLS 1.3 | 18:24 |
| ahasenack | which defeats the point of the SRU that brought it in | 18:24 |
| teward | ahasenack: well for nginx | 18:24 |
| teward | in the SRU we *disabled* NGINX TLS 1.3 by default by simply rebuilding against SSL | 18:25 |
| ahasenack | well, apache had an sru specifically to enable tls1.3, with backported patches and all | 18:25 |
| teward | yeah i'd nACK that | 18:25 |
| teward | a similar SRU came in for NGINX | 18:25 |
| teward | to enable 1.3 by default | 18:26 |
| teward | and we NACK'd that | 18:26 |
| ahasenack | that's the only remaining reason to have an apache task: if we want to revert that | 18:26 |
| ahasenack | rbasak: ^ | 18:26 |
| ahasenack | if not, then we will need tasks for all clients that broke | 18:26 |
| ahasenack | the fix for that could be to implement pha, or not not use tls1.3 when doing certificate auth | 18:27 |
| ahasenack | s/not not/to not/ | 18:27 |
| teward | ahasenack: with nginx, we simply disabled TLS1.3 in the ssl_protocols - is there a way to do that in Apache, that is keep TLS1.3 support but disable it on the default available protocols | 18:35 |
| teward | that way users can still *enable* TLS1.3 but on a selective basis instead of by default | 18:35 |
| teward | I had extensive discussion with mdeslaur and rbasak and sarnold on this from a security perspective | 18:35 |
| teward | and we decided to not backport the TLSv1.3 enablement | 18:36 |
| teward | (but compile nginx against TLS1.3 so we can allow availability) | 18:36 |
| mdeslaur | I don't think we should revert tlsv1.3 just for the few uses of client side certs | 18:37 |
| ahasenack | teward: maybe if it's removed from the "ALL" keyword | 18:37 |
| rbasak | I just wanted to get past triage! | 18:37 |
| rbasak | Can I mark it New again at least, pending further discussion? | 18:37 |
| ahasenack | rbasak: if you mark it new, it will get back into triage | 18:37 |
| teward | ahasenack: well replace "ALL" with -SSLv2 -SSLv3 +TLS1.0 +TLS1.1 +TLS1.2 for the defaults | 18:37 |
| teward | which is, you know, what we do in nginx-conf | 18:38 |
| teward | because otherwise it defaults to "ALL" behind the scenes | 18:38 |
| teward | which for obvious reasons is "Bad" | 18:38 |
| ahasenack | if pha is part of tls1.3, and some client can't do pha, then that client should perhaps have tls 1.3 removed from its list of protocols it can speak | 18:38 |
| ahasenack | since it can't, fully | 18:38 |
| mdeslaur | well then firefox and chromium would get tlsv1.3 removed :P | 18:41 |
| ahasenack | these clients would break if they talked to an apache server out there that didn't come from ubuntu. They might break if they talk to apache from focal, right? In the same way | 18:41 |
| ahasenack | mdeslaur: at least firefox supports pha, I haven't checked if anything changed in the chromium side | 18:42 |
| ahasenack | last I looked they were waiting for some spec | 18:42 |
| mdeslaur | ahasenack: not by default, you have to enable it in settings because it breaks http2 | 18:42 |
| ahasenack | mdeslaur: ah, that was chromium's wait iirc | 18:42 |
| mdeslaur | client side certs aren't common enough for them to care about it | 18:43 |
| mdeslaur | and the workaround to disable tlsv1.3 on the server works | 18:43 |
| ahasenack | ok, my point is that the same bionic client who fails to do post-handshake-auth in tls1.3 with client certs while talking to the new apache shipped with bionic, will also break when talking to a random web server out there who also offers tls v1.3 | 18:44 |
| mdeslaur | yes | 18:44 |
| ahasenack | but there was a change in behavior | 18:45 |
| ahasenack | "stuff was working inside my local net; update apache, stuff broke" | 18:45 |
| rbasak | ahasenack: back into triage> that's OK - I tagged it server-next, so we can just treat it in our backlog - further triage doesn't really matter then, except to respond to further comments | 18:48 |
| ahasenack | rbasak: what do you think about the bug being on the server and the client? The quick discussion above | 18:48 |
| rbasak | I agree it's a regression | 18:48 |
| rbasak | But equally sometimes we decide to not fix regressions. When it's complicated. This is complicated :-( | 18:49 |
| === jge is now known as ezpeezy | ||
| === ezpeezy is now known as kahuna | ||
| === kahuna is now known as ezpeezy | ||
| === y0sh_ is now known as y0sh | ||
| === y0sh_ is now known as y0sh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!