 wxl: If the lxqt-globalkeys code doesn't read XDG variables for us to load in our own config, go shriek at agaida and patch it in globalkeys. If it does, default settings in the normal XDG path
[00:29] <wxl> @tsimonq2: maybe it didn't at the time, but i'm not sure we didn't fix it that way
[00:29] <wxl> ^^ @The_LoudSpeaker that said, hold up a second
[01:41] <tsimonq2> Another nightly kicked off to confirm that we can call i386 officially "dead".
 @tsimonq2 well now that we fixed that CI ssl problem :P
[01:47] <tsimonq2> People on Twitter are freaking out.
 about i386 death?
[01:48] <tsimonq2> I had to clarify that this doesn't mean archive builds will stop.
 them freaking out on Twitter is old news 😛
 people need to read better
[01:48] <tsimonq2> People were thinking their 18.04 i386 machines will be broken.
[01:48] <tsimonq2> Yeah.
[01:48] <kc2bez> Squashed some concern on Telegram earlier too.
 well 18.04 still has i386 support
[01:48] <tsimonq2> I kind of lol'ed at https://twitter.com/ontobelli/status/1145811906441035777
 it won't lose it
[01:50] <tsimonq2> Right.
 TH
 TBH*
 Lubuntu works great on some older x64 systems
[01:50] <kc2bez> Should I tell that person on twitter I run Lubuntu on a Ryzen 2700X with 32G of RAM?
 we have some older amd64 systems that can't run standard Ubuntu but run Lubuntu
 Lubuntu now runs those research systems
[01:50] <tsimonq2> Exaaaactly.
 @wxl [<wxl> ^^ @The_LoudSpeaker that said, hold up a second], Sure. I will just make changes @tsimonq2 mentioned and wait. Won't arc diff.
[05:53] <lynorian> is manual partitioning borked on calamares currently?
[06:02] <lynorian> alright apport is borked on the actual calamares installer live environment
[06:08] <lynorian> alright saving this vm to disc
[08:21] <guiverc> lynorian, O
[08:22] <guiverc> sorry ..
[08:23] <guiverc> lynorian, s/ToDesktoaToLeft/ToDesktopToLeft/ in https://manual.lubuntu.me/F/keyboard_shortcuts.html - openbox_keyboard.rst   (I'll have to learn to do this myself)
[08:24] <guiverc> though tasks D17/D18 will cause this item not to work as documented, so it could be changed then maybe..
 @lynorian [<lynorian> is manual partitioning borked on calamares currently?], I am not sure if any of us has tested that since we got the image to install again.
 @guiverc [<guiverc> though tasks D17/D18 will cause this item not to work as documented, s …], Yeah. It will need to be changed. I will do it once we are clear about D18.
[16:10] <lynorian> thanks for the headsup
[16:25] <apt-ghetto> teward: You have read today the messages in the support channel concerning the keyfile?
[16:25] <apt-ghetto> https://irclogs.ubuntu.com/2019/07/02/%23lubuntu.html#t10:26
 That guy made a nice solve actually. Has he filled a bug report?
[16:27] <apt-ghetto> I don't know, but I am actually writing one
[16:28] <teward> apt-ghetto: i have now
[16:28] <teward> but as I don't use LUKS I'm not susceptible.  (my disks are actually hardware encrypted by another mechanism)
[16:28] <apt-ghetto> Against which package should I file the report? lubuntu-meta? initramfs-tools?
 you could file it against both and see what sticks.
[16:29] <apt-ghetto> And I check "This is a a security vulnerability"?
[16:29] <teward> does it have a CVE yet?
[16:30] <teward> if not you should mark it Private Security
[16:30] <teward> and probably prod #ubuntu-hardened
[16:30] <apt-ghetto> I didn't make a research
[16:30] <teward> given they stated it here
[16:30] <teward> let me make an inquirty amongst Security
[16:30] <teward> ]standby
[16:30] <apt-ghetto> Thanks
[16:38] <tsimonq2> i386 is gone in the CI
[16:38] <tsimonq2> What I did worked \o/
[16:38] <tsimonq2> apt-ghetto: Nice catch, by the way
[16:39] <apt-ghetto> Which one?
[16:39] <tsimonq2> LUKS
[16:40] <apt-ghetto> Yeah, this might be a real big problem or only a configuration issue
[16:40] <apt-ghetto> I didn't have the time to dig into
[16:41] <apt-ghetto> Maybe TJ- could say more about it
[16:47] <tsimonq2> apt-ghetto: Could you report this upstream too?
[16:47] <tsimonq2> To Calamares.
[16:47] <tsimonq2> They should be aware of it as well.
[16:49] <apt-ghetto> Yes, will do after submitting the launchpad bug
[16:54] <teward> apt-ghetto: so, this is only an issue if you have multiple users on-machine.  remotely you still can't breach it unless you have access to the machine anyways
 I think the OP reported it in cala yesterday.
