xchat and hexchat

Tue Mar 27 06:34:03 UTC 2018

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 across Free Software (and otherwise!)
for security vulnerabilities to be fixed by upstreams without disclosing
these were security vulnerabilities; and this doesn't have to indicate ill
intent on the part of the upstream.  Sometimes the upstream has nothing more
than a vague sense that a bug might be exploitable and it's not worth the
effort to prove it.

I don't think it in any way disqualifies hexchat for inclusion in stable
Ubuntu releases to know that upstream has fixed security bugs without going
through a particular disclosure process.  It is not even the responsibility
of the upstream maintainer to notify Ubuntu of such vulnerabilities (though
we certainly welcome having such notifications!), and for packages in
universe, many known vulnerabilities will unfortunately remain unfixed
anyway.  It is definitely not the upstream's responsibility to disclose the
details of security vulnerabilities for the benefit of an unrelated fork
from an older codebase.

> 5) having 40 patches is a complete nonsense, what is the problem if
> somebody is willing to maintain it that way?  would it be better if I
> create a new "upstream" release and upload a no-patch package?  it would
> end up in a similar result, I don't see the difference

I agree that this is no basis for excluding a package from an Ubuntu
release.  There are certainly other packages - including core packages -
that have longer series than this in debian/patches, and some of these are
regularly merged from upstream.

I do question the wisdom of maintaining software exclusively via
debian/patches over the long term, if indeed that's what you're doing here. 
But that's my personal opinion as a developer, and has nothing to do with
whether the package, today, should be removed from the release.

> 6) I'm willing to maintain it for bionic lifespan.

What, in practice, do you believe this maintenance will consist of?  Are you
planning to monitor CVE activity of related codebases to watch for issues
that may also affect xchat, or will this maintenance be entirely reactive in
response to critical bug reports?

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

Nothing so far says to me that we should indeed remove xchat, but I would
appreciate your answers to these questions which will help make it clear to 
the Ubuntu community where things stand.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org

[1] https://irclogs.ubuntu.com/2018/03/02/%23ubuntu-release.html#t23:08
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20180326/74458699/attachment.sig>