public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] RE: Portage package security model...
@ 2002-02-17  1:20 Ali-Reza Anghaie
  2002-02-17  3:59 ` Daniel Mettler
  2002-02-18  3:56 ` Nils Ohlmeier
  0 siblings, 2 replies; 5+ messages in thread
From: Ali-Reza Anghaie @ 2002-02-17  1:20 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]


Like I suspected there was already something similar but I hadn't found
it before. So the files/{digests} is part of the equation. And from at
least one rip in #gentoo it seems signing the packages seems silly to
some...

Anyhow, thanks... -Ali

-- 
OpenPGP key 53F7FF5F
--
I, the above, promise to use as many global variables, magic
numbers, gotos, and longjumps as I can, in order to make my
application code appear more magical.
-- (My friend JB)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] RE: Portage package security model...
  2002-02-17  1:20 [gentoo-dev] RE: Portage package security model Ali-Reza Anghaie
@ 2002-02-17  3:59 ` Daniel Mettler
  2002-02-18  3:56 ` Nils Ohlmeier
  1 sibling, 0 replies; 5+ messages in thread
From: Daniel Mettler @ 2002-02-17  3:59 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 17 February 2002 01:20, Ali-Reza Anghaie wrote:
> equation. And from at least one rip in #gentoo it seems
> signing the packages seems silly to some...

Not me. Well, signing the tgz-source-packages themselves might
be "silly" indeed. But not code/hash signing as such. In my view
good security is one of the most important requirements for
today's and tomorrow's IT (BTW guess why BillG is talking about
"trustworthy computing" suddenly).

And theoretically, "revisable" security is one of the biggest
advantages of Gentoo compared to other distros/OS'es as people
can actually really (re)view all the sources that were used to
build their whole system (not counting closed source packages,
which are not essential for running Linux in general ;). Thus in 
theory there is no need for trust (concerning software) in 
Gentoo. Nevertheless this does not mean we should not care about 
ebuild/hash signing as people usually do not review all their 
source code but trust that many others reviewed the parts of it 
(= that "original" sources have been used, that these sources 
have been reviewed by their original developers etc.). And 
that's exactly what ebuild/hash signing would be for. Of course 
security is never absolute in real-life, but if we can improve 
it with reasonable effort, we should do so (IMHO).

I intend to take a close look at Portage regarding these aspects 
but it will take some time though. Besides, security is a 
process, not a product or a piece of software (even if it is a 
particularly nice one ;). Thus for now I would just kindly ask 
Gentoo developers for some general "security awareness" (if it 
is not the case already).

Regards

Dani

- --
      ...::: Daniel Mettler | http://www.numlock.ch :::....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8byqhSLYjgrGjnWQRAnZYAJ9rxOVfJfntampG2FRgbsHwSmAgYwCfSy50
Lzhx8hLb7ttT/OT6y0FXhl8=
=aQIy
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] RE: Portage package security model...
  2002-02-17  1:20 [gentoo-dev] RE: Portage package security model Ali-Reza Anghaie
  2002-02-17  3:59 ` Daniel Mettler
@ 2002-02-18  3:56 ` Nils Ohlmeier
  2002-02-18  5:13   ` Bruce A. Locke
  1 sibling, 1 reply; 5+ messages in thread
From: Nils Ohlmeier @ 2002-02-18  3:56 UTC (permalink / raw
  To: gentoo-dev; +Cc: Ali-Reza Anghaie

> Like I suspected there was already something similar but I hadn't found
> it before. So the files/{digests} is part of the equation. And from at
> least one rip in #gentoo it seems signing the packages seems silly to
> some...

I don't think it's silly.
Because if Gentoo sings the ebuilds (and digest) my box can trust that what 
it will build out of the source is what the author wants it to do. It is a 
good way to prevent the classic man in the middle attack. I'm aware that i 
have to trust the keyholder and the authors of the ebuilds at all, but i 
don't trust my ISP and all the boxes between my box and cvs.gentoo.org.
Also signing the ebuilds will enabled to trust mirrors which hold the portage 
tree.

I think that the digest (because they are checked after the download) are 
intended to garantee the integrity of the tarballs. But only because of this 
digest i can trust the content of the mirrors.

Maybe the developers are more busy with other things, but its never to early 
to think about security.

Greetings
   Nils Ohlmeier


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] RE: Portage package security model...
  2002-02-18  3:56 ` Nils Ohlmeier
