Re: Bug#129604: general: Social Contract: We Do Hide Problems
On Sun, 2002-01-20 at 20:48, Manoj Srivastava wrote:
> Sounds very shifty to me. Or, to put it more charitably,
> sounds very defensive -- and certainly reduces my trust in the
> locksmith, him having to weasel behind a "you have no legally binding
> agreement" clause.
Let's project this little story back on reality, ie. on the Debian
Project. The bottom line is, no one in the Debian Project can guarantee
that the software we distribute is completely secure. We have neither
the legal backing nor financial slack to do so. So we say, "we have this
software that works for us, and you can use it - note that it may not be
secure so we give you no guarantees, but here's the source code so you
can check for yourself or have someone else check for you".
This is not weaseling behind a "you have no legally binding agreement"
clause, it's just common sense. In fact, it would be very misleading NOT
to say so, because people might think we do make guarantees about the
software, and use it for things it can't do securely.
> Yeah, sure -- I also have no agreement with him that he'll not
> just give his design away to the thieves at the get go, but I still
> have expectations (which may even hold up in court)
>
> All of what you have said makes me trust the locksmith less.
Maybe you had too much trust in him in the first place?
Don't get me wrong, it's easy to trust someone that has never failed
you. But each time there's a possibility of someone failing you, and
someone doesn't, you should be careful not to raise your expectations.
If your expectations and trust in someone are realistic, then you don't
need to start completely distrusting that person when he fails you. No
one is perfect, and perfection shouldn't be expected from anyone.
> But there are other brands. And there are other protective
> measures I can take if I knew the lock is vulnerable. Or other
> companies to go to (I mean, in the lock category called browsers, or
> MTA's, or even bind, there are multuple locksmiths making locks)
Only... They have all agreed, along with the Debian Project, to practise
controlled disclosure. By definition, no subscriber to the information
lists we are talking about can disclose that information without
breaking the agreement. So, while there are indeed other locksmiths,
they have a mutual agreement on this issue.
> Fabian> Are you saying there is someone who has access to
> Fabian> non-disclosure-before-fix information that knowingly spreads the
> Fabian> information to black hats? If you have proof of this, it would be
> Fabian> interesting to see it.
>
> Proof? No, or they would bve in jail. In security, though, one
> does risk assessment, and assessment is oftne done without even a
> vestige of ``proof''. Indeed, asking for proof during risk assessment
> smacks of naivete.
Yes. Only risk assessment is "your" (the user) responsibility. The
Debian Project does security issues in a particular way. So do other
vendors. You must ask yourself, "do I trust the Debian Project" or "do I
trust the red hats" or "do I trust the micro softs". The answer is, you
can't, because you can't control those entities to the full. They may
behave unexpectedly, and your co-operation with them should be adjusted
accordingly.
Thus, you must weigh the risk against the benefit. Many people have
decided that the benefits are big enough to warrant the risk. To reduce
the impact of a catastrophe, they take backups, and/or store sensitive
information in places that are unaccessible or in ways that render the
information useless to someone who steals it.
What I was saying was, "do you think someone who has access to
non-disclosure-before-fix-information has knowingly leaked that
information, breaking the agreement not to do so?" That would indeed be
serious.
> Ignoring the risk (and, in my assessment, looking at how
> widespread the communique between locksmiths is, there is no way in
> hell you can have any assurance there are no bad apples
> apprentices).
That's why the lists are non-disclosure-until-fix. They should be
treated in that way by each receiver. An apprentice should not have
access to the list.
> I would be more open about problems in my busness (espescially
> if that is carved in stone in front of my business -- the bit about
> being open), But, I am a mere farmer, and may not have the skillz or
> time to be a locksmith -- and a locksmith telling me ``if you don't
> like it, go do it yourself'' does not increase my love for the man.
It may well prove that if you take his advice, you'll learn that he is
right. You may never love him, but you may appreciate his frankness. He
can't protect you by being nice and doing everything you think he
should. He can only provide you with the very best of his lock designing
skills, he can show you the blueprints of the lock, and he can keep eyes
and ears open for stuff going on in the lock business and pass on
important information to you.
But he can't turn his back on other locksmiths, saying "my customers are
first priority" when there may be an issue that needs to be cleared out
by the experts before being brought to the public. (Doing something less
evil to prevent a greater evil from happening.)
> No. Don't tell people exactly how to open the lock, but *DO*
> tell them there may be a problem, and please take precautions. You
> can tell me about flaws without going into gory (and thief helping)
> details.
If I say "there's an unfixed root exploit in apache, we're working on a
fix", I've just issued a challenge to the black hats. Who will get there
first? Having my customers on the line, I must put my personal
principles aside for just a little while, bite my teeth and make sure my
customers are _protected_ before I let loose a band of hungry wolves
that will rip them to shreds if I happen not to get there first.
And note that I've already told my customers that they need to watch
out, as discussed above.
Also note that, as I said in an earlier post, I think the default action
should be immediate disclosure. I just acknowledge that things aren't
always that simple.
Cheers,
fabbe
Reply to: