Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Wookey 
On 2016-12-10 06:54 +1030, Ron wrote:

> So I've now orphaned this package, and he has my blessing and sympathy
> for being responsible for whatever happens with it from here.  I haven't
> filed a WNPP bug for that as we don't need to offer it to someone random.

OK. Cheers. Warm potato accepted :-)
 
> Wookey: if you want the complete git history, right back to the very first
> package in 1999, you can grab it from the Vcs-Git URL in the sid package.
> I'm not going to go Full Bruce and rage delete it, but eventually I should
> decruft alioth and remove it from there, so if you want it you should
> probably clone it somewhere that works for you.

OK. I don't use git unless I have to, so I'll let Punit worry about that.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

2016-12-09 Thread Uoti Urpala 
On Sat, 10 Dec 2016 06:54:17 +1030 Ron  wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contributed anything to either).  I'm afraid that's not
> how encouraging volunteers to contribute their time for you works ...
> sorry if this is news to you.

It was perfectly reasonable to ask that if you have any pretense at all
of actually doing the work expected of your maintainer position, you'd
contribute to creating packaging for the new upstream version, instead
of only attacking the people working on it.


> things.  But because the increasingly ill-named technical committee has once
> again refused to stick its collective necks out to actually offer technical
> advice when explicitly asked to.  We chopped some heads off the hydra, but

> Explaining things in careful detail has had every appearance of being a
> complete waste of my time whichever way this might have ended up.  The only

The fundamental problem with most of your technical arguments was that
they were arguments about upstream development, not about packaging.
Even if they were 100% true, they still would not justify how you have
handled the Debian package. If you disagree with upstream that way, you
should try to convince them, and if that fails and you care enough,
create a new upstream fork.

Instead, you turned the Debian packaging into a practical fork. That's
not the right place for hosting a new fork. You also obviously did a
bad job of maintaining your fork (given the complete lack of
development). Your attitude seems to have been that you insist on
keeping the original GLOBAL out of Debian, do no development at all
yourself, and if anyone has problems with your fork you insist that
they do the work of developing it. That's not reasonable at all.

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

2016-12-09 Thread Philip Hands 
Ole Streicher  writes:

> On 09.12.2016 08:37, Philip Hands wrote:
>>> On Wed, 07 Dec 2016, Philip Hands wrote:
 It could be much improved by making it more obvious that the heading is
 a heading.  Even if we're unable to stop headings having a checkbox, we
 could change the text and the hierarchy slightly to be something like
 this:

[ ]  === Debian Desktop Environments:
[x]  ... Gnome
>>> [...]
 Would that cheer people up without needing a major rewrite of tasksel?
>
> This improves the situation, and could probably done quite simple at the
> same place where the ellipsis (...) is introduced:
>
> https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366
>
> One just needs to find out here that it is actually a heading.
>
>> I think that should be a select, rather than a multi-select:
>> 
>>  -->  standard desktop (will install $DESKTOP)  <--
>>   standard server  (includes ssh)
>>   other use cases
>> 
>> (or however the UI presents it)
>> 
>> The reason for the extra bits in brackets is that I've always thought
>> the tasksel menu was hiding just a little too much of what was meant by
>> the options.
>
> I would vote for that, however we would need
>
> 1. someone willing *and* competent (the latter excludes myself) to
> implement this in tasksel,

Just to test things out, if one adds:

  url=hands.com/d-i/bug/846002/preseed.cfg

to the kernel command line (so, hitting TAB as the installer's boot menu)
it will tweaks d-i to have such a menu.

I suspect that the way it works could be improved (it could probably be
plumbed into tasksel itself) but it seems to do the trick, and should
let people have a play and give feedback without needing to create new
.iso images.

I've tried it interactively, but not yet with preseeding, which will
need either this to be changed to chain into your preseed, or vice versa
(if you can work out how, feel free to give that a try and see if you
can find what it breaks :-) ).

