On Fri, Sep 11, 2009 at 10:44:50AM +0100, Darren J Moffat wrote: > Shawn Walker wrote: > >My personal view is that certs, key pairs, etc. should be largely > >invisible to most users, and as such, I'm treating them just as > >invisibly 8)
The key word there is "largely". You cannot completely hide the elements of cryptographic trust from all users always. IT departments can always ensure that the correct trust anchors are installed so that no user need ever be aware of the specifics of the cryptographic protocols used to protect them and the systems that they use. But in the case of independent/home/small office users we cannot entirely avoid interaction over signatures that cannot be validated to a trust anchor. And even if we could, trust needs to be transitive for ease of use, but in practice the longer the chains of trust, the weaker it is, so that even when we do have a suitable TA it may be desirable to interact with the user. > I agree that should be case, however I belive the only way that is going > to happen well is if it is taken into account in the design of the > abstractions between publishers, repositories, streams etc. Otherwise > they will be come more visible because they will be special. I agree. In particular I think that the new pkg set-publisher must be allowed to interact, both, to have the user "validate" certs when there's no suitable TA (sadness) and to have the user validate CA chains. The pkg set-publisher command should be a very infrequent one. I also think that users should be aware of streams -- it should not be easy to accidentally upgrade a system to /dev if it was installed to /release, even if the two streams come from the same publisher. Users may also want to install unsigned pkgs, and even clusters that refer to unsigned pkgs. In the first case there's no need for interaction in the pkg(1) install command: let the user specify a --force option. In the second case the manifest of the cluster should contain a hash of the manifests of unsigned pkgs. > There is important terminology and presentation of that in the UI for > signed manifests as well and I feel if we are having a discussion about > terminology that involves words like "publishers" and the concepts of > where binaries come from we must include the manifest signing > terminology in that too. Otherwise we are going to have to retro fit > or change in the near future. E.g., is there a link to validated execution? Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
