Currently the material flow combines amongst others, a restrictive list of access rights, retention policies and metadata fields. These operate as restrictions on which access rights, retention policies and metadata fields can be supplied by the submitter. We suggest to make it possible to opt-out on any of these restrictions. That would benefit customers that have automated submission workflows outside of Rosetta where the metadata is already checked for validity and fully under control. It would also help solving human errors when new ARs are created, but forgotten to be added to their respective material flows. If it not possible to opt-out, it would be nice to have 'I do not care' or 'Anything' entries in the access right and retention policy list that do basically the same. For us personally, relaxing the access right restrictions would be the biggest win.

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.

The IE delivery rule list contains the following fields:
- active
- name
- description
- creation date
- modification date
- commands view, edit and delete

the dates and commands take up half of the screen, not leaving much space for the name and description. Both these fields are rarely descriptive enough to fully understand the implication of the rule and we have had several occasions where an operator added a rule, changed the order or modified a rule without understanding its impact. Resulting in wrong viewers being used or even files not viewable at all.

We think the list can be improved by removing the date fields, which - at east for us - have little value and condense the action columns. The newly gained column space could be used to display the information from the input parameters in a structured way. I believe that would improve the insight on the impact of a rule right from the list.

We have similar thoughts about the SIP routing rules list. Possibly it could be a suggestion that applies to all rules lists in Rosetta and/or all order-dependent lists.

During a recent batch of deposits (see case 00477041 from the Getty for more info) we figured out that, due to an error in our one of our input files that creates the METS, our original METS file did not have unique file IDs in the structMaps for the preservation master and modified master representations. It was simply repeating the same file ID from the access file representation.

For some reason, this did not cause a METS validation error when we validated against the Rosetta XSD before deposit, nor when it was deposited. However, it resulted in the METS in Rosetta not having any files listed in the structMaps that contained the duplicate files IDs. Since the fileIDs were correct in the fileSec it imported all the files properly, but they were not referenced from any structMap. Fixing this using the back office would have taken too much effort so we deleted the ca. 150 IEs and redid them from scratch.

Might you be able to enhance the METS XSD so that it requires file IDs to be unique in each structMap? I know it is against Rosetta's data model to refer to the same file ID from different representations with the same structMap type so it would make sense if the XSD enforced this requirement.