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

[Philip Hands]

Raphael Hertzog  writes:

> So I have been following this whole discussion and I would like to
> provide my input to Ole and the blends team.
>
> - adding a new important package to work-around the fact that tasksel
>   maintainers were busy/inactive was not a good move. As you all
>   noted, the list of blends does not change often enough to warrant
>   separate maintenance. And by doing that you circumvented the
>   review by the debian-installer team which clearly has made design
>   choices to keep the installer simple.
>
> - the tasksel list with or without the blends already grew and can be
>   confusing for new users, it should not be shown by default but should
>   be offered as an option in all cases. See below for my suggestion.
>
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...
>
> I'm thus suggesting that blends-tasks should be removed and merged in
> tasksel-data. At the same time, we should fix the installer to bypass
> that confusing tasksel screen that we always get by default.
>
> 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?
>
> That would be a good change, yes.
>
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
>
> Install packages for a:
>
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options

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.

The reason to use "other use cases" is that eventually I think that
option should take you to a blends menu, where the first blend could be
a fake custom ("Custom selection of tasks" or similar) blend that drops
you into tasksel.  For now the tasksel menu as it stands will clearly do
the job, and will require least work if left alone.

I think it's better to drop the minimal server option at this level as
people wanting that probably know what they're doing, and will quite
often be preseeding anyway.

In the end, I think it might be worth treating desktop and server as
blends too, to make the logic less messy, but that's probably something
to look into after stretch.

I would hope to have time to work on this -- once I stop running a
temperature with the cold that currently has me sitting in bed.

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

[Vincent Bernat]

 ❦  9 décembre 2016 02:35 +1030, Ron  :

>> > How much am I supposed to hound you when you give a non-answer?
>> 
>> Maybe assume good faith and tell me that the answer doesn't fit you?
>
> You said you weren't interested in debugging it further, and so did
> Punit - how is it not assuming good faith to take what you said at
> face value?  You're the only two users of ggtags that I know of.

I said I weren't interested in debugging it further two months ago (and
I am still not interested). I didn't say such a thing during my initial
participation more than two years ago.

There is no amount of distraction that you can do _now_ that would hide
the inactivity you had during all those years. Even people reporting
easily fixable packaging-related problems with patches were ignored:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587489
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"


signature.asc
Description: PGP signature

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

[Shigio YAMAGUCHI]

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;
if ($?) {
error_and_exit("Cannot execute global.");
}
}
--

Though I don't recognize it is a security hole on Windows, I don't know
whether
it is true in the future. So, it is commented out in the latest release now.

--
[global.cgi.in] (global-6.5.5)
--
if ($^O eq 'MSWin32') {
#
# This code was commented out, because it may have a security hole
in the
# future.  To use this code, please uncomment in your own
responsibility.
#
#open(PIPE, "$global_command" . " --result=ctags-xid $flags
\"$pattern\" |");
error_and_exit("Feature not implemented.");
} else {
open(PIPE, "-|") || exec "$global_command", '--result=ctags-xid',
$flags, $pattern;
if ($?) {
error_and_exit("Cannot execute global.");
}
}
--

Please see the following thread, for the details.

[A CGI security hole on Windows?]
http://lists.gnu.org/archive/html/bug-global/2016-03/msg2.html


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.

Regards,
Shigio

-- 
Shigio YAMAGUCHI 
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
A long mail is hell.
   -- An anonymous philosopher in ancient Greece

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

[Christian PERRIER]

Quoting Raphael Hertzog (hert...@debian.org):

> Christian and Cyril, what are your thoughts on this? Do you think that if
> we come up with a patch implementing the above, we could get it in
> stretch? What would be the last delay to come up with such a patch?


From my own POV, I'm too far from core D-I development (except l10n)
nowadays to get a usefuul advice. When it comes at tasksel, I work in
low maintenance mode. When obvious things pop up, and if I notice
them, I usually apply fixes. The same stands when an upload is needed.

However, when it comes at design issues, I consider that my own advice
would be quite pointless and maybe even confusing.

Sorry for not being very helpful here.



signature.asc
Description: PGP signature

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

[Holger Levsen]

On Thu, Dec 08, 2016 at 06:27:46PM +0100, Raphael Hertzog wrote:
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options

/me likes. Thanks, Raphael.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Cyril Brulebois]

Hi Raphaël and all,