@ 2002-02-18  5:13   ` Bruce A. Locke
  2002-02-19  7:48     ` Nic Desjardins
  0 siblings, 1 reply; 5+ messages in thread
From: Bruce A. Locke @ 2002-02-18  5:13 UTC (permalink / raw
  To: gentoo-dev

On Sun, 2002-02-17 at 22:56, Nils Ohlmeier wrote:

> Maybe the developers are more busy with other things, but its never to early 
> to think about security.

If this matter is important to you then please feel free to work on
adding such functionality to portage.  I would like to see a prototype
of said system. :)

Just a tip though: any such system should be easy to use for the
developer and end user, and happen pretty much automatically for
developers.  I'm personally not going to be very friendly towards any
system that requires me to do gnupg commands manually and worry about
keys every time I want to check in a package, etc.  And only the most
paranoid users are going to go through the trouble of manually verifying
each package (meaning it wouldn't be used by most users).

It may sound lazy but considering upstream packages are not signed, most
developers don't even know each other in real life, and you are
implicitly trusting anyone who has the key and cvs access (any true
paranoid would see what I'm talking about).  Unless the system is simple
and transparent for developers and end users its (disclaimer: in my view
and my view alone) a pain that gives people a false sense of security
about software they are downloading from the internet.

There is also the issue of keys... who holds them, etc.  The signing of
packages could create political side effects and formalities.  We have
quite a few developers with CVS access.  This means we are going to be
sharing keys on multiple machines or have to go through a pain in the
arse every time we want to check a package in.  

Such a system may force the solid formation of "teams" and encourage a
more unfriendly BSD-style core development model.  As a gentoo developer
I like being able to work many different aspects of gentoo whenever I
feel like it.  And if a find an annoying bug I wish to fix, I like being
able to fix it, rather then spending time asking whichever "team" is in
charge of said package and having to ask for permission or whatever.
(ok, I'm exagurating, but I've heard too many horror stories from the
history of the *BSDs)

If we decide to avoid a team based structure, then we are going to have
to worry about individual keys.  Most packages, although sometimes
marked as having a maintainer, do not really have maintainers set in
stone.  Most of the packages are freely modified by any developer who
has a real reason to make changes to said packages.  Although there are
exceptions, portage does have maintainers due to its importance and the
fact its a gentoo creation (we are the upstream maintainers).  Also if
you as a developer are aware that someone is working on a package or has
a pet project, its considered good etiquite to ask them first (chances
are they are already working on the issue anyways).  So that means we
would either have to assign maintainers with keys to specific packages
and have changes cleared through them, or have the system check every
possible key against the package to see if the package has a valid
signature from 1 of 30 or so developers (I'm guessing about that
number).

Another alternative is a global key.  One key shared among all
developers... IMHO, there isn't much point of signing after that... if
the key is leaked (accounts hacked, etc) we'd have to get in touch with
all developers, reissue keys, and resign all packages after verifying
them all.

Just my two cents on the issue, feel free to flame or just call me
paranoid, crazy, etc ;)  Personally, I liked the open (more carefree?)
attitude towards the beginning of the project and I'd hate to see that
go away because of its increased popularity :)

-- 

Bruce A. Locke
blocke@shivan.org

"Those that would give up a necessary freedom for temporary 
  safety deserve neither freedom nor safety."
   -- Ben Franklin




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] RE: Portage package security model...
  2002-02-18  5:13   ` Bruce A. Locke
@ 2002-02-19  7:48     ` Nic Desjardins
  0 siblings, 0 replies; 5+ messages in thread
