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

> >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" right now, nobody will add 
> himself
> to the uploaders list, because right now there are a reason for a new upload

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

> I can just say that my ubuntu membership is dated 2005, I never left the
> committment for my packages to anybody else, including stuff more
> critical, like virtualbox (and please trust me when I say that vbox is
> such a difficult piece of software to maintain).  I don't plan to stop
> contributing in the foreseeable future, and I want to keep the package
> safe and in the archive, with my best knowledge around it, and all the
> good faith from my side I can have.

> You can see that I'm alone even for vbox, but I know there are a lot of
> other people around knowing it, just they won't do any kind of work,
> probably until I stop doing it :)

Regardless of the length of your involvement in Ubuntu, this does make
you a single point of failure for xchat; and unlike for virtualbox, you are
both the de facto upstream and the package maintainer for xchat.  Five years
is a long-term committment for an individual.  You may /intend/ to take care
of this package for five years, but those decisions aren't always within our
control.  I think you are doing a disservice to users if you make xchat
available in the LTS release without at least making an effort to identify
collaborators who would be willing to pick this up if you were unable to
carry it forward.

However, that is again merely a recommendation on my part, and not something
that I consider a reason for me to remove the package from the release.

> Last point, I live near hexchat maintainer, we talk daily about our
> packages, and we disclose issues and fixes, this is not really a war,
> neither an "issue" at least from maintainers opinion.  Mattia is a great
> packager, I even had a chance to meet him some days ago, and I think
> having two packages (and eventually a safe upgrade path), will make things
> better for everybody, if the cost is to maintain a software for 5 years
> more in the archive.

> cheers!
> (sorry for the delay, but I still prefer to use my time for bugs and
> fixing stuff, even if such discussions are really important for the
> community!)

I understand, and don't disagree.  Thank you for taking the time to reply.

At this point I don't believe there's any reason for removing the xchat
package from the bionic release given your interest in continuing to
maintain it.  I am therefore going to close this bug 'wontfix'.

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/
slanga...@ubuntu.com                                     vor...@debian.org

Attachment: signature.asc
Description: PGP signature

technical-board mailing list

Reply via email to