[kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module
Garrett D'Amore
gdamore at sun.com
Fri Apr 4 08:14:23 PDT 2008
Ok, I'm confused.
If the documentation isn't part of the review, and the user experience
isn't really part of the review (by corollary), and the project team
isn't interested in changing anything, then why exactly are we reviewing
this case?
I don't know that I feel TCR strong on much about this case, but then
again, if we're asserting that the only thing I'm looking at as part of
ARC review is "interfaces" between this project and other software, and
it is only using documented PAM interfaces, then there really is nothing
left to review.
I would request TCAs as follows:
*) add an auditable interface to administer (perhaps by just enabling)
the module
*) remove the wording "smartcard" from the prompts -- since it clearly
isn't an actual smartcard
*) the make_hash_links.sh script feels like a hack -- remove the .sh,
and promote it to a regular command if one is needed.
*) the documentation should be provided in a manner that is consistent
with other Sun-delivered projects -- the details for administration of
smartcard authentication should located in the standard Sun manuals
(i.e. in the System Administrator's Guide or whatever it is called these
days)
On an aside, I think it is a total shame that we're completely
abdicating everything about Solaris architecture to Linux or other FOSS
projects. If that is the way forward, then perhaps ARC ought to just
disband.
-- Garrett
Darren J Moffat wrote:
> Wyllys Ingersoll wrote:
>> I disagree. For many weeks now the submitter has answered the
>> questions and made all of the corrective actions requested by the ARC
>> on this case and now there is talk of derailing it? I don't think
>> any architectural issues were found with the project. The
>> documentation is weak, but the submitter has agreed to work with the
>> open source group that owns it to address the doc issues.
>
> I'm with Wyllys on this. The quality of documentation isn't really an
> ARC concern. The ARC's concern is are they presented with sufficient
> specification to understand the architecture. Consider that for most
> projects we never see the actual documentation (other than sometimes
> draft man pages) at ARC review time.
>
>> The "auditable administration" question was answered already - there
>> is no auditable interface for any PAM configuration files or any
>> other files that are managed via "vi" (or whatever editor) for that
>> matter.
>
> I think the issue is more about the modules own config file, however
> there are recently approved ARC cases for PAM modules that use $EDITOR
> as the admin interface.
>
> Also there are plenty of other cases recently that have security
> relevant configuration files that have no admin interface - consider
> things like SSL/TLS configuration of Apache/PHP etc.
>
>> Discussions over how best to merge FOSS and ARC needs is something
>> that should be discussed outside of this case.
>> The project team has been playing fetch-a-rock for too long. The
>> final specs have been submitted, I think Darren is planning on
>> putting them in the case dir very soon. This case should be
>> approved so the team can move ahead.
>
> The only difference was the removal of the pkc11_event_manager.
>
> Given the case has been derailed as fast-track submitter I'm taking
> case ownership of this.
>
> Since the project team has no intention of changing the specification
> or playing further rock fetching games I see no value in having a
> meeting.
>
> I'm calling for an EMAIL VOTE now.
>
> If there are TCRs please articulate them very specifically in a form
> that can realistically be implemented as part of your reply.
>
More information about the kmf-discuss
mailing list