From: Nic Desjardins @ 2002-02-19  7:48 UTC (permalink / raw
  To: gentoo-dev

This may seem quite simple, but i completely agree with you.

I find unless the system were built completely transparent, it would be more trouble for not much more security...


On 18 Feb 2002 00:13:33 -0500
"Bruce A. Locke" <blocke@shivan.org> wrote:

> On Sun, 2002-02-17 at 22:56, Nils Ohlmeier wrote:
> 
> > Maybe the developers are more busy with other things, but its never to early 
> > to think about security.
> 
> If this matter is important to you then please feel free to work on
> adding such functionality to portage.  I would like to see a prototype
> of said system. :)
> 
> Just a tip though: any such system should be easy to use for the
> developer and end user, and happen pretty much automatically for
> developers.  I'm personally not going to be very friendly towards any
> system that requires me to do gnupg commands manually and worry about
> keys every time I want to check in a package, etc.  And only the most
> paranoid users are going to go through the trouble of manually verifying
> each package (meaning it wouldn't be used by most users).
> 
> It may sound lazy but considering upstream packages are not signed, most
> developers don't even know each other in real life, and you are
> implicitly trusting anyone who has the key and cvs access (any true
> paranoid would see what I'm talking about).  Unless the system is simple
> and transparent for developers and end users its (disclaimer: in my view
> and my view alone) a pain that gives people a false sense of security
> about software they are downloading from the internet.
> 
> There is also the issue of keys... who holds them, etc.  The signing of
> packages could create political side effects and formalities.  We have
> quite a few developers with CVS access.  This means we are going to be
> sharing keys on multiple machines or have to go through a pain in the
> arse every time we want to check a package in.  
> 
> Such a system may force the solid formation of "teams" and encourage a
> more unfriendly BSD-style core development model.  As a gentoo developer
> I like being able to work many different aspects of gentoo whenever I
> feel like it.  And if a find an annoying bug I wish to fix, I like being
> able to fix it, rather then spending time asking whichever "team" is in
> charge of said package and having to ask for permission or whatever.
> (ok, I'm exagurating, but I've heard too many horror stories from the
> history of the *BSDs)
> 
> If we decide to avoid a team based structure, then we are going to have
> to worry about individual keys.  Most packages, although sometimes
> marked as having a maintainer, do not really have maintainers set in
> stone.  Most of the packages are freely modified by any developer who
> has a real reason to make changes to said packages.  Although there are
> exceptions, portage does have maintainers due to its importance and the
> fact its a gentoo creation (we are the upstream maintainers).  Also if
> you as a developer are aware that someone is working on a package or has
> a pet project, its considered good etiquite to ask them first (chances
> are they are already working on the issue anyways).  So that means we
> would either have to assign maintainers with keys to specific packages
> and have changes cleared through them, or have the system check every
> possible key against the package to see if the package has a valid
> signature from 1 of 30 or so developers (I'm guessing about that
> number).
> 
> Another alternative is a global key.  One key shared among all
> developers... IMHO, there isn't much point of signing after that... if
> the key is leaked (accounts hacked, etc) we'd have to get in touch with
> all developers, reissue keys, and resign all packages after verifying
> them all.
> 
> Just my two cents on the issue, feel free to flame or just call me
> paranoid, crazy, etc ;)  Personally, I liked the open (more carefree?)
> attitude towards the beginning of the project and I'd hate to see that
> go away because of its increased popularity :)
> 
> -- 
> 
> Bruce A. Locke
> blocke@shivan.org
> 
> "Those that would give up a necessary freedom for temporary 
>   safety deserve neither freedom nor safety."
>    -- Ben Franklin
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-02-19  7:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-17  1:20 [gentoo-dev] RE: Portage package security model Ali-Reza Anghaie
2002-02-17  3:59 ` Daniel Mettler
2002-02-18  3:56 ` Nils Ohlmeier
2002-02-18  5:13   ` Bruce A. Locke
2002-02-19  7:48     ` Nic Desjardins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox