I just finished reviewing the materials for 2006/283 (pkcs11 PAM module)
as promised yesterday. My notes on that case will be sent to that case
log momentarily.
However, it seems that case again underscores this schizophrenia that
ARC (and perhaps all of Solaris) is suffering from. We need to get a
*much* clearer picture of what the rules are for ARC. And this picture
needs to come from the consumers of ARC -- i.e. the community (e.g. the
ON C-Team), and the executive management for Solaris.
Specifically, we seem to have cases which basically want to elide ARC
review, because they are adhering to (or importing from) FOSS software.
What is the point of bringing such cases to ARC at all?
(There are also cases for new stuff developed at Sun, where we've been
told that the project team is under such time pressure to deliver, that
presentation of materials for the system is not being done, or not being
done completely, because of ENOTIME. That seems like a case of
managerial amnesia to me.)
How do we reconcile the issues that arise when software
developed/delivered without ARC review (or with all the normal Big Rules
for Solaris software "waived" because of upstream purity) becomes used
for "core" parts of Solaris. (E.g. when pkcs11_pam is used as a key
piece of our Solaris authentication strategy, but fails to meet certain
"Big Rules" for Solaris security?)
Are we really adding value with ARC review, if large components of the
System are able to waive normal ARC requirements?
Tim, can you *please* help provide direction here? Even after
yesterday's closed meeting to discuss some of this, I feel basically
that ARC is operating rudderless here. We need someone to assert
otherwise, and help us figure out where we are headed!
Yes, I still believe that there is merit here in ARC review, but *only*
if the end-user (or possibly administrator) is able to easily separate
the "stable, reviewed, and architecturally correct parts of Solaris"
from the vast multitude of freeware (some of which may be developed at
Sun!) which is developed under very different rules. Without a way to
separate this, we might as well just give up on most of our engineering
values (ARC review, C-Team, code review, and controlled RTI) and embrace
the anarchy & chaos that characterize most of the rest of the FOSS
world. (The consequences of such a decision are left as an exercise for
the business teams.)
-- Garrett
