I approve this contract as the SUPPLIER. Please have your case owner  
put the contract in the ARC materials directory for 2003/500.

Anup

On Jul 13, 2009, at 2:54 PM, Will Young wrote:

> The following contract is based on the template from 2003/500.
> It requires an approval email from Anup (SUPPLIER) and Craig  
> (CONSUMER).
>       Thanks,
>       Will
>
> @(#)contract  1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6  
> 02/03/27]
> #ident        "@(#)contract.txt       1.3     03/11/04 SMI"
>
>       CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
>
> 0.  Number:  PSARC/2003/500-38
>
> 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: SFW
>   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: Solaris Platform Security
>   Bugtraq Category/SubCategory: solaris/library/libxmlsec
>   Responsible Manager: Craig Payne
>   Packages: SUNWlxmlsec SUNWlxmlsecr
>   Contact: valex-core 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
>
>       /lib/libcrypto.so       Unstable
>       /lib/libssl.so          Unstable
>
>       OpenSSL Headers Location
>
>       /usr/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:
> _NY 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:                 Date:
> For CONSUMER:                 Date:
> For ARC:                      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