Raphael Hertzog  (2016-12-08):
> I'm thus suggesting that blends-tasks should be removed and merged in
> tasksel-data. At the same time, we should fix the installer to bypass
> that confusing tasksel screen that we always get by default.
> 
> 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?
> 
> That would be a good change, yes.
> 
> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options
> 
> You only see "tasksel" if you check the "Show me more options" which
> should be unchecked by default. There's code that translates each option
> into default selections at the tasksel level.
> 
> For instance, if you check "standard desktop" (checked by default like
> currently, then it enables the "GNOME" task (or whatever was set in the
> "desktop" kernel command line option) and the "standard installation".
> 
> If you check standard server, then you get "standard" + "ssh".
> If you check minimal server, then you get only "ssh".
> 
> If you select "Show me more options", you can see the effect of each
> option as you have some tasks already selected.
> 
> If we do that, then IMO it's fine if the tasksel screen is also cluttered
> with blends.
> 
> Christian and Cyril, what are your thoughts on this? Do you think that if
> we come up with a patch implementing the above, we could get it in
> stretch? What would be the last delay to come up with such a patch?

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.


KiBi.


signature.asc
Description: Digital signature

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

[Ole Streicher]

On 08.12.2016 18:27, Raphael Hertzog wrote:
> - trying to keep blends-tasks now because we have no better option on the
>   table right now is not a good move either. Had you not circumvented the
>   d-i review at the time you introduced blends-tasks, then maybe you could
>   have advertised the limitation of tasksel and we could have found sooner
>   someone willing to fix this even if nobody in the blends team had the
>   required skills...

The current solution was announced in bug #758116, which at that time
was assigned to tasksel, so you will find it in your mail archive. In
this bug, there is also a discussion about the limitations of tasksel
(starting in 2014, which is probably soon enough!), and also some
statements from the d-i team that they will probably not have time to
implement something here.

There is (and was) no circumvention of a d-i review. The menu is
available, and you can always review it and file a bug if it has a
problem -- like for any other aspect in Debian. This didn't happen for
the blends-tasks package so far. This shows that either the problems
were not big enough, or that d-i just had no time to do so. In the
latter case, I don't see why d-i would have more time if the tasks menu
would be in tasksel-data.

In my opinion it *is* a good idea to spread responsibilites; especially
when one team is overloaded and the topic fits so well into the field of
another team. And I see no advantage to move the responsibility of the
blends submenu back from the blends team to d-i.

> But more importantly, we need to not show that page at all. I would like
> to suggest a first screen:
> 
> Install packages for a:
> 
>   [X] standard desktop
>   [ ] standard server
>   [ ] minimal server
>   [ ] Show me more options
> 
> You only see "tasksel" if you check the "Show me more options" which
> should be unchecked by default. There's code that translates each option
> into default selections at the tasksel level.

If this could be implemented in Stretch, it would be a good compromise.

Best regards

Ole

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

[Ron]

On Thu, Dec 08, 2016 at 06:24:32PM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 8 décembre 2016, 18.14:12 h CET Tollef Fog Heen a écrit :
> > Using open like in the code snippet above is pretty much inexcusable in
> > this day and age.
> 
> Fair enough, thanks for the explanation.
> 
> Ron: could you point us to your report of this problem to the upstream 
> bugtracker or list? What was the answer you got?

I didn't audit that code exhaustively when Punit proposed uploading it,
there were already enough things obviously wrong with what he was
suggesting to go through all of it with a fine toothed comb to find more
before he'd shown any interest in addressing the first lot.

But it stood out like a sore thumb when I was fact checking the answer
to Phil's question about the CGI being a hopeless case, to be sure that
my answer was as accurate as possible over the range of changes that
have happened to it.

It certainly seems like something that anyone professing that they
should be trusted to maintain this probably should have been looking
at when the red flags went up about upstream's idea of what is
adequately secure ...

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

[Ron]

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 

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

[Wookey]

On 2016-12-08 23:32 +1030, Ron wrote:
> On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote:
> > Ron  writes:
> > 

Thanks for comprehensive reply, Ron. 

I wonder if it would make more sense to have this discussion in
#816924 which is the actual bug for 'should we upgrade global to v6,
and if not, why not?' You have to be in the know to find this on the
ctte mailing list.
 
> >   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.
 
> That one had removed the ability to run it from a secure system CGI
> location at all, and changed the way that it's generated yet again.
> 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.

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.

So this is not an outstanding issue, and no fork needed,but it would
be nice to improve upstrema's build and reduce debian patching here.

> It does comment out that line from above with a note:
> "To use this code, please uncomment in your own responsibility."

OK, so as shipped, that's not actually an active problem.

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

> It has a bunch of immediately obvious problems:
> 
>  - it still passes the unsanitised $pattern to global, which then
>passes it to popen (which again lets it be interpreted by the
>shell).

So $pattern used to be sanitised, because that's what CVE-2000-0952 is
about.  Ah and in fact it still is on line 148. Hmm, but that's after
using it in a pipe, which probably isn't much use... That is pretty
shoddy.

>  - it won't run with perl's taint mode enabled, because that
>simply kills it warning of unsafe operations on untrusted data.
> 
>  - perl's warnings aren't enabled, and it complains of other
>rookie code problems if you do.
> 
>  - Enabling 'use strict' makes it scream with pain and completely
>fail to compile and run.
> 
> 
> It would need more thorough auditing to confirm that there is(n't) an
> exploitable path through that, but given that it ignores even the most
> basic advice which perl has strongly recommended since perl4 was new
> and shiny, then if there isn't, it would be because of luck more than
> obvious care.

I don't claim any web security expertise, so will ask a
potentially-dumb question.  How much of a real world problem is the
shoddiness of this script if it is only used locally, using
htags-server (which is the only functionality now provided by the
package)? It exploses the script only to localhost unless you
explicitly configure it to do more, but not 'the net'. Nothing is done
as root, but it is run as 'you' so potentially gives access to 'you's
data, rather than all of www-data's data. 

The only report of an actual vulnerability I can find online ('global'
is a very unhelpful name to search for vulnerbilities!) is:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0952 (from
2000 for global prior to v4.0.1

Which claimed to be fixing this very issue, but apparently it didn't stay fixed?

And this same code exists in global v5.7.1 (indeed both usages are
there, including the now-commented-out one), so how exactly was that
safer?

> It might not be utterly unfixable, but you'd have to convince upstream
> that security is important, or completely fork it for debian, which
> brings us back to exactly where we are - unless we just remove it all.
> But that would need Time, whoever does it.

I have not grokked why the shoddy code in 5.7.1 is safe but the same
shoddy code in v6 cannot be let out. Did htmake+htconfig stop people
entering $pattern in the form?

> It is what we now have enabled in the package that Wookey uploaded to
> experimental.

Indeed. Bugs (and even better patches) are welcome.

> >   Also, for people that want personal access to htags there is a
> >   htags-server command that brings up a dedicated server to run the CGI
> >   as the invoking user, by default bound to a localhost port.
> 
> htags-server is a shell script that generates python or ruby code
> to use the HTTP server functionality they can provide.

I'd describe it as a script that runs the 

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

[Raphael Hertzog]

So I have been following this whole discussion and I would like to
provide my input to Ole and the blends team.

- adding a new important package to work-around the fact that tasksel
  maintainers were busy/inactive was not a good move. As you all
  noted, the list of blends does not change often enough to warrant
  separate maintenance. And by doing that you circumvented the
  review by the debian-installer team which clearly has made design
  choices to keep the installer simple.

- the tasksel list with or without the blends already grew and can be
  confusing for new users, it should not be shown by default but should
  be offered as an option in all cases. See below for my suggestion.

- trying to keep blends-tasks now because we have no better option on the
  table right now is not a good move either. Had you not circumvented the
  d-i review at the time you introduced blends-tasks, then maybe you could
  have advertised the limitation of tasksel and we could have found sooner
  someone willing to fix this even if nobody in the blends team had the
  required skills...

I'm thus suggesting that blends-tasks should be removed and merged in
tasksel-data. At the same time, we should fix the installer to bypass
that confusing tasksel screen that we always get by default.

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?

That would be a good change, yes.

But more importantly, we need to not show that page at all. I would like
to suggest a first screen:

Install packages for a:

  [X] standard desktop
  [ ] standard server
  [ ] minimal server
  [ ] Show me more options

You only see "tasksel" if you check the "Show me more options" which
should be unchecked by default. There's code that translates each option
into default selections at the tasksel level.

For instance, if you check "standard desktop" (checked by default like
currently, then it enables the "GNOME" task (or whatever was set in the
"desktop" kernel command line option) and the "standard installation".

If you check standard server, then you get "standard" + "ssh".
If you check minimal server, then you get only "ssh".

If you select "Show me more options", you can see the effect of each
option as you have some tasks already selected.

If we do that, then IMO it's fine if the tasksel screen is also cluttered
with blends.

Christian and Cyril, what are your thoughts on this? Do you think that if
we come up with a patch implementing the above, we could get it in
stretch? What would be the last delay to come up with such a patch?

Anyone up for the challenge?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

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

[Didier 'OdyX' Raboud]

Le jeudi, 8 décembre 2016, 18.14:12 h CET Tollef Fog Heen a écrit :
> Using open like in the code snippet above is pretty much inexcusable in
> this day and age.

Fair enough, thanks for the explanation.

Ron: could you point us to your report of this problem to the upstream 
bugtracker or list? What was the answer you got?

-- 
Cheers,
OdyX

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

[Tollef Fog Heen]

]] Didier 'OdyX' Raboud 

> 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's completely different.  It's basically system(3) on a concatenated
string with partial user-defined content vs execve(2) on a list of
arguments (some of which are user-provided).

perldoc -f exec and perldoc -f open might be useful.

Using open like in the code snippet above is pretty much inexcusable in
this day and age.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

[Ron]

On Thu, Dec 08, 2016 at 03:41:14PM +0100, Vincent Bernat wrote:
>  ❦  9 décembre 2016 00:32 +1030, Ron  :
> 
> > How much am I supposed to hound you when you give a non-answer?
> 
> Maybe assume good faith and tell me that the answer doesn't fit you?

You said you weren't interested in debugging it further, and so did
Punit - how is it not assuming good faith to take what you said at
face value?  You're the only two users of ggtags that I know of.

But I can repeat it again one more time.  Pretty please with sugar
on top can we have a real bug report, with real information to let us
assess whether your problem can be fixed with a trivial patch or not?

I'm assuming in good faith that you do know what a proper bug report
should look like, but I can give you some pointers in good faith
if you don't.  Looking at the bugs that Wookey filed should be a
good guide.

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

[Didier 'OdyX' Raboud]

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 

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

[Wookey]

On 2016-12-01 22:56 +0100, Philip Hands wrote:
> Wookey  writes:
> > On 2016-11-30 16:56 +, Ian Jackson wrote:
> >
> >> > And this last bit (integration with system web server) is the
> >> > functionality that had security concerns raised by Ron [etc.]
> >> 
> >> So, to be clear, it is this functionality which is dropped in the
> >> package that you and Wookey uploaded to experimental/delayed ?
> >
> > Said package is available as of today:
> > https://buildd.debian.org/status/package.php?p=global=experimental
> >  
> > And that functionality was left in as it was a self-contained patch,
> > pending determining whether in fact it remained useful/compatible or
> > not. So you still get htmake and htconfig commands.
> >
> > However I have now done some checking, and no it doesn't work any more
> > because it uses the btreeop command, which has been removed in current
> > upstream, and the --action option to htags which is also gone.
> >>  - Run the htags server on a high-numbered port somehow.  (Is there
> >>some kind of simple scriptery provided, to do this?)
> >
> > There is an example in the NEWS file, which should go in the man page. It's 
> > trivial:
> >
> > cd HTML; python -m CGIHTTPServer
> > or
> > cd HTML; python3 -m http.server --cgi
> >
> > Then browse to http://localhost:8000/
> 
> This functionality is also provided by htags-server(1), which is
> included in your package:
> 
>   https://www.mankier.com/1/htags-server
> 
> [BTW htags-server/htags-server.1 should be added to debian/global.manpages]

Well spotted. cheers for feedback.

OK. Punit (and I) prepared an updated package with the above fixes,
and htmake/htconfig dropped, so it's now pretty much a vanilla
upstream package.

Git repo is here:
https://github.com/punitagrawal/global

I've done a 5-day delayed NMU to experimental of 6.5.5-0.2. I'll put
some more details in #816924

This is essentially a candidate for unstable/stretch, should 'putting
v6 in unstable or stretch' be agreed-upon. So anyone who cares should
check it out and file bugs. 

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

[Ron]

On Thu, Dec 08, 2016 at 02:39:44PM +0100, Vincent Bernat wrote:
>  ❦  8 décembre 2016 23:32 +1030, Ron  :
> 
> > One is whatever it is that the third-party ggtags wrapper needs, which
> > aiui is what Vincent and Punit are most annoyed about.  But I don't
> > use emacs, and ggtags isn't even in Debian - and they haven't even
> > told me what error they see, let alone what operation(s) trigger it.
> >
> > Vincent just gave me the output of global's short --help, and said
> > "look, there's new options" - but we don't even know if it's actually
> > a 'missing' command line option that it fails on (or which one that
> > might be), or something else entirely.  My hunch is that one would
> > probably be pretty trivial to fix - either in ggtags or global, or
> > both - if someone who uses it engages with what I asked originally,
> > to file a separate bug from the 'new upstream' one, detailing the
> > actual problem, and is willing to test any proposed fixes even if
> > they aren't up to actually submitting a patch for that themselves.
> > I don't mind writing a patch if we know what actually needs patching.
> 
> And for this particular case, you didn't asked for anything more. You
> just said nothing.

This was the very simple question I asked, and your non-response to it:

  >> I am using gg-tags in Emacs and the current version of global in
  >> Debian just doesn't work with this mode.
  >
  > What changed incompatibly to make it not work?  And what would need
  > patching to fix that?
  >
  > I'd really much rather see problems get fixed than layered under even
  > more problems.  If someone familiar with Emacs has some details of
  > what doesn't work, and what needs to be done so that it will, that
  > sounds like a separate bug to be addressed to me.

  Some arguments seem to not exist in previous versions. I did not
  investigate more


How much am I supposed to hound you when you give a non-answer?
I've asked you again several times here, and each time you put in a
bunch of work to trot out some new accusations, but do nothing to
actually answer the question.

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

[Vincent Bernat]

 ❦  8 décembre 2016 23:32 +1030, Ron  :

> One is whatever it is that the third-party ggtags wrapper needs, which
> aiui is what Vincent and Punit are most annoyed about.  But I don't
> use emacs, and ggtags isn't even in Debian - and they haven't even
> told me what error they see, let alone what operation(s) trigger it.
>
> Vincent just gave me the output of global's short --help, and said
> "look, there's new options" - but we don't even know if it's actually
> a 'missing' command line option that it fails on (or which one that
> might be), or something else entirely.  My hunch is that one would
> probably be pretty trivial to fix - either in ggtags or global, or
> both - if someone who uses it engages with what I asked originally,
> to file a separate bug from the 'new upstream' one, detailing the
> actual problem, and is willing to test any proposed fixes even if
> they aren't up to actually submitting a patch for that themselves.
> I don't mind writing a patch if we know what actually needs patching.

Or, more likely, just like for #587489, #613011, #182188, #212040,
#218111, #669617, #756367 and #130091 (more than half of the open bugs
for global), you will just ignore the bug report. I have not included
#715980 and #716006 which are automated. I don't understand how you can
try to paint yourself as someone who cares about your users while there
is this public track record of your unwilligness to discuss with
anybody.

And for this particular case, you didn't asked for anything more. You
just said nothing.
-- 
The surest protection against temptation is cowardice.
-- Mark Twain


signature.asc
Description: PGP signature

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

[Ron]

On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote:
> Ron  writes:
> 
> > I'm not insisting that's what we should do.  But it's certainly an
> > option, and it dodges the bullet of having to say "Sucks to be you"
> > without any notice at all.  And it doesn't take anything away from
> > the people who want "new upstream or bust" for Stretch, because it
> > can still be available to them in backports.
> 
> Perhaps you'd be kind enough to either confirm or correct my perceptions
> of the current situation:

I'll try to be concise, but I might fail at 'brief', since I think it's
important to fairly summarise all sides of this.  Leaving people to
somehow reconcile narrowly polarised, conflicting sound bites isn't very
helpful.  And since I don't have the option to abstain from an opinion,
and aren't starting from an immutable one, I want to be as sure as I can
that _I've_ got the whole picture clear in my head before settling on
what I think is really best too.

If I show how I got there, and you disagree with my rationale, then I
have something that _I_ can rethink to maybe agree with you.  If all
I do is state a conclusion, and handwave the details of how I got there,
then at best we can agree to disagree, and at worst we get more random
trolls throwing mindless insults at me again.


>   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 Punit and Vincent wanted me to let them upload
and that people complained 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.
The version Punit published and suggested people should use had all
of that enabled in it - and he did that after I'd warned him there
was trouble that shouldn't just be ignored.


That was the shared state and history when this ctte bug was opened.
In the interests of seeing what new options we had _today_, I then did
an initial review of the most recent upstream state, which nobody else
had yet looked at, to see if anything material had changed which might
improve the situation.  My second post here included details of that,
but the short answer is "it got more complicated".

That one had removed the ability to run it from a secure system CGI
location at all, and changed the way that it's generated yet again.
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.

It does comment out that line from above with a note:
"To use this code, please uncomment in your own responsibility."
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).

