Please don't include xchat (abandoned upstream) in 18.04

[dx]

The xchat package was removed from debian on 2016-01-30[1]. The mentioned reason is "dead upstream; active fork available". It hasn't had a stable release in 8 years, and it's been replaced by hexchat, which is still actively developed.

All other distros have removed the xchat package and replaced it with hexchat.

On 2017-08-08, LocutusOfBorg reuploaded xchat to debian with all the patches it had previous to its removal and a few new patches backporting fixes with CVEs from hexchat, resulting in 44 patches on top of the last xchat release from 2010, making it effectively another fork maintained by debian.

TingPing, the main developer of hexchat, contacted the debian maintainer, and the reason for this reintroduction seems to be "nostalgia" and "new libraries not available [in older distros]". See the full blog post[2] for the complete exchange.

As a member of the IRCv3 working group[3] it saddens me to see debian picking up an old version of a client and shipping it as if it were new.

I realize the right place to complain about this would be debian, but the more immediate risk here is ubuntu including it in a LTS release. Having LTS users using xchat is going to hold back the progress of the IRC ecosystem as a whole until 2023. Please don't do this to us.

Not to mention the lack of ipv6, python3 support (with the python2 EOL in two years), SSL SNI, and all the bugs that were not considered worth a CVE. Without looking too far, launchpad bug 349754 (crash when pressing ctrl-i several times) is still unfixed in this xchat package and doesn't affect hexchat. There are other 114 bugs in this tracker alone. And no real upstream.

[1]: https://tracker.debian.org/news/744446
[2]: https://tingping.github.io/2018/03/02/when-distros-get-it-wrong.html
[3]: https://ircv3.net/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[dx (dx)]

I noticed someone else filed an "Intent to file removal bug" in debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891982

[Robie Basak (racb)]

FTR, I've added a request for a decision on this to https://wiki.ubuntu.com/TechnicalBoardAgenda, as I don't see that it can be resolved any other way. I'm not sure at which meeting this will be discussed as tomorrow's meeting may be too short notice.

[Jeremy Bícha (jbicha)]

See also https://launchpad.net/bugs/1758163 for xchat-gnome.

[Steve Langasek (vorlon)]

Hi Robie, Gianfranco,

Lacking quorum, there was no actual TB meeting the other week. However, as
I noted on IRC, I also don't consider this a matter requiring the Technical
Board's input. In the first instance, this falls within the purview of the
archive team, and I'm happy for us to field it as such.

If there are concerns about the archive team's decision here, that decision
may always be appealed to the TB.

The original bug report,
<https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169>, was filed
per my request on #ubuntu-release[1], but I overlooked the actual filing
which came with some delay after the IRC discussion.

This does not mean I agree that the package should be removed, but as you, I
think it's important to have this discussion and take a decision.

I do have concerns about the quality of this software, as well as about the
maintainer's response to the concerns that have been raised. Comments
inline:

On Mon, Mar 12, 2018 at 03:17:55PM +0000, Gianfranco Costamagna wrote:

> >I've added this to the TB agenda. I imagine it'll take quite a bit of
> >reading of the various references (I've added them to the agenda item)
> >so appreciate you may not be able to decide by tomorrow's meeting.

> just to give my quick maintainer point of view.

> 1) the security issues it has, are also applicable to hexchat (we will
> upload a fixed hexchat soon, upstream after all this debate quickly found
> and fixed some issues and released a new upstream tarball)

> this said, the security issues, can crash hexchat or xchat if you connect
> to a malicious server, sending non standard irc replies. (so, an
> exceptional use case I would say)

An IRC client, in its default mode of operation, requires zero
authentication of a remote server. The server must therefore be considered
untrusted and potentially hostile. Even *with* authentication, a remote
server could be compromised.

Any security vulnerability involving a network client failing to validate
input from a remote source is a significant one.

And in my opinion, any network client whose upstream maintainer didn't
consider such vulnerabilities worthy of serious attention should not be
included in a stable Ubuntu release.

So please don't try to argue for xchat's inclusion by downplaying the
significance of security vulnerabilities.

> 2) the package is not upstream maintained but it is fully Debian/Ubuntu
> downstream maintained. I did fix a lot of bugs, and did ~10 uploads in
> the archive, making it suitable again for release (in my maintainer
> opinion, feel free to have whatever different opinion)

I have no problem in principle with a package that is orphaned upstream and
is now maintained only in Debian/Ubuntu. There have certainly been many
other examples of this, and such packages are not categorically worse than
those that have a separate upstream.

My understanding is that most former xchat users find hexchat to be a
reasonable replacement. Can you explain why you do not?

> 4) see my point here
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891982#35

I'm afraid I don't agree at all with this argumentation. For better or
worse, it is a fairly common practice...

[Gianfranco Costamagna (costamagnagianfranco)]

Hello Steve and all,

>Lacking quorum, there was no actual TB meeting the other week. However, as
>I noted on IRC, I also don't consider this a matter requiring the Technical
>Board's input. In the first instance, this falls within the purview of the
>archive team, and I'm happy for us to field it as such.

