import repository from arizona
[raven.git] / webpage / developer.html
1 <html>
2 <head>
3 <title> Developer Information </title>
4 <LINK href="stork.css" rel="stylesheet" type="text/css">
5
6 </head>
7
8 <body>
9
10
11 <div class="display" align="center">
12         <table border="0">
13         <tr>
14                 <td width="170" valign="top">
15
16                                 <br/>
17                                 <table cellpadding="3" width="170" id="links" class="links">
18                                         <tr>
19                                                 <td align="right">
20
21                                                         <ul class="links">
22
23                                                                 <a href = "index.html"><h3>Stork</h3></a>
24                                                                 <li class="links"><a href="tutmain.html">Stork Tutorial</a></li>
25
26                                                                 <li class="links"><a href="advanced.html">Advanced Usage</a></li>
27                                                                 <li class="links"><a href="arch.html">Stork Architecture</a></li>
28                                                                 <li class="links"><a href="filelist.html">Stork File List</a></li>
29                                                                 <li class="links"><a href="about.html">About Us</a></li>
30                                                                 <li class="links"><a href="apps.html">Related Links</a></li>
31                                                                 <li class="links"><a href="contact.html">Contact Stork</a></li>
32                                                                 <h4>Links</h4>
33                                                                 <li class="links"><a href="http://appmanager.berkeley.intel-research.net/plcontrol/apps.php?appid=1029">
34                                                                 Slice Status</a></li>
35                                                                 <li class="links"><a href="https://stork-repository.cs.arizona.edu">Stork Repository</a></li>
36                                                         </ul>
37
38                                                  </td>
39                                         </tr>
40                                 </table>
41                                 <br/>
42                 </td>
43
44                 <td valign="top">
45
46                 <table class="info" cellpadding="0" width="700" >
47                 <tr  height="75"><td colspan="3"><img style="margin-left: -0px;" src="images/stork-header.png" alt="stork logo"/></td></tr>
48                 <tr  bgcolor="#444444" class="headerrow" width="100%" height="2">
49
50                         <th colspan="2"> Developer Information </th>
51
52                 </tr>
53                 <tr valign="top" align="left">
54
55                         <td>
56                                 <table cellpadding="8" id="content" class="content">
57
58                                         <tr>
59                                                 <td>
60
61 This page assumes you understand the basics of Stork as described in the
62 <A HREF="http://www.cs.arizona.edu/stork/tutmain.html">Stork Tutorial</A>.
63 <h1> How packages are signed in Stork</h1>
64
65 Stork protects packages via signatures like most other tools.   However, 
66 signatures in Stork are different in two key aspects that pertain to 
67 package developers.   First, package signatures are <i>detached</i> from 
68 the package file.   This means that rather than adding the signature to the 
69 underlying RPM, tarball, etc. Stork places the signatures in a separate file 
70 called a <A HREF="http://www.cs.arizona.edu/stork/filelist.html">trusted packages</A> 
71 file.   This has several benefits such as allowing users to only download
72 signatures they need and allowing signatures of package types that don't 
73 inherently support them.   However it has the drawback that developers must
74 remember to upload their trusted packages file to the repository in addition
75 to their packages.
76
77 <br>
78 The second key aspect where signatures in Stork differ is that trust can be
79 delegated to other users.   This means that a user can say in their trusted
80 packages file to trust another user for a subset of the packages of interest.
81 This is an important mechanism that should be used by developers to sign 
82 the packages they distribute.
83 <br>
84
85
86 <h1> An Example (of how the world is today) </h1>
87
88 Suppose there is a project <code>foo</code> that distributes code to its 
89 users.   <code>foo</code> has a number of different developers that contribute
90 to the project and would like to be able to distribute updated versions.
91 <br>
92
93 This leaves the project with three alternatives:
94 <ol>
95 <li>Have a project key that all developers share</li>
96 <li>Ask all of the users to add the keys for all of the developers</li>
97 <li>Nominate a developer to be the only one to distribute updates</li>
98 </ol>
99
100 For the first two situations, there are difficulties in keeping key security
101 as members of the <code>foo</code> project come and go.   The third 
102 alternative greatly restricts the developers from distributing updates and
103 causes all fixes (no matter how minor or time sensitive) to filter through a 
104 single developer.   
105
106
107
108 <h1> A Better Way (using Stork) </h1>
109
110 For developers who sign their packages with Stork there is a better way.
111 Stork's trusted packages files can delegate trust to other users.   This
112 means that the <code>foo</code> project can have a trusted packages file
113 that they use as the "project" identity.   This project identity can
114 then delegate trust to the developers that are currently working on the 
115 project.
116 <br>
117
118 The project users need to only deal with the public key of the project
119 identity.   The project private key does not need to be exposed to any
120 of the developers.   If a developer's ability to indicate which packages
121 are trustworthy needs to be revoked (perhaps because the developer
122 leaves the project or has their private key compromised), the project identity
123 can do so without any action by the users or developers.   Similarly, a
124 new user can be authorized by the project identity without requiring manual
125 action by the users or developers.
126 <br>
127
128 <h1> How to set up a project identity </h1>
129
130 Now, step by step instructions for setting up a project identity are 
131 described.   Replace <code>foo</code> with your project name to use
132 these instructions to set up your own project.
133 <br>
134 <br>
135 First of all, create a public / private key pair for the project identity.
136 One way to do this is using the following <code>storkutil.py</code> command.
137 <br>
138 <code>python storkutil.py genpair <i>foo</i></code>
139 <br>
140 <br>
141 Now, for each developer, trust their public key to know which project files are
142 valid.
143 <br>
144 *<small>For large projects with multiple different subpackages, you may wish to put
145 a restriction on the project files that any one user can sign (by specifying
146 the project files instead of a wildcard '*'). </small>
147 <br>
148 <code>python storkutil.py --username=<i>foo</i> --privatekey=<i>foo</i>.privatekey adduser <i>developer</i> <i>developer</i>.publickey allow <i>projectfiles</i></code>
149 <br>
150 <br>
151
152 The project identity can also easily revoke a developer's ability to sign 
153 files.
154 <br>
155 <code>python storkutil.py --username=<i>foo</i> --privatekey=<i>foo</i>.privatekey removeuser <i>developer</i> </code>
156 <br>
157 <br>
158
159 Once you have finished adding and removing developers in your project 
160 identity's trusted packages file, <b>store your project's private key 
161 somewhere safe (preferrably offline).</b>
162
163 <br>
164 <br>
165 Upload the project's trusted packages file to the Stork repository.
166 <br>
167
168 <br>
169 Make your project's public key available to your users.   The users should
170 trust the publickey for only the packages your project distributes. 
171 For example if <code>foo</code> project distributes packages in RPM format, 
172 then the users should execute a command like:
173 <br>
174 <code>python storkutil.py adduser <i>foo</i> <i>foo</i>.publickey allow <i>foo-*.rpm</i></code>
175 <br>
176 <br>
177
178
179 That's it!   Now any of the trusted developers can sign new releases of 
180 the <code>foo</code> project's packages.   All users who trust the project
181 identity will have all of the signed packages available for installation.
182
183                                                         <center><a href = "index.html">Home</a>     <a href = "#top">Top</a></center>
184
185                                                 </td>
186
187                                         </tr>
188                                 </table>
189                         </td>
190                 </tr>
191
192        </table>
193        </td>
194
195      </tr>
196      <tr>
197         <td></td>
198
199         <td>
200                 <a href="http://www.planet-lab.org"><img style="border: 0px; border-style: none;" src="images/powered_by_pl_grey.png" alt="powered by planetlab"></a>
201
202                                         <a href="http://www.cs.arizona.edu"><img style="position:relative; left: 20px; border: 0px; border-style: none;" src="images/template_logo_small_grey.png" alt="University of Arizona, Computer Science logo"></a>
203
204
205
206
207
208         </td>
209      </tr>
210
211 </table>
212
213 </div>
214
215
216 <script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
217 </script>
218 <script type="text/javascript">
219 _uacct = "UA-1868232-1";
220 urchinTracker();
221 </script>
222 </body>
223 </html>
224
225