The files that do the trick are here:  http://hands.com/d-i/bug/846002/

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Sam Hartman 
> "Colin" == Colin Watson  writes:


Colin> As a maintainer who has sometimes had cause to do similar
Colin> things, I'm concerned at the standard being applied here.
Colin> Could you perhaps review the history around groff 1.18.1.1 ->
Colin> 1.20 for comparison?  This is a case that's all over and done
Colin> with seven years ago, so should be free of emotive
Colin> associations by now, and the history can be read through
Colin> reasonably quickly.

Colin> Here are some references: https://bugs.debian.org/196762
Colin> https://bugs.debian.org/374569
Colin> https://lists.gnu.org/archive/html/groff/2007-11/msg00011.html

Reading this first reference was enough for me to identify several
differences I believe are key.

First, upgrading to new upstream is presumed good, not always good.
My concern with Ron's position is mostly that  he wants the people
requesting a new upstream to justify that rather than wanting the htags
users to justify not breaking htags.

I think it was fairly obvious to everyone involved in the groff
discussion that the multibyte patch was required for Japanese man pages
among other things.
That is, I think there is evidence of the importance of the groff
multibyte patch in a way there's not evidence of heavy htags CGI use
here.
Put another way, the record presents evidence sufficient to overcome the
presumption that upgrading is good.

Second, you were responsive and pro-active.  You reached out to the
multibyte patch author.
You tried to forward port it yourself.

Third, there was an eventual way forward.  It was clear that groff would
eventually get to UTF-8 support good enough that we could use it.

So for these reasons, I think the groff situation is different in ways
that matter at least to my analysis.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Ron 
On Fri, Dec 09, 2016 at 05:13:48PM +0100, Didier 'OdyX' Raboud wrote:
> 
> What I see as fundamental difference here was your use of #196762 as a single 
> point of contact for the problem you were facing with groff 1.19, in which 
> you 
> explained, commented and followed up on what the problem was, what were your 
> thoughts, asking for help, and updating this bug regularly. You also used 
> this 
> single point of contact in later bugs:
 
  ...

> That's really the thing I miss most in 'global's history: it shouldn't need a 
> TC bug to get the 'htags' problem described properly, on a public, standalone 
> bug.

So you're saying "if only #574947 existed which did that"?
Oh wait.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Didier 'OdyX' Raboud 
Le vendredi, 9 décembre 2016, 15.03:14 h CET Colin Watson a écrit :
> On Fri, Dec 09, 2016 at 08:58:10AM -0500, Sam Hartman wrote:
> > However, the time at which Debian has last synced with upstream does
> > matter.
> > Six years is a long time.
> > Moreover, I believe that the standard you've used to evaluate whether
> > failing to sync for six years was acceptable is inconsistent with best
> > practices of the project.
> 
> As a maintainer who has sometimes had cause to do similar things, I'm
> concerned at the standard being applied here.  Could you perhaps review
> the history around groff 1.18.1.1 -> 1.20 for comparison?  This is a
> case that's all over and done with seven years ago, so should be free of
> emotive associations by now, and the history can be read through
> reasonably quickly.

Thank you for the example case, including its references.

> Now, my perception of this case is that there was a complex blocking
> issue with the new upstream release that affected a minority of users,
> and therefore I chose to hold back the new upstream until it could be
> handled in a way that did not cause serious regressions.
> 
> (…)
> 
> If the TC thinks my actions in the past were reasonable, then I would
> like any ruling here to be a bit more nuanced about cases of delayed
> syncing with upstream, reflecting whatever important differences you see
> between the two cases.

By a quick glance, your past actions _were_ indeed reasonable. And commenting 
on what differentiates this example with 'global' is a worthwile exercise.

