Re: Reflections on Trusting Trust

From: aristeu (
Date: 11/30/05

To: "Kris Kennaway" <>
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
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,

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

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. ...
  • 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: ...
  • Re: vhdl for beginners
    ... the ieee standardization body. ... officially balloted and approved packages for the vhdl language. ... SLV, but rather defines related types UNSIGNED and SIGNED which have ... For example, if you used an SLV input port, and you need to add one to ...
  • Re: Two issues updating FreeBSD 8.2 with portmaster
    ... excess of 300), ... In the ntp-devel port Makefile on my FreeBSD system. ... The packages are normally built to include the ...
  • 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. ...