Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1069166 > unrolled thread

Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library Neil Williams <codehelp@debian.org> - 2021-08-31 17:00 +0200
    Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library Adrian Bunk <bunk@debian.org> - 2021-09-01 10:10 +0200
      Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library Neil Williams <codehelp@debian.org> - 2021-09-01 10:40 +0200
        Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library Adrian Bunk <bunk@debian.org> - 2021-09-01 11:20 +0200
          Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library Neil Williams <codehelp@debian.org> - 2021-09-01 11:40 +0200

#1069166 — Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library

Package: ftp.debian.org
Severity: normal

gtkpod upstream has moved but has not had any activity for over 5 years.

When investigating the two CVEs against AtomicParsley, former maintainer Matteo F. Vescovi reached
out to me to suggest removal of gtkpod.

The use case for this package seems to be declining / absent and 4 crash bugs are currently open.

Fixes for these bugs and CVEs seem unlikely to appear, it would seem best to remove gtkpod
from Debian at this point.

Thanks

[toc] | [next] | [standalone]

#1069273 — Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library

Control: tags 993378 moreinfo

On Tue, Aug 31, 2021 at 03:49:45PM +0100, Neil Williams wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> gtkpod upstream has moved but has not had any activity for over 5 years.
> 
> When investigating the two CVEs against AtomicParsley, former maintainer Matteo F. Vescovi reached
> out to me to suggest removal of gtkpod.
> 
> The use case for this package seems to be declining / absent and 4 crash bugs are currently open.
> 
> Fixes for these bugs and CVEs seem unlikely to appear, it would seem best to remove gtkpod
> from Debian at this point.

As a user I am quite unhappy when a working package I am using is out of 
the void getting am RM bug.

With software for older hardware it is normal that upstream becomes 
inactive, and anything other than declining usage would be a surprise.

I am also dismayed at the CVEs. At first sight the "two CVEs" might be 
for the same bug, with the fix for the first CVE not fixing the bug.
Does manually backporting the one-character change from CVE-2021-37232 
fix everything, even without the larger CVE-2021-37231 refactoring?

> Thanks

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1069279 — Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library

[Multipart message — attachments visible in raw view] — view raw

On Wed, 1 Sep 2021 11:05:09 +0300
Adrian Bunk <bunk@debian.org> wrote:

> Control: tags 993378 moreinfo
> 
> On Tue, Aug 31, 2021 at 03:49:45PM +0100, Neil Williams wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > gtkpod upstream has moved but has not had any activity for over 5
> > years.
> > 
> > When investigating the two CVEs against AtomicParsley, former
> > maintainer Matteo F. Vescovi reached out to me to suggest removal
> > of gtkpod.
> > 
> > The use case for this package seems to be declining / absent and 4
> > crash bugs are currently open.
> > 
> > Fixes for these bugs and CVEs seem unlikely to appear, it would
> > seem best to remove gtkpod from Debian at this point.  
> 
> As a user I am quite unhappy when a working package I am using is out
> of the void getting am RM bug.
> 
> With software for older hardware it is normal that upstream becomes 
> inactive, and anything other than declining usage would be a surprise.
> 
> I am also dismayed at the CVEs. At first sight the "two CVEs" might
> be for the same bug, with the fix for the first CVE not fixing the
> bug. Does manually backporting the one-character change from
> CVE-2021-37232 fix everything, even without the larger CVE-2021-37231
> refactoring?

Hi Adrian.

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.

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.

-- 
Neil Williams
=============
https://linux.codehelp.co.uk/

[toc] | [prev] | [next] | [standalone]

#1069287 — 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

[toc] | [prev] | [next] | [standalone]

#1069291 — Bug#993372: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library

[Multipart message — attachments visible in raw view] — view raw

On Wed, 1 Sep 2021 12:08:16 +0300
Adrian Bunk <bunk@debian.org> wrote:

> 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.

Packages do not need to be RC buggy to be removed - indeed, many RC
buggy packages remain in unstable for some time as the removal from
testing is automated.

RoQA and RoM are valid reasons for removal of a package from Debian
which do not require any RC bugs to be present.

https://ftp-master.debian.org/removals.html


-- 
Neil Williams
=============
https://linux.codehelp.co.uk/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web