[00:19] <amurray> ItzSwirlz: it could be treated as a security issue (denial of service) depending on what the application is and how it can be triggered - can you elaborate more?
[00:20] <ItzSwirlz> https://github.com/linuxmint/cinnamon-desktop/commit/1b44b9ccc92d8479da3bcd37921c80e64f7d2e91
[00:20] <ItzSwirlz> so in this case, if you ahve a connected but disabled monitor there can be problems and it might end up dividing by 0
[00:20] <ItzSwirlz> 1/(0/1)
[00:21] <ItzSwirlz> hold on, I'm going to look at the function
[00:23] <ItzSwirlz> It's with the scaling of the monitor-so say you have two monitors and one is off.  Basically-cinnamon-desktop is libraries
[00:23] <ItzSwirlz> So it's saying that if something wanted to call it to get the monitor information, it could scale it and cause math that divy's by 0
[00:48] <ItzSwirlz> However the patch just got placed today so I think wait it out
[00:49] <tumbleweed> sonuds like a bug worth SRUing
[00:56] <ItzSwirlz> I'll take your word for it-but let's wait it out until December when upstream's distro gets released and any extra patches come with it
[00:56] <ItzSwirlz> y'know in case *cough* regression
[00:57] <ItzSwirlz> Anyone willing to take a look at reviewing my patch for in the Cinnamon Desktop Libraries, using -- flag when launching the terminal instead of using -x? (Bug #1905630)
[00:58] <sarnold> ItzSwirlz: is that patch the wrong way around? it's removing a changelog entry
[00:58] <sarnold> most of it is removing things
[00:59] <ItzSwirlz> the frick? lemem see
[00:59] <ItzSwirlz> Oh. oh. oh.
[00:59] <ItzSwirlz> Yes! Totally a great idea to REVERSE THE DSC ORRDER.
[00:59] <ItzSwirlz> a.k.a i took the old thing over the new one lol
[01:00] <sarnold> ItzSwirlz: what happens if the script or directory is named something really stupid like $(touch /tmp/HELLO) or `touch /tmp/HELLO` or other ridiculously bad names?
[01:01] <ItzSwirlz> As long as it's an executable
[01:01] <sarnold> it just seem slike anything that breaks on something as common as a space is liable to blow up into a billion pieces when faced with something actually malicious
[01:05] <ItzSwirlz> sarnold: okay so-
[01:05] <ItzSwirlz> gnome-terminal -x (thing)
[01:05] <ItzSwirlz> gnome-terminal -- (thing)
[01:06] <ItzSwirlz> Thats all the patch does. As a matter of fact if you try running gnome-terminal -x (blah) in a terminal, it will even tell you its deprecated and perfers a --
[01:06] <ItzSwirlz> Oh...
[01:06] <ItzSwirlz> gnome-terminal -x is not even an option. It got removed per-groovy.
[01:06] <ItzSwirlz> ¯\_(ツ)_/¯
[01:07] <sarnold> ItzSwirlz: but why does it break with a space in the directory name?
[01:26] <ItzSwirlz> doesn't bash technically break with a space in the dir name?
[01:26] <ItzSwirlz> you have to do some quite funky stuff with it, with the \ and the /
[01:28] <cjwatson> Or just normal quoting
[01:28] <cjwatson> bash is fine, it's just that lots of scripts aren't carefully written
[01:28] <cjwatson> I mean "fine" in implementation terms, not going to defend it as a language
[01:29] <sarnold> :)
[01:30] <cjwatson> And I agree with sarnold's guess here.  It *might* be fine, but this is a red flag for more serious security bugs
[01:30] <cjwatson> Needs a full root cause analysis IMO
[01:32] <ItzSwirlz> If thats the cause then it's because C code
[01:32] <cjwatson> Without having looked at the actual software, there are two likely possibilities here
[01:32] <ItzSwirlz> Which technically would mean go through all the programs and patching it
[01:32] <cjwatson> (1) unlikely but possible: something is manually splitting on spaces and constructing an argument list that way
[01:33] <cjwatson> (2) more likely: something is violating the rule of one layer of quoting per layer of expansion
[01:33] <ItzSwirlz> does this apply upstream?
[01:33] <cjwatson> I have no idea, I haven't done a root cause analysis
[01:34] <cjwatson> If it's (2) it can probably be turned into a security vulnerability
[01:34] <cjwatson> If it's (1) it's probably just poor-quality
[01:34] <ItzSwirlz> well remember its a library
[01:34] <cjwatson> Do you understand shell quoting rules?
[01:34] <ItzSwirlz> The fix for the GitHub upstream bug was technically in the Nemo source code
[01:34] <ItzSwirlz> Pretty sure, yes
[01:35] <cjwatson> Do you understand how argument lists work at the C level?
[01:35] <ItzSwirlz> No
[01:37] <ItzSwirlz> hold on-you talking about the good ol bash -c 'command'
[01:37] <cjwatson> Not really
[01:38] <sarnold> more execve(2) syscall vs system(3) library call level
[01:38] <ItzSwirlz> hm. i'll take a quick glance at it
[01:38] <cjwatson> OK, so when you fork and exec a process at the C level, there should normally not be any shell parsing involved.  Instead what you do is construct a list of arguments which the subsidiary program receives in its argv vector.  Those are *not quoted* (except for the quoting required by the C language): so the equivalent of running something like   some-program 'foo bar' '"foo bar baz"'   in ...
[01:38] <cjwatson> ... shell is an argv of ["some-program", "foo bar", "\"foo bar baz\""] in C
[01:39] <cjwatson> Sometimes programs use the system() C library call, which effectively runs a string through sh -c.  This is extremely often a source of bugs
[01:39] <cjwatson> Because in order to get that right, you have to accurately reverse the shell's parsing, i.e. accurately quote everything
[01:40] <cjwatson> When executing programs from C, it is very much safer to avoid shell parsing entirely
[01:40] <ItzSwirlz> So in this case (this commit which is one of the things done after the schema update I'm considering SRU) at https://github.com/linuxmint/nemo/commit/a2f15e045b5b2d0581bcc10780b3416ea185faa3
[01:40] <ItzSwirlz> g_strdup_printf ("gnome-terminal -x"); - so i'll go see what's really going on
[01:41] <sarnold> twisty maze of abstractions..
[01:41] <ItzSwirlz> Yep. Typical GTK shenanigans
[01:41] <ItzSwirlz> but again yes it could just be bad programming quality
[01:41] <cjwatson> GTK has perfectly good list-based interfaces for subprocesses
[01:41] <cjwatson> Or Glib rather
[01:42] <cjwatson> And yeah, that prepend_terminal_to_command_line function gives me the shivers
[01:43] <cjwatson> Difficult because its interface involves taking a shell command and modifying it, so it's hard to get right by design
[01:45] <cjwatson> A proper fix would probably involve rewriting its interface (and thus its callers) to use argument lists, but it could be patched up with g_shell_quote
[01:45] <sarnold> this looks like it'll take that string and do a bunch of % substitutions via https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html  ... this feels like it's ripe for abuse. I didn't consider scripts named %f or %F or similar.
[01:45] <cjwatson> Not sure whether that's actually what you're running into here
[01:47] <cjwatson> Anyway I need to sleep, it's just that I feel like I've spent most of my career trying to persuade people to get subprocess invocations right :)
[01:48] <ItzSwirlz> Yeah. I hope I didn't tangle you or piss you off.
[01:48] <ItzSwirlz> I'm easy to do that with my dumb and empty brain capabilities
[01:48] <ItzSwirlz> gn o7
[01:48] <ItzSwirlz> I'll mark the issue as "invalid"
[01:48] <cjwatson> Oh you didn't piss me off, and probably the issue isn't invalid
[01:48] <cjwatson> Just needs deeper fixing
[01:48] <ItzSwirlz> ok
[01:48] <ItzSwirlz> Well good thing it's version 4.8 and next version is 5.0, a major! :D
[01:48] <ItzSwirlz> ok go to sleep, take care
[01:49] <cjwatson> Parting note, a friend of mine wrote http://www.greenend.org.uk/rjk/tech/shellmistakes.html#missingquote which is an excellent primer on how shell quoting works without having to load the entire bash man page into your head all at once
[01:50] <ItzSwirlz> o. ty
[01:52] <sarnold> gnight cjwatson, thanks :)
[08:40] <juliank> Ooh I figured I want to re-revive this
[08:40] <juliank> @pilot in
[10:34] <seb128> sil2100, hey, could you retry the build there? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/hirsute/ubuntu-canary
[10:34] <seb128> it failed on a network issue
[10:44] <RikMills> jibel: hi. ubiquity in live session and ubiquity-dm for kubuntu is failing to start, and seems to have been the case since at least 4th November
[10:44] <RikMills> LP: #1903378
[10:45] <RikMills> especially in the live session, I am puzzled, as there is not much useful output to logs, even with -d
[10:45] <RikMills> any help would be appreciated!
[10:45] <RikMills> ^^ or any other installer people ;)
[12:21] <eoli3n> mwhudson is there any way to run commands in chrooted /target after autoinstall ?
[12:21] <eoli3n> from user-data file
[12:21] <eoli3n> without having to - chroot /target command1 \n - chroot /target command2 \n etc..
[12:45]  * RikMills can't spell ubiquity in bugs it seems :/
[12:48] <jibel> RikMills, there is an import error on the sip module apparently
[12:48] <jibel>   File "/usr/lib/ubiquity/ubiquity/frontend/kde_ui.py", line 40, in <module>
[12:48] <jibel>     import sip
[12:48] <jibel> ModuleNotFoundError: No module named 'sip'
[12:50] <RikMills> jibel: ah. I completely failed to find that
[12:51] <jibel> yeah because the error is caught by an importerror and hidden
[12:52] <jibel> RikMills,do you know where sip comes from? python3-qt5.sip is installed but there is not module sip
[12:53] <RikMills> jibel: no. mitya57 might?
[12:56] <eoli3n> what's the launchpad page for autoinstall issues ?
[12:57] <eoli3n> forget it
[13:03] <RikMills> jibel: can you confirm installing python3-sip fixes it?
[13:04] <RikMills> that used to be on the iso, but no more. so perhaps some dependency drop?
[13:05] <jibel> RikMills,yes it does, I was looking was it is not on hirsute
[13:05] <jibel> s/was/why
[13:06] <jibel> RikMills,anyway I think the cause of the error is clear now and you can take it from there?
[13:07] <RikMills> jibel: sure. I will poke around to try to see why it dropped out. and if perhaps one of the pyqt5 packages should depend on it
[13:07] <RikMills> thank you :)
[13:07] <jibel> yw
[13:21] <jibel> RikMills,I guess it comes from this change
[13:21] <jibel> pyqt5 (5.15.0+dfsg-1+exp1) experimental; urgency=medium
[13:21] <jibel>   * Switch from sip4 to sip5:
[13:21] <jibel>     - Update build-dependencies.
[13:36] <sil2100> seb128: running!
[13:36] <seb128> sil2100, thanks!
[13:38] <RikMills> jibel: I am told python3-sip is depreciated, and replacing 'import sip' with 'from PyQt5 import sip' should fix it a better way
[13:38] <RikMills> as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966034
[13:54] <sil2100> seb128: hm, I think it might have failed again in the same way
[13:55] <seb128> sil2100, yes, I was about to ping you
[13:55] <seb128>  /usr/share/livecd-rootfs/get-ppa-fingerprint failing to connect error
[13:56] <seb128> I'm not familiar with get-ppa-fingerprint though, let me try to understand what that does and if it's something weird canary is doing...
[13:59] <seb128> sil2100, I see you asked about that error on the launchpad channel in octobre :)
[13:59] <seb128> how did you fix it at the end?
[14:00] <cjwatson> It's a get-ppa-fingerprint bug
[14:01] <cjwatson> Missing a 'production' second argument
[14:01] <cjwatson> I thought xnox was fixing it
[14:01] <cjwatson> (If you don't specify a service, it defaults to staging)
[14:01] <seb128> cjwatson, thanks
[14:01] <seb128> I wonder why it's impacting the canary build only, that code doesn't seem specific to this image...
[14:01] <cjwatson> Is it possibly only affecting riscv64?
[14:02] <cjwatson> If so it's some quirk of firewall rules - the other builders can only get at staging basically by accident
[14:02] <seb128> cjwatson, that's an amd64 build, https://launchpadlibrarian.net/508742975/buildlog_ubuntu_hirsute_amd64_ubuntu-canary_BUILDING.txt.gz
[14:02] <cjwatson> Or maybe other images don't use extra_ppas
[14:02] <cjwatson> Which would mean that code isn't used
[14:02] <cjwatson> This code was only broken in around August
[14:03] <seb128> canary had been commented for a while since it had other issues which I finally fixed
[14:03] <seb128> cjwatson, thanks for the reply, I will check with xnox what's the status of the get-ppa-fingerprint bug
[14:04] <seb128> cjwatson, but yes, seems like the canary image uses --extra-ppa ubuntu-desktop/canary-image
[14:04] <cjwatson> Looks like it's fixed in livecd-rootfs 2.702
[14:04] <seb128> which would explain the difference with standard desktiop
[14:05] <seb128> ah
[14:05] <cjwatson>  livecd-rootfs | 2.700    | hirsute          | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[14:05] <cjwatson>  livecd-rootfs | 2.702    | hirsute-proposed | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[14:05] <seb128> right, that iso build has 2.700
[14:06] <seb128> so to migrate it needs ubuntu-image autopkgtests to be fixed it seems
[14:13] <sil2100> seb128: do we need the extra PPAs in the meantime?
[14:13] <seb128> sil2100, I don't know, but I'm fixing ubuntu-image :)
[14:13] <seb128> we need livecd-rootfs to migrate anyway, I've other fixes in 702 needed for canary
[14:14] <sil2100> +1
[14:14] <sil2100> I didn't see the u-i failures, but I see I got poked about those on -release
[14:15] <seb128> I've a fix ready to test
[14:17] <sil2100> seb128: ah, it's due to the python defaults switching to 3.9, yeah
[14:17] <sil2100> seb128: give me a poke once you test, I can commit that in the upstream repo then
[14:17] <seb128> sil2100, the issue I'm fixing in not that one
[14:17] <seb128> I'm fixing the
[14:17] <seb128>     AttributeError: 'Changelog' object has no attribute 'get_version'
[14:19] <seb128> which is a change in the newest python-debian
[14:24] <sil2100> Ah, I see, they did get_version() -> _get_version(), which is weird, as that's basically changing the API without notice
[14:28] <seb128> sil2100, right, I don't know if that's an error or not, there was a similar failure there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227#10 where the maintainer said the method was undocumented
[14:29] <kanashiro> mitya57: I am willing to sync ruby-defaults/1:2.7+2 from Debian unstable, we have many FTBFS in proposed because they b-d on rubygems binaries and they are uninstallable at the moment. Are you opposed to that?
[14:29] <seb128> sil2100, https://code.launchpad.net/~seb128/ubuntu-image/+git/ubuntu-image/+merge/394533 is the easy fix, same as they did in ^
[14:37] <seb128> sil2100, I've also submitted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975910 to python-debian to ask if the change was wanted or an overlook mistake
[14:38] <sil2100> seb128: looks good, thanks! I'll get that pushed to the main repo
[14:39] <seb128> sil2100, thanks! Do you want me to handle the package upload or are you doing that as well?
[14:42] <sil2100> seb128: feel free to upload, I guess it'll be faster as you already have everything prepped
[14:43] <seb128> sil2100, thanks
[14:45] <seb128> sil2100, bah, sorry, I just saw that the launchpad git is an import from github, I can redo the mp there
[14:49] <sil2100> seb128: no worried, I'll sync it
[14:49] <seb128> sil2100, k, thanks
[15:02] <seb128> sil2100, I pushed to github anyway, https://github.com/CanonicalLtd/ubuntu-image/pull/195 so we have CI and you just have to press the button
[15:02] <seb128> sil2100, you might still want to tag 1.10+20.10ubuntu3 and push, unsure the mp handles that part correctly
[15:15] <sil2100> seb128: hah, I just prepared a PR for that as well! Since I wanted to skip 1.10+20.10ubuntu3 in the upstream changelog out of stylistic reasons - but anyway, no harm done, good that it's there
[15:16] <sil2100> For devel series specific fixups we don't always tag a release, especially that 1.10+20.10ubuntu3 is a groovy version number released to hirsute, so it's a bit of a bandaid release anyway
[15:17] <sil2100> Though I don't really have preferences, sometimes I just push those fixes up and stage them for the next big upstream release (so for 1.11)
[15:17] <sil2100> This is why I said I'll do it as I wanted to do it 'my way' ;)
[15:20] <sil2100> (also, had to enable hirsute CI since it was disabled)
[15:20] <sil2100> Your PR was a bit early before I did that so it wasn't set up yet ;)
[15:25] <seb128> sil2100, k, no worry, I just didn't want to create more work for you, at least I feel like I've not been lazy letting things for you to clean, feel free to reject the MPs or do things the way you prefer, I'm not picky on details :)
[15:26] <sil2100> seb128: thanks for prepping the quick-fix!
[15:28] <seb128> np!
[15:32] <xnox> seb128:  you could force copy livecd-rootfs to release pocket ;-) you have the powers =)
[15:32] <seb128> xnox, :)
[15:32] <xnox> seb128:  or you can copy livecd-rootfs into the canary ppa. that should work too.
[15:33] <seb128> xnox, would that work since it errors out trying to enable that ppa? :p
[15:33] <seb128> xnox, i need the get-ppa-fingerprint fix
[15:33] <xnox> seb128:  yes, because the livecd-rootfs is installed from that ppa too.
[15:33] <seb128> ah
[15:33] <xnox> on the host, before trying to enable said ppa.
[15:33] <seb128> xnox, anyway I'm not in an hurry, hopefully the ubuntu-image fix uploaded is enough and things migrate today
[15:54] <xnox> what do I use to grant queue rights to myself for a PPA?
[15:55] <xnox> acutally with queue tool i don't see that anything needs doing.
[15:55] <cjwatson> edit-acl
[15:55] <xnox> ah, thanks.
[15:55] <xnox> i was greping for "grant" for some reason.
[17:17] <LocutusOfBorg> hello Unit193, what happened to the libtorrent-rasterbar package?
[17:17] <LocutusOfBorg> do you want to merge it? there is also a tarball mismatch, and the remaing delta should probably be upstreamed
[17:19] <juliank> @pilot out
[17:29] <LocutusOfBorg> mmm the topic still mention the arm*/ppc*/s390x* outage
[17:34] <cjwatson> Fair point
[18:14] <ItzSwirlz> arm builds being out is a pain.
[18:19] <mitya57> kanashiro: it looks like rubygems is built, so I think you can try. In the worst case we will have to remove it from -proposed again.
[18:20] <kanashiro> mitya57: it is working on Debian now, so I do not expect any major issue
[18:20] <mitya57> kanashiro: though I'm not sure if a simple sync will work. Maybe you will have to ask some archive admin to get it re-published instead.
[18:21] <kanashiro> mitya57: you are right, I got it rejected when trying to use syncpackage
[18:22] <mitya57> Maybe vorlon or doko will be able to fix it
[18:23] <mitya57> (re-publish https://launchpad.net/ubuntu/+source/ruby-defaults/1:2.7+2)
[18:24] <kanashiro> I also asked archive admins in #ubuntu-release
[18:32] <cjwatson> ItzSwirlz: They aren't out any more though?
[18:33] <LocutusOfBorg> mitya57, I did that
[18:33] <LocutusOfBorg> ./copy-package --from=ubuntu --to=ubuntu --from-suite=hirsute-proposed --to-suite=hirsute-proposed --include-binaries ruby-defaults --version 1:2.7+2 --force-same-destination
[18:33] <cjwatson> That's why I removed it from the topic
[18:33] <LocutusOfBorg> we cannot remove them, but we can restore them
[18:33] <ItzSwirlz> cjwatson: just woke up. Polari didn't update :P soz. Happy days, happy thanksgiving if celebrating
[18:38] <mitya57> LocutusOfBorg: cool, I didn't know about that :)
[18:39] <LocutusOfBorg> mitya57, ssssh don't tell anybody!
[22:23] <Unit193> LocutusOfBorg: Yeeeah, I noticed that...
[22:38] <Unit193> LocutusOfBorg: Also no reason to keep delta, IMO.