Technical Team/Minutes/2011-08-30

Minutes 8/30/2011

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