Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • On ingest, or on-demand via REST request.  Can store fixity events in repository.
  • How does it extend to other checksum algorithms? 
    • SHA-1 supported because we get it "for free"
    • How do we specify how to specify a checksum?
      • Ingest- a header.  On-demand, in POST
  • For huge files (video files) there is no spec for finer-grained checksums
  • In the EU, checksums and signatures are indicated in an XML format, checked by external tools.  Not sure if it's XML signature spec per se, but it's expressed in XML.  The tool is called Checklex: https://checklex.publications.europa.eu/faces/AboutCheckLex.xhtml;jsessionid=1757FE945F9B55308A09C3E05723171D?lang=en (specs available under request)
  • Will/should fixity generate events picked up by audit?
  • Use case: Fixity against entire collections (trees of resources)
  • Is there a method of fixity checking for external sources.  Is there a standard, e.g. like s3 buckets, swift?
    • Not aware of a standard, but maybe s3, swift indicate a defacto standard?
    • Can we say in the spec that we expect an external application to include a certain header? 
    • Are external resources in the spec at all?
      • There is a note, this will make it into the spec at some point
      • Storing fixity of such resources seems to be reasonable for Fedora to do
        • Some desire just to defer to external system
        • .. but repository can't/shouldn't necessarily trust these external sources.
      • Maybe it's possible to have user specify checksum when creating external resource, or have repository pull in the external source's notion of fixity.
    • In a clustered scenario, do we consider fixity to be a consensus?
      • Self-healing needs to be hidden, or storage needs to be transparent
      • There used to be code related to this, there was a pattern 

...