It has a bunch of immediately obvious problems:

 - it still passes the unsanitised $pattern to global, which then
   passes it to popen (which again lets it be interpreted by the
   shell).

 - it won't run with perl's taint mode enabled, because that
   simply kills it warning of unsafe operations on untrusted data.

 - perl's warnings aren't enabled, and it complains of other
   rookie code problems if you do.

 - Enabling 'use strict' makes it scream with pain and completely
   fail to compile and run.


It would need more thorough auditing to confirm that there is(n't) an
exploitable path through that, but given that it ignores even the most
basic advice which perl has strongly recommended since perl4 was new
and shiny, then if there isn't, it would be because of luck more than
obvious care.

I'd not think it was a Good Plan to push this out as a "rush to beat the
freeze" upload of this source without a much more careful look at it,
and some effort spent actually fixing the already obvious deficiencies,
but the size of the truck you might drive through its holes is a bit
different to where we started from.

It might not be utterly unfixable, but you'd have to convince upstream
that security is important, or completely fork it for debian, which
brings us back to exactly where we are - unless we just remove it all.
But that would need Time, whoever does it.

It is what we now have enabled in the package that Wookey uploaded to
experimental.


>   However, it is possible to generate static content ...

Yes.

>   ... that achieves the
>   same aims, but at the cost of approximately doubling the disk usage,
>   and presumably also requiring more time to generate.

No.  This isn't just a 

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

[Philip Hands]

Ole Streicher  writes:

> On 08.12.2016 09:33, Wouter Verhelst wrote:
>> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>>> But it also gives a wrong sign: Debian Pure Blends are by definition
>>> integral part of Debian itself. But even now, this is hard to understand
>>> for many people -- questions like "what is the difference between Debian
>>> Astro and Debian" are quite common, even in front of a poster describing
>>> exactly that. With having separate official images for all blends,
>>> people would even be more confused. As an example, I would take the
>>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>>> installation options -- people usually think that they have to
>>> re-install the system if they want to switch from one flavour to the
>>> other. Having similar experience with Debian would be bad for the
>>> reputation of the Blends, and for Debian in general.
>> 
>> I don't agree with this argument.
>> 
>> Yes, indeed, in Ubuntu people often don't know that they don't really
>> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
>> that really a problem?
>
> Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
> that [KXG]Ubuntu is not different from Ubuntu except for the package
> selection. I don't know how important it is for them to keep the unity
> -- maybe they don't care here much.
>
> But for Debian Pure Blends, it is important to have it clear that the
> Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
> infrastructure to do something else -- we are an integrated part.

On reflection, I agree wholeheartedly, and probably should not have
revisited the specialised CDs as an idea.  Sorry about that.

It would be depressing if Astrophysicists who used Debian-astro at work
were confused into downloading again because they fancy playing some
games at home, when the only difference between the images would be
about 5 bytes of preseed setting.

That said, it would probably be nice to make it trivially easy to set
downloaded media to default to e.g. debian-astro at the user's
preference, so that someone could do that and hand the result to a
colleague, saying "Just install that".  That's not the same thing as
publishing them like that though.

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)

[Andreas Tille]

On Thu, Dec 08, 2016 at 09:33:04AM +0100, Wouter Verhelst wrote:
> 
> It's certainly *easier* for users to understand that if they want X, Y,
> or Z, they just need to install from the X, Y, or Z image. ...

This argument implies an *exclusive* or which is definitely not the
case.  From the very beginning of the Blends effort (before it even was
called Blends) it was a goal to make Blends metapackages co-installable.
Besides the artificial example that an astronomer might want to install
at home also some Debian Jr. tasks it makes perfectly sense to install
Debian Science in addition to any science oriented Blend.

While I agree that since everything is pure Debian and can be installed
on top of any specific Blend image it does not follow the mindset we had
agreed upon.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Ole Streicher]

On 08.12.2016 09:33, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
>> But it also gives a wrong sign: Debian Pure Blends are by definition
>> integral part of Debian itself. But even now, this is hard to understand
>> for many people -- questions like "what is the difference between Debian
>> Astro and Debian" are quite common, even in front of a poster describing
>> exactly that. With having separate official images for all blends,
>> people would even be more confused. As an example, I would take the
>> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
>> installation options -- people usually think that they have to
>> re-install the system if they want to switch from one flavour to the
>> other. Having similar experience with Debian would be bad for the
>> reputation of the Blends, and for Debian in general.
> 
> I don't agree with this argument.
> 
> Yes, indeed, in Ubuntu people often don't know that they don't really
> need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
> that really a problem?

