-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Klaus Schwenk wrote:
> I had some similar thoughts on that topic recently and do agree with you that
> the current habit of installation handling has several problems.
>
> First of all (at least on MS-based OS's) it's pretty hard to tell what exactly
> is done by the installer. Even harmless software does not always keep a log of
Exactly my point. How do you manage or reduce risk when you can't even
tell what changes are to be made? An executable has to be run to truly
understand its actions; scripts can self-modify (variables run as code),
executables can have odd logic that obfuscates things from heuristics
examinations. You can't make an auditing tool to list all changes about
to be made and actions to be taken by installing the program (aside from
a spare machine and a debugger).
> its actions nor is it observed by some system service. As with malware and/or
> malicious scripts it is relatively easy to hide inside the installer letting it
Flaw in the virus scanner but eh.
> pass through virus detections and the like. In any case this may lead to
> unwanted alterations to the system (be it with good or bad intentions).
>
Yes, evil. Nuff said.
> Now this has been discussed more than once before (and I hope I did not annoy
> too many of you), but besides common sense advise to not execute every program
> Joe User stumbles upon there has been little to no effort to reduce the usage of
> installation scripts/executables. Packet managers as found on *nix derivates are
> imho a step in the right direction but need to be better at telling the user
Package managers found in Linux typically run a pre-install script to
prepare the system, and a post-install script to post-configure the
system. These scripts are bash scripts run as root.
Installing blackdown java on Debian or Ubuntu is something you have to
be very careful about. The pre-install asks about licensing; if you say
"No" it stores that you refused the license agreement in a debconf
database somewhere and aborts the install. You can try to install the
package again, but it will abort. All combinations of --purge and
manually editing the dpkg database do nothing. I couldn't find the
debconf settings database thing it used, so I had to reinstall the system.
That pre-install script could very well have 'dd if=/dev/urandom
of=/dev/hda' and that would be it (I'm on sata so it'd be /dev/sda).
It's a step in the right direction; files are copied where they go by
the package manager. Problem is, other files can be copied around by
the scripts too, and the PM won't remove those.
> what a specific packet will do exactly. As for Windows the situation is more or
It will install X files, and run some script that you can read, but
probably won't understand.
> like a complete mess. Far too many programs wouldn't need an installation in the
> first place. And it's hard to give end users a rule of thumb on how to handle
> installation programs when there is no real agreement on what installers should
> (not) do. At least from my POV.
>
Yes, you hit the nail on the head with a jackhammer. One discussion on
autopackage was that the devs don't want to limit the API and thus want
the prepare, install, and uninstall to be a bash script supplied by the
package "so it can do anything." I hate this logic. Why does it need
to be able to do "anything"?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2rrchDd4aOud5P8RAowyAJ0Ty8CgXLMH5lCHhGwL3H1X4CG/+wCgjJq8
bZYd2oX7moQvJNknR1z1uoM=
=MIlk
-----END PGP SIGNATURE-----
