[SM-Discuss] Threat profile analysis for spackages not signed by authors
Seth Alan Woolley
seth at positivism.org
Wed Aug 31 21:24:19 EDT 2005
On Wed, Aug 31, 2005 at 07:52:02PM -0400, Sergey A. Lipnevich wrote:
> On Wed, 2005-08-31 at 16:00 -0700, Seth Alan Woolley wrote:
> > We can spend all day coming up with attack vectors:
> It's not my idea. It's what people do when they try to protect
> something: they decide who or what is going to endanger the protected
> entity. I believe it's called threat profile analysis, but don't take my
> word for it.
Your list was in no way exhaustive, so it shouldn't have been declared
correct. My point was that you can add points depending on your bias.
Threat profiles (as part of larger risk analyses) tend to best be done
by outside consultants with no stake in the process.
> > Personally, signed by guru anywhere is acceptable to me. HOWEVER, I've
> > proposed ways to resolve this conflict: 1 is with DETAILS signing, and 2
> > is with anonymous key names with a clickthrough wrapper over the
> > security policy to find the identity. 2 is cleanest (and not everybody
> > has to participate), but 1 is "I'll put up with it". Sergey seems to
> > have rejected number 2.
> > I fear though we'll lose Sergey if the clean method is proposed, but I
> > just don't see any reason why he can't use the clean method other than
> > an irrational fear or out of spite.
> Yes. It's not irrational. I develop software for living, so I learned
> not to trust 3rd party code though my professional experience.
90% of what we distribute is third party code. That must present quite
> It doesn't mean that I don't use it, I do a lot, but part of my desire
> to stick to open source and free[dom] software is that closed source
> is more difficult to trust. Also, breaches of sites like gnu.org are
> very recent events.
But as we see here, you seem to have taken the lesser of two evils
approach to the aforementioned conundrum.
In any case, trusting code is an altogether different problem than we
are solving with gnupg. We let the user trust as few third parties as
possible (basesystem) and let them append software from there, third
party as well as second and first party.
The user shouldn't be using us to figure out whether or not to trust a
package anyways -- we might include opera, for example, but who knows
what security vulns are in it?
Our bargain is that if they trust the vendor, we should get them what
the vendor intended -- if the vendor makes it difficult to establish
intent, we work on a best guess basis.
Nowhere in our bargain do we say that if we include a spell that you
should implicitly trust it. This is where choice and disclosure comes
> > Lastly, we all need to let our egos take a step back and let Sergey and
> > Arwed think about for a bit before pushing somebody to a decision. I
> > hope all that's needed to be said has been said at this point and a
> > little reflection will resolve the situation.
> I'm far from pushing anybody. On the contrary, I consider myself pushed,
> but that doesn't matter who's the bully here. The decision has to be
> made on factors other than personalities.
I was referring to people other than yourself, if that means anything,
and I'm trying to keep my replies shorter :)
> > It seems Arwed gets to decide which path we take -- the Clean or the
> > DETAILS (or entire spell) signature method (we really can't do a
> > PGP-based scm at this point) if Thomas isn't going to pipe in. I'd like
> > unanimity from Leads in every policy change such as this.
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050831/8a045ac5/attachment.bin
More information about the SM-Discuss