On Wed, 19 Oct 2016 16:12:51 +0100, Wookey wrote: > Indeed. The current situation is that the existing version is so old > that it doesn't work properly with modern code any more, but the > maintainer has refused to do any of: > 1) upload a new package,
I'm not "refusing to upload a new package", I'm asserting that trading one set of problems for a worse set of problems is not a solution to a problem. The crux of the problem is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131 And I don't think it's contentious to suggest that upstream's proposed 'solution' of using chmod 777 on a privileged directory is not something that's acceptable for a distro package. Shigio contacted me privately in 2010, proposing this mechanism as a replacement for the interface that he and I first worked out in 1999 to do this securely in a way that was suitable for packaged software, and I gave him a detailed review of that, explaining why that wasn't a suitable answer, and what we'd need to do one way or another to make it one. But he then simply ignored that (and later feigned ignorance that we'd even discussed it - despite his own upstream changelog acknowledging that we had), and made a series of incompatible changes to do this anyway. At around the same time, Taisuke Yamada had also expressed an interest in this and tried to reason with him about sane ways to do this, but his comments were similarly ignored as well. I'd persisted with trying to find a common understanding that we could base a real solution on, well past the point where the discussion had become circular and repetitive, before ultimately becoming resigned to the horrible stalemate which occurs when what you're arguing against has devolved to a stubborn insistence that "your suggestion is not simpler than chmod 777". Until the discussion can move beyond that to recognise the problem, our options were always going to be limited. > 2) allow an upload which removes the offending CGI bit (which users > don't really care about anyway) If it was actually true that "users don't care about it", then it shouldn't be a problem to get upstream to remove it. But obviously that hasn't happened (or we wouldn't be having this discussion), and when I last floated that option in one of the re-runs of this, upstream outright rejected it too: https://lists.debian.org/debian-project/2013/06/msg00174.html The only thing he was interested in getting rid of was the option to actually run this securely, with an audited system-wide script. Not the parts where his own documentation and code comments say things like "if you put this on the public internet, you lose", or the part where he expects the CGI script must be installed in the same tree as the rest of the generated page content. It is true (in my opinion) that doxygen now does a much better job of this than htags does, and that it would be no great loss (again to me) for htags to just be killed completely if it can't be made sane and safe. But I think it's a big stretch to claim that is some sort of universal consensus, and that if we removed it, then we wouldn't just end up right back here again with someone seeking to override the maintainer to put it back, because it is essential functionality to them, even if the people pleading here now don't care about it. htags is essentially useless without the CGI support, since that is how it accesses the global tags to provide search and indexing. You really would be far better off just using doxygen and its search facility that doesn't require a CGI. But someone cares about this, because doxygen itself got a patch to let it use htags instead of its own source browser ... (whether anyone actually uses that I'll leave as an exercise for someone to research and report back to us on). So if what you really want to do is kill htags completely, then that's a discussion I'm willing to listen to, but it's going to take some evidence of a genuinely stronger consensus than an off the cuff "I don't care if we do that" - since you haven't so far told us which bits you _do_ use and care about, so it's a bit arbitrary to declare you, or some subset of what global currently includes, more important than anyone else in a "rob peter to pay paul" decision scenario. > 3) write something to change the local behaviour to be satisfactory. I wrote something to do this in 1999. The fundamental problem is itself nearly old enough to drink in pubs. And I've maintained it for as long as doing that was possible - but upstream has now gratuitously broken the interfaces that we added back then (with his agreement and collaboration and blessing) which enabled this to be done in a sane and secure way - so the only alternative to nuking htags if upstream is actively hostile to that now is to fork completely from upstream ... which is essentially what has happened by sitting on the stable version we currently have. Yes, it sucks. But unless somebody else can convince Shigio, or someone cares enough about adding new things to this to maintain a sane fork that we can distribute and promote instead, then every decision we might make from here will suck for someone. I've said (more than once to various people), that I'd take patches to add or fix things people needed to cover for other incompatible changes upstream has made which break other things too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166 ... but so far, nobody seems interested in spending anything more than someone else's time on investigating and fixing that either. > Upstream has been clear that they are not going to change how it > works, but they don't care if debian omits that bit or changes it > locally, [citation needed] I'm not aware of anywhere that upstream has said he is ok with us dropping htags or its supporting CGI. Only with dropping support for providing it securely in a system CGI directory ... I think you might be extrapolating from ambiguous (and yes, sometimes outright conflicting) statements on this, which apparently don't actually mean what we might have hoped they'd mean. But he appeared to clarify this in the negative in his most recent comments to that -project thread. If you're looking at something different to that, then please point, but I suspect this has become a chinese whisper that people here are repeating now, not something upstream actually said or believes. > so it seems to me that a maintainer has to do one of the > above three things. 5 years of this is more than long enough to > conclude that they are not doing their job adequately, and because of > our strong maintainership culture, are preventing other people from > doing that job. Which part of our strong culture is the one that prevents people from actually acknowledging that Hard Problems Are Hard? And that they are even harder when all you do is complain that somebody else didn't fix them for you already. Nobody has been prevented from sending a patch that would fix any actual problem they are having because of the version we currently ship. And of course, nobody has actually ever sent such a patch either. They haven't even actually gone so far as clearly identifying any actual problem they had beyond saying something along the lines of "some stuff seems not to work, I didn't investigate further" ... If your complaint is that "somebody who understands the problem has raised reasoned objections to somebody who doesn't uploading something that isn't suitable for inclusion in the distro" - then I'd call that a ringing endorsement of having delegated and responsible maintainers to shepherd such things. That doesn't remove the ability of other people to also actually contribute to trying to solve hard problems, in some more substantial way than saying "just close your eyes and upload it anyway". > It could just be NMUed, or a global6 uploaded so at least people would > have something to work with, but asking the TC to rule seems like a > more correct way to try and unbung this situation. Yes, I think a discussion here is probably more useful and helpful than the chaos and harm of ignoring the problems and uploading it anyway. I can't help the ghost of Angry Ian if he wants to prejudge things and try to play passive-aggressive mind-games with the actual TC delegates without actually bothering to read what was already discussed many times, but I am sympathetic to the people who currently feel like they have the short straw and are on the wrong side of the pain caused by the current situation. I'm also sympathetic to the other people who you'd be handing that hot potato to by asserting your problem is more important than theirs. I am the one stuck in the middle feeling everyone's pain here, so I have more motivation than all of you for finding a good and lasting solution :) So I think you probably need to clarify what you are really asking for here, since the original question as put to the -ctte glosses over a big bag of implications and consequences. It seems fair to assume that you aren't seriously asking them to endorse the idea of chmod 777 as an acceptable interface for distro software - but that's what "force the new version into the distro one way or another" actually means. So are you asking if we should package a version that has htags removed instead of what we currently have? Because that's the essential implication of "remove the offending CGI bit". Or are you asking if we should somehow fix the incompatibility with "many frontends", that nobody has explicitly detailed or reported yet. Because that's a possibility too, though arguably it's actually a bug in the "many frontends" and/or another fatal flaw in the upstream maintenance of this software that it keeps breaking compatibility by changing the meaning of existing options and renaming them gratuitously. Or something else entirely? When all you ask me is "upload global6 or else", there's not much I can usefully discuss except to repeat facts I've repeated many times before that still haven't changed. If you can acknowledge the problems with that, including the ones it would make for other people which you don't personally care about, then we can try to find some consensus on what a good way forward might be ... and point to that the next time someone asks "what needs to be done to fix this?". But that's hard to do when people are just tugging hard in some direction solely on their own self interest. I want a good solution to this at least as much as anyone else does, but the path of least resistance is what makes a river crooked, so if we don't want this to end up as some sort of bug infested billabong spreading disease to the people who use it, then we will need some better answers than just "blindly package and upload a new upstream version" - because the minimal work needed to do just that is not the actual problem here. Cheers, Ron