On Thu, Dec 08, 2016 at 05:03:40PM +0100, Didier 'OdyX' Raboud wrote: > Just commenting to some specific points as, despite an explicit request, you > have failed (and spectacularly so) to provide brief answers. That's not > helping a quick and clear path towards resolution.
Now I feel like goldilocks, first I'm bad because I didn't respond enough, now I'm bad because I respond too much. But apparently, I should have actually said just a little more in this one too, to explain to you how perl works :) So I'll do that now! > Le jeudi, 8 décembre 2016, 23.32:44 h CET Ron a écrit : > > On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote: > > > Perhaps you'd be kind enough to either confirm or correct my perceptions > > > of the current situation: > > > Version 6 includes a CGI script that one is expected to install in a > > > manner so hopelessly insecure that we'd not accept it in Debian. > > > > For the version (…) that I nacked, which is where this appeal to the ctte > > started from, that's absolutely true. Not only did it have the 'chmod 777' > > interface to enable it, it had little gems in it like this too: > > > > open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern |"); > > > > Which for those who don't speak it, is perl for "anyone can execute > > arbitrary shell commands by typing them into a web browser", since > > $pattern is an unsanitised, untrusted, input from the query string. > > If you haven't yet, I urge you to use our standard interface to report such > bugs; please make sure issues like this one are public on our bugtracker, > with > correct found/notfound version markers. Do you really want entries in the tracker for buggy code that was never in Debian, because I nacked Punit uploading things he didn't understand with a vague promise to maybe look at them later? > This also applies to group who has uploaded the experimental version: please > version-close bugs that this version fixes. > > For that specific Perl problem, I'd love to be enlightened in how the version > in 6.5.5 is significantly worse than the code in 5.7.1-3's global.cgi.tmpl: > > http://sources.debian.net/src/global/5.7.1-3/htags/global.cgi.tmpl/?hl=152#L152 Ok, you don't speak perl ... http://perldoc.perl.org/functions/open.html http://perldoc.perl.org/perlsec.html But in this case, it's also not that different to shell best practice. "You would want to use the list form of the pipe so you can pass literal arguments to the command without risk of the shell interpreting any shell metacharacters in them." > > It also made changes that guarantee everyone will need to fork it > > for distro use, because it now hardcodes a fun mix of paths, like > > /opt/local/bin for perl and /usr/local for global et al. > > That's a _very_ typical distro maintainer's job, really. But still a regression in this code where that previously wasn't needed. > > There's little things like it still having .la files in it, and > > static libs for things that are supposedly 'plugins'. Which aren't > > a big deal on their own to fix, but again suggests that if 'obvious' > > things like that were missed, there's a good chance there will be > > more issues than what I've already seen in a cursory review. > > I don't really appreciate how you're sniping at the maintainers and uploaders > of the version currently in experimental, while doing the job to keep up with > recent versions of global was _your_ duty all along. What about actually > _helping_ making this global version as good as you think it should be? How is pointing out real issues with it "sniping at them"? We have people here saying what a wonderful and perfect job they are doing, while slagging off at me. Including yourself. I didn't see you telling them that sort of thing is not appreciated. Last I heard it was considered bad form to change the package format in an NMU too if you want to talk about "duty". > > What I'd _like_ to see a good consensus on though, is a little more > > than that - because I don't think "should we ship v6 in Stretch" is > > the right question, or rather a _sufficient_ question. Because if > > the answer to that is "yes" - then we still have the question of > > "what should we do with htags in v6", and that's actually the one > > where things go all pear-shaped if we get it wrong. > > > > And even if the answer to it is "no", then that question _still_ > > remains as "what should we do with htags in v6 for stretch+1" ... > > The question was supposed to be asked, and answered in september 2011, when > global 6.0 was released. This question should have been answered for squeeze, > eventually wheezy, really. The question *was* asked (by me), repeatedly. Nothing material changed to alter the problem and hence the answer. Now we're talking about what to do among a wider group of people, given that it still looks like nothing material will change. The system works? > > And ignoring the issues around it totally leads to fun paradoxes > > like OdyX saying that one of the reasons it's important to have v6 > > is that it "fixes bugs like #590053" - when what the reporter of > > that bug wanted fixed is _exactly_ what we would lose by going to > > the htags from v6, and he was one of the people who also spent a > > considerable amount of time trying to work with upstream to have > > a secure system install of the CGI supported ... > > Actually, that bug is a very good example: the request is about a problem > fixed by upstream in 5.9. We still have 5.7, and this bug (filed in 2010, > before the freeze of _squeeze_) is not fixed in the version we're about to > ship in Stretch. And this _again_ is precisely why you thinking that it's unimportant to understand the problem, and that even if you don't you can leap to wild conclusions, is troublesome. That report led to both me and the reporter having a (very) long discussion with upstream about how to resolve the real problem that you keep assuming we never tried to do anything about. Nothing material changed to improve this after that discussion either. I don't blame you for not knowing that. But leaping to your own conclusions without asking isn't helping anyone understand better. > If all the problems come from "the htags from v6", what is blocking you from > at least providing the latest 5.x versions? We are providing the latest 5.x version that didn't break the interfaces we need. I'm talking about v6 here, because v6 is what we are talking about moving to next. > If you _had_ backported whatever fixed the #590053 bug from 5.9 to your > 5.7 version, I could accept your global version freeze. Yeah, that one is a fair cop. It probably just slipped through the cracks because both Taisuke and I were utterly exhausted after the discussion with upstream. I forgot about it, and he never chimed in again to remind me (though we have talked separately again since). I can add that one to the list if we do look at keeping v5 for a bit longer. > Point is, you haven't (we're talking about a 5+ years old bug), and > you continue to pretend there are unfixable bugs in 6.x. Why do you think it's "pretending"? I really would like to know which bit of this you really still don't understand? > It seems to me you're just _not_ interested in providing any other > version than this 5.7.1 one, and I don't understand why. What I'm not interested in, is repeating the same shitfight over and over, with it never getting even an inch closer to addressing the problems that have us stalled there. But I don't see why you claim I'm not interested in finding a way to actually move past this. I said right from the very beginning that while it was clear there was no easy way to move to a later version without breaking significant functionality, that historically was a very important (even the most important) part of this package, I thought that having this come to the ctte was actually a good opportunity to get a broader consensus about how we ought to deal with that. Which part of that don't you understand? I'd like to fix that, because it seems to be a major wall you've put up to us having the sort of conversation we should be having, instead of me having to fend off accusations based on imagined things. > > I'm pretty sure we can agree on some reasonable plan without the > > need for a vote, or to invoke the constitution to force anything. > > According to popcon and apt, 'global' is a unimportant package, with few > users > and no reverse dependencies, Which is another reason it's suffering for attention on many fronts including upstream. It has always been a very niche package, with very few users, all of whom are supposedly software developers. So if people like that can't or don't send patches, and/or are unable to get them accepted upstream - and it's not even like they report a lot of bugs (and that's not because they don't exist) ... And that it is no longer 'state of the art' at what it does ... It's state shouldn't really be all that surprising. And somehow blaming me for that seems a bit disingenuous. Punit promised to maintain his fork too, and it never saw even a single commit after the day he announced that, when he'd scratched his original itch. He promised to deal with the insecure CGI in his fork, but never did. Vincent claimed that he already had, and he couldn't remember whether he had or hadn't. And they still didn't do that before uploading to experimental. But somehow that is ok, but I'm the bad guy? > I can sympathize with some of your arguments: > - version numbers are not silver-bullets, and updating to new versions is not > a goal per-se; > - there are hard problems to solve in new versions of 'global' > - waiting another release will give you time to think a transition plan > through. > > But I disagree that: > - it's fine to keep the Debian package several versions behind, over multiple > releases; I've never said this was 'fine'. Quite the opposite really. I've said we didn't have a good answer. And the only alternative that anyone previously proposed was "the problem doesn't effect me personally, what if we just pretend it doesn't exist"? > - the hard problems are impossible to fix; I've laid out the options we have. You can't pull a fish hook out of your finger without it hurting. Someone is going to get hurt. Previously, I chose to avoid hurting the people who _had_ been contributing to trying to improve this, and to preserve a feature that historically was The Thing this was good at and for. Some people who weren't contributing complained that we should hurt those people anyway if it means they didn't need to help with their own patches. They said the other group of people didn't exist or weren't important. I've suggested a way that spreads the pain as fairly as we can. I've been asking if we have consensus for that, or if not, what this group of people is prepared to take responsibility for deciding as a way forward. > - regressions or functionality losses brought by upstream changes must not be > inflicted upon our users; We solve that problem with Debian specific things all the time. Even systemd diverges from upstream to avoid inflicting those things on our users. It's not _always_ possible, but when we can do it, it is one of the things that makes Debian awesome. There are _always_ tradeoffs. You don't like the one I picked, that fine. But you don't get to complain about that if this is the first time you've ever talked to me about it, _and_ you've not bothered to actually learn the reasons why things are like they are. And you're still not _actually_ addressing the problem at all. You're just scapegoating me, and hoping that if you give the problem to someone else, then you won't have to understand it and make a decision about what _you_ think is the right tradeoff. That's not really a way to encourage anyone else to consult the ctte for advice on how to break hard stalemates in the future. And I was really hoping we could kill that bird with this stone too, and show people by example that there is a better way to handle these sort of things... That the ctte could actually offer _technical_ advice arrived at by consensus, rather than just be arbiters of schoolyard spats. Wouldn't that be a genuinely nice outcome all round?