What I see as fundamental difference here was your use of #196762 as a single 
point of contact for the problem you were facing with groff 1.19, in which you 
explained, commented and followed up on what the problem was, what were your 
thoughts, asking for help, and updating this bug regularly. You also used this 
single point of contact in later bugs:
> Unfortunately, for technical reasons (see bug #196762), it is extremely
> difficult to upgrade to the new upstream release.

All-in-all, although there are appeareances of equivalence between the two 
packages' histories, I certainly see fundamental differences in how the "new 
upstream version has problems that are hard to fix" question was addressed.

There can be valid, strong and solid technical reasons to hold back on new 
upstream versions, but what matters for us as a distribution, is how we 
collaborate and communicate about these blockers. Our SC's "We will not hide 
problems" is not to be understood strictly as "our bugtracker is public" only; 
it is a much larger concern that we should share, so as to make our 
collaboration as frictionless as possible, as well as make the technical 
problems not only reside in the package maintainer's heads, but to share them 
with the project.

That's really the thing I miss most in 'global's history: it shouldn't need a 
TC bug to get the 'htags' problem described properly, on a public, standalone 
bug.

Things like
> (we) are currently discussing changes to the CGI mechanism which may alter
> several things about how this is currently arranged.
in #590053, or the discussion in #574947 where Ron claims to have reached a 
private agreement that is not confirmed by upstream authors are un-
comprehensible for outsiders, which are left without a clue upon what needs to 
be fixed, or done.

The problem I have with how 'global' is maintained is not at all technical. 
Holding back on an old version because of 'htags' breakage _was_ a good 
technical decision back then. But the way this hurdle was (not) documented is 
just not how I want to see maintainers collaborate and "not hide problems" for 
packages in Debian.

The fact that the hurdle is _still not_ properly and publicly documented 
doesn't open room for helping the maintainer, doesn't bring clarity to 
newcomers and therefore puts the maintainer in sole responsiblity. Wei Lui 
expressed that problem clearly in #816924 (March 2016):
> I'm aware of the disagreement between Ron and Shigio, but it's so
> frustrating that no resolution has been found for so many years. There
> were talks about possible designs proposed by Ron and / or Shigio but
> it is just impossible for us users to do archaeology dating back to
> 1999 with no useful references whatsoever.

Another difference I see is this urge you felt. Two months after groff 1.19 
was released, you filed this bug documenting your concerns with it and no less 
than three months later, you wrote:
> I'm beginning to get a bit itchy about falling too far behind upstream
> here.

As a matter of fact, I do _expect_ maintainers to get itchy when they fall too 
far behind upstream. If Ron had documented the problem from the start (or at 
any later point in time, really), users would have found it, and debated ways 
out, patches, etc. This bug would have included upstream developers for a 
discussion _in public_. That bug would have helped joining forces, helped the 
maintainer determine the

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Ron 
On Fri, Dec 09, 2016 at 11:58:02AM +0100, Didier 'OdyX' Raboud wrote:
> Le vendredi, 9 décembre 2016, 04.55:20 h CET Ron a écrit :
> > > 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?
> 
> That code is now in Debian (experimental), so yes, I do expect you to act in 
> good faith and report bugs you see. You are obviously quite versed in how 
> 'global' works, and that's undoubtedly valuable to produce the best possible 
> 'global' package.

No, the code in experimental has that 'fixed', by commenting it out and
inviting the user to uncomment it themselves.

The context for this, was that was the code which was proposed to be
uploaded, and which was last discussed, at the time this was brought
to the ctte.  It never was uploaded to any suite, just published in
collab-maint, and I think Punit provided packages somewhere else.

The code in experimental does have some eye raising things in it, but
nothing that I've yet traced through as being definitely exploitable.
But I also haven't given it a serious audit yet, just eyeballed it
quickly for obvious things.

> > 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?
> 
> It doesn't: it shouldn't take 3 stable releases to get a new upstream release 
> for a leaf package.

There's a difference between blindly uploading a new upstream and
actually having a solution to the problem which is the reason that
it wasn't.

I made that reason very clear, and invited proposed solutions in
the original 'new upstream' bug, #574947.  Nobody else, except
Taisuke and I ever made any effort to deal with that.

Taisuke and I both considered the secure use of htags to be an
important use case.  But given the time that has gone by, and the
fact that the upstream code in what is currently in experimental
has completely eliminated any possible use from a secure system
location now, and how doxygen's seach facility has improved in
the last couple of years - my opinion has likewise changed in line
with that changed circumstance.

But it's taken all of "3 stable releases" for that to actually
change ...  this wasn't all the case at the time of the freeze
for Jessie, or before.


I still think it would be rude to burn the remaining users on
such short notice - but I don't think we should delay doing that
any longer than the end of the Stretch freeze.  And if there is
sufficient consensus to say "burn them immediately", I've already
said I'm ok with that too.  But I would want there to be a consensus
of people who'd have my back about doing that.  Else we just have
the same situation as we do now, where people abuse me for not doing
exactly what _they_ would have preferred.


> > 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.
> 
> By "(very) long discussion", do you mean these 8 mails ?
> 
>   http://lists.gnu.org/archive/html/bug-global/2010-08/threads.html#6

No.  That was one thread of many.  But aside from what's also in
the BTS, and on -devel (or was it -project?), the vast majority
were private emails, and span many years of trying to move this
forward one way or another.

Bug#841294: global maintainer : Draft ballot

2016-12-09 Thread Didier 'OdyX' Raboud 
With the precious help of Phil and Sam, here comes a draft ballot. It is 
attached to this mail, and has been committed to the TC's git repository [0].

It contains the following ballot options:
> - Option A - Reaffirm Ron Lee as 'global' maintainer (§6.1.2)
> - Option B - Declare Wookey as 'global' maintainer (§6.1.2)
> - Option C - Decline to rule, consider case closed
> - Option FD - Further discussion

I hereby open the discussion period, and welcome any amendments on the 
background, rationale, ballot options or the closing words, of course. Please 
apply english wording and all 'obviously consensual' fixes directly in git.

I would like to be able to start a vote on Monday.

-- 
Cheers,
OdyX

[0] https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/
841294_global/draft
# Background

* In #841294, the Technical Committee was asked to overrule the
  maintainer of the 'global' package to get a new upstream version
  packaged.
* As a matter of fact, at the time #841294 was filed, the 'global'
  package's latest upload to unstable had happened in October 2010,
  despite several requests for newer 'global' upstream releases and
  bugreports.
* The discussion, involving various people ranging from bugreporters,
  Debian contributors, the 'global' maintainer, and some TC members, has
  clarified two lines of argumentation around the maintenance of the
  'global' package':
   - global is fine as it is, version numbers are no silver-bullet, and
 there are severe problems in the new upstream versions, that are
 being discussed with upstream.  New features could always be
 backported to the Debian version if worthwhile bugs were reported.
   - there's a rightful expectation to get new upstream versions, even if
 they introduce regressions or functionality losses. No amount of
 upstream problems justify holding new versions back over multiple
 release cycles.

# Rationale

* Our Social Contract's "We don't hide problems" implies that
  maintainers go through reasonable effort to make their packages'
  problems visible; and the usual way is to use the Debian bug tracker.
  It also implies reporting upstream flaws to upstream, ideally in public.
  Adding references to the BTS would avoid the impression that nothing had
  been done.
* Integrating recent versions of upstream software is a maintainers'
  duty, as Debian is a primarily a software distribution; distributions
  exist to facilitate users' access to upstream software. Uploading recent
  versions and making them available to Debian users on a somewhat regular
  basis is our way to find, address and correct problems brought in by new
  upstream releases. The 'experimental' suite exists explicitly for the
  purpose of testing software not immediately suitable for release towards
  future stable releases.
* If the maintainer decides that our users will be best served by not
  upgrading, this should be explicitly stated.  The README.Debian file
  of the package would be a good place to do this, as well as in response
  to bugs requesting upgrades.
* The argument that features could easily be backported would carry
  significantly more weight if there was evidence of patches for past
  bugs being acted upon in a timely manner.

# Ballot

- Option A - Reaffirm Ron Lee as 'global' maintainer (§6.1.2)

- Option B - Declare Wookey as 'global' maintainer (§6.1.2)

- Option C - Decline to rule, consider case closed

- Option FD - Further discussion

# Closing words

We invite all interested parties to contribute in good faith for the
best possible 'global' package. Filing bugs with appropriate severities
is every user's duty, and it is important that those who understand the
package best continue to provide their best inputs.


signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Wookey 
On 2016-12-08 17:03 +0100, Didier 'OdyX' Raboud wrote:

Sorry missed this in all yesterday's mail.

> 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.)

