upgradepkg and *.orig

andygoth · 06-21-2018, 08:16 AM

Whenever upgrading with upgradepkg, replaced configuration files may be backed up with a ".orig" extension. This is a nice feature, but there's a minor issue. A fresh Slackware 14.2 install contains several files named *.orig, so it becomes a little tricky to tell the difference between backup files (which can be deleted after examination) and standard distribution files (which should be left alone).

As of time of writing, Slackware does not contain any files named *.ORIG. Perhaps ".ORIG" would be a better extension to use to unambiguously denote configuration file backups.

I just did an upgrade to Slackware-current from a fresh Slackware-14.2 (32-bit) and compared the list of *.orig files before-and-after. In the before column, there is /etc/kde/kdm/Xsession.orig, which a casual "find /etc -name \*.orig -delete" would unfairly zap. There are also three files named *.orig in /usr/doc and fifteen in /usr/share. It may seem the solution to the latter is to ignore *.orig in /usr, except that the upgrade created /usr/share/vim/vimrc.orig, which may be worth examining, merging, and deleting.

Similar goes for ".new" versus ".NEW". Following the upgrade, I found seven files named "*.new", despite not having selected "n" when asked what to do with configuration files. These files can also cause confusion, but not if upgradepkg used the ".NEW" extension instead.

