KOffice 1.5 beta 1 Released (KDE.News) [LWN.net]

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 17:08 UTC (Wed) by nix (subscriber, #2304) [Link]

Downside of Klik: gross insecurity. The damn thing recommends piping the output of wget straight into sh!

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 17:36 UTC (Wed) by pipitas (guest, #22701) [Link]

True, the "install" script is piped into the shell for direct execution. This script is run straight away. With user privileges, not with root privileges.

I do not see how this is more insecure than running any other installer of a random software package (which you usually do have to run as *root*).

If you do not trust the installer, investigate it. It is shell code, it is open, it is easy:

  wget klik.atekon.de/client/install -O potential.danger.klik.installer
  vim potential.danger.klik.installer

If you then do trust it, run it with some "debug" output:

  sh -x potential.danger.klik.installer

And if you do still not trust it after investigating, just leave it. Don't touch it. But please, don't start spreading FUD ;-)

You can read more about klik in my blog, or in this Dot story which explains a bit more about some beneficial use cases of klik (as well as some of its limitations).

Cheers,
Kurt Pfeifle

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 23:28 UTC (Wed) by nix (subscriber, #2304) [Link]

There are no signatures or any other way to determine that the site you think you're getting the klik package from really is that site. Think DNS cache poisoning attacks, for starters...

Security

Posted Feb 1, 2006 23:41 UTC (Wed) by Ross (subscriber, #4065) [Link]

It is less secure in a number of ways.

First, the actual download isn't being performed separately. Second, some installers do not allow the package they are installing to take arbitrary actions (unfortunately both RPM and Debian packages run scripts which can basically do what they want as the installing user). Third, there is no sanity checking, checksum verification, or signature checking. How do you even know what you are installing is the same as what was on the Web page two seconds ago?

What is the best way to install software? Well, for one thing it should be downloaded by a non-priviledged user, then verified correct against a trusted source through at least a checksum, but optimally through verification of a cryptographic signature. Then, the install tool should finally compile (if needed) and install the software. Any compilation and installation should not be performed with the root uid (even if started by root). This is possible through many mechanisms, but the most obvious one is setting group writability on the destination directories and making the install process run with membership in that group. Does anything work that way out of the box? Not to my knowledge.

But klick is basically the least secure method, similar to the old Nessus installation instructions.

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 17:50 UTC (Wed) by busterb (subscriber, #560) [Link]

slackballs, .deb and .rpm files can all embed shell-scripts to run as
part of the pre and post-install process; this is really no different,
though I do not know if it is possible to sign a shell script like most
distros sign their packages.

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 17:56 UTC (Wed) by kobserver (guest, #30087) [Link]

I do not see the "gross" insecurity. Also, to me klik is not a "damn" thing -- it's a blessing, that lets me testdrive more bleeding edge software faster, easier and more securely, and in a very non-intrusive way :-)

After all, why would popular distributions like Knoppix and Kanotix ship with the klik client pre-installed, if it really were such an unsafe endeavour to use?

klik mostly uses Debian package repositories to fetch its ingredient files from -- and then a klik recipe transforms the (possibly) multiple ingredient files into one single *.cmg file (a compressed file system image/archive), that is freely re-locate-able in user space. Runs from CD. Runs from USB stick. Doesnt need root privileges. Leaves my system package manager (RPM) undisturbed. Makes me happy.

The beauty of klik lies in its "1 application == 1 file" principle, IMHO.

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 21:39 UTC (Wed) by job (guest, #670) [Link]

I don't really get this 'klik' thing. How about just giving me binary
tarballs instead? (I understand there might be problems with crappy apps
using hard coded paths, but that's not something klik can solve either
unless running as root, so I'll accept having to decompress the crappy
ones to a fixed path.)

When I just want to try one new app without pain, I surely don't want to
know about a second new app. And if it fills a void left by the package
managers (whatever that may be), wouldn't it be more proper to fix those
package managers for everybody instead of installing a second package
management system for me?

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 1, 2006 22:56 UTC (Wed) by kobserver (guest, #30087) [Link]

I'd be most interested to hear about your remaining (or newly occuring) questions after you've read the klik FAQ.

There it is explained that

klik is not a package manager, and doesn't strife to be one nor replace one,
how klik works,
which problems klik solves and which gaps it fills.

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 2, 2006 12:29 UTC (Thu) by job (guest, #670) [Link]

Forgive my ignorance, but after reading I hardly see the benefits at all.
I would have expected it to at least run the app in a chroot, if the idea
is for a way to try new software without the risk of introducing
problems. Or at least being a distro-neutral package manager targeted
towards more bleeding edge software, hopefully with at least some
security so you don't have to run untrusted binaries.

The whole point of Klik seems to be to run binaries from a
loopback-mounted archive the spare the user the unarchiving step. The
price here is 1) the software may not be the same as when you want to
install it "permanently", i.e. through your package manager, 2) you don't
get any updates for packages downloaded through Klik, 3) you have to
learn how to use yet another software, Klik, which is what you wanted to
avoid in the first place, and 4) you run untrusted binaries blindly on
your system.

Forgive me for being slightly elitist on this last point, but the install
process scares me. Running code directly from something called
klik.atekon.de strikes me as something a Windows user would do, as in
untrusted ActiveX components etc. I don't want to be ungrateful, and Klik
probably works wonders for some people, this is just not something I
would like to see my users doing.

But the URL handler interface is really nice, I'll give them that. It
will be a happy day when these ideas trickles down into package
management systems and they get as easy to use as Klik.

klik://kspread-1.5-beta is cool (as is the kword one)

Posted Feb 2, 2006 15:01 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

the whole point of klik is that you can klik a file and it'll start a program. and you didn't have to install it, you didn't need root password and you didn't put it in a special place. you also can give it to someone else, and it'll run immediately.

it is NOT a package manager, as it doesn't manage any packages.
you say it has these disadvantages:
1. software is not the same as it is when you install it permanently:
duh, no, it is for testing pre-release software as user.
2. you don't get updates
nope, you get a new package if you want (1 click on the site)
3. you have to learn another package maanger
what? you click the package and it runs? learn?????
4. you run untrusted binaries
well, if you don't trust the debian archives AND don't trust the page you got the klik package from, its untrusted... but as i trust both, i wouldn't call it untrusted.

again, you don't install it - you only run it. as soon as you close the app, it gets unmounted and it didn't change anything. so, again, it is a safe way of running (but not installing) portable software while the author did not have to compile it statically (inflating its size).