Editing Fremantle/Repositories

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

== Introduction ==

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

== 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.

== Security Issues ==

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

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

On 21/01/2013, the Community has been contacted by a Nokia representative from the Nokia MeeGo team in-charge of supporting, in addition to the N9, Fremantle. However, due to the team being the late addition in Harmattan, they are foreign to Fremantle systems.

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 ==

== Options for Solutions ==

=== 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.

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 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 ==

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/Fremantle/Repositories"

Latest revision		Your text
Line 15:		Line 15:


-	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.	+	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.
		+

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

Personal tools

Navigation

Views

Editing Fremantle/Repositories