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, , 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/