Re: A general question about options.
On Wed, May 13, 2009 at 06:07:28PM -0400, Seth Herr wrote:
> Not to be too rude but the option to compile Gnome or KDE from source
> with whatever specific options you would like exists specifically for
> this purpose. Pre-compiled binaries generally exist for less skilled
> users and, as such, *should* include widly used options such as avahi,
> zero conf, etc. The challenge of a widly usable desktop enviroment is
I always thought, that pre-compiled binaries generally existed for
convenience of maintaining the binary distribution.
Anyway, I just suggest, that questionable options should remain optional.
I suggest this as a general policy rule.
It's okay if they are turned on by default, but I still have not found
any realistic way for an average sysadmin to securely turn them off.
Current kdelibs source package is not intended to be compiled without avahi.
Just check the configure file and you will know why.
> to tailor it for the largest subset of users without compromising the
> integrity and security of the system as a whole. Might I suggest emacs as
> a desktop environment for you if you find the inclusion of too many
> additional packages a burdon and don't want to compile your GUI from
Well, emacs is what I'm personally using. (They say you can do everything with
emacs. They just don't have to read OpenOffice diagrams.)
And yes, I have tried to compile kdelibs without avahi.
It does not configure. It has no "avahi" or "zeroconf" configure options.
Almost everything can be turned off - TIFF, libIDN, CUPS. But not avahi.
Okay, I'm lying. Emacs can turn off everything, that's the true power.
It looks for me, that I should go to source repository, try to find
old version without avahi, then merge all later changes, that aren't
avahi-related.
You call it "the option to compile Gnome or KDE from source" ?
I call it misdesign. (Misdesign often happens in commercial software, you know)
Well, could I be security-concerned, but still no expert in svn and autoconf?
> source. On a side note, avahi, zero-conf, et. al. can still be disabled
> at the rc level you want to run at and, even though installed, are
> disabled and and should satisfy your need for "security". I suppose the
Well, my experience suggests, that in real world some applications often
exists separately from their config files, so this is a rather risky approach.
I also remember an incindent when some daemons were restarted during a
package upgrade, but they shouldn't be started since they had incorrect
configuration and were not enabled by /etc/rc?.d links.
But they started to serve the network. So I'm a paranoic about that.
> point is that Linux and Debian as a whole still very much adhere to the
> principal that you, as the user, have ultimate control of your system and
> if you tale the time to understand the inner workings, can adjust it to
> exaclu fit your needs.
Yes, it was true. Now it is not. Because Nobody Cares.
>
> Seth
Thanks for your opinion anyway.
>
> On May 13, 2009, at 7:41 AM, desktop@subscribed.udmvt.ru wrote:
>
>> Good day everyone.
>>
>> I have a rather generic questions about dependencies that various
>> Debian desktop-related packages have, so probably this is the wrong
>> list.
>>
>> I always assumed, that every "auto-" thing such as auto-configuring,
>> auto-publishing, auto-discovery and etc. were only an option,
>> that is required by some (now rather large) group of users.
>>
>> But as I figured that out, it is impossible even to build some
>> debian packages without really optional features, provided by
>> something like avahi set of libraries.
>>
>> Is it correct to presuppose, that features like auto-discovery
>> and zero-configuration is the core of every desktop environment/
>> application
>> and not it's cool options, that can be safely removed when unneeded?
>> It looks like kdelibs Depends on libavahi-client3, libavahi-common3,
>> libavahi-qt3-1. It does not Suggest them, to demonstrate that
>> their usage will improve functionality to a new level.
>> It says instead, that without all that everything will break.
>> OMG, is that REALLY true? Is it all correct?
>>
>> OK, well, I know where that dependencies come from - everything is so
>> patched, that it does not build now without all that originally
>> optional
>> auto- features available as headers and libraries.
>>
>> But features like "auto-discovery of anything" or "auto-configuration
>> of everything" are only useful to rather specific communities of
>> unexperienced/lazy users. Is it allowable to think it is a standard
>> requirement
>> of every possible environment? How well does that perform when
>> something
>> like SELinux is enabled not only for testing or of curiosity, but also
>> to
>> prevent ANY possible information leak?
>>
>> As far as I understand technology like avahi or bonjour, it have a
>> goal to
>> allow the information leakage (it is termed politely as "sharing" and
>> "publishing")
>> with minimal effort even for inexperienced users.
>> Am I wrong on that?
>>
>> Should I now opt out of Debian, because it's desktop unconditionally
>> Depends on avahi?
>> Some day in the past I had to opt out of Windows because it was too
>> obtrusive in it's opinions about almost every aspect of my work.
>> That days Linux required me to manually configure almost everything,
>> it was also somehow obtrusive, but anyway, the system was ALL
>> CONFIGURABLE!!!
>> And that was cool!!! Because I have got a choice to make by myself in
>> the case
>> I need it (almost all of the time I needed no choice though, but yet
>> not all of the time).
>> And I loved that all of the time and very much.
>>
>> Will we have any alternative, any Big Fat Switch to turn off, to
>> remove any crutches,
>> to say
>> "Yes, I Know It May Be Hard To Configure That By Myself, But Let Me Do
>> That Anyway"
>> Maybe some hard-to-install-and-configure Debian GNU/Linux? :)
>>
>> Or to say "I better concerned on security rather than usability, so I
>> want to
>> carefully and manually select features, available in the system". That
>> is not too much,
>> isn't it?
>>
>> All I ask for is a stub packages, that provide no functionality, but
>> allow
>> something like konqueror to install and work in a system without real
>> libavahi.
>> (Well, if all that features are so poorly designed, that it is
>> impossible to build
>> kdelibs without avahi, let them build and install, with this dirty
>> hack.)
>>
>> Why? The lesser depenencies - the lesser the risk of potential bugs
>> and ways to exploit.
>>
>> PS: Looks like Google search on "avahi+security" returns no links to
>> discussion on that subject, but
>> on the third page there are "Disabling the Avahi daemon - The
>> solution" link, but link DOES NOT WORK...
>> PPS: Yes, I'm a paranoic. So what?
>> PPS: Ubuntu Wiki says about zeroconf, that "Attack vectors are limited
>> to the local area network." - but
>> that is still unacceptable for my tasks and environments. I can't
>> tolerate the idea of making every
>> desktop application potentially network-facing, even if that is only a
>> local network. Futhermore
>> I can't tolerate the idea of desktop communicating via loopback with
>> other accounts on the same box.
>>
>> --
>> Anonymous Paranoic.
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-desktop-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>
--
Sincerely yours
Paranoic.
Reply to: