THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Minutes/2011-08-30

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 13:18, 6 March 2013 by MartinMichlmayr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Attendees

  • Bill Schineller
  • Kirsten Newcomer
  • Branden Robinson
  • Peter Williams
  • Gary O’Neall
  • Kate Stewart
  • Jack Manbeck
  • Ed Warnicke

Agenda

  • Composite Package Requirements
  • Verification Code
  • Basic practices on file naming (to include or not include version)

Verification Code

  • Discussion on whether we should include a verification code or just have an algorithm to calculate the verification code from the data within the SPDX document
    • Requirements – determine if a package has been modified – or - was this SPDX file generated against the files being looked at
    • Is it simpler to have a verification code than it is to calculate?
      • Depends on use case
      • Use Case 1: In comparing an SPDX document to the files, the algorithm would need to be executed anyway – would be more work to compare to the verification code
      • Use Case 2: In comparing 2 SPDX documents, only need to compare verification codes – would be less work
      • Variation on Use Case 2: case where the SPDX file represents a binary “blob” and the file level information may be lost
      • Use Case 3: Verification of an SPDX file used in a “side car” scenario (where the SPDX file is not included in the archive file itself)
      • Can’t think of any other use cases – but leaving open the possibility for other use cases
      • Use Case 2 would likely be done in a scenario where Use Case 1 would also be done (or in a scenario where the SPDX is used in a “side-car” scenario)
      • Remove the verification code would cause the SPDX files to not be backwards compatible – would need to be a 2.0 change
      • Concern about losing credibility if we throw the field out this early
      • Proposal to change the verification code to option for backwards compatibility
  • Fixing the algorithms
    • Discussed issues with the locale
    • Discussed proposal to encode in UTF-8 then perform a byte sort
      • Issue with UTF-8 encoding may have some options which differ for unusual characters – would result in byte sequence differences
      • Even if locale issues were resolved, the encoding issues would remain since the hash function is performed on the bytes.
      • Proposal to use common utility “iconv” to encode the text
        • Concern about licensing for some tools
        • Concern about acceptance in the Java community
      • No one on the call was comfortable providing a specific proposal/resolution
  • Next steps:
    • Fix the algorithm – continue discussion on fixing the algorithm
      • Seek out an expert (or experts) on encoding issues
      • Review section
      • Revisit if the field should be removed, remain mandatory or change it as optional
      • Seek out expert on encoding issues
      • For background - review section 7 man page for locale