9

The command checkinstall has been recommended many times in this forum, as a replacement of make install. However when one goes to the official website, the "Recent news" section shows Dec 2016 as the most recent date.


Edit: I read the post Is there any checkinstall alternative?, and I cloned the git repository of checkinstall. As of April 2019, the git log command shows only around 1 commit per year in the last 3 years.

Q1: Is that amount of commits enough to maintain the package?
Q2: Why is checkinstall not on Github? On platforms like that one you would be able to see the last commits and latest releases without the need of cloning the entire repo onto your computer.

1 Answers1

13

Why is checkinstall no longer being maintained?

You really should ask the creator but I can make an educated guess: It is considered a security hazard. And not just a small one.

Martin F. Krafft author of "Debian system" (-> Amazon):

Checkinstall is limited in what it can do. To be precise, the packages it creates can only install files, and checkinstall does not care where it installs them. You can overwrite files in /home directories with checkinstall, among other things. The generated packages can not modify files. If the installation routine modifies existing files, they will be part of the generated package in their entirety.

A horror scenario occurs when an installation routine adds a user by modification of /etc/passwd, which is subsequently included in the package. Installation of the package causes /etc/passwd to be completely replaced, and the deinstallation of the package removes the file, breaking the system in half.

The generated packages also fail to register their configuration files with dpkg, therefore paving the way for upgrades that overwrite local configuration file changes.

In light of these problems, it is probably a good idea to avoid but for the rarest cases.

Rinzwind
  • 310,127
  • 2
    Yes I have a copy of in at work ;) – Rinzwind Apr 26 '19 at 16:52
  • 9
    That is some dubious claim. If you got an adversary project that does something bad to your system upon running make install, then there's no difference if you screw your system with make install or checkinstall. The latter at least tracks what and where was installed. The point of the project is to be a better "make install". Sure, would be nice to have some security here, but in absence of alternatives what can you do. There's no point in telling "let's not use it because it's less secure". Like, less secure than what? – Hi-Angel Dec 21 '20 at 12:47
  • I'll just add that I've had checkinstall actually mess up my boot drive enough that I was forced to completely reinstall the OS. It was a few years ago so I don't remember the details but I recall it had something to do with how it was building fake roots. This was from simply trying to build a .deb package for emacs so nothing too fancy. Since then, I only use it in a VM spun up temporarily just for that purpose. – foobrew Feb 22 '21 at 23:02
  • 2
    @foobrew I just got done unfking my system from the same issue. Thought it was ridiculous that running something like this could delete a bunch of system files and mess my whole damn system up. Took all day to get everything mostly back to how it was before. Lesson learned, do not use checkinstall on your daily driver OS – Liam Clink May 09 '24 at 05:02
  • 1
    @Hi-Angel the point is not that checkinstall doesn’t add security features to catch adversarial projects. The point is that it can turn innocent projects into adversarial packages. If a project’s make install creates a user, that will change /etc/passwd; checkinstall won’t replicate the user creation, it will ship the modified /etc/passwd in the generated package, overwriting the existing file on any system where it’s installed. So while the initial project was fine, the resulting package isn’t. – Stephen Kitt Aug 09 '24 at 13:14
  • @StephenKitt ah, I see, so checkinstall sees that a child process modified /etc/passwd, and it will just assume it needs to be copied into the package? Yeah, that's sad, I thought it is simply using the DESTDIR variable to direct the installation. – Hi-Angel Aug 09 '24 at 18:41
  • 1
    @Hi-Angel checkinstall uses installwatch to watch changes made to the system, so that it can cope with installation processes which don’t use DESTDIR or similar mechanisms; but it does try to run them in a temporary directory. Note however that I’m just describing the point made in Martin Krafft’s description, I haven’t checked myself whether the /etc/passwd scenario is actually an issue. – Stephen Kitt Aug 09 '24 at 21:54