Punit is happy to be maintainer. I am happy to co-maintain with him
(now that I'e gone the trouble of finding out a reasonable amount
about the package).

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Wookey 
On 2016-12-08 17:33 +, Wookey wrote:
> On 2016-12-08 23:32 +1030, Ron wrote:

> > But it also outputs a .htaccess enabling execution in the directory
> > where the output is generated, whether you want to use it from there
> > or not (and adds a second CGI, and a bunch of jquery doing AJAX too).
> 
> The world is absolutely full of jquery doing AJAX. That's not bad in
> itself (much as some of us prefered the 'old web'. We should make it
> use system jquery. 

OK. I tried making it use system jquery and some of the icons in htags
seem to go missing. So the internal jquery-treeview and
jquery-suggests may be incompatible. Needs a bit more research, so
we'll ship the internal one in 6.5.5-0.3 for now.
 
> > the icons and javascript and css for htags 

> Good point. 
> That's an easy fix.

Included in 6.5.5-0.3 which I'm about to upload. So that fixes
#587489, (which has only been pending with a patch since May 2011).

(currently shipped in /usr/share/gtags rather than
/use/share/global/gtags because upstream needs patching to sort that
properly. One thing at a time.)

And now htags browsing has nice little icons for moving about. shiny :-)

We checked that 6.5.5 also fixes #847303. It does.

