So many formats, So few packages

[Jeff Johnson]

On Apr 7, 2011, at 2:31 PM, Bayard Bell wrote:

> 
> On 7 Apr 2011, at 10:46, Anders F Björklund wrote:
> 
>> Or just leave the archives with their +PORTFILE as they are,
>> and just treat the packages like an exported "lossy" format ?
>> The .tbz2.rmd160 should be "good enough" to go, and certainly
>> better than blocking the *real* goal of delivering binaries...
> 
> Anders,
> 
> At the risk of being a broken record, this doesn't solve MITM, which is a substantial problem in the current architecture. A major difference in the way that package managers with signature support operate when bundled with an OS is that you can assume that key distribution problems are already solved (if someone's picked up an OS distro with compromised keys, that's a different order of problem). Off the top of my head, the easiest way to solve this would be to distribute a package manager that's already an OS X signed binary containing a copy of the basic key material, while only publishing those binaries over https.
> 

There are levels of pain here, up to and including IMA/EVM and hardware
enforced package manager executable "trust".

ATM, there simply isn't the infrastructure in place to add
and maintain digital signatures on packages.

I suggested something like a couple weeks ago,
and Jordan's response was largely "Not gonna happen soon."

(and I'd tend to agree, pulling upstream tarballs with attached
signatures and verifying contents is an evolutionary process).

> If you want to ignore this part of the problem definition and not sign your packages, the "real goal" becomes distributing binaries without caring about their integrity or the resulting risk for people using them. If you look around at other contenders in the packaged open source distribution business, that's not where the mark is set.
> 

Its not a question of ignoring, its a question of defining what
the threat models are, prioritizing, and then matching up implementations
against the most important problems first.

Having a digest check -- and having info delivered through a separate channel
which can be secured in other ways -- isn't perfect, doesn't solve certain
attacks like MITM, and still is better than nothing whatsoever.

> I'm not happy showing up at this point and having to make these arguments, but it's not responsible to do otherwise, given that most of the risk will be transferred to users.
> 

responsible? I'm not sure that's the right word here.

One would have to define/prioritize the threat models and then
go through implementations in that order until finished.

In my vocabulary "not responsible" means not fixing a known
and active exploit, or denying the existence of a flaw. YMMV.

There's nothing "not responsible" between balancing risk and solution
cost transparently and focussing on the next level of security to implement.

I'd hardly call that "transferred to users" because "trust" is always
determined by end-users, it is end-user risk no matter what.

All that a MacPorts distro process can do is try to provide
info pertinent to making a "trust" decision to end users openly
and transparently.

Again, that is soley how I define "responsible", feel free to define
however you wish.

hth

73 de Jeff