(I didn't realize this at first, but installpkg is also capable of replacing configuration files and will name them *.orig or *.new too.)

volkerdi · 06-21-2018, 02:24 PM

Quote:

Originally Posted by andygoth

Whenever upgrading with upgradepkg, replaced configuration files may be backed up with a ".orig" extension.

[...]

(I didn't realize this at first, but installpkg is also capable of replacing configuration files and will name them *.orig or *.new too.)

There's no feature in either installpkg or upgradepkg to create .orig files.

bassmadrigal · 06-21-2018, 03:48 PM

Quote:

Originally Posted by volkerdi

There's no feature in either installpkg or upgradepkg to create .orig files.

I'm thinking he meant slackpkg when you upgrade a package and it then prompts you what to do about changed config files.

andygoth · 06-21-2018, 08:05 PM

Quote:

Originally Posted by bassmadrigal

I'm thinking he meant slackpkg when you upgrade a package and it then prompts you what to do about changed config files.

Right. I incorrectly assumed that since slackpkg wraps installpkg and upgradepkg, the latter two were handing the *.orig and *.new file creation. You're telling me slackpkg manages that internally. Either way, I stand by my request to rename to *.ORIG and *.NEW to avoid ambiguity with files that ship with Slackware.

rworkman · 06-22-2018, 12:49 AM

This is a longstanding slackpkg thing, and while I wouldn't have done it that way if I'd originally written it (I wouldn't save the .orig files at all - if you say to overwrite the originals with the .new files, then that's what you get) ; however, at this point, inertia wins.

andygoth · 06-22-2018, 01:02 AM

Quote:

Originally Posted by rworkman

This is a longstanding slackpkg thing, and while I wouldn't have done it that way if I'd originally written it (I wouldn't save the .orig files at all - if you say to overwrite the originals with the .new files, then that's what you get) ; however, at this point, inertia wins.

I don't see any reason why slackpkg can't be extended with new options or menu choices to customize this behavior.

While we're on the subject of new functionality, it might also be nice to have the option to only write .orig or .new files in the case where the original file on disk differs from what was originally supplied by the old version of the package. I'm not sure if there's a database of checksums for old packages lying around within easy reach, but if there is, this would be a good use for it. Basically, the only time I really care about .orig files is when they afford me the opportunity to merge in my local changes. But if I haven't made any local changes, I'm happy to upgrade away and don't look back! Until things break, of course, at which point I downgrade the whole package rather than just the configuration file.

rworkman · 06-22-2018, 03:55 AM

That would be at least marginally useful, but out of scope for slackpkg. If that were going to be done, it would be in pkgtools and probably along these lines:
If /etc/someconfig is identical to the /etc/someconfig.new that was contained in the to-be-upgraded version of the package, then overwrite /etc/someconfig with
the /etc/someconfig.new from the upgraded package, i.e. don't even install a .new file. As far as I'm concerned, that would be a welcome change, but the infrastructure to do it is not currently in place. As to whether it's worth adding that infrastructure for the perceived benefit, I'm not sure.

bassmadrigal · 06-22-2018, 10:05 AM

Quote:

Originally Posted by rworkman

That would be at least marginally useful, but out of scope for slackpkg. If that were going to be done, it would be in pkgtools and probably along these lines:
If /etc/someconfig is identical to the /etc/someconfig.new that was contained in the to-be-upgraded version of the package, then overwrite /etc/someconfig with
the /etc/someconfig.new from the upgraded package, i.e. don't even install a .new file. As far as I'm concerned, that would be a welcome change, but the infrastructure to do it is not currently in place. As to whether it's worth adding that infrastructure for the perceived benefit, I'm not sure.

Isn't this already done in the config() function of doinst.sh?

Code:

config() {
  NEW="$1"
  OLD="$(dirname $NEW)/$(basename $NEW .new)"
  # If there's no config file by that name, mv it over:
  if [ ! -r $OLD ]; then
    mv $NEW $OLD
  elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then
    # toss the redundant copy
    rm $NEW
  fi
  # Otherwise, we leave the .new copy for the admin to consider...
}

(Although, in this case, it actually just removes the .new file since they are the same. It could easily be adjusted to move the .new file over the existing file.

andygoth · 06-22-2018, 12:04 PM

I was talking about an option to not create .orig or .new files, just replace the file, if the file being replaced matches what was in the old version of the package being updated. In other words, if the user didn't modify it, just go ahead and upgrade it, on the theory that the user didn't need to do any merging. The code you show is to avoid creating .orig or .new files if the file being replaced matches what's in the new version of the package.

Also, why compare MD5 checksums? Why not just compare the files with cmp?

bassmadrigal · 06-22-2018, 12:46 PM

Quote:

Originally Posted by andygoth

I was talking about an option to not create .orig or .new files, just replace the file, if the file being replaced matches what was in the old version of the package being updated. In other words, if the user didn't modify it, just go ahead and upgrade it, on the theory that the user didn't need to do any merging. The code you show is to avoid creating .orig or .new files if the file being replaced matches what's in the new version of the package.

Replacing the file if there were just no changes to the original would require creating a new database (or adding to a current one) to store hashes of the original file. Plus, there's times when an upgraded config may drastically change the expected behavior of a package. An example of this is when openssh was upgraded to fix a security issue in 14.1, but the new config prevented root logins with passwords, which could potentially lock people out of their systems if they're remote.

Code:

Fri Jan 15 02:29:54 UTC 2016
patches/packages/openssh-7.1p2-x86_64-1_slack14.1.txz: Upgraded.
This update fixes an information leak and a buffer overflow. In particular,
the information leak allows a malicious SSH server to steal the client's
private keys. Thanks to Qualys for reporting this issue.
For more information, see:
https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0778
*****************************************************************
* IMPORTANT: READ BELOW ABOUT POTENTIALLY INCOMPATIBLE CHANGES *
*****************************************************************
Rather than backport the fix for the information leak (which is the only
hazardous flaw), we have upgraded to the latest OpenSSH. As of version
7.0, OpenSSH has deprecated some older (and presumably less secure)
algorithms, and also (by default) only allows root login by public-key,
hostbased and GSSAPI authentication. Make sure that your keys and
authentication method will allow you to continue accessing your system
after the upgrade.
The release notes for OpenSSH 7.0 list the following incompatible changes
to be aware of:
* Support for the legacy SSH version 1 protocol is disabled by
default at compile time.
* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
is disabled by default at run-time. It may be re-enabled using
the instructions at http://www.openssh.com/legacy.html
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
* Support for the legacy v00 cert format has been removed.
* The default for the sshd_config(5) PermitRootLogin option has
changed from "yes" to "prohibit-password".
* PermitRootLogin=without-password/prohibit-password now bans all
interactive authentication methods, allowing only public-key,
hostbased and GSSAPI authentication (previously it permitted
keyboard-interactive and password-less authentication if those
were enabled).
(* Security fix *)