I have a query pending with Ron for if it's OK with him to move to
0-day uploads to experimental as I don't think the conventional NMU
delay is actually helping anyone in this case. It just makes things
slow. I'll just replace the pending 0.2 upload with this 0.3 one for
now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Sam Hartman 
> "Didier" == Didier 'OdyX' Raboud  writes:


Didier> That code is now in Debian (experimental), so yes, I do
Didier> expect you to act in good faith and report bugs you see. You
Didier> are obviously quite versed in how 'global' works, and that's
Didier> undoubtedly valuable to produce the best possible 'global'
Didier> package.

Ron,  I would prefer that Didier use a different tone.
However, it's my opinion as someone who will be voting on this that
Didier is essentially right that your view of this situation and of the
responsibilities of a Debian maintainer are inconsistent with the
project as a whole.
You have continued to try and frame the discussion in the terms you
would prefer.
I have considered those terms, and I do not find framing the discussion
in those terms compelling.

In the language similar to the  IETF, used only because we're both familiar with
it, the technical issues surrounding global-6 and the question of
evidence regarding htags have been considered.  My judgment of the
discussion is that the rough consensus here is that those issues are not
significant compared to failing to upgrade global in six years.  That
is, we in this discussion have reach an informed opinion that those
issues are not significant enough to block.  It is my opinion you are in
the rough.

I think the question before the TC is (and is properly) how should
global-6 be maintained and whether you are the person to do that.

You have tried to frame it arguing that the version number doesn't
matter.
I absolutely agree.
However, the time at which Debian has last synced with upstream does
matter.
Six years is a long time.
Moreover, I believe that the standard you've used to evaluate whether
failing to sync for six years was acceptable is inconsistent with best
practices of the project.

--Sam

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Shigio YAMAGUCHI 
Hi all,
Please forgive me one more comment.

