Ethan Blanton <[EMAIL PROTECTED]> writes: [...]
> As an interesting contrast, I "trust" the key used to sign Linux > Kernel releases, simply because it has been used for years to sign > empirically "good" kernel releases in a public location for which > bogosity would have been reported in some fashion in that span of > time were it going on; this is not a secure trust relationship, but > it is a sufficient indication that Things are As They Should Be for > a quick download check. I suspect it's more general than that. My boss at the time (and my current boss, as it happens) suggested years ago that signed email might usefully use similar ideas: really I want to know that the email is signed by the same key that a sequence of emails from that address has used rather than that the key owner has paid money to some company in the US. So really what I want is a user agent that tracks identities (including keys used for signing, email addresses, etc.) that I see, and lets me give some indication of my trust in the authorship of the messages, and it could keep track of how much I ought to trust a particular message based on past experience. (I guess nowadays the spam/not spam Bayesian buttons that many UAs have would be an obvious analogy, but I think they weren't around then---or weren't so common, anyway.) (Of course, this presupposes that people generally sign messages, which seems unlikely ever to be true; at the time we were part of a merger with the company that did Simeon/Execmail, which did PGP and S/MIME signing.) And (obviously) maybe a VCS could use some kind of similar idea, rather than trust always being binary. So maybe when I do "mtn update", I could give some indication of how lucky I feel, and then mtn could choose a revision that's either completely tested and signed by people I definitely trust, or perhaps a riskier one with possibly more features. _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
