Should I open a bug or would I be wasting my time

[Duncan]

Kevin Chadwick posted on Sun, 31 Mar 2013 20:39:00 +0100 as excerpted:

> Or they could build KDE without polkit, however I have read that KDE's
> position is that KDE built without polkit is unsupported and would like
> clarification on that if possible.

There's certainly parts of it that won't work (or even build) in that 
case.  All the pointy-clicky-priv-requiring stuff won't work, as it has 
been "improved" to be more point-clicky and less passwordy, with polkit, 
and the old way either won't work at all now, or will, but kde no longer 
ships with a configuration that would do it.  And parts of auto-mount and 
the like will fail, due to missing components or bad permissions.  Etc.

So (as a user) I'd guess that's the deal with support.  The vision from 
those involved in the various pieces is that they work point-clicky, in 
many cases without requiring further authorization to do stuff that has 
traditionally required such authorization, and if you choose not to do it 
that way, in many cases you'd simply not be using the kde tools they've 
designed to handle it, to handle it, so of course, that bit not being kde, 
they won't support it.

> To me and please don't get offended. It basically comes down to a choice
> or perhaps laziness to use polkit over the even more capable and maximum
> security encouraging sudo which is compliant with Unixes traditionally
> modular nature and avoids these kind of dependency problems, which no
> one would argue is not a big problem and that people have been fighting
> against for years with varying success that seems to have fallen away of
> late.

... But it's not pointy-clicky enough.  And actually asking for a 
password to do something that could have system-wide effects isn't 
considered easy enough any more.

> If you take PAM, support for it is widely available and has just been
> added to the Linux ssh port but dependency upon it in my experience is
> always optional.

Well, (open)ssh (I assume you mean openssh, not the original company-
produced version that went proprietary quite some years ago...) is a bit 
of a special beast, as "upstream" for it is the BSD folks.  They have 
their own way of doing things, and their primary focus is the BSD side, 
with the Linux port playing second fiddle.  No big deal with it being 
handled that way as there's certainly enough Linux-primary, BSD-second, 
projects out there, and having the tables reversed once in awhile isn't 
a /bad/ thing.  But it does explain why the otherwise reasonably mature 
ssh is only now getting PAM support on Linux.

Meanwhile, in general, PAM, pluggable authentication modules, was 
designed with both pluggability and compatibility in mind, so there's 
little surprise that it's optional.  

Polkit is much different.  It far more emphasizes dbus IPC and pointy-
clicky management, and as such, basically drops compatibility with the 
old command line stuff by the wayside, since pointy-clicky's supposed to 
be so much better.

> There are many who would not use PAM if you paid them
> too and I am sure RedHat would use nothing else and I am glad PAM's
> design does not cause people problems.
> 
> I therefore suggest that polkit or KDE are designed incorrectly and
> would invite any thoughts or opinions on this.

I wouldn't say it's designed incorrectly, simply that the emphasis is 
different than it used to be.  If the emphasis is on automated policy and 
single-signon management in a point-clicky world, polkit works well, and 
that's where kde's (or at least that segment thereof that deals with 
these things) focus seems to be, these days.  If it's on giving the 
sysadmin familiar with the old way more direct, troublefree and familiar 
ways to text-config-file-edit the config, that's something entirely 
different, and not where the people actually doing the kde coding are 
taking it.

Of course, kde being a "volunteer" organization (if coders are getting 
paid for it, it's their employers doing the volunteering), if your vision 
is different and you're in a position to do so, volunteer your skills, or 
money to sponsor someone else to do it, and I quite expect existing kde-
ers would be happy to either arrange for the components you produce to be 
available alternatives, or to integrate the sudo-managed functionality in 
parallel to the polkit managed functionality, probably with a kcontrol 
applet to allow individual installations or users to choose one or the 
other as appropriate.

However, it may well still remain a pre-compile-time choice, thus forcing 
distros to choose one way or the other for their shipped binaries.  And 
actually, that's a pretty common solution -- far more common than I think 
most binary-distro users (as opposed to package maintainers, who will 
obviously need to know) realize.

That's actually one facet of the well known user/developer divide.  FLOSS 
was and remains designed for users that are both willing and able to take 
part in creating their own software reality, and pre-supposes that at 
minimum, they'll be a large enough share to keep the community self-
sustaining.  But there's very much a divide between "simple users" and 
"users who actively participate in choosing and building this software 
reality", and simple users more or less get carried along on the tide of 
those who actively participate.  And the binary distros are, fortunately 
or unfortunately, generally focused on these "simple users", who don't 
care -- who in general don't WANT to care -- about the details.  By 
definition, these users in general just want it to work, and are happy 
enough to let someone else make the decisions, as long as it does so.  
Otherwise they'd be making other choices in regard to their distros, 
choosing distros that gave them more power to make their own local 
software reality, even if it meant a few extra hours doing a nearly 
completely automated build in ordered to do so.

But that level of control isn't what most people want or are interested 
in at all, as long as it works for them, and that's OK.  Not everybody 
has to want/need that level of control, and I'm glad there's distros out 
there catering to the needs of the many, as well as those catering to the 
needs of a rather smaller market segment, my own, where people want that 
level of control and responsibility for themselves, even if they must pay 
a (to them) relatively small cost in time and convenience terms in 
ordered to be able to have it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.