Fremantle/Repositories - Revision history

imported_>sixwheeledbeast: Reverted edits by 85.207.214.182 (Talk) to last revision by 212.186.52.66

2022-07-04T12:36:24Z

Reverted edits by 85.207.214.182 (Talk) to last revision by 212.186.52.66

← Older revision		Revision as of 12:36, 4 July 2022
Line 51:		Line 51:
	=== Proposed Solution 1 - CSSU-Security ===		=== Proposed Solution 1 - CSSU-Security ===

	A CSSU-style ~~ups~~ pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.		A CSSU-style update is pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.


Line 58:		Line 58:

	This proposed solution would also require Community to sustain the infrastructure in the future to allow users to fix the GPG key issue on virgin fremantle systems, after a reflash or on freshly purchased devices. Support from Nokia in form of paying (part of) the bills for that hosting and maintenance of maemo infra would be highly appreciated.		This proposed solution would also require Community to sustain the infrastructure in the future to allow users to fix the GPG key issue on virgin fremantle systems, after a reflash or on freshly purchased devices. Support from Nokia in form of paying (part of) the bills for that hosting and maintenance of maemo infra would be highly appreciated.
	~~[http://www.example.com link title]~~

	== Agreed Solution ==		== Agreed Solution ==

85.207.214.182: /* Proposed Solution 1 - CSSU-Security */

2022-07-04T07:38:48Z

Proposed Solution 1 - CSSU-Security

← Older revision		Revision as of 07:38, 4 July 2022
Line 51:		Line 51:
	=== Proposed Solution 1 - CSSU-Security ===		=== Proposed Solution 1 - CSSU-Security ===

	A CSSU-style ~~update is~~ pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.		A CSSU-style ups pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.


Line 58:		Line 58:

	This proposed solution would also require Community to sustain the infrastructure in the future to allow users to fix the GPG key issue on virgin fremantle systems, after a reflash or on freshly purchased devices. Support from Nokia in form of paying (part of) the bills for that hosting and maintenance of maemo infra would be highly appreciated.		This proposed solution would also require Community to sustain the infrastructure in the future to allow users to fix the GPG key issue on virgin fremantle systems, after a reflash or on freshly purchased devices. Support from Nokia in form of paying (part of) the bills for that hosting and maintenance of maemo infra would be highly appreciated.
			[http://www.example.com link title]

	== Agreed Solution ==		== Agreed Solution ==

212.186.52.66: /* Issue 1 - Expired GPG key */ minor wording change

2013-01-22T16:12:05Z

Issue 1 - Expired GPG key: minor wording change

← Older revision		Revision as of 16:12, 22 January 2013
Line 22:		Line 22:
	=== Issue 1 - Expired GPG key ===		=== Issue 1 - Expired GPG key ===

	It is common knowledge that the GPG keys for Nokia's official Fremantle repositories ~~has been~~ expired ~~since~~ a few months.		It is common knowledge that the GPG keys for Nokia's official Fremantle repositories have expired a few months ago.


Line 38:		Line 38:

	There's only one key that would work, GPG key 4510B055 "MaemoSW Admin <admin@maemo.research.nokia.com>", which, luckily, has no expiration date. If Nokia is still in possession of the matching secret key, all they need to do for now is to sign their Release file with that key, and HAM will immediately work again as it did before - and then we can begin to think about shipping updates to users, to notify them of the existance of CSSU and/or to fix security issues (like the recent TÜRKTRUST intermediate CA leak).		There's only one key that would work, GPG key 4510B055 "MaemoSW Admin <admin@maemo.research.nokia.com>", which, luckily, has no expiration date. If Nokia is still in possession of the matching secret key, all they need to do for now is to sign their Release file with that key, and HAM will immediately work again as it did before - and then we can begin to think about shipping updates to users, to notify them of the existance of CSSU and/or to fix security issues (like the recent TÜRKTRUST intermediate CA leak).


	== Current Issues ==		== Current Issues ==

212.186.52.66: /* Basics of Operations */ minor wording

2013-01-22T16:08:09Z

Basics of Operations: minor wording

← Older revision		Revision as of 16:08, 22 January 2013
Line 15:		Line 15:


	HAM adds another layer of ~~complication~~ to this: every package installed via HAM, and the packages preinstalled in the .fiasco images, belong to a certain domain; each domain has a trust level, as specified in /usr/share/hildon-application-manager/domains/variant-domains.xexp, and each preinstalled repository specifies a certain domain for its packages; domains also have a certain list of keys, and for a certain version of a package to belong in a domain, the repo it's in has to be signed and correctly verified by HAM/apt-worker and the key used for the signing has to be listed in the domain information. This domain information is used by HAM to prevent upgrades of a package from a domain with a certain trust level to a domain with a lower trust level - and if the verification fails, packages are considered to be in the domain with 0 trust.		HAM adds another layer of complexity to this: every package installed via HAM, and the packages preinstalled in the .fiasco images, belong to a certain domain; each domain has a trust level, as specified in /usr/share/hildon-application-manager/domains/variant-domains.xexp, and each preinstalled repository specifies a certain domain for its packages; domains also have a certain list of keys, and for a certain version of a package to belong in a domain, the repo it's in has to be signed and correctly verified by HAM/apt-worker and the key used for the signing has to be listed in the domain information. This domain information is used by HAM to prevent upgrades of a package from a domain with a certain trust level to a domain with a lower trust level - and if the verification fails, packages are considered to be in the domain with 0 trust.


	== Security Issues ==		== Security Issues ==

imported_>kerio: a bit of explanation

2013-01-22T09:31:05Z

a bit of explanation

← Older revision		Revision as of 09:31, 22 January 2013
Line 12:		Line 12:
	== Basics of Operations ==		== Basics of Operations ==

			Every time HAM refreshes the catalogues, for each catalogue, the date on the Release file is checked, and, if it's more recent than the local copy, the Release file is downloaded, together with the Release.gpg file, that contains a gpg signature for it; the Release file is then considered valid if the signature was correctly made using a known, valid key; known keys are the ones stored in /etc/apt/trusted.gpg, and can be listed with `apt-key list` (ran as root). The Release file contains hashes of the Packages(.gz\|.bz2) file, which then contains the hashes of the rest of the files in the repo. Tools like apt-get will only issue a warning if a certain Release file can't be verified against a known key, and will ask for confirmation when it's time to download a package from an unverified repository.


			HAM adds another layer of complication to this: every package installed via HAM, and the packages preinstalled in the .fiasco images, belong to a certain domain; each domain has a trust level, as specified in /usr/share/hildon-application-manager/domains/variant-domains.xexp, and each preinstalled repository specifies a certain domain for its packages; domains also have a certain list of keys, and for a certain version of a package to belong in a domain, the repo it's in has to be signed and correctly verified by HAM/apt-worker and the key used for the signing has to be listed in the domain information. This domain information is used by HAM to prevent upgrades of a package from a domain with a certain trust level to a domain with a lower trust level - and if the verification fails, packages are considered to be in the domain with 0 trust.


Line 28:		Line 31:
	The issue is with the GPG key 13FA4ED6, known as "Nokia repository signing key 4v1". The Nokia MeeGo team have requested the Community to assist in a way forward that would help in solving this issue for all N900s.		The issue is with the GPG key 13FA4ED6, known as "Nokia repository signing key 4v1". The Nokia MeeGo team have requested the Community to assist in a way forward that would help in solving this issue for all N900s.


			The issue we're currently facing is caused by the expiration of the key used by Nokia to sign the Release files on the ssu/mr0 and ssu/apps repositories; the key is no longer valid, and HAM will regard all the packages in those repos as untrusted, preventing any upgrade or reinstallation of said packages from the Nokia repos - and the stock metapackage, used for "system upgrades", is one of those packages. As long as this situation isn't fixed, there's very little that can be done with those repositories, with regards to system packages.


			There's very little in terms of choice, to fix this: assuming we want to solve the problems for "vanilla" devices and "vanilla" users that don't know about CSSU, and that we want to avoid doing silly things like shipping an update to an unrelated package in a repository that we control (n900-fmrx-enabler for instance), the repository must be signed with a key that's already on the device, and the key must be listed as a viable key in the HAM domains, for the nokia-system and the nokia-certified domains.


			There's only one key that would work, GPG key 4510B055 "MaemoSW Admin <admin@maemo.research.nokia.com>", which, luckily, has no expiration date. If Nokia is still in possession of the matching secret key, all they need to do for now is to sign their Release file with that key, and HAM will immediately work again as it did before - and then we can begin to think about shipping updates to users, to notify them of the existance of CSSU and/or to fix security issues (like the recent TÜRKTRUST intermediate CA leak).


	== Current Issues ==		== Current Issues ==

imported_>joerg_rw: /* Options for Solutions */

2013-01-22T06:43:11Z

Options for Solutions

← Older revision		Revision as of 06:43, 22 January 2013
Line 46:		Line 46:


	This proposed solution would also require ~~Nokia~~ to ~~help~~ the ~~Community sustain~~ infrastructure in the future ~~via either sponsorship for~~ a ~~proposed 2 years~~ in ~~the~~ form of ~~hosting costs~~ for ~~all Maemo infrastructure~~ that ~~the Community will be~~ hosting~~. Therefore, a win-win situation for Nokia~~ and ~~users~~ of ~~Maemo~~.		This proposed solution would also require Community to sustain the infrastructure in the future to allow users to fix the GPG key issue on virgin fremantle systems, after a reflash or on freshly purchased devices. Support from Nokia in form of paying (part of) the bills for that hosting and maintenance of maemo infra would be highly appreciated.




	== Agreed Solution ==		== Agreed Solution ==

imported_>thedead1440 at 05:51, 22 January 2013

2013-01-22T05:51:17Z

← Older revision		Revision as of 05:51, 22 January 2013
Line 38:		Line 38:


	== Proposed Solution 1 - CSSU-Security ===		=== Proposed Solution 1 - CSSU-Security ===

	A CSSU-style update is pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.		A CSSU-style update is pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.
Line 48:		Line 48:
	This proposed solution would also require Nokia to help the Community sustain infrastructure in the future via either sponsorship for a proposed 2 years in the form of hosting costs for all Maemo infrastructure that the Community will be hosting. Therefore, a win-win situation for Nokia and users of Maemo.		This proposed solution would also require Nokia to help the Community sustain infrastructure in the future via either sponsorship for a proposed 2 years in the form of hosting costs for all Maemo infrastructure that the Community will be hosting. Therefore, a win-win situation for Nokia and users of Maemo.





	== Agreed Solution ==		== Agreed Solution ==

imported_>thedead1440 at 05:50, 22 January 2013

2013-01-22T05:50:29Z

← Older revision		Revision as of 05:50, 22 January 2013
Line 16:		Line 16:

	== Security Issues ==		== Security Issues ==


			=== Issue 1 - Expired GPG key ===

	It is common knowledge that the GPG keys for Nokia's official Fremantle repositories has been expired since a few months.		It is common knowledge that the GPG keys for Nokia's official Fremantle repositories has been expired since a few months.
Line 34:		Line 37:
	== Options for Solutions ==		== Options for Solutions ==

	Proposed Solution 1:
	A CSSU-style update is pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.		== Proposed Solution 1 - CSSU-Security ===
	CSSU-Security would merely add a repository to the user's device which would be able to first fix the signing key issue with a new signing key. This new signing key would be required to be added on Nokia's servers too.
	This proposed solution would also require Nokia to help the Community sustain infrastructure in the future via either sponsorship for a proposed 2 years in the form of hosting costs for all Maemo infrastructure that the Community will be hosting. Therefore, a win-win situation for Nokia and users of Maemo.		A CSSU-style update is pushed out to N900 devices. This CSSU update would be independent of the user having CSSU-Stable or CSSU-Testing. The proposed CSSU-Security branch would be solely for the purpose of pushing out security updates now and in the future.


			CSSU-Security would merely add a repository to the user's device which would be able to first fix the signing key issue with a new signing key. This new signing key would be required to be added on Nokia's servers too.


			This proposed solution would also require Nokia to help the Community sustain infrastructure in the future via either sponsorship for a proposed 2 years in the form of hosting costs for all Maemo infrastructure that the Community will be hosting. Therefore, a win-win situation for Nokia and users of Maemo.

imported_>thedead1440 at 05:48, 22 January 2013

2013-01-22T05:48:53Z

@@ Line 2: / Line 2: @@
 This page serves to stimulate discussion and exchange ideas with regards to Fremantle Repositories for the following:
-  Basics of Operation
+  Basics of Operations
   Security Issues
   Current Issues
   Options for Solutions
   Agreed Solution

imported_>thedead1440: Created page with "== Introduction == This page serves to stimulate discussion and exchange ideas with regards to Fremantle Repositories for the following: Basics of Operation Security Issues C…"

2013-01-22T05:34:22Z

Created page with "== Introduction == This page serves to stimulate discussion and exchange ideas with regards to Fremantle Repositories for the following: Basics of Operation Security Issues C…"

New page

== Introduction ==

This page serves to stimulate discussion and exchange ideas with regards to Fremantle Repositories for the following:
Basics of Operation
Security Issues
Current Issues
Options for Solutions
Agreed Solution