/[gentoo]/misc/rfc/secure.rfc
Gentoo

Contents of /misc/rfc/secure.rfc

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Thu Sep 5 01:01:21 2002 UTC (12 years ago) by rphillips
Branch: MAIN
CVS Tags: HEAD
initial import

1 Purpose: Make Portage security aware
2
3 Pri Description Status Deadline Dependency Bug# Assigned
4 -------------------------------------------------------------------------------------
5 3 Signed ebuilds/packages (Status: Not Started) 1,2
6 1 Force RESTRICTed ebuilds (Status: Not Started) 1,2 1925 rphillips <rphillips@gentoo.org>
7 not to be mirrored
8 2 Accepted Use Crypto (Status: Not Started) 3 1925
9 Policy License Agreement
10
11 *Key*:
12 Pri: Priority (1=high)
13 Description:
14 Status: Not Started, Started, Beta, Alpha, Done
15 Deadline: Date, or empty for no deadline
16 Dependency: comments are labled below by number
17 Bug#: Is the bug referenced within the bug tracker?
18 Assigned: Anybody working on task?
19
20 ******************************************************************************
21 1:
22
23 Date: Mon, 2 Sep 2002 09:33:29 -0700
24 From: Ryan Phillips <rphillips@gentoo.org>
25 To: Daniel Mettler <mettlerd@icu.unizh.ch>
26 Cc: Spider <spider@gentoo.org>, "V. Alex Brennen" <vab@cryptnet.net>,
27 blizzy@gentoo.org, rphillips@gentoo.org
28 Subject: Re: Strong Distro Model
29
30 I just wanted to remind everyone that the encryption portion
31 that is either integrated internally/externally has to have the
32 ability to be turned 'off' - due to legal issues within certain countries.
33
34 Having a wrapper around GPG seems like the logical approach.
35
36 Here is a feature list I would like to see:
37
38 * make.conf variable that allows precidence of authentication method.
39 ie: AUTHMETHOD=3D"gpg,md5" or
40 AUTHMETHOD=3D"md5"
41 =20
42 * make.conf variable that allows unsigned files to be merged, but they
43 have to pass md5 checksums. This is for custom ebuilds, and 3rd party
44 ebuilds.
45 =20
46 * Due to filesizes of signature files I think they need to be committed
47 as binary signatures and not ascii armored... Ascii armored signatures
48 on tons of ebuilds will produce a large portage tree.
49
50 On the subject of security here are a few other things I have noted:
51
52 * Have a RESTRICT variable or keyword (or something) per ebuild that will
53 tell ibiblio not to mirror the archive tarball. There are certain
54 things that should not be exported from the ibiblio site (libdecss,
55 etc).
56
57 * Gentoo really needs an accepted license variable. This variable should
58 have a variable called: 'high-crypto' (just for an example) to enable
59 strong encryption support. Bug #1925 deals with this. We shouldn't
60 force strong encryption, openssl can be built with exportable encryption
61 that all countries should accept.
62
63 As a side note, I did submit an email to the Bureau of Export Control,
64 all *opensource* crypto is allowed to be exported from ibiblio and
65 mirrors legally from within the U.S.
66
67 Thoughts/additions on anything?
68
69 Regards,
70 Ryan
71
72 * Daniel Mettler <mettlerd@icu.unizh.ch> [2002-09-02 05:24]:
73 > -----BEGIN PGP SIGNED MESSAGE-----
74 > Hash: SHA1
75 >=20
76 > hi all,
77 >=20
78 > thanks for cc'ing.
79 >=20
80 > On Sunday 01 September 2002 10:39, Spider wrote:
81 > > "V. Alex Brennen" <vab@cryptnet.net> wrote:
82 > > > If you guys are serious about this I'll help you
83 > > > build your keyring/wot and modify the portage
84 > > > software to support a backward compatible
85 > > > crypto based verification system.
86 >=20
87 > great, i think many people are interested in seeing this feature
88 > in portage! :)
89 >=20
90 > > > We could
91 > > > probably use gpgme.
92 >=20
93 *snipped*
94
95 ******************************************************************************
96 2:
97
98 From: Daniel Mettler <mettlerd@icu.unizh.ch>
99 To: Spider <spider@gentoo.org>, "V. Alex Brennen" <vab@cryptnet.net>
100 Subject: Re: Strong Distro Model
101 Date: Mon, 2 Sep 2002 03:16:30 +0200
102 User-Agent: KMail/1.4.3
103 Cc: blizzy@gentoo.org, rphillips@gentoo.org
104
105 hi all,
106
107 thanks for cc'ing.
108
109 On Sunday 01 September 2002 10:39, Spider wrote:
110 > "V. Alex Brennen" <vab@cryptnet.net> wrote:
111 > > If you guys are serious about this I'll help you
112 > > build your keyring/wot and modify the portage
113 > > software to support a backward compatible
114 > > crypto based verification system.
115
116 great, i think many people are interested in seeing this feature
117 in portage! :)
118
119 > > We could
120 > > probably use gpgme.
121
122 it's probably the best gpg wrapper out there but "unfortunately"
123 it is written in c whereas portage is written in python. thus
124 gpgme is not really suitable for portage as spider mentioned
125 (unless portage would be rewritten from scratch using c)
126
127 let me share some experiences with you.
128
129 when i wrote my package-signing extension for portage
130 (http://www.icu.unizh.ch/~mettlerd/semesterthesis/) i was
131 looking for suitable crypto libraries for python and especially
132 python wrappers for gpg. i found only one such gpg wrapper which
133 seemed more or less suitable:
134
135 'python gnupginterface'
136 https://sourceforge.net/docman/display_doc.php?docid=5499&group_id=29555
137
138 as this wrapper did not look like being such a big deal nor
139 actively maintained, i decided to rather just hack the needed
140 things by myself. after all, gpg itself is already quite
141 suitable for being used from within other apps as it offers
142 options like --batch, --yes, --no etc. and especially
143 - --status-fd which writes tags for "parsing" to stdout.
144
145 alternatively, i was thinking about using a more "low-level"
146 crypto library instead, such as the 'python cryptography
147 toolkit' (http://www.amk.ca/python/code/crypto.html). the
148 advantage of this would be that the whole package-signing could
149 be really tightly integrated with portage. but the disadvantages
150 weighted too heavy in my view (re-implement most functionalities
151 of gpg, not leveraging gpg, probably lesser security than gpg
152 due to narrower exposure, risk of losing interop with gpg,
153 weaker performance, ...)
154
155 thus i decided to use gpg directly from within portage-sec and i
156 would recommend to do the same for the portage package signing
157 to be developed. gpg is nice and i think we could save a lot of
158 time and headache by leveraging it.
159
160 (btw. i am sorry for only scratching the surface here. the paper
161 eventually lightens some of the reasons behind my decisions. i
162 can elaborate it in greater detail later, if desired)
163
164 On Sunday 01 September 2002 10:39, Spider wrote:
165 > We are quite serious about this, but due to very limited
166 > portage developers, theres quite some time ahead before this
167 > can be made plausible.
168
169 my full understanding for this. i'd also vote for taking enough
170 time to really make good decisions and a nice design with
171 well-thought processes, use and test cases. right now,
172 stabilization is probably more important. later, on a new
173 development branch one could approach this.
174
175 > Whats needed is a simple interface in portage to automatically
176 > check the integrity of the .ebuild and the digest, as well as
177 > the patches.
178
179 yes. and perhaps some more, depending on what additional features
180 portage eventually will offer for ebuild devs.
181
182 btw. as my implementation was only a proof-of-concept i left out
183 patch verification (integrity of patches etc. was meant to be
184 ensured by the trusted ebuild dev "by contract", thus the ebuild
185 dev was meant to check the integrity of the required patches
186 from within the ebuild itself. this is suboptimal of course but
187 from a theoretical point it was ok then).
188
189 > to sign the digest would be enough to make sure the package
190 > wasn't tampered with on an external server, patches are
191 > equally important as the ebuild since you can sneak in
192 > anything in the patch.
193
194 yep.
195
196 if you have some time i would recommend to read chapter iii.10
197 and iii.11 (p. 22 bottom to p. 28 top) of the paper. this
198 describes the core concept of package signing behind the
199 portage_sec implementation i've written. whereas the
200 implementation is not really meant for being used furthermore
201 (prototype), the concept is imho actually quite nice (actually
202 quite standard, but it's explained concisely and
203 well-understandable). nevertheless i did not put every single
204 thought in the paper as i was pretty short in time already ;) i
205 can elaborate further details later.
206
207 i would love to hear some opinions about this concept from you,
208 especially about its feasibility regarding the gentoo
209 development process. at the time of writing i did not know
210 (still don't ;) how the gentoo dev process is really defined,
211 thus i just guessed how it might work. for example i designed it
212 that signing should happen on each (or some) devs own box
213 (instead of on a central server). then that signature gets
214 committed by cvs like any other file. this, to ensure maximum
215 security (as having private keys on servers is a big risk for
216 several reasons). devs' keys being signed by a master key which
217 can revoke its signature if needed. etc.
218
219 if somebody of you also made a concrete concept paper/sketch how
220 package-signing might be done for portage i would appreciate
221 very much if i could take a look at it, so we can discuss these
222 different concepts together, recognize weaknesses and strengths
223 and finally design/assemble a suitable concept alltogether.
224
225 btw. if you were wondering about why i put some (but not too much
226 either) emphasis on concepts it might explain some things if you
227 take a look at xp (e.g. on http://www.extremeprogramming.org/).
228 i really like some ideas of xp as a very light-weight, pragmatic
229 approach to software developing.
230
231 well, now... as a conclusion:
232
233 i would happily join your development efforts to build a nice
234 package-signing concept/extension for portage! :) i think that
235 my experience from making a package-signing prototype would be
236 of help for gentoo and i am very interested that portage/gentoo
237 gets a sophisticated, secure package signing feature.
238
239 thus, do not hesitate to drop me a line when time has come to
240 start on this! :) hmm.. actually we could already slightly start
241 discussing and evaluating conceptual things, what do you think?
242 just not too heavily as i am also limited in time atm (preps for
243 exams ;)
244
245 if you have any questions/remarks, feel free to ask/notify me!
246
247 regards
248
249 dan
250
251 ******************************************************************************
252 3:
253
254 PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY
255 SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING
256 TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS
257 OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-
258 DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR
259 EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY
260 ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS
261 WHICH APPLY TO YOU. THE AUTHORS OF GENTOO ARE NOT LIABLE FOR ANY
262 VIOLATIONS YOU MAKE HERE. SO BE CAREFULLY YOURSELF, IT IS YOUR
263 RESPONSIBILITY.

  ViewVC Help
Powered by ViewVC 1.1.20