[kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module

[Garrett D'Amore]

Nicolas Williams wrote:
> On Thu, Apr 03, 2008 at 01:56:48PM -0700, Garrett D'Amore wrote:
>   
>>> 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.
>>>       
>> As I indicated earlier, if the pressure is one particular customer, why 
>> not send binary relief to that one customer, while the project team 
>> works to fully address concerns to make this bit of software up to the 
>> same quality (and I'm not just talking about code quality/robustness 
>> here -- but also supporting documentation, adherence to Big Rules, and 
>> fit-and-finish issues of the kind we normally require for Sun-developed 
>> software.
>>     
>
> Because then they can't get support through normal channels (e.g., by
> filing a bug via opensolaris.org).
>   

There are a lot of unbundled products that have never been reviewed, or 
are reviewed with different constraints (Sun Ray anyone?  Or 
historically, the various extra drivers such as Alternate Pathing, FDDI, 
HSI/P, etc.)

I don't think support == ARC review == integration into ON (or even 
Solaris).

It *may* be true that the group doing support may have to be the project 
team, rather than RPE.  But while the team is actively working on the 
project, this seems not unreasonable.

> I don't see the problem with having different levels of support for
> native features, well-integrated and not-so-well-integrated third party
> features.  The fact that this case came to the ARC says noone is
> avoiding the SDF, so talk of lower review requirements seems
> unwarranted.  OTOH, I think the i-team is asking for lower architectural
> requirements, as many a FOSS integration case seem to lately.
>   

Agreed.
> I think a warning in the manpage about volatility of the interfaces and
> lack of complete integration should suffice.  But when the project team
> comes back to complete the pam_smartcard replacement then all these
> issues should be addressed (i.e., I agree with Gary's comments).
>   

I think that is what I originally suggested, though I did say that 
derailing in order to offer the advice needed might be another 
reasonable option.  Mark took that option, and I support his decision.  
I didn't feel strongly enough to derail on my own.

Now the good news about this case getting derailed, is that unlike other 
recent cases which were also derailed, this one seems unlikely to 
abandon the project just because the case was derailed.  Which means 
that ARC will finally have a chance to write an opinion and maybe set 
some precedent.  Furthermore, it may bring the harsh light of day 
directly to bear on the problem that the ARC has been having sorting out 
these different review requirements.

If an important case is held up because we lack adequate direction to 
properly review it, then maybe the folks that need to help us find that 
direction will recognize that their leadership here is required.  
Wandering aimlessly doesn't seem to be working too well....

    -- Garrett