I agree, thanks for simplifying the things :)
>If there are concerns about the archive team's decision here, that decision
>may always be appealed to the TB.
>
>The original bug report,
><https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169>, was filed
>per my request on #ubuntu-release[1], but I overlooked the actual filing
>which came with some delay after the IRC discussion.
>
>This does not mean I agree that the package should be removed, but as you, I
>think it's important to have this discussion and take a decision.

thanks
>I do have concerns about the quality of this software, as well as about the
>maintainer's response to the concerns that have been raised. Comments
>inline:

lets try to answer

>An IRC client, in its default mode of operation, requires zero>authentication of a remote server. The server must therefore be considered
>untrusted and potentially hostile. Even *with* authentication, a remote
>server could be compromised.
>
>Any security vulnerability involving a network client failing to validate
>input from a remote source is a significant one.
>
>And in my opinion, any network client whose upstream maintainer didn't
>consider such vulnerabilities worthy of serious attention should not be
>included in a stable Ubuntu release.
>
>So please don't try to argue for xchat's inclusion by downplaying the
>significance of security vulnerabilities.

ack here, but sorry if I made this false assumption. the mean of that
sentence was not "don't care because internet is broken or evil",
but more a "hey, such vulnerabilities exists in probably *all* irc clients,
including hexchat and others, at least in stable releases. You can do fuzzy
testing against the versions to check them.

So, while I *always* fixed CVEs on my packages, I also think we should focus
more to real bugs, not something discovered by a fuzzy test, that affects probably
most irc clients, with an userbase really low, and with a crash as effect and not
a personal data leak or similar.

My assumption was just to mention that a "crash" for a vulnerability is something
we might really like at the end :)

>I have no problem in principle with a package that is orphaned upstream and
>is now maintained only in Debian/Ubuntu. There have certainly been many
>other examples of this, and such packages are not categorically worse than
>those that have a separate upstream.
>
>My understanding is that most former xchat users find hexchat to be a
>reasonable replacement. Can you explain why you do not?

it is, but new features breaks it from time to time (eg. 1.14.0 vs 1.14.1, the latter
has been pushed because of the previous one not being suitable for usage), moreover
we still don't have a clean upgrade path from xchat to hexchat, at least for configuration files.

People might want to keep it, until we smoothly upgrade them and move around configuration.
(t...

[Jeremy Bícha (jbicha)]

On Wed, Apr 4, 2018 at 2:01 AM, Gianfranco Costamagna
<email address hidden> wrote:
> we still don't have a clean upgrade path from xchat to hexchat, at least for configuration files.

I don't give much weight to this reason since xchat wasn't in Ubuntu
16.04 LTS. Therefore, there is no upgrade problem.

Thanks,
Jeremy Bicha

[Steve Langasek (vorlon)]

n Wed, Apr 04, 2018 at 06:01:38AM +0000, Gianfranco Costamagna wrote:

> >An IRC client, in its default mode of operation, requires zero
> >authentication of a remote server. The server must therefore be
> >considered untrusted and potentially hostile. Even *with*
> >authentication, a remote server could be compromised.

> >Any security vulnerability involving a network client failing to validate
> >input from a remote source is a significant one.

> >And in my opinion, any network client whose upstream maintainer didn't
> >consider such vulnerabilities worthy of serious attention should not be
> >included in a stable Ubuntu release.

> >So please don't try to argue for xchat's inclusion by downplaying the
> >significance of security vulnerabilities.

> ack here, but sorry if I made this false assumption. the mean of that
> sentence was not "don't care because internet is broken or evil",
> but more a "hey, such vulnerabilities exists in probably *all* irc clients,
> including hexchat and others, at least in stable releases. You can do fuzzy
> testing against the versions to check them.

> So, while I *always* fixed CVEs on my packages, I also think we should
> focus more to real bugs, not something discovered by a fuzzy test, that
> affects probably most irc clients, with an userbase really low, and with a
> crash as effect and not a personal data leak or similar.

> My assumption was just to mention that a "crash" for a vulnerability is
> something we might really like at the end :)

Thanks for clarifying. Yes, a crash on invalid input that can't be turned
into a remote code execution vulnerability is definitely a lower priority,
and there's nothing wrong with recognizing that. We should also recognize
that there is a long history of security researchers finding ways to turn
bugs that were triaged as "just" crashes, into code execution
vulnerabilities, and therefore we should not be complacent.

> >I have no problem in principle with a package that is orphaned upstream and
> >is now maintained only in Debian/Ubuntu. There have certainly been many
> >other examples of this, and such packages are not categorically worse than
> >those that have a separate upstream.

> >My understanding is that most former xchat users find hexchat to be a
> >reasonable replacement. Can you explain why you do not?

> it is, but new features breaks it from time to time (eg. 1.14.0 vs
> 1.14.1, the latter has been pushed because of the previous one not being
> suitable for usage), moreover we still don't have a clean upgrade path
> from xchat to hexchat, at least for configuration files.

> People might want to keep it, until we smoothly upgrade them and move
> around configuration. (this is something somewhat slowly ongoing=

Jeremy's reply is relevant here, but in any case this is not a blocking
issue in my view; merely additional input for the xchat maintainer to
consider.

> >Do you have any collaborators on the upstream maintenance of xchat, or is
> >this truly an individual committment, with all the caveats that apply?

> no collaborators, even if at least other 2-3 DDs asked me to help, so I might not
> be alone, but since the package is "working" r...