Bug#841294: Overrule maitainer of "global" to package a new upstream version
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?
Reply to: