Difference between revisions of "Features/Signed Bundles"
(Created page with '<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> == Summary == Signed bundles are bundles which have been cryptographically signed to verify the identity of their creator, …') |
m |
||
| Line 1: | Line 1: | ||
| − | <noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> | + | <noinclude>{{GoogleTrans-en}}{{TOCright}} |
| + | [[Category:Feature Page Incomplete]] | ||
| + | [[Category:Feature|Signed Bundles]]</noinclude> | ||
== Summary == | == Summary == | ||
| Line 16: | Line 18: | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
| − | Signed bundles would allow deployments to | + | Signed bundles would allow deployments to guarantee that bundles were created by the holder of specific key. |
== Scope == | == Scope == | ||
The signing tools are available at http://dev.laptop.org/git/projects/olpc-contents/ | The signing tools are available at http://dev.laptop.org/git/projects/olpc-contents/ | ||
| − | Support for parsing the format, maintaining "root keys", and displaying the keys via some user interface would need to be implemented | + | Support for parsing the format, maintaining "root keys", and displaying the keys via some user interface would need to be implemented in Sugar. |
== How To Test == | == How To Test == | ||
| Line 27: | Line 29: | ||
== User Experience == | == User Experience == | ||
| − | This needs to be fleshed out. But, when a bundle is signed the user would likely see some information in the Journal indicating who signed it. | + | This needs to be fleshed out. But, when a bundle is signed, the user would likely see some information in the Journal indicating who signed it. |
== Dependencies == | == Dependencies == | ||
== Contingency Plan == | == Contingency Plan == | ||
| − | We could switch from .xo to .rpm or another format with built in support for signing. | + | We could switch from .xo to .rpm or another format with built-in support for signing. |
== Documentation == | == Documentation == | ||
| Line 41: | Line 43: | ||
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] | ||
| − | |||
| − | |||
| − | |||
---- | ---- | ||
''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]'' | ''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]'' | ||
Revision as of 01:36, 18 October 2009
Summary
Signed bundles are bundles which have been cryptographically signed to verify the identity of their creator, or for other purposes. The specification was written by OLPC but never fully implemented.
Owner
This feature is looking for someone to adopt it.
Current status
- Targeted release:
- Last updated:
- Percentage of completion: 10%
Detailed Description
See olpc:Contents_manifest_specification
Benefit to Sugar
Signed bundles would allow deployments to guarantee that bundles were created by the holder of specific key.
Scope
The signing tools are available at http://dev.laptop.org/git/projects/olpc-contents/
Support for parsing the format, maintaining "root keys", and displaying the keys via some user interface would need to be implemented in Sugar.
How To Test
Features/Signed Bundles/Testing
User Experience
This needs to be fleshed out. But, when a bundle is signed, the user would likely see some information in the Journal indicating who signed it.
Dependencies
Contingency Plan
We could switch from .xo to .rpm or another format with built-in support for signing.
Documentation
Release Notes
Comments and Discussion
You can add categories to tie features back to real deployments/schools requesting them, for example [[Category:Features requested by School Xyz]]