I approve this contract as the SUPPLIER.

Anup

On Jan 27, 2009, at 10:00 AM, Mark A. Carlson wrote:

> Anup,
>
> Please reply-all to this email indicating you accept this contract.
>
> Thanks,
>
> -- mark
>       CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
>
> 0.  Number:  PSARC/2003/500-31
>
> 1.  This contract is between
>       a SUPPLIER of INTERFACES and
>       a CONSUMER of those INTERFACES,
>    both of whom are entities within Sun Microsystems, Incorporated.
>
> 2.  The SUPPLIER (definer and/or implementor) is identified by the  
> following:
>    Product or Bundle:  Solaris WOS
>    Consolidation: ON
>    Department or Group: Solaris Security Technology Group (SSTG)
>    Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl
>    Responsible Manager: Anup Sekhar
>    Contact: contract-2003-500 at sun.com
>
> 3.  The CONSUMER is identified by the following:
>    Product or Bundle: Solaris WOS
>    Consolidation: sfw
>    Department or Group: Open Solaris
>    Bugtraq Category/SubCategory: solaris/wbem/openwsman
>    Responsible Manager: kenneth.davis at sun.com
>    Packages: SUNWopenwsmanu, SUNWopenwsmanr
>    Contact: SPSG_Indiana_Team at sun.com
>
> 4.  The INTERFACES are:
>
>       The interfaces covered by this contract are limited to a subset
>       of the C programming APIs that the OpenSSL communittee has
>       choosen to document in man pages.  It is the subset that the
>       SUPPLIER beleives to be reasonably stable.
>
>       That subset covers the following major subsystems:
>
>       ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND,
>       SMIME, SSL, BIO, X509
>
>       In particular it does NOT cover "direct use" of encryption algorithm
>       APIs outside of the EVP_ interfaces, eg do not call DES or AES
>       except via EVP_Encrypt*()
>
>       This contract does NOT cover the use of the openssl(1) command
>       as an interface to be consumed.
>
>       This contract does NOT cover any API or implementation artifact
>       that does not have an OpenSSL delivered man page.
>
>       OpenSSL Package names
>
>        SUNWopenssl-include            Unstable
>        SUNWopenssl-libraries          Unstable
>       
>       OpenSSL Library Location
>
>       /usr/sfw/lib/libcrypto.so       Unstable
>       /usr/sfw/lib/libssl.so          Unstable
>
>       OpenSSL Headers Location
>
>       /usr/sfw/include/openssl/*.h    UnStable
>
>       ASN1_                           External
>       BN_                             External
>       BIO_                            External
>       CRYPTO_                         External
>       EVP_                            External
>       HMAC                            External
>       OpenSSL_                        External
>       OBJ_                            External
>       PEM_                            External
>       PKCS7                           External
>       PKCS12_                         External
>       RAND_                           External
>       SMIME_                          External
>       SSL_                            External
>       X509_                           External
>
>
>
> 5.  The ARC controlling these INTERFACES is: PSARC
>
> 6.  The CASE describing these INTERFACES is: PSARC/2003/500
>
>    Note: this contract is not about a specific version of OpenSSL.  
> It covers
>    version 0.9.7d from PSARC/2003/500 and all subsequent versions.  
> If a
>    change in the OpenSSL interfaces requires an update of the  
> contract then
>    OpenSSL iteam will contact the consumer.
>
> 7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
>    imposed by the stability levels listed in section 4 above:
>
> _Y_ 7a. Although the stability level doesn't normally restrict it,
>        SUPPLIER promises to only modify INTERFACES in an incompatible
>       way as follows:
>
>        The SUPPLIER will modify the interfaces as needed by the  
> evolution
>        of OpenSSL releases shipped by on the www.openssl.org site.
>
> _N_ 7b. Although the stability level doesn't normally allow it,  
> CONSUMER will
>        expose INTERFACES to a PARTNER, which is external to Sun,  
> namely:
>               Name of Company:
>               Name of Department or Group within Company:
>               Responsible Manager:
>
> _Y_ 7c. Although the stability level doesn't normally allow it,  
> CONSUMER will
>        import INTERFACES from a separate consolidation.
>
>        This contract is only avaliable for CONSUMERS who deliver  
> directly
>        to the Solaris WOS.
>
>        If a contract for a CONSUMER who is not part of the Solaris  
> WOS is
>        requested it will be dealt with by ARC and the SUPPLIER as a  
> new
>        contract.
>
> _Y_ 7d. If SUPPLIER decides to change (including replace or remove)  
> any
>       portion of the INTERFACES, SUPPLIER will notify CONSUMER of the
>       proposed new version, no later than the application for ARC
>       approval of the new version.
>       If SUPPLIER and CONSUMER are contained in the same
>       consolidation, they will have simultaneous conversion to the
>       new interfaces.
>       The SUPPLIER will make a best effort to do most of the work, but
>       the CONSUMER must be willing to supply resources to assist with
>       modification/testing of their consuming code if necessary.
>
>       Only a single version of the INTERFACES will be available at any
>       one time.
>
> 8. If CONSUMER requires changes in INTERFACES, they must work with the
>   OpenSSL communittee.  The SUPPLIER is willing to assist with this
>   process on a best effort to accommodate such changes.
>   In general INTERFACE changes will not be made unless they come from
>   the OpenSSL communittee.
>
> 9. N/A
>
> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
>    handled as follows:
>
>    The SUPPLIER will update the OpenSSL code base in the ON  
> consolidation
>    on an as needed basis.  The trigger for these events is based on  
> the
>    externally defined schedule of the OpenSSL communittee.
>
>    The SUPPLIER will inform the CONSUMER(S) of this change via the
>    contract alias before filing the RTI for integration into ON.
>
>    Note that it may be necessary to update INTERFACES (or more likely
>    the implementations of them) with less than 5 working days notice.
>
> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
>    follows:
>
>    The SUPPLIER will NOT provide any assistance for use of the  
> interfaces
>    they are Externally defined and the SUPPLIER is not necessarily an
>    expert in their use.
>
> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
>    follows:
>
>    The only documentation will be that provided by the OpenSSL
>    communittee, it will be shipped in the SUNWopenssl-man package
>    in the form of Solaris nroff man pages.
>
> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
>    tested as follows:
>
>    Before each intergration the OpenSSL test suites will be run.  The
>    standard for "PASS" is that the version in the ON gate should  
> produce
>    the same functionality as binaries built using the OpenSSL  
> makefiles
>    for the same processor architecture.
>
> 14. SUPPLIER and CONSUMER agree that this contract can be terminated  
> as
>    follows:
>
>    The CONSUMER may choose to terminate this contract at any time by
>    sending email to the contract-2003-500 at sun.com alias.
>
>    The SUPPLIER may terminate this contract only after giving suffient
>    notice to the CONSUMER.   Sufficient notice in the case of  
> CONSUMERS
>    that are external to the ON consolidation must take into account  
> the
>    Solaris WOS build schedule and its restrictions for change.
>
>    The SUPPLIER will terminate this contract if the interfaces
>    are ever reclassified to something other than External.
>
> 15. This contract is not valid until "signed" via agreement from the
>    SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
>    this contract.  E-mail agreement to the contract should be archived
>    in the mail archive of CASE; verbal agreement to the contract
>    should be noted in the meeting minutes.  This contract remains
>    valid until superseded or invalidated.
>
> For SUPPLIER:  Anup Sekhar            Date:
> For CONSUMER:  Srirama Sharma         Date: 01/27/2009
> For ARC:       Mark Carlson           Date:
>
>    A copy of this contract shall be deposited in the CASE directory as
>    "contract-<digits>" or in a "contracts" subdirectory.
>
> 16. (Not to be filled in until superseded or invalidated.)
>    This contract was superseded or invalidated by CASE:
>    For ARC:                   Date:
>


Reply via email to