Shawn Walker wrote:
Nicolas Williams wrote:
On Thu, Sep 10, 2009 at 06:08:59PM -0500, Shawn Walker wrote:
Nicolas Williams wrote:
- Publishers are defined by files installed by packages. Those files
At this time, I don't believe packages are the right solution; it
creates a nasty boot-strapping problem and doesn't bring much benefit.
The specific details of how publishers are added are not as important as
the UI details. The UI should require users to point at publisher
definitions, and then should require users to "validate" any publishers
which are not signed by others. The nice thing about using pkgs is that
you'll get the "publisherd spec signatures" for free via manifest
signatures, but whatever.
What boot-strapping issues? The CD image would have the relevant files
installed already, therefore it'd trust the initial set of publishers.
First of all, the whole trust/signing thing is still under design
discussion, so I'm going to ignore anything related to that because I
can't account for what isn't yet designed.
That means you are saying "don't care about security we can bolt it on
later". No can't you need to build that into the design because not
getting the security model right will have major issues later. See
below for why I think this is important, it really impacts the
terminology and the abstractions between them.
I think if I had to summarise the proposal in a nutshell, it's simply this:
* Users shouldn't be adding/removing repositories.
Great.
* Users should just add publishers to their system (or use publishers
that were already defined on their pre-installed system); the process of
which pre-defines the available repositories, etc. from which we can
derive the available set of packages and streams.
Great.
Personally I find all the terminology in this very confusing and I have
a reasonable understanding of pkg(5) already. I think part of my
problem is that other systems only talk about "repositories" and today
that is all we really have.
I'm trying to understand what we actually gain by having any more
complexity than just repository as the terminology and I'm not sure I
get it yet.
Part of this is that I don't actually believe that there should be a
single signing key/cert pair used for /dev, /release, /nightly,
/contrib. The fact that the the master versions of them all are
"hosted" on opensolaris.org isn't to me relevant. It is interesting
that they are related and I see great benefit in having them be related
- but not necessarily by using the same manifest signing keys/certs. -
they may (very very likely in fact) use the same SSL transport
keys/certs. The rationale about /dev vs /release is good and I think
that type of relationship needs to be able to be modelled. Particularly
since we could in theory end up having a /contrib that needs to match a
corresponding /release.
In fact good security practice says don't sign multiple "product"
releases with the same key material. I know that security concious
customers would expect it. This was the intent of how elfsign works and
it supports that even if we don't (currently) use it that way.
We could end up with a /release (or /support) like repository for each
Release of the OS (or other layered software stack using pkg) say
Solaris N, Solaris N+1 etc. Or we could have a single /release
repository and use pacakge versions (particularly when we have freeze
points or what ever the correct name is) to do it. Either way we
really should change the manifest signing keys each time - or at least
provide the ability to do so; the NIST (US) and CESG (UK) guidelines on
encryption key mangement and lifetime highly recommend such behaviour.
I also see a strong need for (and the in design manifest signing allows
for this) a given repository to host packages signed differently. In
fact this is actually a good model for something like /contrib. The
person submitting and "owning" the package could be the one to sign it.
This allows for the case were binaries are pushed into a repository by
multiple different unrelated organisations/people.
I know I've rambled on a lot above about the manifest signing but I hope
you can see the connection between that and the terminology you are
proposing.
Over all I think it is actually pretty close, the one thing I'd consider
dropping is the stream concept and just keep it as publishers and
repositories. I think the stream concept is a good one but I'm not sure
we need to expose that to the users via the UI. Instead could we allow
repositories to contain repositories at least as far as the UI
terminology goes.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
