After experiencing some problems with Rosetta's Format Library update mechanism (see SC 00423700 "error while updating Format Library [Rosetta 5.1.0.2]", handled by Paul), we got thinking about Rosetta updates in general. Currently, all updates are downloaded through an unencrypted connection. This includes:
- Rosetta updates (major, minor, service packs, hotfixes) and their checksum files (!)
- Oracle updates and their checksum files
- PDS updates (presumably)
- Format Library updates
Due to this, there's no way to verify authenticity of ExLibris' servers and the integrity of the update packages/the checksums. All information that are downloaded from ExLibris' servers must be seen as tainted and cannot be trusted, because the transmission is unguarded. Even though ExLibris provides checksums for some (all?) of the updates provided, verifying that information against the calculated fixity from the update packages will not provide any additional security, as both the patches and the checksums could be tampered with in a man-in-the-middle attack. This contradicts current best practices in IT security and is considered a risk for the integrity of the repository software and data. Also, if I understand the comment from SC 00423700 correctly, the current FTP password for Format Library updates is hardcoded into Rosetta when it really shouldn't be.

A possible update scenario for major/minor/servicepack updates could look as follows: on Rosetta installation, customers provide ExLibris with a PublicKey specific to that Rosetta installation. To reduce administrative overhead, several/all servers of the same multi server environment could share the same key. That key is added to the ExLibris update servers' list of authorized keys, thus allowing the customers' servers to connect. During the update, the "util sp" command queries the user for the key passphrase and connects to ExLibris' update servers via SFTP to download the patch packets and fixity information. The fixity information is then compared against the calculated fixity of the patches downloaded previously.

A possible update scenario for hotfixes could look as follows: users manually connect to the update server from the Rosetta server CLI using the SSH key. The user then downloads and validates the patch packets and fixity information. Alternatively, the update procedure is unified with the process used for all other updates (btw, is there any technical requirements this hasn't already happened?) and the procedure described above is used.

Updates for PDS and Oracle could be distributed in a way similar to the one described in the hotfixes paragraph.

We've noticed that the first step on improving update security is already done by providing Format Library updates via SFTP (set General Parameter "usesftp" to "true"). However, this is foiled by Rosetta checking for FL updates via plain unencrypted FTP on every reload of the "Home => Preservation => Manage Format Library Version" page. Apparently, that step fails if "usesftp" is set to "true" in Rosetta 5.1.x.

Please keep in mind that publishing and enforcing (!) a policy against short keylengths/weak crypto algorithms/weak kex algorithms is highly recommended when using SFTP/SCP.