Survey about the MD5 attribute (August 2012)
In August 2012, we conducted a survey of the 'comp' PWG mailing list, to ask for opinions about the MD5 attribute in the then-current version of the draft specification for Hierarchical Model Composition. The question posed was the following:
In section 3.3 of the current draft specification for 'comp' (release of 30 July 2012), the ExternalModelDefinition class is defined to have an attribute called md5. This attribute is meant to provide a way to perform a data integrity check over the contents of a remotely-located submodel. We would like to find out how important people feel it is to have this feature defined and supported in the first release of the 'comp' specification.
Do you believe the md5 attribute should be defined and supported in the first release of the 'comp' specification, or could it be left to a later edition of 'comp'?There were 7 responses to the survey. The table below summarizes the results:
The survey also provide space for people to write comments if they wished. The following are the comments that were written:
- (Voted ""I think it's essential and must be included"): "The md5 attribute is the only way to assure that an external module is unmodified otherwise an existing model may change without being noticed".
- (Voted "I think it's essential and must be included"): "As an optional attribute. And libSBML does not need to do anything special for now, just read and write it. Software are responsible to define it or not but I think it is important to have a way of checking that the model did not change and allow software that decide to support the attribute to print a warning if it does change."
- (Voted "I think it's defintely not essential, and I think it really should not be included") "I don't think it should be included as long as not all concerns about it have been resolved. Most importantly what is to be done in case the md5 sum does no longer match. Especially in cases where models are accessed via remote reference, where they are generated dynamically this seems to be an issue. This is better left to something like the COMBINE archive."
- (Voted "I think it's defintely not essential, and I think it really should not be included") "I think that it would be far better to rely on repository software that controls how URLs change as versions of documents change. The MD5 could change due to a range of things, from changing a comment or metadata in the file through to major changes, and so an MD5 hash is not sufficient as a meaningful signal about whether the interface has changed and the model still is valid. In addition, because of the well known security problems with MD5, it is likely that implementations of MD5 are going to become harder to find in the future, given that it is ineffective as a cryptographic hash function, and there is a risk that developers of tools will end up being forced to implement MD5 from scratch when building tools on new software platforms in the future. If you really want to use a hash function, I would suggest either using a simpler non-cryptograhic hash function, or using a more modern cryptographic hash function like SHA-2."
- (Voted "I don't think it's essential, but I don't mind if it's included in the first release") "Doesn't seem like a very useful feature to me, but I guess there might be some value in a quick and dirty check tools can make in order to flag a potential warning to users. Future versions might be able to make use of COMBINE archives or version control systems to define best practices for linking to external documents."