Re: Reflections on Trusting Trust

From: aristeu (suporte_at_wahtec.com.br)
Date: 11/30/05 

To: "Kris Kennaway" <kris@obsecurity.org>
Date: Wed, 30 Nov 2005 13:01:38 -0200

>> Yes and no. Fixing other potential security risks is good, but not if
>> it leads users to think that the packages are more trustworthy than they
>> really are. In particular, if we started distributing signed packages,
>> I suspect that most people would assume that the signatures guaranteed
>> that the packages were good, rather than simply ensuring that the
>> packages
>> hadn't been modified with after they were built.
>>
>> If we're going to sign anything, we need to ensure not just that we're
>> signing what we think we're signing, but also that we're signing what the
>> *end users* think that we're signing.
>
>Seems to me that ignorance and a false sense of security is bad
>wherever it appears, so all we can do is try our best to educate users
>about what they're getting.

I think that with a clear policy the ports and packages could be singned.
Something like a banner during installation of a port "This key ensures that
this port was made/arranged by an official freebsd port mantainer. The
freebsd security team does not take responsability for its contents since it
was not scrutinized by them. Good luck!", or, for packages, a similar
message saying the package was built on freebsd infrastructure, but the
freebsd team don`t take responsability fot its contents, bla, bla...

I don't know what kind of authentication with port mantainers do you have,
but I
think between you guys and the port mantainers must exist some good scheme.
This part is OK. now is just the freebsd server and end users part. Sign it
with a "ports system" secret key, and a public key pre-installed on clients.
The secret key well guarded on ports system core... Simple as that, it can
mitigate some problems.

I realy dont think signing things ensure that a port or package is secure,
but but makes a hell of a better job proving that it came from where it
saids it came than loose hashes. Other than that,
"security by omission", if exists this, won't solve anything.

I know the freebsd-update and portsnap (potsnap I just discovered in this
thread)
solutions are good. I'm wishing this to be the freebsd standard.

I don't wanna push things, and I know things don't work this way. I just
wanned to show an end user opinion, on the reflections topic... :)
that said, I'm gone....

Thanks and best regards,
--aristeu

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

Relevant Pages

  • Re: binary patches?
    ... relatively small binary patch? ... upgrades could be done this way in preference to re-compiling ... that's why I prefer ports over packages at all. ... seperate binpatches for every port option or build setting. ...
    (freebsd-questions)
  • Re: Security advisory SA-02:04 typo?
    ... > The version of mutt on my Linux box is 1.2.5i. ... > my FreeBSD 4 Stable boxes is 1.2.4i, ... > the mutt port on the 4.4-RELEASE CD, 1.2.5i, and the mutt port just ... > In the advisory the following URLs are listed as fixed packages: ...
    (FreeBSD-Security)
  • Re: binary patches?
    ... downloading a binary diff file, ... relatively small binary patch? ... that's why I prefer ports over packages at all. ... seperate binpatches for every port option or build setting. ...
    (freebsd-questions)
  • Re: portupgrade O(n^m)?
    ... wanted to try and port sections of portupgrade and its related tools to ... in 15 mn to 20 mn you have your packages. ... because packages don't break when compiling. ...
    (freebsd-hackers)
  • Regarding packages and ports, up to dateness
    ... Recently, I have installed FreeBSD 5.4, first I would ... NetBSD on many of my computers, ... packages available for the latest stable release ... of its port for the latest stable release of FreeBSD. ...
    (freebsd-questions)