Yes. In the whole 12 years of Ubuntu, they didn't succeed to make clear
that [KXG]Ubuntu is not different from Ubuntu except for the package
selection. I don't know how important it is for them to keep the unity
-- maybe they don't care here much.

But for Debian Pure Blends, it is important to have it clear that the
Pure Blends are just plain ("Pure") Debian. We don't just use the Debian
infrastructure to do something else -- we are an integrated part.
DebianMed and Debian Astro are in no way different from Debian, and if
you have Debian, then you have the Debian Pure Blends as well: it is
just a matter of package selection (and, ofcourse, mainly having the
special packages for our fields available).

And I still think that it would be horrible, if someone wanting to
switch to or from a Pure Blend would feel the need of re-installing.

The argument of wanting more than one blend installed at the same time
(not so rare within interdisciplinary teams) comes on top of that.

> It's certainly *easier* for users to understand that if they want X, Y,
> or Z, they just need to install from the X, Y, or Z image.

So, if they want KDE, they should just need to install a KDE Debian image?

The idea of the Debian Pure Blends is much similar to the idea of the
Desktop environments: There is no "KDE Debian", there is "just" a K
Desktop Environemnt in Debian. Similarly, the is no "Astro-Debian".
There is just a useful environment for astronomers in Debian.

And, having extra images per blend would multiply the number of images
we have to maintain. Instead of 10 official architectures, we would have
10 + 10 * number_of_blends. Possibly again multiplied by the number of
desktop environments, if we apply the same argument to them.
I am not sure that the cdimage team would be happy about this.