Mon, 24 Oct 2016 19:31:05 +1030, Ron wrote:
> ... and it may well be that this has actually happened now with
> upstream's decision to drop all support for providing a secure
> system CGI of any form that people can use for this.  The upstream
> code is basically now back to what it was in the 90's, with the only
> way to use this being to allow execution of a generated CGI in the
> same tree as the html content.  Which was already well known to be a
> dangerous and ill advised idiom even back then ...

Apache + system CGI is somewhat overdone to use htags.
GLOBAL is just a source code tagging tool for developers;
it is not a system to publish something to the world.

My answer is htags-server(1), a private http server for htags.
You should invoke this command for each project like this:

$ gtags
$ htags --suggest2
$ htags-server
Please access at http://127.0.0.1:8000
Python2 http/cgi server
Serving HTTP on 127.0.0.1 port 8000 ...

You can see the output of htags through 'http://127.0.0.1:8000'.
It is easy to use, and is safer because it runs with user's
privilege without publishing to the network by default.
This command was added to GLOBAL-6.3 in 2014.

IMO, it is useless to continue supporting system CGI.
It is difficult to set up, and never makes something safer.

Regards,
Shigio
-- 
Shigio YAMAGUCHI 
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
I don't like FUD.
   -- Anonymous

December 2016 TC meeting is at 'Thu Dec 22 18:00:00 UTC 2016'

2016-12-09 Thread Didier 'OdyX' Raboud 
The December Debian Technical Committee Meeting will happen at

date -d 'Thu Dec 22 18:00:00 UTC 2016'
in #debian-ctte on irc.debian.org

The meetings.ics file [0] and the agenda were updated accordingly in git;
please make any necessary changes.

The meeting poll has also been updated for the January & February meetings,
please update your preferences.

[0] Pointed by https://deb.li/tcmeetings

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Shigio YAMAGUCHI 
Hi,
2016-12-09 18:26 GMT+09:00 Philip Hands :
> > open(PIPE, "-|") || exec '@globalpath@', '--result=ctags-xid',
> > $flags, $pattern;
>
> Is it not the case that this last line forks and execs global, passing
> $pattern as a parameter to global's -e option, and that $pattern is
> untrusted input?

Yes. $patern is untrusted input.

> Looking at global.c it seems that before it is passed on to popen, it is
> run through quote_shell() which quotes any single-quotes in the string.
>
> That seems to deal with Ron's assertion that it's exploitable, although
> I have a slight feeling of impending doom about relying upon just this.

I agree.
I uses popen() in global.c to call idutils(1). I would like to rewrite it
in near future.

> Would it not be wise to make the network-facing perl code runnable with
> strict and taint turned on, if only to stop people reacting with horror
> at first glance?
>
> I presume patches would be welcome?

Of course! Thank you.

Regargs,
Shigio

-- 
Shigio YAMAGUCHI 
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Didier 'OdyX' Raboud 
Le vendredi, 9 décembre 2016, 04.55:20 h CET Ron a écrit :
> > 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?

That code is now in Debian (experimental), so yes, I do expect you to act in 
good faith and report bugs you see. You are obviously quite versed in how 
'global' works, and that's undoubtedly valuable to produce the best possible 
'global' package.

> 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?

It doesn't: it shouldn't take 3 stable releases to get a new upstream release 
for a leaf package.

> 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.

By "(very) long discussion", do you mean these 8 mails ?

http://lists.gnu.org/archive/html/bug-global/2010-08/threads.html#6

As far as I could see, this is the only thread in all of bug-global's (public) 
history in which you contributed, hence your only public input to upstream 
about how >> 5.7.1 versions have problems in your opinion.

Is there another public bug tracker somewhere that I missed?

Did you have other conversations with upstream? If so, where can we find them?

> > 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.

Fair enough. Sorry for assuming the breakage was in from 6.0 on.

