There are lots of rivers to the same ocean! Being able to have custom slackpkg templates for its variety of deployments keeps slackware tight, too!

The template feature is amazing, especially for working with stable slackware deployments, and is much faster than what I used to do: installpkg with customized tagfiles stored within each set directory. I used to manually replace all the stock tagfiles with the custom ones, before running installpkg. Hats off again to slackpkg for speeding things up!

14.2 was getting stale enough that I switched to current, which adds new packages enough, that the slackpkg blacklist became convenient, and achieves the same thing: a custom set of packages for a deployment.

Either way requires a little bit of system administration: either generating new templates or editing blacklist file, as new packages are added to slackware-current.

In the computer security realm there is an axiom, the essence of which can be expressed: if a piece of software is not installed on a computer, then the flaws in this piece of software (or in its configuration) can not be used to attack this computer.

For a computer which has a routable IP address on the public Internet and which runs 24 hours per day, I think it is a good idea to not install software when one knows the software will never be used on the particular computer.

Baumei. That is pretty much the way I see it too. if the software aint installed, it can't be compromised.

Very true, but it also won't be an issue if that software is not running. There are probably vulnerabilities in a lot of pieces of software used today that are unknown (or at the very least, undisclosed). There are some that are obvious when they are not running (like actual programs), others, like libraries can be much harder to figure out.

For those users that are familiar with Linux dependencies and how to troubleshoot programs broken due to missing dependencies, leaving out software that is not expected to be used is relatively simple and missing dependencies can be resolved as they come up. But for users that aren't familiar with it, it could lead to a broken system and a frustrated user.

As I said above, this can be good advice for someone who understands the way software links in the system and has the knowledge on how to resolve dependency issues if they arise, but for users who don't have that knowledge, they might remove something they think is harmless, which might actually be harmful and can break the system.

Ultimately, you need to do a risk/rewards rundown to determine if a minimal system is right for you. While I have enough knowledge to be dangerous and could probably figure out missing dependencies if I were to run a minimal install, the rewards to me aren't worth the risk of needing to figure out dependencies if something is broken. I imagine that's why a lot of forum regulars do full installs. But for others, the rewards of running a minimal system outweigh the risk of running into dependency problems.

Years ago I read about an architect who must have really loved his work. His hobby was buying and renovating historic homes. However, he, supposedly, made it a rule to live in each house for at least 30 days before considering what "improvements" he would make, if any.
IMHO, that approach should be taken with Slackware. That is, do the recommended full installation, live with it for X number of days or weeks to learn how it works and all fits together, and then decided what you want to remove, if anythnig.
:)

I'm sure we can put our heads together and engineer a situation where that statement is wrong. Package A checks for availability of Package B in location XXX at runtime and does a bunch of extra stuff if it finds it, possibly invoking additional functionality from Package B, with additional security risk.

The flip side is the user not understanding why including package C actually provides *additional* security, or makes package A follow a more typical execution path which is better scrutinised from a security POV.

If I was running something other than Slackware with better dependency management I'd not include anything I didn't need. When running Slackware it's a more difficult decision and involves a compromise. For personal desktop machines I'd include everything, for virtual machines for specific tasks I try to be pragmatic. So if I have a router machine I want nslookup, so I have to include bind, because Slackware doesn't separate the two which is a pain, but it's still less of a pain than using Debian or one of the other modern distributions.

Books on computer security discuss this:
As "bifferos" has said, the above is not necessarily true. Malevolent people have put their heads together, and they have made plans.

After an attack gets access to the computer, then it can run library functions, and/or run application software. Consider:
(1) The flawless software on the computer could be used in this software's normal manner, but used in a malicious manner, or used in a set of steps leading to a malicious act.
(2) The software on the computer has a flaw which facilitates an unintended ability, and the unintended ability is used in a malicious manner.

I'm well aware of this which is why I included the following line two sentences after the one you quoted:

You're always able to take the SlackBuild and build things without other dependencies if they aren't required build dependencies or in this case, see if bind can be removed after compiling so you can get just nslookup.

If an attacker gets access to the computer all bets are off. This is why you should employ good passwords and firewalls, along with good monitoring (like fail2ban). All these things mitigate the chances of attackers getting access.

======================

My point wasn't to say that everybody should install every piece of software and just not run stuff that might be compromised, but rather people should take into account the complexity of dependencies and the difficulty in ensuring all dependencies are met on Slackware when an other-than-full install is completed. For some that comes easier than others.

Certain things like KDE packages are pretty straightforward to realize if you're running them or not. Other things, like libpng or ffmpeg's libraries, can be much harder to determine if they're running when invoked in other programs. Things like ldd and readelf can certainly help track down some of these dependencies, but I don't think we have a good method to track down other dependencies (like python dependencies would likely required digging through the files and seeing what modules are invoked).

If you remove the wrong library, thinking it isn't needed, it could break parts of the system. I just encourage people to be cautious and be ready to find a solution if something breaks.

No,
"If an attacker gets access to the computer all bets are off.",
is not necessarily the case. Yes, it is dangerous for the security of the computer, but it is not necessarily the end of the story.

In the books on computer security is described a concept called defense-in-depth; a very short description is loosely this:
(1) firewall -- to keep obvious attacks away from the computer;
(2) good username and password practice -- to keep obvious interlopers out of the computer;
(3) make the environment inside the computer inhospitable to the attacker -- so if the attacker does get in, then what the attacker wants to do is difficult or not possible, and/or the attacker's actions are rapidly detected and stopped.