> I don't buy that presenting users with a choice of image to download
> "confuses" them, when it in fact *takes away* a very confusing menu from
> the installer. 

I would again ask to present some empirical data that adding the Blends
menu is "very confusing". The menu is there since quite a while, and it
was presented to many people, and we usually *do* get a response if
nobody understands the installation process. So, where are the complaints?

After eight months of testing, we can compare the fears here with the
collected experience. And this just doesn't support the fears.

> I think it's going to be obvious to people that if you
> download, say, a Debian Med image, you're going to have a different
> experience than if you download a "plain vanilla" Debian image; and
> that's *certainly* going to make things easier for Debian Med users,
> too.

The experience when installing Debian Astro is just Debian. It only adds
a useful selection of software on top of that, so that you immediately
can start your research, but aside from that everything is as everywhere.

So, the difference here is even less than the difference in experiencing
different desktop environments.

And my experience is that it is easier if people ask about how to
install Debian Astro, I can tell "Just select it in the last step of the
normal installer", instead of "Go to our home page, download a separate
image from there, and install this". It actually makes much difference
if the users can "feel" that they are just inside Debian, and not in a
special distribution.

Best regards

Ole

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

[Wouter Verhelst]

On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

I don't agree with this argument.

Yes, indeed, in Ubuntu people often don't know that they don't really
need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
that really a problem?

It's certainly *easier* for users to understand that if they want X, Y,
or Z, they just need to install from the X, Y, or Z image. We can
present them with a message at the end of the installation, or add some
documentation, or whatever, to the effect that switching from one "type"
of Debian to another doesn't require a reinstall; but even if that's
what people end up doing, so what? I don't see the problem -- and it
*would* make this problem go away, since you lose the need for the
tasksel menu entirely.

After all, Ubuntu isn't the only distribution anymore which ships
several images; these days, if you want to install Fedora, you have to
choose between a "workstation", "server", or "atomic"/"cloud" image. It
seems to work for them.

I don't buy that presenting users with a choice of image to download
"confuses" them, when it in fact *takes away* a very confusing menu from
the installer. I think it's going to be obvious to people that if you
download, say, a Debian Med image, you're going to have a different
experience than if you download a "plain vanilla" Debian image; and
that's *certainly* going to make things easier for Debian Med users,
too.

Just my 2¢.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12