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.
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.
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
> 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.
> It is what we now have enabled in the package that Wookey uploaded to
> experimental.
At least now we have a version in Debian we can compare with. Noone has
claimed it would be perfect, but uploading this new version (to whichever
suite, really) was your duty as maintainer and you failed to do so in 6+
years.
> > Are there any other regressions that you are aware of in v6?
>
> In terms of the upstream code, the issues with htags are the main
> 'showstopper' I'm currently aware of. But I haven't tested the
> rest of it anywhere near exhaustively yet either.
>
> In terms of the package currently in experimental, there's a bunch
> of issues with it that would need to be fixed if we were going to
> want it in Stretch.
Please file these as bugreports, with appropriate severities. This is the only
way we will all be able to have a clear picture of what makes each version the
most suitable to release in Stretch.
> 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?
> 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.
> Because people saying "it's irrelevant, uploading 'something newer'
> is overwhelmingly more important" completely misses the point that
> uploading something newer unavoidably involves someone answering
> that question.
Uploading newer versions of upstream software is constantly about compromises,
functionality losses, and new functionalities. That's just how software
development works, and Debian is constantly following up on the new versions
of all sorts of software. With your approach, we'd have Gnome 2, KDE 3,
PostgreSQL 8.4 and GCC 4.4 in stretch, just with some compatibility patches,
because we'd have been too conservative. That's not the sort of Debian
releases I want to see.
> 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.
If all the problems come from "the htags from v6", what is blocking you from
at least providing the latest 5.x versions? If you _had_ backported whatever
fixed the #590053 bug from 5.9 to your 5.7 version, I could accept your global
version freeze. 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. 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.
> 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, and we all have now spent way too much time
discussing its maintainership, frankly.
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;
- the hard problems are impossible to fix;
- regressions or functionality losses brought by upstream changes must not be
inflicted upon our users;
I don't know yet what the good decision for the future maintenance of
src:global is, but I'm convinced that you have actually made a disservice to
'global' users, for way too long, and I want this to stop.
Sniping at the people who have gone through some effort to actually upload a
v6 version is not helping, at all. You should be grateful that they have
produced this effort, and _help_ them making this version of a package you're
the maintainer of. This was your duty all along.
I think a better service would be done by other maintainers, deferring the 'v6
in stretch' question to them. I'll start drafting a proposal along these lines
tomorrow.
Wookey, Vincent, Punit: would any of you be willing to receive the 'global'
package maintainer hat? (which would of course come with the possibility to
share and change the maintainer status afterwards.)
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.