[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-download-manager (Ubuntu Vivid) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-download-manager in Ubuntu. https://bugs.launchpad.net/bugs/1330770 Title: click packages rely upon tls for integrity and authenticity Status in Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Fix Released Status in ubuntu-system-settings package in Ubuntu: Fix Released Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: Won't Fix 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
Fixed in https://gitlab.com/ubports/development/core/lomiri-download- manager/-/commit/df3665685da5cfb559a06016d4e0339c29b903e1 (2015), that first appeared in version 0.9+15.10.20150723.2-0ubuntu1. ** Changed in: ubuntu-download-manager (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-download-manager in Ubuntu. https://bugs.launchpad.net/bugs/1330770 Title: click packages rely upon tls for integrity and authenticity Status in Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Fix Released Status in ubuntu-system-settings package in Ubuntu: Fix Released Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Summary changed: - Indications of Anxiety Disorder and Depression + click packages rely upon tls for integrity and authenticity ** Description changed: 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. - - https://usapillspharma.com/ 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 -- 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 Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: Fix Released Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Status: In Progress => Fix Released -- 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 Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: Fix Released Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch unlinked: lp:click/devel -- 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 Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Status: Fix Committed => Fix Released -- 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 Canonical System Image: Fix Released Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Status: In Progress = Fix Committed -- 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 Canonical System Image: Fix Committed Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~ubuntu-branches/ubuntu/wily/ubuntu-download- manager/wily-proposed -- 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 Canonical System Image: In Progress Status in Click Package Index: Fix Released Status in Software Center Agent: Fix Released Status in click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
this seems stalled ** Changed in: canonical-devices-system-image Milestone: ww26-2015 = ww34-2015 -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Milestone: ww21-2015 = ww26-2015 ** Changed in: canonical-devices-system-image Assignee: Canonical Phone Foundations (canonical-phonedations-team) = John McAleely (john.mcaleely) -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager source package in Vivid: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Milestone: ww17-2015 = ww21-2015 -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Assignee: Ricardo Salveti (rsalveti) = Canonical Phone Foundations (canonical-phonedations-team) -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Assignee: Bill Filler (bfiller) = Ricardo Salveti (rsalveti) ** Changed in: canonical-devices-system-image Milestone: ww13-2015 = ww17-2015 -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Milestone: ww09-2015 = ww11-2015 -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Milestone: ww11-2015 = ww13-2015 ** No longer affects: ubuntu-download-manager (Ubuntu RTM) ** No longer affects: ubuntu-system-settings (Ubuntu RTM) -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~mandel/ubuntu-download-manager/general-errors ** Branch linked: lp:~mandel/ubuntu-download-manager/general-errors-rtm -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu RTM: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Also affects: ubuntu-download-manager (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-download-manager (Ubuntu RTM) Importance: Undecided Status: New ** Changed in: ubuntu-download-manager (Ubuntu RTM) Importance: Undecided = Critical ** Changed in: ubuntu-download-manager (Ubuntu) Importance: Undecided = Critical ** Changed in: ubuntu-download-manager (Ubuntu RTM) Status: New = Confirmed ** Changed in: ubuntu-download-manager (Ubuntu) Status: New = Confirmed ** Changed in: ubuntu-download-manager (Ubuntu) Assignee: (unassigned) = Manuel de la Peña (mandel) ** Changed in: ubuntu-download-manager (Ubuntu RTM) Assignee: (unassigned) = Manuel de la Peña (mandel) -- 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: In Progress 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-download-manager package in Ubuntu: Confirmed Status in ubuntu-system-settings package in Ubuntu: In Progress Status in unity-scope-click package in Ubuntu: Fix Released Status in ubuntu-download-manager package in Ubuntu RTM: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Milestone: ww07-2015 = ww09-2015 ** Changed in: canonical-devices-system-image Assignee: Canonical Devices Products (canonical-devices-products-team) = Bill Filler (bfiller) -- 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: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Status: Confirmed = In Progress ** Changed in: canonical-devices-system-image Milestone: ww05-2015 = ww07-2015 -- 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: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
The fix that landed in trunk isn't quite complete, it does verify the hash properly but doesn't handle the error signal. I'm suspecting it isn't getting the error signal from ubuntu-download-manager. ** Changed in: ubuntu-system-settings (Ubuntu) Status: Fix Released = In Progress -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
I'm using a python script to run a fake server, you can see the instructions in our test plan under CHECK HASH https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
I added some debug output to download_tracker.cpp, registerError is never getting called, which is the function connected to Download::error. I don't think ubuntu-download-manager is emitting the error when the hash check fails. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:ubuntu/vivid-proposed/ubuntu-system-settings -- 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: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
This bug was fixed in the package ubuntu-system-settings - 0.3+15.04.20150123-0ubuntu1 --- ubuntu-system-settings (0.3+15.04.20150123-0ubuntu1) vivid; urgency=low [ Manuel de la Peña ] * Add support for checksum validation. (LP: #1330770) [ Diego Sarmentero ] * Add support for checksum validation. (LP: #1330770) -- Ubuntu daily release ps-jenk...@lists.canonical.com Fri, 23 Jan 2015 16:53:49 + ** Changed in: ubuntu-system-settings (Ubuntu) Status: Confirmed = Fix Released -- 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: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~ken-vandine/ubuntu-system-settings/rtm-check-hash -- 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: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~mandel/ubuntu-system-settings/check-hash -- 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: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~mandel/ubuntu-download-manager/check-hash -- 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: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Also affects: ubuntu-system-settings (Ubuntu RTM) Importance: Undecided Status: New ** Changed in: ubuntu-system-settings (Ubuntu RTM) Status: New = Confirmed ** Changed in: ubuntu-system-settings (Ubuntu RTM) Importance: Undecided = Critical ** Changed in: ubuntu-system-settings (Ubuntu RTM) Assignee: (unassigned) = Manuel de la Peña (mandel) -- 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: Confirmed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Status: In Progress = New ** Changed in: ubuntu-system-settings (Ubuntu) Status: New = Confirmed ** Changed in: ubuntu-system-settings (Ubuntu) Assignee: Ken VanDine (ken-vandine) = peterstan (stasnel) -- 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: Confirmed Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
seb were you handling this one? ** Changed in: canonical-devices-system-image Milestone: ww51-2014 = ww05-2015 ** Changed in: ubuntu-system-settings (Ubuntu) Assignee: peterstan (stasnel) = Sebastien Bacher (seb128) ** Changed in: ubuntu-system-settings (Ubuntu) Assignee: Sebastien Bacher (seb128) = Manuel de la Peña (mandel) -- 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: Confirmed Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
I just noticed the open task for ubuntu-system-settings about doing a addtional hashsum check for the download. Fwiw, click is already doing a gpg verification before the install so corrupted/MITMed clicks will not get installed there. Having the hash check may still be a good idea for e.g. better error reporting. -- 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: Confirmed Status in unity-scope-click package in Ubuntu: Fix Released 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: canonical-devices-system-image Importance: Undecided = High ** Changed in: canonical-devices-system-image Status: New = Confirmed ** Changed in: canonical-devices-system-image Milestone: None = r1 ** Changed in: canonical-devices-system-image Assignee: (unassigned) = Canonical Devices Products (canonical-devices-products-team) -- 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 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** No longer affects: unity-scope-click -- 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 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Assignee: Diego Sarmentero (diegosarmentero) = Sebastien Bacher (seb128) -- 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 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Assignee: Sebastien Bacher (seb128) = (unassigned) -- 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 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Assignee: (unassigned) = Ken VanDine (ken-vandine) -- 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 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Tags removed: touch-2014-10-16 ** Tags added: touch-2014-10-23 -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Tags removed: touch-2014-10-09 ** Tags added: touch-2014-10-16 -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~diegosarmentero/ubuntu-system-settings/check-hash -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: ubuntu-system-settings (Ubuntu) Status: Triaged = In Progress -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed 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 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
I've set this to Critical, because it will affect every user doing updates of any app. ** Changed in: ubuntu-system-settings (Ubuntu) Importance: High = Critical -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: Fix Released Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Tags added: touch-2014-10-09 -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: Fix Released Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
I see an ubuntu-system-settings task and was wondering what it is for? The spec (https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning) says: Configuring the system to allow installing unsigned packages should not be exposed via the UI and only available via the command line/adb. Should this task be removed? ** Changed in: ubuntu-system-settings (Ubuntu) Status: Triaged = Incomplete -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: Fix Released Status in “ubuntu-system-settings” package in Ubuntu: Incomplete Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:ubuntu/utopic-proposed/click -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
This bug was fixed in the package click - 0.4.31.2 --- click (0.4.31.2) utopic; urgency=medium [ Michael Vogt ] * Add click info interface to get manifest corresponding to file in installed package (LP: #1324853). * Add support for click package gpg signatures (LP: #1330770). [ Colin Watson ] * Ugly hack to get coverage reporting working again with gcovr 3.1. [ Ubuntu daily release ] * New rebuild forced -- Ubuntu daily release ps-jenk...@lists.canonical.com Fri, 22 Aug 2014 17:19:06 + ** Changed in: click (Ubuntu) Status: In Progress = Fix Released -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: Fix Released Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:ubuntu/utopic-proposed/unity-scope-click -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Committed 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
This bug was fixed in the package unity-scope-click - 0.1.1+14.10.20140821.1-0ubuntu1 --- unity-scope-click (0.1.1+14.10.20140821.1-0ubuntu1) utopic; urgency=medium [ Alejandro J. Cura (alecu) ] * New upstream release. - Display Ubuntu logo in the header of apps scope. (LP: #1350610) - Pass the sha512 hash from the details webservice to download manager. (LP: #1330770) - Sort departments alphabetically. (LP: #1354044) - Exclude empty departments from the departments tree in Apps. (LP: #1350609) - Provide updated departments to match latest server changes. Bumped schema to 3. - New script to enable purchases in the scope during beta. (LP: #1356419) - Add dependency on libglib2.0-bin and upstart-bin for script above. - Enable QNetworkDiskCache for http GET requests. (LP: #1351212) - Query download manager for in-progress downloads. (LP: #1234965) - Only show extended info for apps from the store. (LP: #1350571) - Don't expand categories by default in the store. (LP: #1355221) - Do not use static const strings for translations. (LP: #1354501) - Change All departments to just All. (LP: #1351536) - Localize the extra department title in the store. (LP: #1358790) - Updated translations. [ Martin Pitt ] * Mark for using language packs. [ Ubuntu daily release ] * New rebuild forced -- Ubuntu daily release ps-jenk...@lists.canonical.com Thu, 21 Aug 2014 20:40:59 + ** Changed in: unity-scope-click (Ubuntu) Status: Fix Committed = Fix Released -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Released 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: unity-scope-click (Ubuntu) Status: In Progress = Fix Committed -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: Fix Committed Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: Fix Committed 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: click-package-index Status: Fix Committed = Fix Released -- 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 Click Package metadata search service: Fix Released Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: In Progress 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: unity-scope-click (Ubuntu) Status: New = In Progress -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: Fix Committed Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: In Progress 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~alecu/unity-scope-click/verify-sha512 -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: Fix Committed Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: In Progress 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: software-center-agent Status: Fix Committed = Fix Released -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: Fix Released Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: In Progress 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: click (Ubuntu) Assignee: (unassigned) = Michael Vogt (mvo) -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: Fix Committed Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: software-center-agent Status: New = In Progress -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: In Progress Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: software-center-agent Status: In Progress = Fix Committed -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: Fix Committed Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: click-package-index Assignee: James Tait (jamestait) = (unassigned) -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: New Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: click-package-index Status: New = Fix Committed -- 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 Click Package metadata search service: Fix Committed Status in Online service used by software center: New Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Also affects: unity-scope-click Importance: Undecided Status: New ** Also affects: click-package-index Importance: Undecided Status: New ** Changed in: click-package-index Assignee: (unassigned) = James Tait (jamestait) -- 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 Click Package metadata search service: New Status in Online service used by software center: New Status in Click Packages Scope for Unity: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/click-package-index/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: unity-scope-click (Ubuntu) Importance: Undecided = High -- 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 Online service used by software center: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: Triaged Status in “unity-scope-click” package in Ubuntu: New 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/software-center-agent/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Changed in: click (Ubuntu) Status: New = In Progress ** Changed in: click (Ubuntu) Importance: Undecided = High -- 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 Online service used by software center: New Status in “click” package in Ubuntu: In Progress Status in “ubuntu-system-settings” package in Ubuntu: New Status in “unity-scope-click” package in Ubuntu: New 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/software-center-agent/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1330770] Re: click packages rely upon tls for integrity and authenticity
** Branch linked: lp:~mvo/click/debsigs-verify -- 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 Online service used by software center: New Status in “click” package in Ubuntu: New Status in “ubuntu-system-settings” package in Ubuntu: New Status in “unity-scope-click” package in Ubuntu: New 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/software-center-agent/+bug/1330770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