I'm purposedly not answering to the rest of your email, as I think the TC now 
has enough information to issue a decision.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Wookey 
On 2016-12-09 11:58 +0900, Shigio YAMAGUCHI wrote:
> Hello all,
> 2016 19:05:55 +, Wookey wrote:
> > The .cgi scripts are generated from .in files which are correctly
> > parameterised with @PERLPATH@ and @GLOBALPATH@ etc. Upstream
> > unhelpfully ships pre-generated versions with the above arbitrary
> > local paths, but we kicked the build to force regeneration of these so
> > that all the scripts come out with correct debian paths. That was in
> > 6.5.5-0.1 and is in 6.5.5-0.2 (with ctags path set correctly
> > too). Please file a bug if we missed any.
> 
> It's my mistake. I will fix it soon.
> 
> It is helpful if these bug reports are sent to bug-glo...@gnu.org.
> Thank you in advance.

Yes. Now that we have the package in some sort of reasonable shape in
debian we will forward the relevant bits upstream, in order to
minimise debian patches. There are quite a few things we want to
discuss :-)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#841294: Overrule maitainer of "global" to package a new upstream version

2016-12-09 Thread Philip Hands 
Hi Shigio,

Thanks for getting involved.

Shigio YAMAGUCHI  writes:

> Hello all,
>
> 2016 23:32:44 +1030, Ron wrote:
>> 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.
>
> This code is for Windows; it is not used in UNIX.
> Ron's quotation seems to be part of the following code:
>
> --
> [global.cgi.tmpl.in] (global-6.5.2)
> --
> if ($^O eq 'MSWin32') {
> open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern
> |");
> } else {
> open(PIPE, "-|") || exec '@globalpath@', '--result=ctags-xid',
> $flags, $pattern;

Is it not the case that this last line forks and execs global, passing
$pattern as a parameter to global's -e option, and that $pattern is
untrusted input?

Looking at global.c it seems that before it is passed on to popen, it is
run through quote_shell() which quotes any single-quotes in the string.

That seems to deal with Ron's assertion that it's exploitable, although
I have a slight feeling of impending doom about relying upon just this.

Would it not be wise to make the network-facing perl code runnable with
strict and taint turned on, if only to stop people reacting with horror
at first glance?

I presume patches would be welcome?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

2016-12-09 Thread Ole Streicher 
On 09.12.2016 08:37, Philip Hands wrote:
>> On Wed, 07 Dec 2016, Philip Hands wrote:
>>> It could be much improved by making it more obvious that the heading is
>>> a heading.  Even if we're unable to stop headings having a checkbox, we
>>> could change the text and the hierarchy slightly to be something like
>>> this:
>>>
>>> [ ]  === Debian Desktop Environments:
>>> [x]  ... Gnome
>> [...]
>>> Would that cheer people up without needing a major rewrite of tasksel?

This improves the situation, and could probably done quite simple at the
same place where the ellipsis (...) is introduced:

https://sources.debian.net/src/tasksel/3.38/tasksel.pl/#L360-L366

One just needs to find out here that it is actually a heading.

> I think that should be a select, rather than a multi-select:
> 
>  -->  standard desktop (will install $DESKTOP)  <--
>   standard server  (includes ssh)
>   other use cases
> 
> (or however the UI presents it)
> 
> The reason for the extra bits in brackets is that I've always thought
> the tasksel menu was hiding just a little too much of what was meant by
> the options.

I would vote for that, however we would need

1. someone willing *and* competent (the latter excludes myself) to
implement this in tasksel,

2. someone convincing Cyril that this is ready to go into Stretch:

On 08.12.2016 23:20, Cyril Brulebois wrote:
> While it's clear to me we need to fix the blends situation at some point
> before the release (couldn't find time to do so yet; last resort option
> is masking all of them entirely), I'm rather dubious about changing the
> package selection/tasksel screen at this point of the release cycle.

Volunteers for any of those tasks?

Best regards

Ole