I approve this contract as the RM for the SUPPLIER. Anup
On Oct 22, 2008, at 8:58 AM, Don Cragun wrote: > > ------------- Begin Forwarded Message ------------- > > Return-Path: <psarc-intern-list-request at sun.com> > Date: Fri, 17 Oct 2008 13:30:32 -0700 (PDT) > From: Don Cragun <don.cragun at sun.com> > Subject: Re: slrn 0.9.9 [PSARC/2008/639 FastTrack timeout 10/23/2008] > To: PSARC-ext at sun.com, Tim.Sparlin at sun.com, Anup.Sekhar at sun.com > Cc: Kenjiro.Tsuji at sun.com > MIME-version: 1.0 > >> Date: Thu, 16 Oct 2008 15:45:08 -0500 >> From: Nicolas Williams <Nicolas.Williams at sun.com> >>> >> On Thu, Oct 16, 2008 at 01:40:42PM -0700, Gary Winiger wrote: >>>> Imported interface Classification Notes >>>> =========================== ================= ============== >>>> S-Lang library Uncommitted PSARC/2008/135 >>>> OpenSSL External PSARC/2003/500 >>> >>> IIRC in today's terms External would have been proceeded by >>> Contracted. Is there a requirement for a contract here? > > PSARC: Yes, a contract is needed and the "External" on OpenSSL should > have been "Contracted Volatile" (although it remains "External" > in the PSARC/2003/500 case materials and in the template > provided for contracts for consumers of OpenSSL). A draft > contract (built from the template in PSARC/2003/500/contracts) > is attached. A copy of this draft contract has also been > placed in PSARC/2003/500/contracts/contract-27. > > Anup: Please reply to this message stating that you agree to the > contract and are willing to sign the contract as the > responsible manager for the SUPPLIER. > > Tim: Please reply to this message stating that you agree to the > contract and are willing to sign the contract as the > responsible manager for the CONSUMER. > > Thanks, > Don > > ------------- End Forwarded Message ------------- > > #ident "@(#)contract.txt 1.3 03/11/04 SMI" > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2003/500-27 > > 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: Solaris Interfaces > Bugtraq Category/SubCategory: utility/slrn (Not yet created) > Responsible Manager: tim.sparlin at sun.com > Packages: SUNWslrn > Contact: SI-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: 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: >
