I love a good bug hunting story, and this one is right up there as a great one. Way back in 2018, Doug Brown discovered that after installing Ubuntu MATE 18.04, if he launched Firefox from the icon in the default panel arrangement to install Chrome from the official Chrome website, the process was broken. After downloading the .deb and double-clicking it, GDebi would appear, but after clicking “Install”, nothing happened.
What was supposed to happen is that after clicking “Install”, an authentication dialog should appear where you enter your root password, courtesy of gksu. However, this dialog did not appear, and without thinking too much of it, Brown shrugged and just installed the downloaded Chrome .deb through the terminal, which worked just fine. While he didn’t look any deeper into the cause of the issue, he did note that as the years and new Ubuntu releases progressed, the bug would still be there, all the way up until the most recent release.
Finally, 2.5 years ago, he decided to dive into the bug. It turned out there were lots of reports about this issue, but nobody stepped up to fix it. While workarounds were made available through wrapper scripts, and deeper investigations into the cause revealed helpful information. The actual error message was a doozy: “Refusing to render service to dead parents”, which is quite metal and a little disturbing.
In summary, the problem was that GDebi was using execv() to replace itself with an instance of pkexec, which was intended to bring up an authentication dialog and then allow GDebi to run as a superuser. pkexec didn’t like this arrangement, because it wants to have a parent process other than init. Alkis mentioned that you could recreate the problematic scenario in a terminal window by running gdebi-gtk with setsid to run it in a new session.
↫ Doug Brown
Backing up a few steps, if the name “gksu” rings a bell for you, you might have already figured out where the problem most likely originated from. Right around that time, 2018, Ubuntu switched to using PolicyKit instead, and gksu was removed from Ubuntu. GDebi was patched to work with PolicyKit instead, and this was what introduced the actual bug.
Sadly, despite having a clear idea of the origin of the bug, as well as where to look to actually fix it, nobody picked it up. It sat there for years, causing problems for users, without a fix in sight. Brown was motivated enough to fix it, submitted the patch, but after receiving word it would be looked at within a few days, he never heard anything back for years, not helped by the fact that GDebi has long been unmaintained. It wasn’t until very recently that he decided to go back again, and this time, after filling out additional information required for a patch for an unmaintained package, it was picked up, and will become available in the next Ubuntu release (and will most likely be backported, too).
Brown further explains why it took so long for the bug to be definitely fixed. Not only is GDebi unmaintained, the bug also only manifested itself when launching Firefox from the panel icon – it did not manifest when launching Firefox from the MATE menu, so a lot of people never experienced it. On top of that, as we all sadly know, Ubuntu replaced the Firefox .deb package with the SNAP version, which also doesn’t trigger the bug.
It’s a long story for sure, but a very interesting one. It shows how sometimes, the stars just align to make sure a bug does not get fixed, even if everyone involved knows how to fix it, and even if fixes have been submitted. Sometimes, things just compound to cause a bug to fall through the cracks.
I think the problem really comes from missunderstanding the problem itself.
You are not supposed to download and run deb files from the internet unless you are an experienced user. There is dgpk -i %filename% for that and it has always worked in the described scenario.
If you want to download binary versions via the web browser and without safeguards think they will just install from the file manager, there is more suitable distributions than ubuntu and debian or even neptune or q4os.
Can i recommend “red flag os”? DPRK fork of debian that controlls every packet sent in and out as well as the gui and tui of what you are allowed to write. I mean, sure… it is giving all my data away to the north korean government, but DANG those icons look good, or as Steve Jobs would say “lickable”
> it has always worked in the described scenario.
It did work, the story literally says that. Your misunderstanding is the framing with regards to what is being talked about and when it was a problem for him, for a couple of years from 6 odd years ago, and what was available at the time with the environment he chose to use.
The overall point of the post misses the mark. A tonne of bug fixes get ignored because people up the chain let their personality flaws get in the way. But more important than that is there’s a sea of distros and people are fixing bugs in each distro which is a massive waste of resource, 10 bugs fixed across 10 distros – maybe one of those fixes goes upstream, the rest were just for stupid stuff in the respective distro.
I wonder if Commissar of Censorship will delete this post.