Re: xchat and hexchat
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. (this is something somewhat slowly ongoing= >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. sure, this wasn't a really strong point on my side :) >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. ack >What, in practice, do you believe this maintenance will consist of? Are you &g
Re: xchat and hexchat
n Wed, Apr 04, 2018 at 06:01:38AM +, 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" 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 woul
Re: xchat and hexchat
On Wed, Apr 4, 2018 at 2:01 AM, Gianfranco Costamagna <costamagnagianfra...@ubuntu.com> 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 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: xchat and hexchat
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 +, 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 w
Re: xchat and hexchat
Hello, >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) 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) 3) I still need to reproduce the ctrl+i crash, I failed so far 4) see my point here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891982#35 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 6) I'm willing to maintain it for bionic lifespan. 7) people debating about something is not a good reason from stopping adoption or remove it (cfr: init systems war :p ) 8) both upstream/hexchat and Ubuntu/xchat maintainers opinion are biased, so, consider that here I'm just making a point for xchat, not against. just my .02$, feel free to do whatever your hat demands to do, I'll happily accept any decision you will take on this matter :) (I'll continue to maintain it in my ppa anyway, unless you ask me to stop doing it :p ) thanks for reading, (Robie, please bounce the email in case it doesn't reach the two lists) Gianfranco -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: xchat and hexchat
On Thu, Mar 08, 2018 at 10:01:32PM +, Robie Basak wrote: > I'd like to bring the release team's attention to this bug: > > https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169 > > This seems like a matter where people are getting quite personally > and emotionally involved, so I think it's probably best for most of us > to stay out of it and leave it to our designated leaders to make a > decision, per our CoC. > > I'm not sure if it's an archive admin thing, a release team thing, or a > tech board thing. If it isn't obvious which team should make the > decision, perhaps it should be left to the TB to decide that first. But > if a decision needs to be made, that decision should probably be made > before Bionic's release, so I thought it'd be appropriate to bring it to > attention on this list now. > > As the only one of these three teams that has regular meetings is the > TB, should this be added to the TB agenda? 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. Please note that I have no horse in this race. I have my opinions but either way would be fine with me, as long as the bug gets closed with _some_ resolution. I'm bringing this to the TB as I think we need _a_ decision and it would be helpful to the community to not let it languish. Thanks, Robie signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: xchat and hexchat
hi, Am Donnerstag, den 08.03.2018, 22:01 + schrieb Robie Basak: > I'd like to bring the release team's attention to this bug: > > https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169 > ... > if a decision needs to be made, that decision should probably be made > before Bionic's release, so I thought it'd be appropriate to bring it > to attention on this list now. as an extra data point, there is an upstream maintained hexchat snap in the store that tingping (upstream) himself keeps well up to date, also the (slightly angry) blog post he wrote (linked in the bug description) makes its rounds through the social channels currently ... ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
xchat and hexchat
I'd like to bring the release team's attention to this bug: https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169 This seems like a matter where people are getting quite personally and emotionally involved, so I think it's probably best for most of us to stay out of it and leave it to our designated leaders to make a decision, per our CoC. I'm not sure if it's an archive admin thing, a release team thing, or a tech board thing. If it isn't obvious which team should make the decision, perhaps it should be left to the TB to decide that first. But if a decision needs to be made, that decision should probably be made before Bionic's release, so I thought it'd be appropriate to bring it to attention on this list now. As the only one of these three teams that has regular meetings is the TB, should this be added to the TB agenda? Thanks, Robie signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
