| 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.
|
| 264 |
|
Parent Directory
| 
Revision Log