Nicolas Williams wrote:
On Fri, Sep 11, 2009 at 10:44:50AM +0100, Darren J Moffat wrote:
[snip]
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.
Can you provide more detail here please? Mostly, I'd like to know why a
longer chain of trust is weaker, and how long it'd need to be before we
asked a 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'll let others comment on interactivity except to say that my
understanding is that being non-interactive is a hard requirement for
the base cli. That doesn't mean that all clients must be
non-interactive, the GUI is an excellent example of an interactive UI.
Since, as you say, setting a publisher is rare, I don't see a reason to
break that requirement for a command users will use very infrequently.
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.
Can't imagine anyone disagreeing with that.
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.
No one ever said all packages had to be signed. I suggest you take a
close look at Bart's email on manifest signing, I think that will make
clear why clusters wouldn't need the hashes of manifests in them.
Brock
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
