Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, Sep 01, 2021 at 09:32:09AM +0100, Neil Williams wrote:
>...
> Hi Adrian.
Hi Neil,
> Sorry, No. The commit linked to CVE-2021-37232 does not even fix the
> problem described as being fixed by that commit in atomicparsley, at
> least in my testing using the data file supplied by upstream. I
> mentioned this in the bug report against atomicparsley - 993366
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5
>
> That atomicparsley data file cannot be used to test gtkpod, only
> atomicparsley itself.
"atomicparsley itself" is a CLI with a copy of the code,
not much different from gtkpod.
gtkpod at least tries (in a broken way) to share the library with other
programs.
> As mentioned already, gtkpod is now orphaned and the maintainer who
> orphaned it suggested removing the package. (The CVEs are not the only
> bugs against either atomicparsley or gtkpod).
>
> The two CVEs are not the same bug - at least not according to the
> commits made upstream for the two issues in atomicparsley.
>
> Orphaned packages are at risk of sudden removal - until and unless
> someone adopts the package.
>...
Why do you want to screw our users (in this case including me)
with sudden removals?
QA maintained packages tend to be better maintained than many packages
owned by nearly-MIA maintainers, so why are you forcing people to move
packages out or QA maintainance just for preventing random people doing
sudden removals out of the void?
I can adopt gtkpod and many other QA maintained packages if that is the
only way to stop removal requests from people like you.
This would change the Maintainer field without fixing any bugs.
The normal approach is that people file RC bugs for RC issues
or an RC "should this package be removed?" bug against the
package first. This gives people time to react and discuss.
cu
Adrian
Reply to: