Skip to content

Technical Team/Minutes/2011-08-30

Archived page

Read-only copy of the SPDX wiki. The wiki is no longer active; its content has moved to https://github.com/spdx. Last edited 2013-03-06 by MartinMichlmayr.

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

Categories: Minutes, Technical