On 05/27/10 03:39 AM, John Rice wrote:
Thanks Brock - comments below.
JR
[snip]
GUI Required changes:
-----------------------------------------
Edit->Preferences: Certificate Tab: need image wide option support
to allow setting default signature verification policy (ignore,
verify, require).
This should use the same interface that pkg set-property uses.
Sure
Add Publisher:
- If signed display the common name for the CA for this Publisher
(also visible in Manage Publisher)
What do you do when a publisher has multiple CAs with potentially
different CNs?
You tell me, what will the CLI do, presumably this information will be
listed for the publisher in the "pkg publisher". We will need to play
with the UI for this a bit.
I have no plans for the CLI to display this information at the moment.
Once I decide what the right interface for --remove-ca-cert is, that
will likely inform this decision.
[snip]
- Allow optional overriding of Image signature verification policy
setting
- Need additional progress support to display when adding Publisher:
-- Download CA certs, verify CA certs, verify chain of trust.
I disagree. These will not be progress tracked for now beyond being
tracked by whatever operations include them. They will generally be
hidden inside the pkgplan evaluate step.
Ok if they are hidden in the pkgplan evaluate, that's fine as long as
we get some progress indication that something is happening.
Manage Publisher:
- Need to allow certificates common name to be viewed
Why?
This is part of the meta information for the Publisher, if its got a
CA then I assume the user would want to know or be able to access the
details.
In general, I have no plans for certs to be user visible at all by
default (probably). The idea is for signing not to bother the user as
much as is possible.
- Allow editing of signature verification policy setting
- Allow editing/ adding of certification path
Um, what's a certification path?
The path defined in the --add-ca-cert
After --add-ca-cert is run, the cert will be sucked into the image and
stored internally. We're not storing the external path.
[snip]
Install
- Need additional progress information to display to the user when
installing a package for:
-- CS cert download, manifest signature checking, verify chain of
trust....
See comment above.
Again we need a heartbeat at least to indicate to the user that
something is happening and we are not frozen.
If it turns out that this becomes a problem, we'll address it then.
Certificate expiration
- When should this be checked? On initial startup, will slow things
down, on install, remove, search?
Search? Why would signing ever be used for search?
Poor choice perhaps, just first use of the API could trigger the check
and then if it fails the user gets notified.
These are not SSL certs. They're only checked on the install of pacakges.
Certificates are verified on install. I imagine it has the potential
to slow things down some.
- If a certificate is expired user is warned, how do they renew the
certificate? Should we give them the option to disable the Publisher?
Please reread the document and the following discussion thread as I
explained how certificate expiration is handled. In short a user will
never be notified that a certificate has expired.
I did read the thread and thought that a certificate could expire. It
certainly did before and an exception was thrown, this was seen with
"extras". I will read it again though. Is the plan that the Publisher
will just update the certificate seamlessly for the user? If they fail
too then presumably an exception will be thrown and we will need to
handle that.
The certificates are verified against the time stamp of the package
they've signed. From that perspective, they cannot expire.
Listing Packages
- Will signed status of an installed package be returned in the List
API, and if so then we could indicate signed status to the user in
the main list or in the Details?
The signed status will not be returned in the list API.
Himm, seems like an omission to me. It gives a user a very important
level of reassurance to see that a package has been signed by a
trusted authority. Still I assume this information will be available
in the info API call at least, so we can display this in the Details
for a package.
Just as we don't support stickiness on a per package basis, nor will we
support (any time soon) signature decisions on a per-package basis. If
you want to be sure that a package is signed, set its publisher's
signature-policy to be "require-signatures". There are no plans to
include signature state in either list or info at this time.
Brock
Brock
JR
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
