From sacadmin Fri Oct 19 14:15:47 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JLFlkj021182; Fri, 19 Oct 2007 14:15:47 -0700 (PDT) Received: (from carlsonj@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9JLFlun021174; Fri, 19 Oct 2007 14:15:47 -0700 (PDT) Date: Fri, 19 Oct 2007 14:15:47 -0700 (PDT) From: James Carlson Message-Id: <200710192115.l9JLFlun021174@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Alpine: Mail User Agent [PSARC/2007/609 FastTrack timeout 10/26/2007] Status: RO Content-Length: 558 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Alpine: Mail User Agent 1.2. Name of Document Author/Supplier: Author: Paul Jakma 1.3 Date of This Document: 19 October, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Fri Oct 19 14:31:27 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JLVQle021284 for ; Fri, 19 Oct 2007 14:31:27 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9JLK231010712; Fri, 19 Oct 2007 17:20:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9JLJoTK010703; Fri, 19 Oct 2007 17:19:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18201.8054.263477.816885@gargle.gargle.HOWL> Date: Fri, 19 Oct 2007 17:19:50 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com cc: Paul Jakma Subject: 2007/609 Alpine: Mail User Agent X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1517 I'm sponsoring this fast-track request for Paul Jakma. The timer is set to 10/26/2007. Intended for SFW consolidation with "Micro" release binding, treating SFW updates as such. Background Alpine is a free, text-based, user-friendly yet powerful Mail User Agent (MUA). Alpine is developed by the University of Washington and succeeds PINE, the very well-known MUA. Alpine is, modulo regressions, fully backward compatible with PINE in terms of UI and configuration. Alpine is licensed under the Apache License, Version 2.0, where PINE is licensed under a unique licence which does not allow for redistribution of modified versions. Alpine supports IMAP; POP3; various local, file-based mailstores; TLS; GSSAPI authentication; UTF-8 (lacking in PINE), amongst other things. Proposal - Deliver Alpine, version 0.9999 or later, to SFW. - Remove PINE from the Companion CD. Interfaces SUNWalpine Uncommitted SFW Package Name /usr/bin/alpine Uncommitted Command /usr/bin/pilot Uncommitted Command /usr/bin/pico Uncommitted Command /usr/bin/rpload Uncommitted Command /usr/bin/rpdump Uncommitted Command /usr/bin/pine Uncommitted Symlink to alpine SFWpine Removed CCD Package Name /opt/sfw/bin/pico Removed /opt/sfw/bin/pilot Removed /opt/sfw/bin/pine Removed /opt/sfw/bin/rpdump Removed /opt/sfw/bin/rpload Removed Man pages will be delivered (/usr/share/man) for pine(1), alpine(1), pico(1), pilot(1), rpdump(1), and rpload(1). Dependencies: OpenSSL From gww@eng.sun.com Fri Oct 19 17:51:44 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9K0piWV024220 for ; Fri, 19 Oct 2007 17:51:44 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9K0mHA4009305; Fri, 19 Oct 2007 17:48:17 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9K0oS7n026115; Fri, 19 Oct 2007 17:50:28 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9K0oSWm026114; Fri, 19 Oct 2007 17:50:28 -0700 (PDT) Date: Fri, 19 Oct 2007 17:50:28 -0700 (PDT) From: Gary Winiger Message-Id: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> To: psarc-ext@sac.sfbay.sun.com, james.d.carlson@sun.com Subject: Re: 2007/609 Alpine: Mail User Agent Cc: paul@jakma.org X-Sun-Charset: US-ASCII Status: RO Content-Length: 148 > Dependencies: OpenSSL Nit. I presume this is PSARC/2003/500 OpenSSL in /usr/sfw. (later moved to /usr) Doesn't it require a contract? Gary.. From bart.smaalders@Sun.COM Fri Oct 19 19:10:21 2007 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9K2AL8d026231 for ; Fri, 19 Oct 2007 19:10:21 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9K1xRM0318637; Sat, 20 Oct 2007 01:59:27 GMT Message-ID: <4719602A.7090701@Sun.COM> Date: Fri, 19 Oct 2007 18:55:54 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: Gary Winiger CC: psarc-ext@sac.sfbay.sun.com, james.d.carlson@Sun.COM, paul@jakma.org Subject: Re: 2007/609 Alpine: Mail User Agent References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> In-Reply-To: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 389 Gary Winiger wrote: >> Dependencies: OpenSSL > > Nit. I presume this is PSARC/2003/500 OpenSSL in /usr/sfw. > (later moved to /usr) Doesn't it require a contract? > > Gary.. ; Fri, 19 Oct 2007 20:44:59 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9K3fY3N024072; Fri, 19 Oct 2007 20:41:34 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9K3hji8026290; Fri, 19 Oct 2007 20:43:45 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9K3hjA7026289; Fri, 19 Oct 2007 20:43:45 -0700 (PDT) Date: Fri, 19 Oct 2007 20:43:45 -0700 (PDT) From: Gary Winiger Message-Id: <200710200343.l9K3hjA7026289@marduk.eng.sun.com> To: gww@eng.sun.com, bart.smaalders@Sun.COM Subject: Re: 2007/609 Alpine: Mail User Agent Cc: psarc-ext@sac.sfbay.sun.com, james.d.carlson@Sun.COM, paul@jakma.org X-Sun-Charset: US-ASCII Status: RO Content-Length: 420 Bart, > ; Mon, 22 Oct 2007 03:08:38 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l9MA5CKg027668 for ; Mon, 22 Oct 2007 03:05:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9MA56JX012789 for ; Mon, 22 Oct 2007 10:05:07 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQB00A014LAYX00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 22 Oct 2007 11:05:06 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQB00K1P5CG2T10@fe-emea-09.sun.com>; Mon, 22 Oct 2007 11:05:05 +0100 (BST) Date: Mon, 22 Oct 2007 11:05:04 +0100 From: Darren J Moffat Subject: Re: 2007/609 Alpine: Mail User Agent In-reply-to: <4719602A.7090701@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Bart Smaalders Cc: Gary Winiger , psarc-ext@sac.sfbay.sun.com, James.D.Carlson@Sun.COM, paul@jakma.org Message-id: <471C75D0.80307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 844 Bart Smaalders wrote: > Gary Winiger wrote: >>> Dependencies: OpenSSL >> >> Nit. I presume this is PSARC/2003/500 OpenSSL in /usr/sfw. >> (later moved to /usr) Doesn't it require a contract? >> >> Gary.. > > ; Mon, 22 Oct 2007 04:57:21 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MBk0Fk014086; Mon, 22 Oct 2007 07:46:00 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9MBjuqK014083; Mon, 22 Oct 2007 07:45:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18204.36212.231973.642083@gargle.gargle.HOWL> Date: Mon, 22 Oct 2007 07:45:56 -0400 From: James Carlson To: Darren J Moffat Cc: Bart Smaalders , Gary Winiger , psarc-ext@sac.sfbay.sun.com, paul@jakma.org Subject: Re: 2007/609 Alpine: Mail User Agent In-Reply-To: <471C75D0.80307@Sun.COM> References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1592 Darren J Moffat writes: > The only way we can "fix" that is if OpenSSL stops breaking ABI (not > just API) compatibility in what we would know as bug fix or patch releases. I suspect there's a pretty big difference between depending on the OpenSSL published interfaces and depending on the unfiltered guts of the implementation. It'd be nice if we could at least get a stability commitment for the published interfaces, because OpenSSL -- not PKCS#11 -- is _the_ de-facto standard for dealing with encryption mechanisms. We're going to see many more of these, not fewer, and the idea of having contracts for each becomes less plausible with time. > They don't do this lightly but it does happen and has happened recently > - this is one of the reasons that an upgrade of OpenSSL version takes so > long. For what it's worth, we also obsolete interfaces and then change or remove them. I think the root question here is whether there's notice and if there's some way to avoid a broken build. As long as that exists, I don't think the contract helps. > That is why the ARC contract system is being used it allows the team > that looks after OpenSSL in ONNV to contact all the other consumers and > work with them on version upgrades that may cause issues. I'll add a contract if that's what you want to see here, though I think it's the wrong way forward. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@Sun.COM Mon Oct 22 05:06:55 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MC6tS9005273 for ; Mon, 22 Oct 2007 05:06:55 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9MC3TEm009549 for ; Mon, 22 Oct 2007 05:03:29 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9MC3Nrd029346 for ; Mon, 22 Oct 2007 12:03:23 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQB00H01AJIK800@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 22 Oct 2007 13:03:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQB00KJUAT62T10@fe-emea-09.sun.com>; Mon, 22 Oct 2007 13:03:07 +0100 (BST) Date: Mon, 22 Oct 2007 13:03:06 +0100 From: Darren J Moffat Subject: Re: 2007/609 Alpine: Mail User Agent In-reply-to: <18204.36212.231973.642083@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Bart Smaalders , Gary Winiger , psarc-ext@sac.sfbay.sun.com, paul@jakma.org Message-id: <471C917A.2080501@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> <18204.36212.231973.642083@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 2764 James Carlson wrote: > Darren J Moffat writes: >> The only way we can "fix" that is if OpenSSL stops breaking ABI (not >> just API) compatibility in what we would know as bug fix or patch releases. > > I suspect there's a pretty big difference between depending on the > OpenSSL published interfaces and depending on the unfiltered guts of > the implementation. The problem here though is that the applications using OpenSSL all do so for different reasons and at different layers. Some just use the SSL API and do so nicely. Others use the EVP layer of libcrypto. There are even those that stick their dirty little fingers deep inside the structures of the lowest level APIs. How do we deal with applications in a consolidation different to the one OpenSSL is in (currently ON) when the version of OpenSSL changes ? > It'd be nice if we could at least get a stability commitment for the > published interfaces, because OpenSSL -- not PKCS#11 -- is _the_ > de-facto standard for dealing with encryption mechanisms. We're going > to see many more of these, not fewer, and the idea of having contracts > for each becomes less plausible with time. I agree contracts isn't the way to deal with this, but it is the only mechanism we have for finding the OpenSSL consumers and contacting them when we know that a new version of OpenSSL will cause breakage. >> They don't do this lightly but it does happen and has happened recently >> - this is one of the reasons that an upgrade of OpenSSL version takes so >> long. > > For what it's worth, we also obsolete interfaces and then change or > remove them. I think the root question here is whether there's notice > and if there's some way to avoid a broken build. As long as that > exists, I don't think the contract helps. Given that the consumers are spread over (at least) three different consolidations of Solaris it isn't an easy task. >> That is why the ARC contract system is being used it allows the team >> that looks after OpenSSL in ONNV to contact all the other consumers and >> work with them on version upgrades that may cause issues. > > I'll add a contract if that's what you want to see here, though I > think it's the wrong way forward. It is what PSARC wanted when the original case to include OpenSSL was reviewed. The contact is very explicit about which OpenSSL APIs we believe the OpenSSL community has some commitment to (the SSL and EVP APIs in particular). Personally I don't mind either way, however without one there is no comeback to the OpenSSL team if they introduce an updated version of OpenSSL and the build of another project in another consolidation starts failing. That is not to say they won't help debug the issue though. -- Darren J Moffat From bart.smaalders@Sun.COM Mon Oct 22 09:17:32 2007 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MGHWCG009571 for ; Mon, 22 Oct 2007 09:17:32 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MG6afT357698; Mon, 22 Oct 2007 16:06:36 GMT Message-ID: <471CC9B6.3000308@Sun.COM> Date: Mon, 22 Oct 2007 09:03:02 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: Darren J Moffat CC: James Carlson , paul@jakma.org, psarc-ext@sac.sfbay.sun.com, Gary Winiger Subject: Re: 2007/609 Alpine: Mail User Agent References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> <18204.36212.231973.642083@gargle.gargle.HOWL> <471C917A.2080501@Sun.COM> In-Reply-To: <471C917A.2080501@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1115 Darren J Moffat wrote: > It is what PSARC wanted when the original case to include OpenSSL was > reviewed. The contact is very explicit about which OpenSSL APIs we > believe the OpenSSL community has some commitment to (the SSL and EVP > APIs in particular). > > Personally I don't mind either way, however without one there is no > comeback to the OpenSSL team if they introduce an updated version of > OpenSSL and the build of another project in another consolidation starts > failing. That is not to say they won't help debug the issue though. > > Why not place the portions of the API that you deem more stable into a version in the library mapfile, and place the rest (unstable) in another version? Any application linking w/ OpenSSL can instantly determine its ACTUAL usage of the APIs, and thus those apps using the portion of the OpenSSL APIs considered stable can avoid the paperwork. This also makes the OpenSSL team's job easier when it comes time to change OpenSSL versions.... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Darren.Moffat@Sun.COM Mon Oct 22 09:31:39 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MGVdNE009689 for ; Mon, 22 Oct 2007 09:31:39 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l9MGSCwT003243 for ; Mon, 22 Oct 2007 09:28:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9MGS79R007716 for ; Mon, 22 Oct 2007 16:28:07 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQB00M01N2MZT00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 22 Oct 2007 17:28:07 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQB00KS1N2U2T20@fe-emea-09.sun.com>; Mon, 22 Oct 2007 17:28:06 +0100 (BST) Date: Mon, 22 Oct 2007 17:28:06 +0100 From: Darren J Moffat Subject: Re: 2007/609 Alpine: Mail User Agent In-reply-to: <471CC9B6.3000308@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Bart Smaalders Cc: James Carlson , paul@jakma.org, psarc-ext@sac.sfbay.sun.com, Gary Winiger Message-id: <471CCF96.40605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> <18204.36212.231973.642083@gargle.gargle.HOWL> <471C917A.2080501@Sun.COM> <471CC9B6.3000308@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1542 Bart Smaalders wrote: > Darren J Moffat wrote: >> It is what PSARC wanted when the original case to include OpenSSL was >> reviewed. The contact is very explicit about which OpenSSL APIs we >> believe the OpenSSL community has some commitment to (the SSL and EVP >> APIs in particular). >> >> Personally I don't mind either way, however without one there is no >> comeback to the OpenSSL team if they introduce an updated version of >> OpenSSL and the build of another project in another consolidation >> starts failing. That is not to say they won't help debug the issue >> though. >> >> > > Why not place the portions of the API that you deem more stable into > a version in the library mapfile, and place the rest (unstable) in > another version? That seems reasonable, it won't stop the breakage but at least it helps find it when it occurs and helps understand when a given application crosses the boundary. We could start by doing this only for the APIs that are in the current contracts, however ideally we would get agreement on this from OpenSSL (we did a similar thing for the MIT libkrb5 library). > Any application linking w/ OpenSSL can instantly > determine its ACTUAL usage of the APIs, and thus those apps using the > portion of the OpenSSL APIs considered stable can avoid the paperwork. > This also makes the OpenSSL team's job easier when it comes time to > change OpenSSL versions.... Feel free to log an RFE for this, but I doubt you want this case to take that job on right ? -- Darren J Moffat From bart.smaalders@Sun.COM Mon Oct 22 09:56:03 2007 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9MGu3sg010256 for ; Mon, 22 Oct 2007 09:56:03 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MGj7IQ358840; Mon, 22 Oct 2007 16:45:07 GMT Message-ID: <471CD2BC.9070304@Sun.COM> Date: Mon, 22 Oct 2007 09:41:32 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: Darren J Moffat CC: James Carlson , paul@jakma.org, psarc-ext@sac.sfbay.sun.com, Gary Winiger Subject: Re: 2007/609 Alpine: Mail User Agent References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> <18204.36212.231973.642083@gargle.gargle.HOWL> <471C917A.2080501@Sun.COM> <471CC9B6.3000308@Sun.COM> <471CCF96.40605@Sun.COM> In-Reply-To: <471CCF96.40605@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 270 Darren J Moffat wrote: > > Feel free to log an RFE for this, I'll do so. > but I doubt you want this case to take > that job on right ? > Certainly not. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Jan.Pechanec@Sun.COM Tue Oct 23 11:04:09 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9NI49MA016124 for ; Tue, 23 Oct 2007 11:04:09 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.EU.Sun.COM [192.18.6.24]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9NI0esS003121 for ; Tue, 23 Oct 2007 11:00:41 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9NI0ZOZ013628 for ; Tue, 23 Oct 2007 18:00:35 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQD00J01LSJ3900@fe-emea-09.sun.com> (original mail from Jan.Pechanec@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 23 Oct 2007 19:00:35 +0100 (BST) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQD006A2M0TWM50@fe-emea-09.sun.com>; Tue, 23 Oct 2007 19:00:30 +0100 (BST) Date: Tue, 23 Oct 2007 19:59:16 +0200 (CEST) From: Jan Pechanec Subject: Re: 2007/609 Alpine: Mail User Agent In-reply-to: <471CCF96.40605@Sun.COM> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@fossa.czech.sun.com To: Darren J Moffat Cc: Bart Smaalders , James Carlson , paul@jakma.org, psarc-ext@sac.sfbay.sun.com, Gary Winiger Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> <4719602A.7090701@Sun.COM> <471C75D0.80307@Sun.COM> <18204.36212.231973.642083@gargle.gargle.HOWL> <471C917A.2080501@Sun.COM> <471CC9B6.3000308@Sun.COM> <471CCF96.40605@Sun.COM> Status: RO Content-Length: 2252 On Mon, 22 Oct 2007, Darren J Moffat wrote: >> > Personally I don't mind either way, however without one there is no >> > comeback to the OpenSSL team if they introduce an updated version of >> > OpenSSL and the build of another project in another consolidation starts >> > failing. That is not to say they won't help debug the issue though. >> > >> > >> >> Why not place the portions of the API that you deem more stable into >> a version in the library mapfile, and place the rest (unstable) in >> another version? > > That seems reasonable, it won't stop the breakage but at least it helps find it > when it occurs and helps understand when a given application crosses the > boundary. I don't think the biggest problem is that API changes. The problem is that ABI changes from time to time. Dividing OpenSSL API into two parts won't help much; I remember just 1 or 2 const changes during the 0.9.7d -> 0.9.8a upgrade in the whole WOS. However, when (if) we adopt 0.9.9 in the future we must rebuild all consumers. then we need that list of consumers (6 consolidations now use OpenSSL). I really don't think there is any sense in having an OpenSSL consumer without the contract *now*. we might have a filter library exporting just some most stable interfaces. That library would keep the name so no rebuilding would be needed - but still, the change can happen anyway and we can't do much about it. As already said, we would need to work with OpenSSL team on this. >> Any application linking w/ OpenSSL can instantly >> determine its ACTUAL usage of the APIs, and thus those apps using the >> portion of the OpenSSL APIs considered stable can avoid the paperwork. This >> also makes the OpenSSL team's job easier when it comes time to change OpenSSL >> versions.... it would be much easier for me but quite risky for consumers. I remember the last time, install packages stopped working because there was an undocumented change inside of SSL functions (not in API or ABI) - using very high level interface didn't help there. so now, every consumers should have a contract otherwise it can run into troubles that we might forget about that dependency. I would be happy to change this situation. Jan. -- Jan Pechanec From carlsonj@phorcys.east.sun.com Tue Oct 23 12:42:02 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9NJg1BU019232 for ; Tue, 23 Oct 2007 12:42:02 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9NJUZWj020369; Tue, 23 Oct 2007 15:30:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9NJUXqd020366; Tue, 23 Oct 2007 15:30:33 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18206.19417.195748.371217@gargle.gargle.HOWL> Date: Tue, 23 Oct 2007 15:30:33 -0400 From: James Carlson To: Gary Winiger Cc: psarc-ext@sac.sfbay.sun.com, paul@jakma.org Subject: Re: 2007/609 Alpine: Mail User Agent In-Reply-To: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> References: <200710200050.l9K0oSWm026114@marduk.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 7794 Gary Winiger writes: > > Dependencies: OpenSSL > > Nit. I presume this is PSARC/2003/500 OpenSSL in /usr/sfw. > (later moved to /usr) Doesn't it require a contract? I've added a draft contract to the common contracts directory of 2003/500 as "contract-14", and symlink'd it to this case's materials. Once the draft has had some time for review, I'll send it off for signatures. Here's a copy: @(#)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 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: Craig.Payne@Sun.COM Contact: contract-2003-500@sun.com 3. The CONSUMER is identified by the following: Product or Bundle: Solaris WOS Consolidation: SFW Department or Group: Solaris Networking Bugtraq Category/SubCategory: solaris/consolidation/sfw Responsible Manager: Shantnu Sharma Packages: SUNWalpine Contact: sfw_eval@sun.com 4. The INTERFACES are: SSL_CTX_ctrl Volatile SSL_CTX_free Volatile SSL_CTX_load_verify_locations Volatile SSL_CTX_new Volatile SSL_CTX_set_cipher_list Volatile SSL_CTX_set_default_verify_paths Volatile SSL_CTX_set_tmp_rsa_callback Volatile SSL_CTX_set_verify Volatile SSL_CTX_use_PrivateKey Volatile SSL_CTX_use_RSAPrivateKey_file Volatile SSL_CTX_use_certificate Volatile SSL_CTX_use_certificate_chain_file Volatile SSL_accept Volatile SSL_ctrl Volatile SSL_free Volatile SSL_get_error Volatile SSL_get_fd Volatile SSL_get_peer_certificate Volatile SSL_library_init Volatile SSL_load_error_strings Volatile SSL_new Volatile SSL_pending Volatile SSL_read Volatile SSL_set_bio Volatile SSL_set_connect_state Volatile SSL_set_fd Volatile SSL_shutdown Volatile SSL_state Volatile SSL_write Volatile SSLv23_client_method Volatile SSLv23_server_method Volatile TLSv1_client_method Volatile TLSv1_server_method Volatile Package SUNWopenssl-libraries Unstable Library link /usr/sfw/lib/libssl.so Unstable /usr/sfw/include/openssl/*.h Unstable 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@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-" 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: From Shantnu.Sharma@Sun.COM Wed Nov 14 08:08:36 2007 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAEG8amk003484 for ; Wed, 14 Nov 2007 08:08:36 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAEG8axY057920 for ; Wed, 14 Nov 2007 08:08:36 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAEG8ZGV028508 for ; Wed, 14 Nov 2007 16:08:35 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRI00C01750BE00@mail-amer.sun.com> (original mail from Shantnu.Sharma@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 14 Nov 2007 09:08:35 -0700 (MST) Received: from [129.148.9.173] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRI007QE7HU46E0@mail-amer.sun.com>; Wed, 14 Nov 2007 09:08:19 -0700 (MST) Date: Wed, 14 Nov 2007 11:08:17 -0500 From: Shantnu Sharma Subject: Re: contract for 2007/609: Alpine: Mail User Agent In-reply-to: <18234.61567.47264.847156@gargle.gargle.HOWL> Sender: Shantnu.Sharma@Sun.COM To: psarc-ext@sac.sfbay.sun.com Cc: Anup.Sekhar@Sun.COM, Paul Jakma Message-id: <473B1D71.3080309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <18234.61567.47264.847156@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 8279 I am ok with this. Thanks James Carlson wrote: > Please sign this contract for OpenSSL interfaces used by the open > source "alpine" mail client. You can sign by replying to this message > (the "reply-to" is set to "psarc-ext@sac.sfbay") and indicating your > acceptance. > > If any of the terms are unacceptable, then please let me know, and > we'll work out alternatives. > > > > @(#)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-14 > > 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@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Networking > Bugtraq Category/SubCategory: solaris/consolidation/sfw > Responsible Manager: Shantnu Sharma > Packages: SUNWalpine > Contact: sfw_eval@sun.com > > 4. The INTERFACES are: > > SSL_CTX_ctrl Volatile > SSL_CTX_free Volatile > SSL_CTX_load_verify_locations Volatile > SSL_CTX_new Volatile > SSL_CTX_set_cipher_list Volatile > SSL_CTX_set_default_verify_paths Volatile > SSL_CTX_set_tmp_rsa_callback Volatile > SSL_CTX_set_verify Volatile > SSL_CTX_use_PrivateKey Volatile > SSL_CTX_use_RSAPrivateKey_file Volatile > SSL_CTX_use_certificate Volatile > SSL_CTX_use_certificate_chain_file Volatile > SSL_accept Volatile > SSL_ctrl Volatile > SSL_free Volatile > SSL_get_error Volatile > SSL_get_fd Volatile > SSL_get_peer_certificate Volatile > SSL_library_init Volatile > SSL_load_error_strings Volatile > SSL_new Volatile > SSL_pending Volatile > SSL_read Volatile > SSL_set_bio Volatile > SSL_set_connect_state Volatile > SSL_set_fd Volatile > SSL_shutdown Volatile > SSL_state Volatile > SSL_write Volatile > SSLv23_client_method Volatile > SSLv23_server_method Volatile > TLSv1_client_method Volatile > TLSv1_server_method Volatile > > Package SUNWopenssl-libraries Unstable > Library link /usr/sfw/lib/libssl.so Unstable > > /usr/sfw/include/openssl/*.h Unstable > > > 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@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-" 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: > > -- -------------------------- Shantnu Sharma Development Manager, New Solaris Burlington, MA Shantnu.Sharma@SUN.com 978.239.8154 Cell 781.442.2370 Work From Anup.Sekhar@sun.com Thu Nov 15 08:31:43 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAFGVgnf002391 for ; Thu, 15 Nov 2007 08:31:42 -0800 (PST) Received: from [10.7.250.81] (punchin-client-10-7-250-81.SFBay.Sun.COM [10.7.250.81]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lAFGVgki992929; Thu, 15 Nov 2007 08:31:42 -0800 (PST) In-Reply-To: <18234.61567.47264.847156@gargle.gargle.HOWL> References: <18234.61567.47264.847156@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Shantnu.Sharma@sun.com Content-Transfer-Encoding: 7bit From: Anup Sekhar Subject: Re: contract for 2007/609: Alpine: Mail User Agent Date: Thu, 15 Nov 2007 08:31:19 -0800 To: psarc-ext@sac.sfbay.sun.com X-Mailer: Apple Mail (2.752.3) Status: RO Content-Length: 8246 I accept this contract. Anup On Nov 14, 2007, at 4:56 AM, James Carlson wrote: > Please sign this contract for OpenSSL interfaces used by the open > source "alpine" mail client. You can sign by replying to this message > (the "reply-to" is set to "psarc-ext@sac.sfbay") and indicating your > acceptance. > > If any of the terms are unacceptable, then please let me know, and > we'll work out alternatives. > > > > @(#)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-14 > > 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@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Networking > Bugtraq Category/SubCategory: solaris/consolidation/sfw > Responsible Manager: Shantnu Sharma > Packages: SUNWalpine > Contact: sfw_eval@sun.com > > 4. The INTERFACES are: > > SSL_CTX_ctrl Volatile > SSL_CTX_free Volatile > SSL_CTX_load_verify_locations Volatile > SSL_CTX_new Volatile > SSL_CTX_set_cipher_list Volatile > SSL_CTX_set_default_verify_paths Volatile > SSL_CTX_set_tmp_rsa_callback Volatile > SSL_CTX_set_verify Volatile > SSL_CTX_use_PrivateKey Volatile > SSL_CTX_use_RSAPrivateKey_file Volatile > SSL_CTX_use_certificate Volatile > SSL_CTX_use_certificate_chain_file Volatile > SSL_accept Volatile > SSL_ctrl Volatile > SSL_free Volatile > SSL_get_error Volatile > SSL_get_fd Volatile > SSL_get_peer_certificate Volatile > SSL_library_init Volatile > SSL_load_error_strings Volatile > SSL_new Volatile > SSL_pending Volatile > SSL_read Volatile > SSL_set_bio Volatile > SSL_set_connect_state Volatile > SSL_set_fd Volatile > SSL_shutdown Volatile > SSL_state Volatile > SSL_write Volatile > SSLv23_client_method Volatile > SSLv23_server_method Volatile > TLSv1_client_method Volatile > TLSv1_server_method Volatile > > Package SUNWopenssl-libraries Unstable > Library link /usr/sfw/lib/libssl.so Unstable > > /usr/sfw/include/openssl/*.h Unstable > > > 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@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-" 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: > From carlsonj@phorcys.east.sun.com Thu Nov 15 08:58:45 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAFGwiiq002994 for ; Thu, 15 Nov 2007 08:58:45 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lAFGw06C022410; Thu, 15 Nov 2007 11:58:00 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lAFGw09a022407; Thu, 15 Nov 2007 11:58:00 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18236.31384.809278.190151@gargle.gargle.HOWL> Date: Thu, 15 Nov 2007 11:58:00 -0500 From: James Carlson To: Anup Sekhar Cc: psarc-ext@sac.sfbay.sun.com, Shantnu.Sharma@Sun.COM Subject: Re: contract for 2007/609: Alpine: Mail User Agent In-Reply-To: References: <18234.61567.47264.847156@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 367 This case was approved during ARC business several weeks ago, and the contract is now signed. I've marked it as "closed approved fast-track." -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677