Of course, what of the above is implemented is the choice of the wise network and server administrator(s). Implementing all of the above requires some knowledge and effort, both to install and operate --- it is reasonable for the administrator(s) to balance the costs associated with a successful attack against the costs of hardening the system. However, some aspects of the above are cheap and easy to employ.

Not having unnecessary software on the computer is in category #3 (above), and has a fairly small cost to implement and operate.

Yes, I understand that leaving off a particular piece of software introduces the likelihood one will find it was the dependency of something. I am disgusted that the dependencies of each piece of software are not widely and clearly disseminated --- for example, here on Linux Questions the standard recommendation is to install all of Slackware, because there is no reasonable way to know the dependencies. In addition, I have many times seen derogatory or unhelpful comments toward someone wishing to do a partial install, so in this thread I weigh in to lay out reasoning which I think supports the OP's proposition.

It is not a small cost for Slackware users (or even other distros that do offer dependency management), which has been my whole point. There would be required mounds of research to find out exactly what various pieces of software do and whether or not it is needed by the system. The latter part is vastly easier if dependency management is available, but we've seen countless examples where those are extremely broad and adding or removing one piece of software can have a cascading effect requiring the addition or removal of many packages.

Then it seems Slackware may not be the distro for you. Between this belief and your feelings in the KDE4 vulnerabilities thread, it seems like Slackware's model may not match with your desired needs of a Linux distro.

That being said, if you are interested, the salix developers have listed dependencies for official packages, but it doesn't seem like it is ever planned for Pat to officially document dependencies for Slackware packages.

That is because people are generally wanting to do minimal installs under some incorrect notion that it will make their computer faster or not use as much memory. They also don't realize that what's minimal for them may not be minimal for someone else (and they usually don't mention their needs when mentioning a minimal install). There will never be a consensus of what "minimal" constitutes for everyone. For those that are interested in slimming down Slackware for valid reasons, including the security reasons you mention, knowing you don't need some software, and even just trying to play with Slackware and figuring what is and isn't possible, there have been many threads with a lot of helpful responses.

To attack a computer through software that is "just there", the attacker has to be already inside the system (to be able to start it).
The important ones are the daemons (and services) running on your system as they can be (tried to) connected to, so disabling all rc.* scripts (in Slackware, /etc/rc.d) mostly does just the same. For instance: E-mail handling may be needed internally (like for cron error messages) but that doesn't mean you have to enable E-mail recieving from other systems.

Hi "bassmadrigal",

Thank you for the URL to package dependencies as listed by the Salix folks. :-) I expect this will be useful to me in the near future.

Please understand my position: I have in general found the people which frequent the Slackware section of LinuxQuestions to be knowledgeable and helpful, and I enjoy reading quite a few of the threads here. Also, it makes sense to me that Slackware does not do dependency checking; I think Mr. Volkerding's choice is eminently reasonable.

It appears you do not realize I have been using Slackware for more than twenty years, and that for all this time I have been generally delighted with Slackware.

For the many computers on which I have installed Slackware, not one has been a full-install. Though many people say doing a partial-install begins a terrible experience, I have not found this to be the case.

Very early in my Slackware career I created a recipe for the install process. Initially, I read the package descriptions, and chose some packages to install. Then, for each package I chose: I listed it in my recipe, and installed it on the computer. When I was done with setup, I rebooted the computer and began to use it. If I found any dependency problem, then I figured out why, fixed it, and edited the recipe. Because I kept the recipe from one installation to the next, I never had to figure out a particular dependency problem more than once.

Over the many years, and with many computers, I have not found using partial-installs of Slackware to be difficult to maintain or to operate.

A 'minimal' desktop these days would be, web browser & internet connectivity, anything else would be the choice of the user, & can be installed as required.

For an example of this type of minimal set up, check out MIYO Linux. :)

While this may be true.. it is seldom the assumption of those in the Slackware "community" that a person is asking for "valid reasons". Ironically most users also forget that data costs are not cheap in all parts of the world. It may not be an issue of just "making it slow" as much as a real up-front-cost needed to download the ISO. While some may then say that Slackware should not be used, the question then becomes: where do you find stability in an OS like Slackware without frequent or forced updates?

Interesting how Slackware (as an OpenSource project which anyone can freely modify) has a community surrounding it that strictly abhors any "editing" to the base install. Many a time people will simply flame or ignore a Slackware-related question once they find out a single package was removed from the full installation. This does not do much to encourage people in it's usage or back up the claim to flexibility or total control.

In regards to dependencies inside Slackware itself, it seems simple enough to take advantage of the Salix team's efforts in that "narrowing down" - but Patrick and the team are busy enough with the massive amount of transitions needed to get in Plasma and XFCE 4.14 alone that it simply isnt worth their time. If we want 15.0 released any time soon we should probably keep our expectations reasonable..

To sum it up, I'd make the following argument(s):

• Should Slackware have a list of all internal dependencies? .. no - not really necessary as it would be redundant (and time consuming).
  
• Should the community around Slackware be a little bit more understanding towards the use cases of others rather than assuming they have no clue? .. yes.
  
• Should new users be warned of the potential dangers of not performing a full install? Emphatically yes! However they should not feel limited or forced into it!

Over the years what I've seen, repeatedly, is someone asking a question about this or that problem, and it is only after several board members have made an attempt to help, that we eventually find out the person with the problem didn't do a full installation.
:banghead:

Another frequent source of problems, and this is, again, just my observation, is the incorrect use of the "slackpkg" system. Perhaps, they should learn to use "upgradepkg" first?
:twocents: