Regarding this thread (Bc shell command - missing libreadline.so.6) it is possible that an IPFire installation could get somehow out of sync and not all system files match a certain release version.
Wouldn’t it be a nice and secure thing if pakfire would have an option like e.g. pakfire check-release which would run through the relevant IPFire files and folders and compare the actual files with e.g. the checksum/hash of the installed files and folders on the system and show which files are not correct?
This is also a security measure, as it would show if someone modified certain important system files. Also could be displayed on the web gui, to show the admin, that everything is ok with the installation.
In the project’s defense, stable releases of IPFire should never introduce quirks like this. Due to capacity constraints and some core developers being unavailable, QA for Core Update 167 was done in a non-optimal fashion, but we learned from that, and are now doing more checks to prevent libraries issues due to dependencies not being shipped.
Especially with regards to security, I like your idea as well, which is reminiscent of tripwire. In IPFire 2.x, we unfortunately do not have a checksum list for every files, as the Core Updates come as a signed tarball, which contents are not signed individually. For Pakfire in IPFire 3.x, which Michael is currently working on, I recall such a functionality is planned - but that is something for the future, not a timely solution.
At the moment, I am afraid you are stuck with some icky procedures such as installing IPFire in a VM from a verified ISO, build manual checksum lists, scp them to your productive installation, and do something like sha515sum -c ... to verify the integrity.
Sorry to disappoint, and best regards,
Peter Müller
thanks for your detailed answer and nothing to apologize for! Thanks for all the things you guys do for the project!
In the end I think it would be not so complicated to implement. Main point is in my eyes the security part of such a check.
Rather than signing each individual file I guess it is enough to have one signed text file which contains all the relevant files and folders including their checksums and a process running through them and comparing them.
Of course someone with a deeper understanding of the file structure of ipfire (non-changing files) would be needed to build up that list. Once the list is there, the generation of the list per release could be automated within the build process. And of course the list must be updated when new files come or old files go. So that might be more of a problem in the release process.
I don’t think auto repair features are necessary … I think it would be fine if there would just be an output of possible errors/differences and the admin can decide for himself what to do from there.
But in the end its all a matter of your roadmap plans and if or how to prioritize such a feature.
