@Mechanicalsnail Did you see that launchpad bug against LP itself got closed? I checked the control file and I don't think the person that closed the bug did.
@Mechanicalsnail I'm going to apt-mirror source repos this weekend and grep for the problem to see if I can find an exploitable instance of it. Then they'll have to not ignore it.
That whole don't bring a gun to a gunfight. bring a nuke to a knife-fight mentality
@EliahKagan Traditional Japanese is top to bottom, right to left, like Chinese, while westernized Japanese is left to right, top to bottom. Usually modern Japanese is westernized. This also applies to macro-reading direction (as in, books also start at the other end respectively).
an explanation was provided in the last comment on the bug, if library maintainers aren't changing package name properly on SONAME change then it's a package bug obviously
@AbrahamVanHelpsing Why do you think it's a Launchpad bug? The package's dependencies are wrong -- they don't provide the files that it depends on. The fact that a rebuild fixes it doesn't make it not a package bug if the package's dependencies don't tell the packaging infrastructure that it needs a rebuild.
@AbrahamVanHelpsing It's not Launchpad's job to trigger rebuilds in cases of broken dependencies anyway; it's a separate part of the Ubuntu archive management infrastructure. But even then it's not a bug there, since that infrastructure relies on package dependencies rather than knowing how to manual check relationships for every one of the dozens of language-specific library formats.
It seems to me: Depending on a pseudo-package for dev files: Good thing. Depending on dynamically generated binary dependencies: Good thing. That's where my logic stops. I can agree it's not against launchpad though.
@Mechanicalsnail This is why there's work being done on automated package testing, however covering tens of thousands of packages in universe can be infeasible
Why do you think it is a Launchpad or archive infrastructure bug, when multiple Ubuntu developers and a Launchpad developer have categorically told you that it is not?
if i can leverage this evidencing somewhere else in a delay loaded library that requests root privileges expectedly then i can load an arbitrary so as root. which becomes a problem. rapidly. it's fine though. we'll go about it a different way.
no it's not. if a package gets "updated" and ldpath contains a directory i control that isn't root owned(possible) and i can get an so there under the old name...i have a priv esc exploit waiting to happen.
@AbrahamVanHelpsing If you're trying to find a way to prove that this is a build system bug, you're going to be trying for a while. I suggest you start treating it as a package bug so it can actually get fixed.
That's triggered semi-automatically when dependencies break
The problem here is that, due to a package bug, the dependencies are still satisfiable
This is probably a bug in libgutenprint
If I write a new language with a new library system and get it into Ubuntu, it's not the job of the Ubuntu archive to understand my new language's dependency system and work out when the package will no longer work
It's the job of my package's to declare the correct dependencies, so the archive can know in a language- and build system-agnostic manner whether the dependencies are satisfiable.
If libgutenprint-dev creates a binary dependency that doesn't provide the files that applications linked against it need, then that's not an archive problem.
