touch-packages team mailing list archive

["Alejandro J. Cura" <alecu@xxxxxxxxxxxxx>]

Weird, I remember getting errors from download manager when testing the click scope with packages in staging with broken hashes.
Perhaps something changed in download manager since we landed this in the scope (mid august)?

Btw, is there any package in the staging store with broken hash? We can
try installing it with the click scope.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1330770

Title:
  click packages rely upon tls for integrity and authenticity

Status in the base for Ubuntu mobile products:
  Confirmed
Status in Click Package metadata search service:
  Fix Released
Status in Online service used by software center:
  Fix Released
Status in click package in Ubuntu:
  Fix Released
Status in ubuntu-system-settings package in Ubuntu:
  In Progress
Status in unity-scope-click package in Ubuntu:
  Fix Released
Status in ubuntu-system-settings package in Ubuntu RTM:
  Confirmed

Bug description:
  Hello, I just completed a quick review of the click source and the
  unity-scope-click source and behaviours, and found some opportunities
  for improvement.

  Debian, and Ubuntu, rely upon signed repository files with
  cryptographic hashes of packages to provide both integrity and
  authenticity checks for the packages hosted on that repository.

  The click framework and the unity-scope-click discovery and
  installation tool do not use signed repository files, nor do they have
  signatures of any sort on downloaded packages. The only integrity and
  authenticity checks are provided by the use of HTTPS.  The click
  verify command will check files within the archive against MD5sums
  stored inside the archive but the click verify command is not used
  during package installation. (This is suitable for validating
  integrity against accidental changes only.)

  While it appears that unity-scope-click properly uses HTTPS to
  download package metadata and packages, HTTPS alone is insufficient
  for our needs:

  - Someone in a position to create new certificates at any of several
  hundred certificate authorities could create certificates purporting
  to be our update servers. This actual problem has been discovered in
  the wild with several certificate authorities issuing wild-card
  certificates or even certificates with signing authority.

  - X.509 is extremely complicated; TLS is extremely complicated. Flaws
  in both are inevitable.

  - HTTPS prevents the use of caching.

  - HTTPS only 'works' for data-in-motion; it is useless for data-at-
  rest integrity and authenticity checks.

  I have not yet reviewed the tools that application authors will use to
  upload their packages to our distribution servers but note in passing
  that most of these issues are also issues for adding packages to our
  update servers -- packages in flight within our network can be
  corrupted for many reasons, packages on disk can be corrupted for many
  reasons. A signature mechanism can protect against internal network
  faults, storage faults, and provide assurance months or years later
  that an uploaded package was uploaded by someone in control of a
  corresponding private key.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1330770/+subscriptions