mupdate is a proposal for a binary updater to install os software updates. The idea is to allow users to update their systems with security patches without the need to compile source code or work with patches.
Many other operating systems provide such functionality.
The client would be a shell script or c program which would do the following:
- Fetch a list of software updates given the operating system version (using uname or whatever)
- Compare and list installed and available updates.
- Fetch packages given a flag to install.
- Verify the files have been installed using md5/sha256
- Prompt the user if existing files do not match the assumption... i.e. the md5 is different for the file.
- Log patch installation history.
These steps could be accomplished in a number of ways. The list of packages could be a flat file, xml or a sqlite database (similar to mport design ideas). We could use packages from mport (or pkg_add for now) or use binary diffs using bsdiff (FreeBSD security officer's little utility) and bspatch.
The operations could work like OS X's softwareupdate command line utility, freebsd-update or something different.
A GUI version would be helpful down the road. A future GUI version should have a simple interface but still allow advanced users to see patch notes (similar to Mac OS X). The GUI should include a graphical means of displaying install history.
The files could be stored on the MidnightBSD FTP server which is mirrored.
We'd need updates for each OS release we intend to support.
One idea for making the patches:
find /path/to/release -print > os_base find /path/to/newversion -print > os_updated
Compare and automatically add any new files and folders to a third working directory for the patch (if we go the package route) Compare every file present in the os_updated file with the original. Any files that have been changed must be included. md5 checksums (and whatever else) must be generated for each new file and all the original files for the release.
These checksums will allow the updater to verify it is safe to replace files.
Verifying identity of the server would require some type of signing system and we don't have gpg or other choices in base. The update database should be signed and possibly packages if we wish to make this secure.
We need to enumerate all the cases including files have changed outside the scope of the update, how to deal with etc, major os upgrades (0.1 to 0.2?), deleted files, etc.
Automating patch generation.