[16:54] <teward> so the "risk" is lower
 I had trouble following at first but I get it now.
 I think you nailed it teward
 Someone already has machine access at that point.
[16:58] <teward> from a CVSS score perspective, it requires AV:L (local or physical access at least), AC:H (the complexity of the attack is not necessarily "simple" (I'd call it High Complexity)), PR:L (low privs necessary i.e. system access), UI:R (requires user interaction), S:C (it can affect everyone), C:H (high impact on confidentiality), I:H (high integrity impact), A:H (high availability impact)
[16:58] <teward> it comes to 7l.5, which is a higher risk, but exploitability of the risk is very low
[16:58] <teward> (0.8 by NIST standards)
[16:59] <teward> with a temporal score of 6.5, which comes to 7.2 overall, so to be fair, while the risk is 'higher' than some, it requires actual access somehow
[16:59] <teward> either remote access or physical access to the machine
[17:00] <teward> with a user on system (privreq: low, av: local/phsyical)
[17:00] <teward> so I'd say that while this IS a risk as it requires physical or otherwise pre-established access to the machine, THIS specific issue wouldn't go past a Medium in CVE importance
[17:00] <teward> and even then you have to be careful messing with LUKS :P
[17:01] <teward> i'd say this is a problem because of Cala but i can't deduce that specifically
[17:01]  * teward uses hardware level encryption rather than software disk encryption via LUKS
[17:02] <apt-ghetto> My DREAD rating:
[17:02] <apt-ghetto> Damage: HIGH => This attack allows to get the keyfile
[17:02] <apt-ghetto> Reproducibility: HIGH => Works every time with access to the system
[17:02] <apt-ghetto> Exploitability: MEDIUM => You must have access to a shell and the unencrypted device
[17:02] <apt-ghetto> Affected users: MEDIUM => Every user which uses Lubuntu 18.10 or newer in combination with FDE, maybe also other users
[17:02] <tsimonq2> FDE didn't work in 18.10.
[17:02] <tsimonq2> Only 19.04.
[17:02] <apt-ghetto> Discoverability: HIGH because it is logged publicly
[17:02] <tsimonq2> Anyway...
[17:03] <teward> so this is a 19.04+ issue only?
[17:03] <apt-ghetto> With end of support in july, I'd say, yes
 The init image is the issue. The keyfile itslf has the right permissions
 *itself
[17:04] <apt-ghetto> With any exploit in Firefox or Falkon or whatever, you can execute the attack and send the cryptofile to pastebin or something else
[17:05] <tsimonq2> teward: How do you do hardware encryption ooc?
 @tsimonq2 [<tsimonq2> teward: How do you do hardware encryption ooc?], +1
 everything that is sensitive sits on an external hardware-encrypted USB drive, it maintains its own crypto keys in its own internal chip storage not accessible outside of the device itself, and when in encrypted state before proper decryption codes are properly entered on the device itself, it is unreadable.
 i don't keep 'sensitive' info on the system itself
 Isn't BIOS password much easier and better? It will ask password on boot after POST. Won't even start any software. I like that.
[17:11] <teward> BIOS password doesn't necessarily provide encryption to the disk
[17:11] <apt-ghetto> @The_Loudspeaker =>  https://bios-pw.org/
 (Photo, 720x1280) https://i.imgur.com/XjMFKFN.jpg I meant setting all these.
 Supervisor, user and hdd. Also enable password on boot.
 @apt-ghetto> @The_Loudspeaker = [<apt-ghetto> @The_Loudspeaker =>  https://bios-pw.org/], What this? Which code is it asking?
 *it is
[17:15] <apt-ghetto> Does this encrypt your data? Does your UEFI has set a default password? Where is the password saved?
[17:16] <apt-ghetto> There are lists of default passwords for quite every BIOS
 @apt-ghetto [<apt-ghetto> Does this encrypt your data? Does your UEFI has set a default passw …], Idk.
 @apt-ghetto [<apt-ghetto> There are lists of default passwords for quite every BIOS], You mean there is a default supervisor password?
[17:19] <apt-ghetto> No, I mean there could be a default password for the version you use, but there might be also a design flaw or vulnerability in your UEFI, which is surely quite complex
 It doesn't encrypt. The passwords are stored on the same place where secure boot keys are stored I guess.
[17:33] <apt-ghetto> The bug report is sent
 I have a friend who likes to take pictures of where we live. Photos that unfortunately do not have the best resolution, because otherwise they could be used for some secondary wallpaper for free. They are here: … https://costadacaparica.wordpress.com/ … I can ask my son to try to take some picture like that in Full HD. But not in 4
[17:36] <lynorian> I am kind of sad that apport is borked
[17:46] <lynorian> in the installer
 @lynorian [<lynorian> I am kind of sad that apport is borked], Hi lynorian, could you please create a phab task or share the link, if there is one?
 I am not sure if it is broken in all ubuntu flavors though
 @lynorian is that the initramfs tools ou're talking about?
 1835095?
[18:34] <lynorian> don't think so
[18:35] <teward> bleh I meant apt-ghetto i can't read
[18:35]  * teward shoots self
[18:35] <teward> someone filed a bug on that sec risk issue
[18:35] <teward> it's being discussed in #ubuntu-hardened
 Yes, that‘s my bug report
[18:37] <teward> @aptghetto OK it seems this is an Lubuntu specific issue if i'm reading hardened right
 No, it should be 1835096
[18:37] <teward> hmm probably invisible
[18:38] <teward> but it LOOKS like this issue was reported in 1835095
[18:38] <teward> private sec would be Sec Team only though
 I think, it is from the original poster
[18:40] <teward> indeed.  came in a little late though if it was
[18:45] <teward> @aptghetto yours was duped to 1835095 :P
[18:45] <teward> @aptghetto it sounds more and more like this is a Calamares issue
[18:45] <teward> at least as I read the discussion in -hardened
[18:46] <wxl> you going to dig farther re: apport @lynorian ?
 I hope it is only a config issue, so that we can rely on FDE
[18:48] <wxl> @tsimonq2: re: teleirc, are images somehow not working on #lubuntu where they are here? i don't see the image that "David Groves" posted that @The_LoudSpeaker replied to
 @wxl [<wxl> @tsimonq2: re: teleirc, are images somehow not working on #lubuntu where t …], It's not an image. It's his message. He has a system without great specs but lubuntu is very unresponsive he says.
 message copied to IRC manually
[18:51] <wxl> i'm referring to the image
[18:51] <lynorian> wxl I was thinking of trying the main  ubuntu  iso
 there  was no image wxl
 there was a .txt file
 @lynorian [<lynorian> wxl I was thinking of trying the main  ubuntu  iso], Trying Main ubuntu image for?
 @teward001 [there was a .txt file], With his pc specs listed.
[18:52] <wxl>  @David Groves [<reply to image>], The specs are sound. There should be no problem. But wait for sometime. Others might be able to help. wxl: @kc2bez @aptghetto @teward001  ?
[18:52] <lynorian> see if apport works there
 but it was a txt not a file
[18:52] <wxl> that's what i mean
 s/file/image/
 wxl: it was a .txt file attachment
[18:52] <wxl> oh.
[18:52] <wxl> dumb.
 as i said twice now.
 *passes a cup of coffee to wxl to wake him up*
[18:56] <wxl> @lynorian: let me know what you find out
[18:59] <lynorian> wxl for what it is worth at elast apport works on the installed system
[18:59] <lynorian> doesn't work during the installer
[19:00] <wxl> @lynorian: not so good from a testing standpoint. is it installed in the live system?
[19:01] <lynorian> yes it is not recognizing any package as part of ubuntu
[19:02] <wxl> what about `dpkg-reconfigure` or maybe just an uninstall and reinstall?
[19:07] <lynorian> wxl wierd news the main ubuntu desktop doesn't have apport broken
[19:14] <wxl> @lynorian: same verion of apport and the dependencies of apport?
[19:16] <lynorian> yes same version of apport on both
[19:17] <tsimonq2> wxl: tl;dr two Cala CVEs found. See -hardened.
[19:17] <tsimonq2> wxl: FDE with Cala on 19.04 is messed up a bit.
[19:22] <wxl> @lynorian: what about the dependencies?
[19:23] <lynorian> depencies are the same
[19:23] <wxl> @tsimonq2: soooooooooooooo fix CVEs and we're fixed or what?
[19:23] <wxl> @lynorian: same versions though, right?
[19:23] <tsimonq2> wxl: Talking in #cala with [ade]
[19:23] <lynorian> yes
[19:23] <wxl> ok that's weird
[19:23] <wxl> @lynorian: let's check other flavors, please
[19:26] <teward> wxl: FWIW the CVE IDs were just requested from MITRE by me
[19:26] <teward> it'll take a day or more for them to get to it
[19:26] <teward> i know their CVEForm gets a lot of cruft
 glad I got the 2TB ssd now
[19:31] <lynorian> I tried the new daily from today and now reporting bugs on calamares works
[19:32] <lynorian> I am quite confused not sure what changed
[19:34] <teward> gremlins
[19:42] <wxl> weird
[22:55] <teward> tsimonq2: re: cala, CVEs CVE-2019-13178 and CVE-2019-13179
[22:57] <teward> yes we know ubot, these were just issued :p