| Eickmeyer | Probably not a bug as the mentality there is, "They don't seriously have a blank password if they're locking the screen." | 00:01 |
|---|---|---|
| * arraybolt3 watches tsimonq2 write a patch for XScreenSaver out of thin air | 00:05 | |
| arraybolt3 | tsimonq2: Keep in mind that, as far as restricting the user's freedom of choice, a user who wants to set a blank password is free to edit the configuration in /etc/calamares to do whatever they want. Nothing we choose here is something they can't override. | 00:09 |
| arraybolt3 | It just sets a default that keeps them from harming themselves in multiple ways. | 00:09 |
| arraybolt3 | Even if we can fix XScreenSaver, I still feel like it would be better to enforce a password by default. Sure, we want the user to do things as they see fit, but if we know something is usually a bad idea, there's no harm in guiding them away from that and letting them override us if they think they know better for their use case. | 00:10 |
| arraybolt3 | Grief. I just actually took a look inside passwd.c in XScreenSaver, and... no. That is a nightmare. | 00:53 |
| arraybolt3 | Plus jwz apparently isn't well-known for descriptive variable or function names... | 00:53 |
| arraybolt3 | At least not always. | 00:54 |
| arraybolt3 | I *think* (not sure) that it uses PAM thought. | 00:56 |
| arraybolt3 | *though | 00:56 |
| arraybolt3 | Possibly could be related to PAM configuration and "nullok"? | 00:57 |
| Eickmeyer | This is *quite* the rabbit hole for this late in the cycle. | 00:57 |
| arraybolt3 | Agreed, but Simon is the release manager. If he doesn't want us to enforce a password by default, and we don't have a council vote to say otherwise, then alternative solutions are possibly good. | 00:59 |
| arraybolt3 | (And I'm not about to be the one to ask for us to vote on it :P) | 00:59 |
| Eickmeyer | In the meantime, I'm not happy because Studio is left hanging with what I consider a security bug. | 01:00 |
| arraybolt3 | I wish Simon was still around though - I don't see him on Matrix at the moment. | 01:00 |
| Eickmeyer | And even if the Lubuntu part isn't included, both have to be respun. | 01:00 |
| arraybolt3 | That's true. | 01:00 |
| arraybolt3 | Well, in the mean time, I have to go take care of the animals. I'll be back soon, most likely. | 01:01 |
| arraybolt3 | OK back. | 01:07 |
| arraybolt3 | Sigh. I said I wasn't going to ask for a vote, but if Simon's no longer around and we need to do something... | 01:15 |
| arraybolt3 | I'll make sure that Ubuntu Desktop does indeed prohibit a blank password. If it does, I think that's more reason to enforce it in Lubuntu. | 01:16 |
| arraybolt3 | Otherwise we're going to be the only flavor that allows this unsafe configuration by default, and it looks like it may require relaxing more security settings elsewhere in the system in order to make it work right, which I think is a really bad idea. | 01:22 |
| arraybolt3 | Confirmed, you do indeed *need* to provide a password. | 01:22 |
| arraybolt3 | For Ubuntu Desktop with the Flutter installer. | 01:22 |
| Eickmeyer[m] | I confirmed it with jbicha as well. | 01:39 |
| arraybolt3 | I'm waiting on input from the rest of the Council at the moment. If voted in, I'll ask for it to be accepted. | 01:40 |
| guiverc | thanks tsimonq2 | 11:19 |
| tsimonq2 | No worries | 11:38 |
| -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Lunar Final] has been updated (20230417) | 17:36 | |
| Eickmeyer | Everyone: I'm of 1/2 a mind to security SRU bug 2016436 into Jammy. | 18:05 |
| -ubottu:#lubuntu-devel- Bug 2016436 in calamares-settings-ubuntu (Ubuntu) "Calamares will let you set up a user account with no password" [Critical, Fix Released] https://launchpad.net/bugs/2016436 | 18:05 | |
| Eickmeyer | Wouldn't take effect until 22.04.3, but still... | 18:06 |
| arraybolt3 | Eickmeyer: I don't think the bug affects Jammy. | 19:29 |
| Eickmeyer | Would have to test, but I'd almost bet it does. | 19:29 |
| tsimonq2 | -1 for the security pocket, subject to override by the Security Team. | 19:35 |
| Eickmeyer | tsimonq2: You and I agree on a lot, but security is one area where I'm not willing to compromise user choice. I'm sure teward would agree with me on this one. | 19:37 |
| teward | sounds like you need me to make a choice | 19:38 |
| teward | :P | 19:38 |
| Eickmeyer | teward: Apparently we (both Lubuntu and Ubuntu Studio) have been letting Calamares let the user install without a password, which IMO compromises the security of the installed system. | 19:38 |
| Eickmeyer | Fixed for 23.04 but we don't know if the LTS has been letting that happen all along or not. Yet to investigate. | 19:39 |
| tsimonq2 | I still consider it a UX regression, and if the user wants to install without a password (like every other major platform) they should be warned but not stopped | 19:39 |
| Eickmeyer | Ubiquity has *never* allowed zero password, and ubuntu-desktop-installer doesn't either. | 19:39 |
| Eickmeyer | All for security reasons. | 19:40 |
| Eickmeyer | Security > UX | 19:40 |
| tsimonq2 | I still don't think it's a security bug | 19:41 |
| teward | then you're not aware of how MITRE processes passwords | 19:42 |
| tsimonq2 | And how is that, exactly? | 19:42 |
| teward | CWE-20 | 19:42 |
| teward | https://owasp.org/www-community/vulnerabilities/Empty_String_Password | 19:42 |
| teward | CWE-258 | 19:42 |
| teward | https://cwe.mitre.org/data/definitions/258.html | 19:42 |
| teward | others | 19:43 |
| teward | so the vulnerability of *allowing* empty or nonexistent passwords is a violation of at least one CWE | 19:43 |
| teward | if this doesn't have a CVE yet it should get one | 19:43 |
| Eickmeyer | teward: Have at it. bug 2016436 | 19:44 |
| -ubottu:#lubuntu-devel- Bug 2016436 in calamares-settings-ubuntu (Ubuntu) "Calamares will let you set up a user account with no password" [Critical, Fix Released] https://launchpad.net/bugs/2016436 | 19:44 | |
| tsimonq2 | If you're confident this qualifies, fine, but a) I'm not volunteering for any paperwork and b) every other platform might as well have a CVE too | 19:44 |
| teward | c) Security team handles CVEs | 19:45 |
| teward | tsimonq2: if this is a configurable *option* or gives a warning about risk and user has to accept the risk, that mitigates the CWE | 19:45 |
| teward | but simply *allowing* it without any notice is a badness | 19:45 |
| teward | same for weak passwords - it shows "weak password" in all the installers currently so you KNOW you're using a weak pw | 19:45 |
| teward | thereby leaving it to the user to *accept* that it's a weak pw or such | 19:45 |
| teward | no password is the weakest :p | 19:46 |
| tsimonq2 | I'm in favor of a user warning and would definitely write that code, what I'm not in favor of is completely disallowing blank passwords even if the user explicitly wants it | 19:47 |
| Eickmeyer | *sigh* Well, Ubuntu Studio will not be using Calamares in 23.10 and later. Even if I can't get the new installer figured-out, we'll be going back to Ubiquity and use the GTK version. | 19:50 |
| Eickmeyer | I'm just tired of this stuff popping up. | 19:50 |
| tsimonq2 | Your call, we'll still be on Calamares for the foreseeable future. | 19:53 |
| Eickmeyer[m] | <tsimonq2> "If you're confident this..." <- I can do the SRU paperwork, and since it's a security issue, I'll involve the security team. | 19:58 |
| arraybolt3 | Eickmeyer[m]: I'd really recommend testing before doing all that :) | 20:04 |
| arraybolt3 | Remember we had a *major* Calamares version upgrade in Kinetic. | 20:04 |
| arraybolt3 | Focal did *not* allow blank passwords. | 20:05 |
| arraybolt3 | And I think Jammy probably won't either. | 20:05 |
| arraybolt3 | (I'd test but other stuff is in the way over here so...) | 20:05 |
| Eickmeyer | arraybolt3: Yes, obviously. | 20:05 |
| Eickmeyer | I've got stuff in the way as well. | 20:05 |
| arraybolt3 | Sigh. Maybe there's some way us and Studio can come to an agreement on what we will and won't do with Calamares so we can both keep using it? I have an installation of Studio over here that would have been either impossible or very difficult to do with Ubiquity that was actually doable with Calamares. | 20:08 |
| arraybolt3 | And I hate Ubiquity, like, a lot as far as installers go. | 20:08 |
| Eickmeyer | Everyone: Jammy does allow a blank password. | 20:15 |
| arraybolt3 | #WellThatStinks | 20:15 |
| arraybolt3 | OK, SRU and CVE it is. And we should add instructions to test for this sort of thing to our testcases. | 20:16 |
| arraybolt3 | Other Ubuntu flavors have password requirement testing as part of the testcases, but Lubuntu's testing system doesn't really use the ISO tracker test cases since we have more complex requirements. And it appears this slipped through. | 20:17 |
| Eickmeyer | Well, it's possible that the password requirement was *intentionally omitted*. Still waiting on a response from the security team. | 20:18 |
| arraybolt3 | That I do not know. I wasn't around for the initial Jammy release. | 20:19 |
| arraybolt3 | (If this had started in Kinetic, I would know it wasn't intentional because it would have been my fault in porting over the Calamares config to the newer version. But in Jammy, no clue there.) | 20:19 |
| Eickmeyer | Not your fault. Don't worry about Kinetic, it has 3 months of life left and we can't exactly respin, nor are we expecting a point release for it. 22.04.3 is an eventuality, though. | 20:20 |
| arraybolt3 | Glad we found it and are getting it fixed. | 20:22 |
| arraybolt3 | (One more thought I just had is that a passwordless, sudo-enabled account on Linux has more far-reaching consequences than a passwordless administrator account on Windows. If a command asks for admin privileges on Windows, UAC still requires that the user provide that permission, even if it can be given my just pressing a button. On Linux, a malicious program could just fire up "sudo" and be | 20:28 |
| arraybolt3 | in.) | 20:28 |
| arraybolt3 | *by, not my | 20:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!