From sacadmin Tue Apr 22 10:36:23 2008
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 m3MHaNEt025912;
	Tue, 22 Apr 2008 10:36:23 -0700 (PDT)
Received: (from markcarl@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m3MHaMEb025908;
	Tue, 22 Apr 2008 10:36:22 -0700 (PDT)
Date: Tue, 22 Apr 2008 10:36:22 -0700 (PDT)
From: Mark Carlson <markcarl@sac.sfbay.sun.com>
Message-Id: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
To: LSARC@sac.sfbay.sun.com
Subject: axyftp [LSARC/2008/271 Self Review]
Status: RO
Content-Length: 16707


Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 axyftp
    1.2. Name of Document Author/Supplier:
	 Author:  Charles Baker
    1.3  Date of This Document:
	22 April, 2008
4. Technical Description
FCL--FOSS Check List
    
1.0 Project Information
1.1 Name of project/component
	axyftp-0.5.1

1.2 Author of document
	Charles Baker Charles.Baker@Sun.com

2.0 Project Summary
  2.1 Project Description
  axyftp is a X Window system FTP client designed for unix.

   The integration of the new axyftp package into the Indiana project
   will provide a user friendly ftp client into Solaris, making
   Indiana more user friendly.
  
  2.2 Release binding
      What is is the release binding?
      (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/)
      [ ] Major
      [ ] Minor
      [X] Patch or Micro
      [ ] Unknown -- ARC review required

  2.3 Originating Community
    2.3.1 Community Name
        axyftp
    	http://www.wxftp.seul.org/

    2.3.2 Community Involvement
      Indicate Sun's involvement in the community
      [ ] Maintainer
      [ ] Contributor
      [X] Monitoring
      
      Will the project team work with the upstream community to resolve
      architectural issues of interest to Sun?
      [X] Yes 
      [ ] No - briefly explain
      
      Will we or are we forking from the community?
      [ ] Yes - ARC review required prior to forking
      [X] No
      
3.0 Technical Description
  3.1 Installation & Sharable
    3.1.1S Solaris Installation - section only required for Solaris Software
      (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details)
      Does this project follow the Install Locations best practice?
      [X] Yes 
      [ ] No - ARC review required
      
      Does this project install into /usr under [sbin|bin|lib|include|man|share]?
      [X] Yes
      [ ] No or N/A
      
      Does this project install into /opt?
      [ ] Yes - explain below
      [X] No or N/A
      
      Does this project install into a different directory structure?
      [ ] Yes - ARC review required
      [X] No or N/A
      
      Do any of the components of this project conflict with anything under /usr?
      (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details)
      [ ] Yes - explain below
      [X] No
      
      If conflicts exist then will this project install under /usr/gnu?
      [ ] Yes
      [ ] No - ARC review required
      [X] N/A
      
      Is this project installing into /usr/sfw?
      [ ] Yes - ARC review required
      [X] No
      
    3.1.1W Windows Installation - section only required for Windows Software
      (see http://sac.sfbay/WSARC/2002/494 for details)
      Does this project install software into a 
      <system drive>:\Program Files\Sun\<product> or <system drive>:\Sun\<product>
      directory?
      [ ] Yes
      [ ] No - ARC review required
      
      Does the project use the Windows registry?
      [ ] Yes
      [ ] No - ARC review required
      
      Does the project use 
      HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\<product>\<version>
      for the registry key?
      [ ] Yes
      [ ] No - ARC review required
      
      Is the project's stored location
      HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\<product id>\<version id>\Path?
      [ ] Yes
      [ ] No - ARC review required
      
    3.1.2 Share and Sharable
      Does the module include any components that are used or shared by 
      other projects?
      [ ] Yes
      [X] No
    
      If yes are these components packaged to be shared with the other FOSS?
      [ ] Yes
      [ ] No - ARC review required
    
      Are these components already in the Solaris WOS?
      [ ] Yes
      [X] No - continue with next section
    
      If yes are these newer versions being delivered?
      [ ] Yes
      [ ] No - ARC review required
      
      If yes are the newer versions replacing the existing versions?
      [ ] Yes
      [ ] No - ARC review required

  3.2 Libraries
      Are 64-bit libraries being delivered?
      [ ] Yes
      [ ] No - ARC review required
      [X] N/A
	No Libraries are being delivered, only a single user binary.
    
      Are static versions of the library being delivered?
      [ ] Yes - ARC review required
      [X] No 
      
  3.3 Services and the /etc Directory
      (see http://opensolaris.org/os/community/arc/policies/SMF-policy/)
      Does the project integrate anything into /etc/init.d or /etc/rc?.d?
      [ ] Yes - ARC review required
      [X] No
      
      Does the project integrate any new entries into /etc/inittab or
      /etc/inetd.conf?
      [ ] Yes - ARC review required
      [X] No
      
      Does the project integrate any private non-public files into /etc/default
      or /etc/ configuration files?
      [ ] Yes - ARC review required
      [X] No
      
      Does the service manifests method context grant rights above that
      of the noaccess user and basic privilege set?
      [ ] Yes - ARC review required
      [X] No
        
  3.4 Security
    3.4.1 Secure By Default 
      (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details)
      (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details)
      (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for
       addtional details)
      Are network services enabled by default?
      [ ] Yes - ARC review required
      [X] No
      [ ] N/A
      
      Are network services automatically enabled by the project during installation?
      [ ] Yes - ARC review required
      [X] No
      [ ] N/A
      
      Are inbound network communications denied by default?
      [ ] Yes
      [ ] No - ARC review required
      [X] N/A
      
      Is inbound data checked to prevent content-based attacks?
      [ ] Yes
      [ ] No - ARC review required
      [X] N/A
      
      Is the outbound receiver authenticated?
      [X] Yes
      [ ] No - ARC review required
      [ ] N/A
      
      Is the receiver authenticated prior to receiving any sensitive outbound communication?
      [X] Yes
      [ ] No - ARC review required
      [ ] N/A
      
    3.4.2 Authorization
      (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and
	   http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and
	   http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
           for details)
      Are there any setuid/setgid privileged binaries in the project?
      [ ] Yes - ARC review required
      [X] No - continue with next section
      
      If yes then are the setuid/setgid privileges handled by the use of roles?
      [ ] Yes
      [ ] No - ARC review required

    3.4.3 Auditing
      (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details)
      (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
      Does this component contain administrative or security enforcing software?
      [ ] Yes - ARC review required
      [X] No - continue to next section
      
      (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
      Do the components create audit logs detailing what took place including what event
      took place, who was involved, when the event took place?
      [ ] Yes - ARC contract and Audit project team review required
      [ ] No - ARC review required
        
        
    3.4.4 Authentication
      (see http://opensolaris.org/os/community/arc/policies/PAM/)
      Do the components contain any authentication code?
      [ ] Yes
      [X] No - continue to next section
      
      If yes do the components use PAM (plugable authentication modules) for authentication?
      [ ] Yes
      [ ] No - ARC review required
      
      If yes is a single PAM session maintained during authentication?
      [ ] Yes
      [ ] No - ARC review required
      
      If yes are the components sufficiently privileged to allow the requested 
      operations (authentication, password change, process credential manipulation, 
      audit state initialization)?
      [ ] Yes - briefly describe below
      [ ] No - ARC review required
      
    3.4.5 Passwords
      (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and
           http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details)
      Do any of the components for the project deal with passwords?
      [X] Yes
      [ ] No - continue to next section
      
      If yes are these passwords entered via the CLI or environment?
      [ ] Yes - ARC review required
      [ ] No
      [X] GUI window, all entries shown as '*'.
      
      Are passwords stored within the file system for the component?
      [X] Yes
      [ ] No - continue to next section
      
      If yes are the permissions on the file such to protect exposing the password(s)?
      [X] Yes
      [ ] No - ARC review required
      
    3.4.6 General Security Questions
      (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details)
      Do the components use standard network protocols?
      [X] Yes
      [ ] No - ARC review required
      
      Do network services for the project make decisions based upon user, host or 
      service identities?
      [X] Yes - explain below
      [ ] No
      [ ] N/A
          This ia an ftp client that requires user specified host, user id, and password.
      
      Do the components make use of secret information during authentication and/or
      authorization?
      [X] Yes - explain below
      [ ] No
      [ ] N/A
          This ia an ftp client that requires user specified host, user id, and password.
  
  3.5 Networking
      Do the components access the network?
      [X] Yes
      [ ] No - continue to next section
      
      If yes do the components support IPv6?
      [X] Yes 
      [ ] No - ARC review required
          
  3.6 Core Solaris Components
      Do the components of this project compete with or duplicate core 
      Solaris components?
      [ ] Yes - ARC review required
      [X] No 
      
      Examples of Core Solaris Components include but are not limited to:
      
        Secure By Default
        Authorizations
        PAM -- Plugable Authentication Module
        Privilege
        PRM -- Process Rights Management -- Privilege
        Audit
        xVm -- Virtualization
        zones / Solaris Containers
        PRM -- Process Rights Management
        RBAC -- Role Based Access Control
        TX / Trusted Extensions
        ZFS
        SMF -- Service Management Facility
        FMA -- Fault Management Architecture
        SCF -- Smart Card Facility
        IPsec
        
4.0 Interfaces
  (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details)
  4.1 Exported Interfaces
  
    Interface Name		Classification      Comments
    --------------------------- ------------------- ---------------------------
    AxYftp			Uncommitted         version 0.5.1

    SUNWaxyftp			Uncommitted         axyftp's packaging

    /usr/bin/axyftp             Uncommitted         Current version 0.5.1
                                                    last changed Jan. 2000
  Manual Pages
    /usr/share/man/man1/axyftp.1

  Help Documentation
    /usr/share/doc/axyftp/help.html                
    /usr/share/doc/axyftp/intro.html
    /usr/share/doc/axyftp/axyftp.html
    /usr/share/doc/axyftp/main.html
    /usr/share/doc/axyftp/options.html
    /usr/share/doc/axyftp/panels.html
    /usr/share/doc/axyftp/problems.html
    /usr/share/doc/axyftp/session.html
    /usr/share/doc/axyftp/glossary.html
    /usr/share/doc/axyftp/doc.gif
    /usr/share/doc/axyftp/folder.gif
    /usr/share/doc/axyftp/link.gif
    /usr/share/doc/axyftp/up.gif

  License Files
    /usr/share/doc/axyftp/artistic.txt              
    /usr/share/doc/axyftp/lgpl.txt
    
  4.2 Imported Interfaces
    Interface Name		Classification       Comments
    --------------------------- -------------------- --------------------------
    GTK+ 1.2.10                 Volatile             PSARC/2000/487
    GLIB 1.2.10                 Volitile             PSARC/2000/487
    GDK 1.2.10                  Volitile             PSARC/2000/487

    libsocket(3LIB)             Committed
    libnsl(3LIB)                Committed
    X(5)                        Committed
    libm(3LIB)                  Committed

          
  Brief Interface Classifications - See Appendix C for definitions
    Volatile - use check list for approval
    Uncommitted - ARC review might be required, seek committee member advice
                  package names do not require further review
    Committed - ARC review required
    Project Private - no review required, just documentat in table
    Contracted (interface modifier) - further review required

Appendix A - References
  1.  Solaris Installation Locations Policy
      http://opensolaris.org/os/community/arc/policies/install-locations/
  2.  /usr/gnu Installation ARC case
      http://opensolaris.org/os/community/arc/caselog/2007/047/
  3.  Secure By Default Policy
      http://opensolaris.org/os/community/arc/policies/secure-by-default/
  4.  Network Install Time Securityuy Policy
      http://www.opensolaris.org/os/community/arc/policies/NITS-policy/
  5.  Adding RBAC Authorizations Policy
      http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/
  6.  When to use setuid -vs- RBAC roles and profiles
      http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and
  7.  Building RBAC Rights Profiles
      http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
  8.  Solaris Audit Policy
      http://opensolaris.org/os/community/arc/policies/audit-policy/
  9.  Security questionaire
      http://opensolaris.org/os/community/arc/bestpractices/security-questions/
  10. Interface Taxonomy
      http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/
  11. Plugable Authentication Modules -- PAM
      http://opensolaris.org/os/community/arc/policies/PAM/
  12. Reusable Passwords In Command Line Arguments and Environment Variables
      http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/
  13. Storing Reusable Passwords on a Filesystem
      http://opensolaris.org/os/community/arc/bestpractices/passwords-files/
  14. Release Taxonomy
      http://opensolaris.org/os/community/arc/policies/release-taxonomy/
  15. Service Management Facility (SMF) usage
      http://opensolaris.org/os/community/arc/policies/SMF-policy/

  
Appendix B - Suggested case materials
  1. man pages
  2. SMF manifests
  3. links to contracts
  
Appendix C - Definitions
Submitter
     an agent responsible for creation of an ARC project along with the
     materials describing that project.
Owner
     the ARC agent responsible for shepherding the case through review
     and ensuring a formal opinion is written where required.
Maintainer
     an agent responsible for releasing new versions of a program, typically
     the "main" contributor or person incharge of making Architectural
     decisions for the project
Contributor
     an agent who make contributions to a project, typically has a voice in
     making Architectural decisions for the project
Monitoring
     an agent who is only following the changes made in the community and
     has no Architectural input into the project
Volatile*
    interfaces that are very fluid and typically follow the originating 
    community.  Typically these interfaces can not be imported by other
    projects.
Uncommitted*
    interfaces that are still evolving but will most likely be present from
    release to release.
Committed*
    interfaces that are stable and with Sun guaranteeing some level of
    compatibility from release to release.
Project Private*
    interfaces that are exposed only to or intended to be used only by
    the project being reviewed.  These interfaces can not be imported by
    other projects.
Not-An-Interface*
    components that are not interfaces.
Contracted* (interface modifier) - ARC review of Contract required
    interfaces that do not allow another project to import can be 

*Note: see http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: Automatic
    6.6. ARC Exposure: open


From Mark.Carlson@sun.com Tue Apr 22 10:44:55 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MHisZ7026114
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 10:44:54 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MHiY1G004440
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 22 Apr 2008 18:44:53 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZQ00F27MMPP100@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@Sun.COM); Tue, 22 Apr 2008 10:44:49 -0700 (PDT)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZQ00EEMMMPSMB0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue,
 22 Apr 2008 10:44:49 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MHinYs002542	for
 <lsarc-ext@Sun.COM>; Tue, 22 Apr 2008 17:44:49 +0000 (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 <0JZQ00B01M9BPA00@mail-amer.sun.com>
 (original mail from Mark.Carlson@Sun.COM)
 for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue,
 22 Apr 2008 11:44:48 -0600 (MDT)
Received: from Macintosh-39.local ([71.237.94.98])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZQ00IWCMM8C1D0@mail-amer.sun.com> for
 lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue,
 22 Apr 2008 11:44:33 -0600 (MDT)
Date: Tue, 22 Apr 2008 11:44:32 -0600
From: "Mark A. Carlson" <Mark.Carlson@sun.com>
Subject: axyftp [LSARC/2008/271 Self Review]
In-reply-to: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
Sender: Mark.Carlson@sun.com
To: lsarc-ext@sun.com
Message-id: <480E2400.1030009@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 17781

I am sponsoring this case for Charles Baker and marking it closed
approved automatic based on the FOSS checklist in the case directory.

-- mark

Mark Carlson wrote:
> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
>     1.1. Project/Component Working Name:
> 	 axyftp
>     1.2. Name of Document Author/Supplier:
> 	 Author:  Charles Baker
>     1.3  Date of This Document:
> 	22 April, 2008
> 4. Technical Description
> FCL--FOSS Check List
>     
> 1.0 Project Information
> 1.1 Name of project/component
> 	axyftp-0.5.1
>
> 1.2 Author of document
> 	Charles Baker Charles.Baker@Sun.com
>
> 2.0 Project Summary
>   2.1 Project Description
>   axyftp is a X Window system FTP client designed for unix.
>
>    The integration of the new axyftp package into the Indiana project
>    will provide a user friendly ftp client into Solaris, making
>    Indiana more user friendly.
>   
>   2.2 Release binding
>       What is is the release binding?
>       (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/)
>       [ ] Major
>       [ ] Minor
>       [X] Patch or Micro
>       [ ] Unknown -- ARC review required
>
>   2.3 Originating Community
>     2.3.1 Community Name
>         axyftp
>     	http://www.wxftp.seul.org/
>
>     2.3.2 Community Involvement
>       Indicate Sun's involvement in the community
>       [ ] Maintainer
>       [ ] Contributor
>       [X] Monitoring
>       
>       Will the project team work with the upstream community to resolve
>       architectural issues of interest to Sun?
>       [X] Yes 
>       [ ] No - briefly explain
>       
>       Will we or are we forking from the community?
>       [ ] Yes - ARC review required prior to forking
>       [X] No
>       
> 3.0 Technical Description
>   3.1 Installation & Sharable
>     3.1.1S Solaris Installation - section only required for Solaris Software
>       (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details)
>       Does this project follow the Install Locations best practice?
>       [X] Yes 
>       [ ] No - ARC review required
>       
>       Does this project install into /usr under [sbin|bin|lib|include|man|share]?
>       [X] Yes
>       [ ] No or N/A
>       
>       Does this project install into /opt?
>       [ ] Yes - explain below
>       [X] No or N/A
>       
>       Does this project install into a different directory structure?
>       [ ] Yes - ARC review required
>       [X] No or N/A
>       
>       Do any of the components of this project conflict with anything under /usr?
>       (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details)
>       [ ] Yes - explain below
>       [X] No
>       
>       If conflicts exist then will this project install under /usr/gnu?
>       [ ] Yes
>       [ ] No - ARC review required
>       [X] N/A
>       
>       Is this project installing into /usr/sfw?
>       [ ] Yes - ARC review required
>       [X] No
>       
>     3.1.1W Windows Installation - section only required for Windows Software
>       (see http://sac.sfbay/WSARC/2002/494 for details)
>       Does this project install software into a 
>       <system drive>:\Program Files\Sun\<product> or <system drive>:\Sun\<product>
>       directory?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       Does the project use the Windows registry?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       Does the project use 
>       HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\<product>\<version>
>       for the registry key?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       Is the project's stored location
>       HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\<product id>\<version id>\Path?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>     3.1.2 Share and Sharable
>       Does the module include any components that are used or shared by 
>       other projects?
>       [ ] Yes
>       [X] No
>     
>       If yes are these components packaged to be shared with the other FOSS?
>       [ ] Yes
>       [ ] No - ARC review required
>     
>       Are these components already in the Solaris WOS?
>       [ ] Yes
>       [X] No - continue with next section
>     
>       If yes are these newer versions being delivered?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       If yes are the newer versions replacing the existing versions?
>       [ ] Yes
>       [ ] No - ARC review required
>
>   3.2 Libraries
>       Are 64-bit libraries being delivered?
>       [ ] Yes
>       [ ] No - ARC review required
>       [X] N/A
> 	No Libraries are being delivered, only a single user binary.
>     
>       Are static versions of the library being delivered?
>       [ ] Yes - ARC review required
>       [X] No 
>       
>   3.3 Services and the /etc Directory
>       (see http://opensolaris.org/os/community/arc/policies/SMF-policy/)
>       Does the project integrate anything into /etc/init.d or /etc/rc?.d?
>       [ ] Yes - ARC review required
>       [X] No
>       
>       Does the project integrate any new entries into /etc/inittab or
>       /etc/inetd.conf?
>       [ ] Yes - ARC review required
>       [X] No
>       
>       Does the project integrate any private non-public files into /etc/default
>       or /etc/ configuration files?
>       [ ] Yes - ARC review required
>       [X] No
>       
>       Does the service manifests method context grant rights above that
>       of the noaccess user and basic privilege set?
>       [ ] Yes - ARC review required
>       [X] No
>         
>   3.4 Security
>     3.4.1 Secure By Default 
>       (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details)
>       (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details)
>       (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for
>        addtional details)
>       Are network services enabled by default?
>       [ ] Yes - ARC review required
>       [X] No
>       [ ] N/A
>       
>       Are network services automatically enabled by the project during installation?
>       [ ] Yes - ARC review required
>       [X] No
>       [ ] N/A
>       
>       Are inbound network communications denied by default?
>       [ ] Yes
>       [ ] No - ARC review required
>       [X] N/A
>       
>       Is inbound data checked to prevent content-based attacks?
>       [ ] Yes
>       [ ] No - ARC review required
>       [X] N/A
>       
>       Is the outbound receiver authenticated?
>       [X] Yes
>       [ ] No - ARC review required
>       [ ] N/A
>       
>       Is the receiver authenticated prior to receiving any sensitive outbound communication?
>       [X] Yes
>       [ ] No - ARC review required
>       [ ] N/A
>       
>     3.4.2 Authorization
>       (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and
> 	   http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and
> 	   http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
>            for details)
>       Are there any setuid/setgid privileged binaries in the project?
>       [ ] Yes - ARC review required
>       [X] No - continue with next section
>       
>       If yes then are the setuid/setgid privileges handled by the use of roles?
>       [ ] Yes
>       [ ] No - ARC review required
>
>     3.4.3 Auditing
>       (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details)
>       (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
>       Does this component contain administrative or security enforcing software?
>       [ ] Yes - ARC review required
>       [X] No - continue to next section
>       
>       (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
>       Do the components create audit logs detailing what took place including what event
>       took place, who was involved, when the event took place?
>       [ ] Yes - ARC contract and Audit project team review required
>       [ ] No - ARC review required
>         
>         
>     3.4.4 Authentication
>       (see http://opensolaris.org/os/community/arc/policies/PAM/)
>       Do the components contain any authentication code?
>       [ ] Yes
>       [X] No - continue to next section
>       
>       If yes do the components use PAM (plugable authentication modules) for authentication?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       If yes is a single PAM session maintained during authentication?
>       [ ] Yes
>       [ ] No - ARC review required
>       
>       If yes are the components sufficiently privileged to allow the requested 
>       operations (authentication, password change, process credential manipulation, 
>       audit state initialization)?
>       [ ] Yes - briefly describe below
>       [ ] No - ARC review required
>       
>     3.4.5 Passwords
>       (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and
>            http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details)
>       Do any of the components for the project deal with passwords?
>       [X] Yes
>       [ ] No - continue to next section
>       
>       If yes are these passwords entered via the CLI or environment?
>       [ ] Yes - ARC review required
>       [ ] No
>       [X] GUI window, all entries shown as '*'.
>       
>       Are passwords stored within the file system for the component?
>       [X] Yes
>       [ ] No - continue to next section
>       
>       If yes are the permissions on the file such to protect exposing the password(s)?
>       [X] Yes
>       [ ] No - ARC review required
>       
>     3.4.6 General Security Questions
>       (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details)
>       Do the components use standard network protocols?
>       [X] Yes
>       [ ] No - ARC review required
>       
>       Do network services for the project make decisions based upon user, host or 
>       service identities?
>       [X] Yes - explain below
>       [ ] No
>       [ ] N/A
>           This ia an ftp client that requires user specified host, user id, and password.
>       
>       Do the components make use of secret information during authentication and/or
>       authorization?
>       [X] Yes - explain below
>       [ ] No
>       [ ] N/A
>           This ia an ftp client that requires user specified host, user id, and password.
>   
>   3.5 Networking
>       Do the components access the network?
>       [X] Yes
>       [ ] No - continue to next section
>       
>       If yes do the components support IPv6?
>       [X] Yes 
>       [ ] No - ARC review required
>           
>   3.6 Core Solaris Components
>       Do the components of this project compete with or duplicate core 
>       Solaris components?
>       [ ] Yes - ARC review required
>       [X] No 
>       
>       Examples of Core Solaris Components include but are not limited to:
>       
>         Secure By Default
>         Authorizations
>         PAM -- Plugable Authentication Module
>         Privilege
>         PRM -- Process Rights Management -- Privilege
>         Audit
>         xVm -- Virtualization
>         zones / Solaris Containers
>         PRM -- Process Rights Management
>         RBAC -- Role Based Access Control
>         TX / Trusted Extensions
>         ZFS
>         SMF -- Service Management Facility
>         FMA -- Fault Management Architecture
>         SCF -- Smart Card Facility
>         IPsec
>         
> 4.0 Interfaces
>   (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details)
>   4.1 Exported Interfaces
>   
>     Interface Name		Classification      Comments
>     --------------------------- ------------------- ---------------------------
>     AxYftp			Uncommitted         version 0.5.1
>
>     SUNWaxyftp			Uncommitted         axyftp's packaging
>
>     /usr/bin/axyftp             Uncommitted         Current version 0.5.1
>                                                     last changed Jan. 2000
>   Manual Pages
>     /usr/share/man/man1/axyftp.1
>
>   Help Documentation
>     /usr/share/doc/axyftp/help.html                
>     /usr/share/doc/axyftp/intro.html
>     /usr/share/doc/axyftp/axyftp.html
>     /usr/share/doc/axyftp/main.html
>     /usr/share/doc/axyftp/options.html
>     /usr/share/doc/axyftp/panels.html
>     /usr/share/doc/axyftp/problems.html
>     /usr/share/doc/axyftp/session.html
>     /usr/share/doc/axyftp/glossary.html
>     /usr/share/doc/axyftp/doc.gif
>     /usr/share/doc/axyftp/folder.gif
>     /usr/share/doc/axyftp/link.gif
>     /usr/share/doc/axyftp/up.gif
>
>   License Files
>     /usr/share/doc/axyftp/artistic.txt              
>     /usr/share/doc/axyftp/lgpl.txt
>     
>   4.2 Imported Interfaces
>     Interface Name		Classification       Comments
>     --------------------------- -------------------- --------------------------
>     GTK+ 1.2.10                 Volatile             PSARC/2000/487
>     GLIB 1.2.10                 Volitile             PSARC/2000/487
>     GDK 1.2.10                  Volitile             PSARC/2000/487
>
>     libsocket(3LIB)             Committed
>     libnsl(3LIB)                Committed
>     X(5)                        Committed
>     libm(3LIB)                  Committed
>
>           
>   Brief Interface Classifications - See Appendix C for definitions
>     Volatile - use check list for approval
>     Uncommitted - ARC review might be required, seek committee member advice
>                   package names do not require further review
>     Committed - ARC review required
>     Project Private - no review required, just documentat in table
>     Contracted (interface modifier) - further review required
>
> Appendix A - References
>   1.  Solaris Installation Locations Policy
>       http://opensolaris.org/os/community/arc/policies/install-locations/
>   2.  /usr/gnu Installation ARC case
>       http://opensolaris.org/os/community/arc/caselog/2007/047/
>   3.  Secure By Default Policy
>       http://opensolaris.org/os/community/arc/policies/secure-by-default/
>   4.  Network Install Time Securityuy Policy
>       http://www.opensolaris.org/os/community/arc/policies/NITS-policy/
>   5.  Adding RBAC Authorizations Policy
>       http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/
>   6.  When to use setuid -vs- RBAC roles and profiles
>       http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and
>   7.  Building RBAC Rights Profiles
>       http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
>   8.  Solaris Audit Policy
>       http://opensolaris.org/os/community/arc/policies/audit-policy/
>   9.  Security questionaire
>       http://opensolaris.org/os/community/arc/bestpractices/security-questions/
>   10. Interface Taxonomy
>       http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/
>   11. Plugable Authentication Modules -- PAM
>       http://opensolaris.org/os/community/arc/policies/PAM/
>   12. Reusable Passwords In Command Line Arguments and Environment Variables
>       http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/
>   13. Storing Reusable Passwords on a Filesystem
>       http://opensolaris.org/os/community/arc/bestpractices/passwords-files/
>   14. Release Taxonomy
>       http://opensolaris.org/os/community/arc/policies/release-taxonomy/
>   15. Service Management Facility (SMF) usage
>       http://opensolaris.org/os/community/arc/policies/SMF-policy/
>
>   
> Appendix B - Suggested case materials
>   1. man pages
>   2. SMF manifests
>   3. links to contracts
>   
> Appendix C - Definitions
> Submitter
>      an agent responsible for creation of an ARC project along with the
>      materials describing that project.
> Owner
>      the ARC agent responsible for shepherding the case through review
>      and ensuring a formal opinion is written where required.
> Maintainer
>      an agent responsible for releasing new versions of a program, typically
>      the "main" contributor or person incharge of making Architectural
>      decisions for the project
> Contributor
>      an agent who make contributions to a project, typically has a voice in
>      making Architectural decisions for the project
> Monitoring
>      an agent who is only following the changes made in the community and
>      has no Architectural input into the project
> Volatile*
>     interfaces that are very fluid and typically follow the originating 
>     community.  Typically these interfaces can not be imported by other
>     projects.
> Uncommitted*
>     interfaces that are still evolving but will most likely be present from
>     release to release.
> Committed*
>     interfaces that are stable and with Sun guaranteeing some level of
>     compatibility from release to release.
> Project Private*
>     interfaces that are exposed only to or intended to be used only by
>     the project being reviewed.  These interfaces can not be imported by
>     other projects.
> Not-An-Interface*
>     components that are not interfaces.
> Contracted* (interface modifier) - ARC review of Contract required
>     interfaces that do not allow another project to import can be 
>
> *Note: see http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>    	6.4.1. Consolidation C-team Name:
> 		ON
>     6.5. ARC review type: Automatic
>     6.6. ARC Exposure: open
>
>   

From gww@eng.sun.com Tue Apr 22 11:13:28 2008
Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MIDRgj028108
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 11:13:28 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3MIDPgp002752
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 23 Apr 2008 02:13:26 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZQ00G1BNYDQW00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 11:13:25 -0700 (PDT)
Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZQ00F88NYCZO10@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 11:13:24 -0700 (PDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m3MIDODC003830; Tue, 22 Apr 2008 11:13:24 -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 m3MID8P0020844; Tue,
 22 Apr 2008 11:13:09 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MID8Q8020843; Tue,
 22 Apr 2008 11:13:08 -0700 (PDT)
Date: Tue, 22 Apr 2008 11:13:08 -0700 (PDT)
From: Gary Winiger <gww@eng.sun.com>
Subject: Re: axyftp [LSARC/2008/271 Self Review]
To: Mark.Carlson@sun.com, lsarc-ext@sun.com
Message-id: <200804221813.m3MID8Q8020843@marduk.eng.sun.com>
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 2430

	Using the check list as the project definition seems to be lacking.
	Is there no documentation that describes what's being proposed?

	Manual Pages
	     /usr/share/man/man1/axyftp.1

	Minimally I'd expect to find this in the case directory.

	Help Documentation
	    /usr/share/doc/axyftp/help.html               
	    /usr/share/doc/axyftp/intro.html
	    /usr/share/doc/axyftp/axyftp.html
	    /usr/share/doc/axyftp/main.html
	    /usr/share/doc/axyftp/options.html
	    /usr/share/doc/axyftp/panels.html
	    /usr/share/doc/axyftp/problems.html
	    /usr/share/doc/axyftp/session.html
	    /usr/share/doc/axyftp/glossary.html
	    /usr/share/doc/axyftp/doc.gif
	    /usr/share/doc/axyftp/folder.gif
	    /usr/share/doc/axyftp/link.gif
	    /usr/share/doc/axyftp/up.gif
	Maximally I'd expect to find these in the case directory.

> >     3.4.3 Auditing
> >       (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details)
> >       (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
> >       Does this component contain administrative or security enforcing software?
> >       [ ] Yes - ARC review required
> >       [X] No - continue to next section
> >       

> >     3.4.4 Authentication
> >       (see http://opensolaris.org/os/community/arc/policies/PAM/)
> >       Do the components contain any authentication code?
> >       [ ] Yes
> >       [X] No - continue to next section

> >     3.4.5 Passwords
> >       (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and
> >            http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details)
> >       Do any of the components for the project deal with passwords?
> >       [X] Yes
> >       [ ] No - continue to next section
> >       
> >       If yes are these passwords entered via the CLI or environment?
> >       [ ] Yes - ARC review required
> >       [ ] No
> >       [X] GUI window, all entries shown as '*'.
> >       
> >       Are passwords stored within the file system for the component?
> >       [X] Yes
> >       [ ] No - continue to next section
> >       
> >       If yes are the permissions on the file such to protect exposing the password(s)?
> >       [X] Yes
> >       [ ] No - ARC review required
> >       

	Just to be clear, this is a FTP client, correct?  So what is it
	doing storing passwords?  Why shouldn't it be using a keychain?

Gary..

From sacadmin Tue Apr 22 11:49:25 2008
Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MInPQw029071;
	Tue, 22 Apr 2008 11:49:25 -0700 (PDT)
Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MInOB2029401;
	Tue, 22 Apr 2008 11:49:24 -0700 (PDT)
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10])
	by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MInIbV016944;
	Tue, 22 Apr 2008 18:49:18 GMT
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZQ00D01PG19400@fe-emea-10.sun.com>
 (original mail from Mark.Phalan@Sun.COM); Tue, 22 Apr 2008 19:49:18 +0100 (BST)
Received: from [192.168.1.34] ([193.85.70.14])
 by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZQ00AKCPM02420@fe-emea-10.sun.com>; Tue,
 22 Apr 2008 19:49:18 +0100 (BST)
Date: Tue, 22 Apr 2008 20:48:31 +0200
From: Mark Phalan <Mark.Phalan@Sun.COM>
Subject: Re: axyftp [LSARC/2008/271 Self Review]
In-reply-to: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
Sender: Mark.Phalan@Sun.COM
To: Mark Carlson <markcarl@sac.sfbay.sun.com>
Cc: LSARC@sac.sfbay.sun.com
Message-id: <1208890111.989.18.camel@localhost>
MIME-version: 1.0
X-Mailer: Evolution 2.22.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
Status: RO
Content-Length: 1906

On Tue, 2008-04-22 at 10:36 -0700, Mark Carlson wrote:
...
>     
> 1.0 Project Information
> 1.1 Name of project/component
> 	axyftp-0.5.1
...
>       [ ] Unknown -- ARC review required
> 
>   2.3 Originating Community
>     2.3.1 Community Name
>         axyftp
>     	http://www.wxftp.seul.org/
> 
>     2.3.2 Community Involvement
>       Indicate Sun's involvement in the community
>       [ ] Maintainer
>       [ ] Contributor
>       [X] Monitoring
>       
>       Will the project team work with the upstream community to resolve
>       architectural issues of interest to Sun?
>       [X] Yes 
>       [ ] No - briefly explain

Is there any upstream to work with? This project looks totally dead with
the last news being posting 8 years ago (roughly).

...
>     
>   4.2 Imported Interfaces
>     Interface Name		Classification       Comments
>     --------------------------- -------------------- --------------------------
>     GTK+ 1.2.10                 Volatile             PSARC/2000/487
>     GLIB 1.2.10                 Volitile             PSARC/2000/487
>     GDK 1.2.10                  Volitile             PSARC/2000/487

GTK+ 1.X has been essentially obsoleted by GTK+ 2.X. None of the
standard desktop apps use GTK 1.X.

Have other graphical gtk clients been evaluated? It would seem to me
(from 5 mins google'ing) that gFTP (http://gftp.seul.org/) would be a
far better option for a graphical ftp client.

* It uses GTK 2.X (the current graphical toolkit of the Solaris desktop)
* At least some recent activity on the site, although the last release 
  was in 2005.
* It would seem to support more features - SFTP support is one that 
  sticks out.


* The "features" section of Axyftp says the following:
     "This is an ``alpha'' quality software. Please avoid any use on a 
      production, mission-critical, or systems with sensitive or 
      unrecoverable data."

-M


From sacadmin Tue Apr 22 13:22:31 2008
Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MKMVjG003431;
	Tue, 22 Apr 2008 13:22:31 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MKMV0N018301;
	Tue, 22 Apr 2008 13:22:31 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MKMVAm027545;
	Tue, 22 Apr 2008 20:22:31 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 <0JZQ00801TKEGH00@mail-amer.sun.com>
 (original mail from John.Fischer@Sun.COM); Tue,
 22 Apr 2008 14:22:31 -0600 (MDT)
Received: from 129.145.154.70 ([129.145.154.70])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZQ00KFQTX368G0@mail-amer.sun.com>; Tue,
 22 Apr 2008 14:22:16 -0600 (MDT)
Date: Tue, 22 Apr 2008 13:22:15 -0700
From: John Fischer <John.Fischer@Sun.COM>
Subject: Re: axyftp [LSARC/2008/271 Self Review]
In-reply-to: <1208890111.989.18.camel@localhost>
Sender: John.Fischer@Sun.COM
To: Mark Phalan <Mark.Phalan@Sun.COM>
Cc: John Fischer <John.Fischer@Sun.COM>,
        Mark Carlson <markcarl@sac.sfbay.sun.com>, LSARC@sac.sfbay.sun.com
Reply-to: John.Fischer@Sun.COM
Message-id: <1208895734.35863.23.camel@sr1-umpk-19>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.4.6.301
Content-type: text/plain; charset=ASCII
Content-transfer-encoding: 7BIT
References: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
 <1208890111.989.18.camel@localhost>
Status: RO
Content-Length: 2223

Mark,

There are several ftp clients on the list to be
integrated into Open Solaris.  One client one that
list is gFTP.  It will be coming soon.

John

On Tue, 2008-04-22 at 11:48, Mark Phalan wrote:
> On Tue, 2008-04-22 at 10:36 -0700, Mark Carlson wrote:
> ...
> >     
> > 1.0 Project Information
> > 1.1 Name of project/component
> > 	axyftp-0.5.1
> ...
> >       [ ] Unknown -- ARC review required
> > 
> >   2.3 Originating Community
> >     2.3.1 Community Name
> >         axyftp
> >     	http://www.wxftp.seul.org/
> > 
> >     2.3.2 Community Involvement
> >       Indicate Sun's involvement in the community
> >       [ ] Maintainer
> >       [ ] Contributor
> >       [X] Monitoring
> >       
> >       Will the project team work with the upstream community to resolve
> >       architectural issues of interest to Sun?
> >       [X] Yes 
> >       [ ] No - briefly explain
> 
> Is there any upstream to work with? This project looks totally dead with
> the last news being posting 8 years ago (roughly).
> 
> ...
> >     
> >   4.2 Imported Interfaces
> >     Interface Name		Classification       Comments
> >     --------------------------- -------------------- --------------------------
> >     GTK+ 1.2.10                 Volatile             PSARC/2000/487
> >     GLIB 1.2.10                 Volitile             PSARC/2000/487
> >     GDK 1.2.10                  Volitile             PSARC/2000/487
> 
> GTK+ 1.X has been essentially obsoleted by GTK+ 2.X. None of the
> standard desktop apps use GTK 1.X.
> 
> Have other graphical gtk clients been evaluated? It would seem to me
> (from 5 mins google'ing) that gFTP (http://gftp.seul.org/) would be a
> far better option for a graphical ftp client.
> 
> * It uses GTK 2.X (the current graphical toolkit of the Solaris desktop)
> * At least some recent activity on the site, although the last release 
>   was in 2005.
> * It would seem to support more features - SFTP support is one that 
>   sticks out.
> 
> 
> * The "features" section of Axyftp says the following:
>      "This is an ``alpha'' quality software. Please avoid any use on a 
>       production, mission-critical, or systems with sensitive or 
>       unrecoverable data."
> 
> -M
> 


From sacadmin Tue Apr 22 13:41:47 2008
Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MKfl1E004189;
	Tue, 22 Apr 2008 13:41:47 -0700 (PDT)
Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MKfkGo027600;
	Tue, 22 Apr 2008 13:41:47 -0700 (PDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12])
	by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MKfexq002954;
	Tue, 22 Apr 2008 20:41:41 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 <0JZQ00001UQD0X00@fe-emea-09.sun.com>
 (original mail from Mark.Phalan@Sun.COM); Tue, 22 Apr 2008 21:41:40 +0100 (BST)
Received: from [192.168.1.33] ([193.85.70.14])
 by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZQ00L0MUTFBD10@fe-emea-09.sun.com>; Tue,
 22 Apr 2008 21:41:40 +0100 (BST)
Date: Tue, 22 Apr 2008 22:41:39 +0200
From: Mark Phalan <Mark.Phalan@Sun.COM>
Subject: Re: axyftp [LSARC/2008/271 Self Review]
In-reply-to: <1208895734.35863.23.camel@sr1-umpk-19>
Sender: Mark.Phalan@Sun.COM
To: John.Fischer@Sun.COM
Cc: Mark Phalan <Mark.Phalan@Sun.COM>,
        Mark Carlson <markcarl@sac.sfbay.sun.com>, LSARC@sac.sfbay.sun.com
Message-id: <E67AF0F0-E07D-4D90-A60A-72C9F149C612@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.919.2)
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <200804221736.m3MHaMEb025908@sac.sfbay.sun.com>
 <1208890111.989.18.camel@localhost> <1208895734.35863.23.camel@sr1-umpk-19>
Status: RO
Content-Length: 229


On 22 Apr 2008, at 22:22, John Fischer wrote:
> Mark,
>
> There are several ftp clients on the list to be
> integrated into Open Solaris.  One client one that
> list is gFTP.  It will be coming soon.

Good to hear.

Thanks,

-M

From sacadmin Tue Apr 22 14:22:18 2008
Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MLMI0s005790;
	Tue, 22 Apr 2008 14:22:18 -0700 (PDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MLM73S051174;
	Tue, 22 Apr 2008 14:22:07 -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 m3MLLqlW021493;
	Tue, 22 Apr 2008 14:21:52 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MLLqe3021492;
	Tue, 22 Apr 2008 14:21:52 -0700 (PDT)
Date: Tue, 22 Apr 2008 14:21:52 -0700 (PDT)
From: Gary Winiger <gww@eng.sun.com>
Message-Id: <200804222121.m3MLLqe3021492@marduk.eng.sun.com>
To: Mark.Phalan@sun.com, John.Fischer@sun.com
Subject: Re: axyftp [LSARC/2008/271 Self Review]
Cc: markcarl@sac.sfbay.sun.com, LSARC@sac.sfbay.sun.com
X-Sun-Charset: US-ASCII
Status: RO
Content-Length: 250


> There are several ftp clients on the list to be
> integrated into Open Solaris.  One client one that
> list is gFTP.  It will be coming soon.

	So is this case just one of those check list items that the
	ARC should just Deny?  (Viz. zoo)

Gary..

From Charles.Baker@sun.com Tue Apr 22 15:12:40 2008
Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MMCdVe007729
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 15:12:39 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3MMC4BI004223;
	Wed, 23 Apr 2008 06:12:37 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZQ00107Z0XWM00@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 22 Apr 2008 15:12:33 -0700 (PDT)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZQ00EUVZ0WUE40@nwk-avmta-1.sfbay.Sun.COM>; Tue,
 22 Apr 2008 15:12:32 -0700 (PDT)
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 m3MMCWqT013000; Tue,
 22 Apr 2008 22:12:32 +0000 (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 <0JZQ00G01YX98K00@mail-amer.sun.com>
 (original mail from Charles.Baker@Sun.COM); Tue,
 22 Apr 2008 16:12:32 -0600 (MDT)
Received: from [192.168.1.23] ([129.150.34.91])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZQ00K35YZ73Q60@mail-amer.sun.com>; Tue,
 22 Apr 2008 16:11:36 -0600 (MDT)
Date: Tue, 22 Apr 2008 16:11:17 -0600
From: Charles Baker <Charles.Baker@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <480E2CEE.7020400@sun.com>
Sender: Charles.Baker@sun.com
To: "Mark A. Carlson" <Mark.Carlson@sun.com>, Gary.Winiger@sun.com
Cc: Charles.Baker@sun.com, lsarc-ext@sun.com
Message-id: <480E6285.5090806@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_UDkFahNXvzdvkr0xtGB9HA)"
X-PMX-Version: 5.4.1.325704
References: <480E2CEE.7020400@sun.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070424)
Status: RO
Content-Length: 9560

This is a multi-part message in MIME format.

--Boundary_(ID_UDkFahNXvzdvkr0xtGB9HA)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi Mark,

Please see in-line.

thanks
Charles

> ------------------------------------------------------------------------
>
> Subject:
> Re: axyftp [LSARC/2008/271 Self Review]
> From:
> Gary Winiger <gww@eng.sun.com>
> Date:
> Tue, 22 Apr 2008 11:13:08 -0700 (PDT)
> To:
> Mark.Carlson@Sun.COM, lsarc-ext@sun.com
>
> To:
> Mark.Carlson@Sun.COM, lsarc-ext@sun.com
>
>
> 	Using the check list as the project definition seems to be lacking.
> 	Is there no documentation that describes what's being proposed?
>
> 	Manual Pages
> 	     /usr/share/man/man1/axyftp.1
>
> 	Minimally I'd expect to find this in the case directory.
>
> 	Help Documentation
> 	    /usr/share/doc/axyftp/help.html               
> 	    /usr/share/doc/axyftp/intro.html
> 	    /usr/share/doc/axyftp/axyftp.html
> 	    /usr/share/doc/axyftp/main.html
> 	    /usr/share/doc/axyftp/options.html
> 	    /usr/share/doc/axyftp/panels.html
> 	    /usr/share/doc/axyftp/problems.html
> 	    /usr/share/doc/axyftp/session.html
> 	    /usr/share/doc/axyftp/glossary.html
> 	    /usr/share/doc/axyftp/doc.gif
> 	    /usr/share/doc/axyftp/folder.gif
> 	    /usr/share/doc/axyftp/link.gif
> 	    /usr/share/doc/axyftp/up.gif
> 	Maximally I'd expect to find these in the case directory.
>
>   
The additional materials have been placed in the case directory.
>>>     3.4.3 Auditing
>>>       (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details)
>>>       (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details)
>>>       Does this component contain administrative or security enforcing software?
>>>       [ ] Yes - ARC review required
>>>       [X] No - continue to next section
>>>       
>>>       
>
>   
>>>     3.4.4 Authentication
>>>       (see http://opensolaris.org/os/community/arc/policies/PAM/)
>>>       Do the components contain any authentication code?
>>>       [ ] Yes
>>>       [X] No - continue to next section
>>>       
>
>   
>>>     3.4.5 Passwords
>>>       (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and
>>>            http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details)
>>>       Do any of the components for the project deal with passwords?
>>>       [X] Yes
>>>       [ ] No - continue to next section
>>>       
>>>       If yes are these passwords entered via the CLI or environment?
>>>       [ ] Yes - ARC review required
>>>       [ ] No
>>>       [X] GUI window, all entries shown as '*'.
>>>       
>>>       Are passwords stored within the file system for the component?
>>>       [X] Yes
>>>       [ ] No - continue to next section
>>>       
>>>       If yes are the permissions on the file such to protect exposing the password(s)?
>>>       [X] Yes
>>>       [ ] No - ARC review required
>>>       
>>>       
>
> 	Just to be clear, this is a FTP client, correct?  So what is it
> 	doing storing passwords?  Why shouldn't it be using a keychain?
>   
The axyftp GUI allows the user to save the "jumbled" password.  The 
"jumbled" password
is saved in a ~/.axyftp directory.  The file containing the jumbled 
password  has permissions
set to 600.  This project includes only an inbound OSR at this time.
> Gary..
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc@opensolaris.org
>   


--Boundary_(ID_UDkFahNXvzdvkr0xtGB9HA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
Please see in-line.<br>
<br>
thanks<br>
Charles<br>
<br>
<blockquote cite="mid:480E2CEE.7020400@sun.com" type="cite">
  <hr size="4" width="90%"><br>
  <table class="header-part1" border="0" cellpadding="0" cellspacing="0"
 width="100%">
    <tbody>
      <tr>
        <td>
        <div class="headerdisplayname" style="display: inline;">Subject:
        </div>
Re: axyftp [LSARC/2008/271 Self Review]</td>
      </tr>
      <tr>
        <td>
        <div class="headerdisplayname" style="display: inline;">From: </div>
Gary Winiger <a class="moz-txt-link-rfc2396E" href="mailto:gww@eng.sun.com">&lt;gww@eng.sun.com&gt;</a></td>
      </tr>
      <tr>
        <td>
        <div class="headerdisplayname" style="display: inline;">Date: </div>
Tue, 22 Apr 2008 11:13:08 -0700 (PDT)</td>
      </tr>
      <tr>
        <td>
        <div class="headerdisplayname" style="display: inline;">To: </div>
<a class="moz-txt-link-abbreviated" href="mailto:Mark.Carlson@Sun.COM">Mark.Carlson@Sun.COM</a>, <a class="moz-txt-link-abbreviated" href="mailto:lsarc-ext@sun.com">lsarc-ext@sun.com</a></td>
      </tr>
    </tbody>
  </table>
  <table class="header-part2" border="0" cellpadding="0" cellspacing="0"
 width="100%">
    <tbody>
      <tr>
        <td>
        <div class="headerdisplayname" style="display: inline;">To: </div>
<a class="moz-txt-link-abbreviated" href="mailto:Mark.Carlson@Sun.COM">Mark.Carlson@Sun.COM</a>, <a class="moz-txt-link-abbreviated" href="mailto:lsarc-ext@sun.com">lsarc-ext@sun.com</a></td>
      </tr>
    </tbody>
  </table>
  <br>
  <pre wrap="">	Using the check list as the project definition seems to be lacking.
	Is there no documentation that describes what's being proposed?

	Manual Pages
	     /usr/share/man/man1/axyftp.1

	Minimally I'd expect to find this in the case directory.

	Help Documentation
	    /usr/share/doc/axyftp/help.html               
	    /usr/share/doc/axyftp/intro.html
	    /usr/share/doc/axyftp/axyftp.html
	    /usr/share/doc/axyftp/main.html
	    /usr/share/doc/axyftp/options.html
	    /usr/share/doc/axyftp/panels.html
	    /usr/share/doc/axyftp/problems.html
	    /usr/share/doc/axyftp/session.html
	    /usr/share/doc/axyftp/glossary.html
	    /usr/share/doc/axyftp/doc.gif
	    /usr/share/doc/axyftp/folder.gif
	    /usr/share/doc/axyftp/link.gif
	    /usr/share/doc/axyftp/up.gif
	Maximally I'd expect to find these in the case directory.

  </pre>
</blockquote>
The additional materials have been placed in the case directory.
<blockquote cite="mid:480E2CEE.7020400@sun.com" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">    3.4.3 Auditing
      (see <a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/policies/audit-policy/">http://opensolaris.org/os/community/arc/policies/audit-policy/</a> for details)
      (see <a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/caselog/2003/397">http://opensolaris.org/os/community/arc/caselog/2003/397</a> for details)
      Does this component contain administrative or security enforcing software?
      [ ] Yes - ARC review required
      [X] No - continue to next section
      
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">    3.4.4 Authentication
      (see <a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/policies/PAM/">http://opensolaris.org/os/community/arc/policies/PAM/</a>)
      Do the components contain any authentication code?
      [ ] Yes
      [X] No - continue to next section
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">    3.4.5 Passwords
      (see <a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/">http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/</a> and
           <a class="moz-txt-link-freetext" href="http://opensolaris.org/os/community/arc/bestpractices/passwords-files/">http://opensolaris.org/os/community/arc/bestpractices/passwords-files/</a> for details)
      Do any of the components for the project deal with passwords?
      [X] Yes
      [ ] No - continue to next section
      
      If yes are these passwords entered via the CLI or environment?
      [ ] Yes - ARC review required
      [ ] No
      [X] GUI window, all entries shown as '*'.
      
      Are passwords stored within the file system for the component?
      [X] Yes
      [ ] No - continue to next section
      
      If yes are the permissions on the file such to protect exposing the password(s)?
      [X] Yes
      [ ] No - ARC review required
      
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
	Just to be clear, this is a FTP client, correct?  So what is it
	doing storing passwords?  Why shouldn't it be using a keychain?
  </pre>
</blockquote>
The axyftp GUI allows the user to save the "jumbled" password.&nbsp; The
"jumbled" password<br>
is saved in a ~/.axyftp directory.&nbsp; The file containing the jumbled
password&nbsp; has permissions<br>
set to 600.&nbsp; This project includes only an inbound OSR at this time.
<blockquote cite="mid:480E2CEE.7020400@sun.com" type="cite">
  <pre wrap="">
Gary..
_______________________________________________
opensolaris-arc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:opensolaris-arc@opensolaris.org">opensolaris-arc@opensolaris.org</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_UDkFahNXvzdvkr0xtGB9HA)--

From Darren.Moffat@sun.com Tue Apr 22 15:31:40 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MMVdIQ008605
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 15:31:40 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MMVVV6027252;
	Tue, 22 Apr 2008 23:31:37 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZQ00301ZWOY800@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 16:31:36 -0600 (MDT)
Received: from gmp-eb-inf-1.sun.com ([192.18.6.21])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZQ00NPCZWN4020@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 16:31:35 -0600 (MDT)
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10])
	by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MMVYOm006149; Tue,
 22 Apr 2008 22:31:34 +0000 (GMT)
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZQ00J01ZPK4W00@fe-emea-10.sun.com>
 (original mail from Darren.Moffat@Sun.COM); Tue,
 22 Apr 2008 23:31:34 +0100 (BST)
Received: from [129.156.173.199] by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JZQ0016RZWLF420@fe-emea-10.sun.com>; Tue,
 22 Apr 2008 23:31:34 +0100 (BST)
Date: Tue, 22 Apr 2008 23:31:33 +0100
From: Darren J Moffat <Darren.Moffat@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <480E6285.5090806@sun.com>
Sender: Darren.Moffat@sun.com
To: Charles Baker <Charles.Baker@sun.com>
Cc: "Mark A. Carlson" <Mark.Carlson@sun.com>, Gary.Winiger@sun.com,
        lsarc-ext@sun.com
Message-id: <480E6745.2010908@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <480E2CEE.7020400@sun.com> <480E6285.5090806@sun.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080225)
Status: RO
Content-Length: 374

Charles Baker wrote:

> The axyftp GUI allows the user to save the "jumbled" password.  The 
> "jumbled" password
> is saved in a ~/.axyftp directory.  The file containing the jumbled 
> password  has permissions
> set to 600.  This project includes only an inbound OSR at this time.

What is the algorithm for this obscuring mechanism ? base64 rot13 ?

-- 
Darren J Moffat

From Charles.Baker@sun.com Tue Apr 22 15:38:14 2008
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MMcEet009044
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 15:38:14 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MMcDaZ021404;
	Tue, 22 Apr 2008 15:38:14 -0700 (PDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR0050D07P3O00@nwk-avmta-2.sfbay.sun.com>; Tue,
 22 Apr 2008 15:38:13 -0700 (PDT)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR0036807M6W50@nwk-avmta-2.sfbay.sun.com>; Tue,
 22 Apr 2008 15:38:10 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MMcAM0020241; Tue,
 22 Apr 2008 22:38:10 +0000 (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 <0JZQ00I01ZYFF200@mail-amer.sun.com>
 (original mail from Charles.Baker@Sun.COM); Tue,
 22 Apr 2008 16:38:10 -0600 (MDT)
Received: from [192.168.1.23] ([129.150.34.91])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZR000EI0793950@mail-amer.sun.com>; Tue,
 22 Apr 2008 16:38:00 -0600 (MDT)
Date: Tue, 22 Apr 2008 16:37:43 -0600
From: Charles Baker <Charles.Baker@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <480E6745.2010908@Sun.COM>
Sender: Charles.Baker@sun.com
To: Darren J Moffat <Darren.Moffat@sun.com>
Cc: "Mark A. Carlson" <Mark.Carlson@sun.com>, Gary.Winiger@sun.com,
        lsarc-ext@sun.com, Charles.Baker@sun.com
Message-id: <480E68B7.5010302@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <480E2CEE.7020400@sun.com> <480E6285.5090806@sun.com>
 <480E6745.2010908@Sun.COM>
User-Agent: Thunderbird 2.0.0.0 (X11/20070424)
Status: RO
Content-Length: 396

Darren J Moffat wrote:
> Charles Baker wrote:
>
>> The axyftp GUI allows the user to save the "jumbled" password.  The 
>> "jumbled" password
>> is saved in a ~/.axyftp directory.  The file containing the jumbled 
>> password  has permissions
>> set to 600.  This project includes only an inbound OSR at this time.
>
> What is the algorithm for this obscuring mechanism ? base64 rot13 ?
>
rot13


From gww@eng.sun.com Tue Apr 22 15:55:10 2008
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MMtA6Y009870
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 15:55:10 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MMt6pH015281
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 22 Apr 2008 15:55:10 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR005150ZXJM00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 16:55:09 -0600 (MDT)
Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00NQR0ZU3Y30@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 16:55:06 -0600 (MDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m3MMt4Mm036660; Tue, 22 Apr 2008 15:55:05 -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 m3MMso0F021721; Tue,
 22 Apr 2008 15:54:50 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MMsoTB021720; Tue,
 22 Apr 2008 15:54:50 -0700 (PDT)
Date: Tue, 22 Apr 2008 15:54:50 -0700 (PDT)
From: Gary Winiger <gww@eng.sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
To: Darren.Moffat@sun.com, Charles.Baker@sun.com
Cc: Mark.Carlson@sun.com, Gary.Winiger@sun.com, lsarc-ext@sun.com
Message-id: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 879

]> >> The axyftp GUI allows the user to save the "jumbled" password.  The 
> >> "jumbled" password
> >> is saved in a ~/.axyftp directory.  The file containing the jumbled 
> >> password  has permissions
> >> set to 600.  This project includes only an inbound OSR at this time.
> >
> > What is the algorithm for this obscuring mechanism ? base64 rot13 
	
	IMO, the question of relevance still applies both to why are
	we including this and why shouldn't it be using the keychain.

	Is there some reason to have this checkbox piece of SW that
	is warned to be Alpha quality and seems quite out of date?

	Probably Self Review is optimistic.  It seems clear this is
	not current architectural technology.  Why should it be part
	of the single Solaris bucket?
	Is the project team prepaired to bring it up to date with current
	technology and support it as part of Solaris?

Gary..

From John.Plocher@sun.com Tue Apr 22 16:24:03 2008
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MNO3HC010273
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 16:24:03 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MNO36B022833;
	Tue, 22 Apr 2008 16:24:03 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR007092C3AI00@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:24:03 -0600 (MDT)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00N8G2BX3W50@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:23:57 -0600 (MDT)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MNNvtQ027663;
 Tue, 22 Apr 2008 16:23:57 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZR0090123A6600@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Tue,
 22 Apr 2008 16:23:57 -0700 (PDT)
Received: from wp668.local ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JZR0053D2BOWA30@fe-sfbay-09.sun.com>; Tue,
 22 Apr 2008 16:23:48 -0700 (PDT)
Date: Tue, 22 Apr 2008 16:23:48 -0700
From: John Plocher <John.Plocher@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
Sender: John.Plocher@sun.com
To: Gary Winiger <gww@eng.sun.com>
Cc: lsarc-ext@sun.com
Message-id: <480E7384.9030601@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 632

Gary Winiger wrote:
>  Why should it be part of the single Solaris bucket?

Maybe this (and the other "Comay-List" cases) should simply
be targeting the CompanionCD Consolidation, and we can simply
have one mondo-case that says "this list of 500 cases goes
there, where we expect to have architectural chaos, unsupportable
and unsupported dumpware mixed up with a few priceless jewels"

Seriously.  If we don't ever intend to put any engineering effort
into these things to make them work [at all, better, as expected]
on OpenSolaris, we shouldn't be mixing them into the core OS source
tree (aka the ON consolidation)!

   -John



From sacadmin Tue Apr 22 16:24:03 2008
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MNO3eS010275
	for <psarc-members@sac.eng.sun.com>; Tue, 22 Apr 2008 16:24:03 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MNO36B022833;
	Tue, 22 Apr 2008 16:24:03 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR007092C3AI00@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:24:03 -0600 (MDT)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00N8G2BX3W50@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:23:57 -0600 (MDT)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MNNvtQ027663;
 Tue, 22 Apr 2008 16:23:57 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZR0090123A6600@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM); Tue,
 22 Apr 2008 16:23:57 -0700 (PDT)
Received: from wp668.local ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JZR0053D2BOWA30@fe-sfbay-09.sun.com>; Tue,
 22 Apr 2008 16:23:48 -0700 (PDT)
Date: Tue, 22 Apr 2008 16:23:48 -0700
From: John Plocher <John.Plocher@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
Sender: John.Plocher@sun.com
To: Gary Winiger <gww@eng.sun.com>
Cc: lsarc-ext@sun.com
Message-id: <480E7384.9030601@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 632

Gary Winiger wrote:
>  Why should it be part of the single Solaris bucket?

Maybe this (and the other "Comay-List" cases) should simply
be targeting the CompanionCD Consolidation, and we can simply
have one mondo-case that says "this list of 500 cases goes
there, where we expect to have architectural chaos, unsupportable
and unsupported dumpware mixed up with a few priceless jewels"

Seriously.  If we don't ever intend to put any engineering effort
into these things to make them work [at all, better, as expected]
on OpenSolaris, we shouldn't be mixing them into the core OS source
tree (aka the ON consolidation)!

   -John



From Mark.Carlson@sun.com Tue Apr 22 16:24:06 2008
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MNO5AO010281
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 16:24:06 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MNO57f041036
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 22 Apr 2008 17:24:05 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR0071L2C5AI00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 17:24:05 -0600 (MDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00N052C33P60@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 17:24:03 -0600 (MDT)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MNO3kL029305	for
 <lsarc-ext@sun.com>; Tue, 22 Apr 2008 23:24:03 +0000 (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 <0JZR00D0126UJ100@mail-amer.sun.com>
 (original mail from Mark.Carlson@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 17:24:03 -0600 (MDT)
Received: from Macintosh-39.local ([71.237.94.98])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZR00F7Q2BQLY00@mail-amer.sun.com>; Tue,
 22 Apr 2008 17:23:51 -0600 (MDT)
Date: Tue, 22 Apr 2008 17:23:49 -0600
From: "Mark A. Carlson" <Mark.Carlson@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
Sender: Mark.Carlson@sun.com
To: Gary Winiger <gww@eng.sun.com>
Cc: Darren.Moffat@sun.com, Charles.Baker@sun.com, lsarc-ext@sun.com
Message-id: <480E7385.8070305@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_DcFqq6jbDm2C5hcy3RXbOg)"
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 3679

This is a multi-part message in MIME format.

--Boundary_(ID_DcFqq6jbDm2C5hcy3RXbOg)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Gary,

I know there is an outstanding issue with the value of including all this
FOSS stuff with minimal resources to adapt to our environment. But this 
case
doesn't seem to be any more egregious than others. Fighting the business
decision, one ARC case at a time, seems futile also. I would like to help
folks that are willing to fill out the checklist, do the right thing here,
within the bounds of the resources they have.

-- mark

Gary Winiger wrote:
> ]> >> The axyftp GUI allows the user to save the "jumbled" password.  The 
>   
>>>> "jumbled" password
>>>> is saved in a ~/.axyftp directory.  The file containing the jumbled 
>>>> password  has permissions
>>>> set to 600.  This project includes only an inbound OSR at this time.
>>>>         
>>> What is the algorithm for this obscuring mechanism ? base64 rot13 
>>>       
> 	
> 	IMO, the question of relevance still applies both to why are
> 	we including this and why shouldn't it be using the keychain.
>
> 	Is there some reason to have this checkbox piece of SW that
> 	is warned to be Alpha quality and seems quite out of date?
>
> 	Probably Self Review is optimistic.  It seems clear this is
> 	not current architectural technology.  Why should it be part
> 	of the single Solaris bucket?
> 	Is the project team prepaired to bring it up to date with current
> 	technology and support it as part of Solaris?
>
> Gary..
>   

--Boundary_(ID_DcFqq6jbDm2C5hcy3RXbOg)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Gary,<br>
<br>
I know there is an outstanding issue with the value of including all
this<br>
FOSS stuff with minimal resources to adapt to our environment. But this
case <br>
doesn't seem to be any more egregious than others. Fighting the business<br>
decision, one ARC case at a time, seems futile also. I would like to
help<br>
folks that are willing to fill out the checklist, do the right thing
here,<br>
within the bounds of the resources they have.<br>
<br>
-- mark<br>
</tt><br>
Gary Winiger wrote:
<blockquote cite="mid:200804222254.m3MMsoTB021720@marduk.eng.sun.com"
 type="cite">
  <pre wrap="">]&gt; &gt;&gt; The axyftp GUI allows the user to save the "jumbled" password.  The 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">"jumbled" password
is saved in a ~/.axyftp directory.  The file containing the jumbled 
password  has permissions
set to 600.  This project includes only an inbound OSR at this time.
        </pre>
      </blockquote>
      <pre wrap="">What is the algorithm for this obscuring mechanism ? base64 rot13 
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->	
	IMO, the question of relevance still applies both to why are
	we including this and why shouldn't it be using the keychain.

	Is there some reason to have this checkbox piece of SW that
	is warned to be Alpha quality and seems quite out of date?

	Probably Self Review is optimistic.  It seems clear this is
	not current architectural technology.  Why should it be part
	of the single Solaris bucket?
	Is the project team prepaired to bring it up to date with current
	technology and support it as part of Solaris?

Gary..
  </pre>
</blockquote>
</body>
</html>

--Boundary_(ID_DcFqq6jbDm2C5hcy3RXbOg)--

From sommerfeld@sun.com Tue Apr 22 16:45:34 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MNjXpF010730
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 16:45:34 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3MNjVbX023657;
	Wed, 23 Apr 2008 00:45:32 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR008053BUJ800@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:45:30 -0600 (MDT)
Received: from localhost.east.sun.com ([10.7.251.192])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00NVD3BO3Y50@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 17:45:24 -0600 (MDT)
Received: from localhost.east.sun.com (localhost [127.0.0.1])
	by localhost.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3MNjN9V004252;
 Tue, 22 Apr 2008 16:45:23 -0700 (PDT)
Received: (from sommerfeld@localhost)	by localhost.east.sun.com
 (8.14.2+Sun/8.14.2/Submit) id m3MNjMg8004251; Tue,
 22 Apr 2008 16:45:22 -0700 (PDT)
Date: Tue, 22 Apr 2008 16:45:22 -0700
From: Bill Sommerfeld <sommerfeld@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <480E7385.8070305@sun.com>
To: "Mark A. Carlson" <Mark.Carlson@sun.com>
Cc: Gary Winiger <gww@eng.sun.com>, Charles.Baker@sun.com, lsarc-ext@sun.com
Message-id: <1208907922.1919.40.camel@localhost>
MIME-version: 1.0
X-Mailer: Evolution 2.12.2
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
 <480E7385.8070305@sun.com>
X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to
 sommerfeld@sun.com using -f
Status: RO
Content-Length: 790


On Tue, 2008-04-22 at 17:23 -0600, Mark A. Carlson wrote:
> Gary,
> 
> I know there is an outstanding issue with the value of including all this
> FOSS stuff with minimal resources to adapt to our environment. But this case 
> doesn't seem to be any more egregious than others. Fighting the business
> decision, one ARC case at a time, seems futile also. I would like to help
> folks that are willing to fill out the checklist, do the right thing here,
> within the bounds of the resources they have.

if we're not doing any engineering or integration on the code, what's
the compelling reason to put this into the core ON consolidation rather
than one of the less-core consolidations such as SFW or JDS?

(seems like the FOSS checklist needs some guidance on that front..)

					- Bill



From gww@eng.sun.com Tue Apr 22 16:54:30 2008
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MNsUue011019
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 16:54:30 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MNsTtr029406
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 22 Apr 2008 16:54:30 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR0080H3QTY500@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 17:54:29 -0600 (MDT)
Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00NXL3QO3Q60@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 17:54:24 -0600 (MDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m3MNsNvC063736; Tue, 22 Apr 2008 16:54:23 -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 m3MNs90K021909; Tue,
 22 Apr 2008 16:54:09 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3MNs9ig021908; Tue,
 22 Apr 2008 16:54:09 -0700 (PDT)
Date: Tue, 22 Apr 2008 16:54:09 -0700 (PDT)
From: Gary Winiger <gww@eng.sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
To: gww@eng.sun.com, John.Plocher@sun.com
Cc: lsarc-ext@sun.com, david.comay@sun.com
Message-id: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 1901

> Gary Winiger wrote:
> >  Why should it be part of the single Solaris bucket?
> 
> Maybe this (and the other "Comay-List" cases) should simply
> be targeting the CompanionCD Consolidation, and we can simply
> have one mondo-case that says "this list of 500 cases goes
> there, where we expect to have architectural chaos, unsupportable
> and unsupported dumpware mixed up with a few priceless jewels"

	Having just chatted with Dave [Cced], there seems to be some
	miscommunication from what might have been said to what
	might have been heard.  The page I've been on and I believe
	is the page Dave espoused, is that Sun needs to have engineering
	resources who will work with the community and maintain the
	FOSS being added.  Secondly there needs to be a reason for adding
	the particular component whether FOSS or internal.  There was
	a list of packages that OpenSolaris didn't contain.  Of those
	packages, engineering resources were to be applied to triage
	them and determine whether they were indeed good candidates for
	OpenSolaris.  It was not here's 100s or 1000s of things that
	will compile on OpenSolaris, lets throw them all in the bucket.
	It was of the 100s or 1000s of things which make sense to provide
	in OpenSolaris and will have engineering support to work with the
	community to support/sustain/improve/maintain current in OpenSolaris.

	Again no free puppies here.

> Seriously.  If we don't ever intend to put any engineering effort
> into these things to make them work [at all, better, as expected]
> on OpenSolaris, we shouldn't be mixing them into the core OS source
> tree (aka the ON consolidation)!

	I don't believe axyftp was proposed for the ON consolidation.
	In fact, not that it's really architecturally relevant, I can't
	find a consolidation noted in the Self Review submission.

	Frankly I don't believe this any longer qualifies as Self Review.

Gary..

	

From gww@eng.sun.com Tue Apr 22 17:05:10 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N05Aqu011429
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 17:05:10 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3N053YM000536
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 23 Apr 2008 01:05:09 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR00E0B48IMR00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 17:05:06 -0700 (PDT)
Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00ETT48IUL80@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 17:05:06 -0700 (PDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m3N055rK003133; Tue, 22 Apr 2008 17:05:05 -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 m3N04psc021929; Tue,
 22 Apr 2008 17:04:51 -0700 (PDT)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3N04pwF021928; Tue,
 22 Apr 2008 17:04:51 -0700 (PDT)
Date: Tue, 22 Apr 2008 17:04:51 -0700 (PDT)
From: Gary Winiger <gww@eng.sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
To: gww@eng.sun.com, John.Plocher@sun.com
Cc: lsarc-ext@sun.com, david.comay@sun.com
Message-id: <200804230004.m3N04pwF021928@marduk.eng.sun.com>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 918

> > Seriously.  If we don't ever intend to put any engineering effort
> > into these things to make them work [at all, better, as expected]
> > on OpenSolaris, we shouldn't be mixing them into the core OS source
> > tree (aka the ON consolidation)!
> 
> 	I don't believe axyftp was proposed for the ON consolidation.
> 	In fact, not that it's really architecturally relevant, I can't
> 	find a consolidation noted in the Self Review submission.
> 
> 	Frankly I don't believe this any longer qualifies as Self Review.

	Argggg, I missed this.

6. Resources and Schedule
    6.4. Steering Committee requested information
        6.4.1. Consolidation C-team Name:
                ON
    6.5. ARC review type: Automatic
    6.6. ARC Exposure: open

	Please see my earlier comments about the point of integrating
	FOSS.  If that's not clear, please let me know and I'll derail
	this case and get a definitive vote.

Gary..

From John.Plocher@Sun.COM Tue Apr 22 17:08:51 2008
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N08pdD011685
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 17:08:51 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3N08oox051588
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 22 Apr 2008 18:08:50 -0600 (MDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR0091B4EQRC00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@Sun.COM); Tue, 22 Apr 2008 18:08:50 -0600 (MDT)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00NFK4EN3P70@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Tue,
 22 Apr 2008 18:08:47 -0600 (MDT)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3N08lvs014065	for
 <lsarc-ext@Sun.COM>; Tue, 22 Apr 2008 17:08:47 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZR00B014C55500@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue,
 22 Apr 2008 17:08:47 -0700 (PDT)
Received: from wp668.local ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JZR005564EM3S30@fe-sfbay-09.sun.com>; Tue,
 22 Apr 2008 17:08:46 -0700 (PDT)
Date: Tue, 22 Apr 2008 17:08:46 -0700
From: John Plocher <John.Plocher@Sun.COM>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
Sender: John.Plocher@Sun.COM
To: Gary Winiger <gww@eng.sun.com>
Cc: lsarc-ext@Sun.COM, David.Comay@Sun.COM
Message-id: <480E7E0E.7060506@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 366

Gary Winiger wrote:
> 	I don't believe axyftp was proposed for the ON consolidation.

Found in the 1-pager in LSARC/2008/271/20080422_charles.baker:

6. Resources and Schedule
     6.4. Steering Committee requested information
         6.4.1. Consolidation C-team Name:
                 ON
     6.5. ARC review type: Automatic
     6.6. ARC Exposure: open

   -John

From Charles.Baker@sun.com Tue Apr 22 17:53:14 2008
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N0rDYH012434
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 17:53:13 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3N0r8FC024295;
	Tue, 22 Apr 2008 17:53:13 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR00C116GNJE00@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 18:53:11 -0600 (MDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR00NQV6GM3Q90@brm-avmta-1.central.sun.com>; Tue,
 22 Apr 2008 18:53:10 -0600 (MDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3N0rAY6019907; Wed,
 23 Apr 2008 00:53:10 +0000 (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 <0JZR00H016EF5600@mail-amer.sun.com>
 (original mail from Charles.Baker@Sun.COM); Tue,
 22 Apr 2008 18:53:10 -0600 (MDT)
Received: from [10.108.81.34] ([164.47.45.37])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JZR002536GL8BE0@mail-amer.sun.com>; Tue,
 22 Apr 2008 18:53:10 -0600 (MDT)
Date: Tue, 22 Apr 2008 18:53:05 -0600
From: Charles Baker <Charles.Baker@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <1208907922.1919.40.camel@localhost>
Sender: Charles.Baker@sun.com
To: Bill Sommerfeld <sommerfeld@sun.com>
Cc: "Mark A. Carlson" <Mark.Carlson@sun.com>, Gary Winiger <gww@eng.sun.com>,
        lsarc-ext@sun.com, Charles.Baker@sun.com
Message-id: <480E8871.2050100@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_zcM75T8eh+0weeqgSxQ1cQ)"
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
 <480E7385.8070305@sun.com> <1208907922.1919.40.camel@localhost>
User-Agent: Thunderbird 2.0.0.12 (X11/20080310)
Status: RO
Content-Length: 3508

This is a multi-part message in MIME format.

--Boundary_(ID_zcM75T8eh+0weeqgSxQ1cQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Bill Sommerfeld wrote:
> On Tue, 2008-04-22 at 17:23 -0600, Mark A. Carlson wrote:
>   
>> Gary,
>>
>> I know there is an outstanding issue with the value of including all this
>> FOSS stuff with minimal resources to adapt to our environment. But this case 
>> doesn't seem to be any more egregious than others. Fighting the business
>> decision, one ARC case at a time, seems futile also. I would like to help
>> folks that are willing to fill out the checklist, do the right thing here,
>> within the bounds of the resources they have.
>>     
>
> if we're not doing any engineering or integration on the code, what's
> the compelling reason to put this into the core ON consolidation rather
> than one of the less-core consolidations such as SFW or JDS?
>
> (seems like the FOSS checklist needs some guidance on that front..)
>
> 					- Bill
>
>
>   
I think I missed something here.  This is targeting the sfw consolidation.

The project team currently consists of 1 person.. me, and I only have an 
inbound
OSR.  I was under the impression that I would be required to provide 
support for this
project.  If there are specific enhancements you would like to see, 
please let me know.

Yes, this is older software, but it works well.  I have been using it 
for more than 7 years
at Sun, and thought it would be a good thing to share with our users.

thanks
Charles


--Boundary_(ID_zcM75T8eh+0weeqgSxQ1cQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bill Sommerfeld wrote:
<blockquote cite="mid:1208907922.1919.40.camel@localhost" type="cite">
  <pre wrap="">On Tue, 2008-04-22 at 17:23 -0600, Mark A. Carlson wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Gary,

I know there is an outstanding issue with the value of including all this
FOSS stuff with minimal resources to adapt to our environment. But this case 
doesn't seem to be any more egregious than others. Fighting the business
decision, one ARC case at a time, seems futile also. I would like to help
folks that are willing to fill out the checklist, do the right thing here,
within the bounds of the resources they have.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
if we're not doing any engineering or integration on the code, what's
the compelling reason to put this into the core ON consolidation rather
than one of the less-core consolidations such as SFW or JDS?

(seems like the FOSS checklist needs some guidance on that front..)

					- Bill


  </pre>
</blockquote>
I think I missed something here.&nbsp; This is targeting the sfw
consolidation.<br>
<br>
The project team currently consists of 1 person.. me, and I only have
an inbound<br>
OSR.&nbsp; I was under the impression that I would be required to provide
support for this<br>
project.&nbsp; If there are specific enhancements you would like to see,
please let me know.<br>
<br>
Yes, this is older software, but it works well.&nbsp; I have been using it
for more than 7 years<br>
at Sun, and thought it would be a good thing to share with our users.<br>
<br>
thanks<br>
Charles<br>
<br>
</body>
</html>

--Boundary_(ID_zcM75T8eh+0weeqgSxQ1cQ)--

From danek.duvall@Sun.COM Tue Apr 22 21:03:44 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3N43hsI016375
	for <LSARC-ext@sac.sfbay.sun.com>; Tue, 22 Apr 2008 21:03:44 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3N43WSI016517
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 23 Apr 2008 05:03:42 +0100 (BST)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZR00501FA38C00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Tue, 22 Apr 2008 22:03:39 -0600 (MDT)
Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZR001CBFA3AT20@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue,
 22 Apr 2008 22:03:39 -0600 (MDT)
Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40])
	by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m3N43cxK019593; Tue, 22 Apr 2008 21:03:38 -0700 (PDT)
Received: from zruty.sfbay.sun.com (localhost [127.0.0.1])
	by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3N43cTf016552; Tue,
 22 Apr 2008 21:03:38 -0700 (PDT)
Received: (from dduvall@localhost)
	by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m3N43csx016551; Tue,
 22 Apr 2008 21:03:38 -0700 (PDT)
Date: Tue, 22 Apr 2008 21:03:38 -0700
From: Danek Duvall <danek.duvall@Sun.COM>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <480E7384.9030601@Sun.Com>
To: John Plocher <John.Plocher@Sun.COM>
Cc: lsarc-ext@Sun.COM
Message-id: <20080423040338.GN2543@zruty.sfbay.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.4.1.325704
References: <200804222254.m3MMsoTB021720@marduk.eng.sun.com>
 <480E7384.9030601@Sun.Com>
User-Agent: Mutt/1.5.16 (2007-06-27)
Status: RO
Content-Length: 863

On Tue, Apr 22, 2008 at 04:23:48PM -0700, John Plocher wrote:

> Seriously.  If we don't ever intend to put any engineering effort
> into these things to make them work [at all, better, as expected]
> on OpenSolaris, we shouldn't be mixing them into the core OS source
> tree (aka the ON consolidation)!

*Please* stop conflating the OS with ON.  There are plenty of core
technologies outside of ON, and there are plenty of non-core technologies
*in* ON.  Likewise, there is plenty of engineering effort going on in other
consolidations, and there are plenty of parts of ON that are suffering from
lack of any effort at all.

I'm quite sure that axyftp wasn't targeting ON.  While most of the Sun
folks here understand that, and know what consolidations are and what the
general boundaries are, not everyone else does.  Please stop confusing
them.

Thanks,
Danek

From Joerg.Barfurth@sun.com Fri Apr 25 07:42:43 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3PEggBG025972
	for <LSARC-ext@sac.sfbay.sun.com>; Fri, 25 Apr 2008 07:42:42 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3PEgbTg015527
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Apr 2008 15:42:41 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZV00H01Y74PC00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@Sun.COM); Fri, 25 Apr 2008 07:42:40 -0700 (PDT)
Received: from gmp-eb-inf-2.sun.com ([192.18.6.24])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZV00D2EY7311D0@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Fri,
 25 Apr 2008 07:42:39 -0700 (PDT)
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12])
	by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3PEgcJl023832	for
 <lsarc-ext@Sun.COM>; Fri, 25 Apr 2008 14:42:38 +0000 (GMT)
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JZV00L01XW41900@fe-emea-10.sun.com>
 (original mail from Joerg.Barfurth@Sun.COM)
 for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri,
 25 Apr 2008 15:42:38 +0100 (BST)
Received: from [10.16.66.63] by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JZV00NUHY6Z3D10@fe-emea-10.sun.com>; Fri,
 25 Apr 2008 15:42:35 +0100 (BST)
Date: Fri, 25 Apr 2008 16:42:35 +0200
From: Joerg Barfurth <Joerg.Barfurth@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
Sender: Joerg.Barfurth@sun.com
To: Gary Winiger <gww@eng.sun.com>
Cc: John.Plocher@sun.com, David.Comay@sun.com, lsarc-ext@sun.com
Message-id: <4811EDDB.5060201@sun.com>
Organization: Sun Microsystem - Desktop
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
X-PMX-Version: 5.4.1.325704
References: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
Status: RO
Content-Length: 964

Gary Winiger schrieb:

>> Seriously.  If we don't ever intend to put any engineering effort
>> into these things to make them work [at all, better, as expected]
>> on OpenSolaris, we shouldn't be mixing them into the core OS source
>> tree (aka the ON consolidation)!
> 
> 	I don't believe axyftp was proposed for the ON consolidation.
> 	In fact, not that it's really architecturally relevant, 
> 

Would this not be architecturally relevant, if the case is importing 
Volatile or Consolidation Private interfaces? This case does import 
Volatile interfaces (the dated 1.2 versions of GTK+,glib,gdk).

I do note that the checklist says
     Volatile - use check list for approval
but can't find a specific checklist for this.

- Jörg

-- 
Joerg Barfurth
Software Engineer        mailto:joerg.barfurth@sun.com
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/



From Sebastien.Roy@sun.com Fri Apr 25 08:27:38 2008
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3PFRcCc027014
	for <LSARC-ext@sac.sfbay.sun.com>; Fri, 25 Apr 2008 08:27:38 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3PFRbZX016391
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Apr 2008 09:27:38 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JZW00I0B0A1B800@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 25 Apr 2008 08:27:37 -0700 (PDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JZW00BIZ0A1M680@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 25 Apr 2008 08:27:37 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3PFRbM9005795	for
 <lsarc-ext@sun.com>; Fri, 25 Apr 2008 15:27:37 +0000 (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 <0JZV00301ZW15M00@mail-amer.sun.com>
 (original mail from Sebastien.Roy@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 25 Apr 2008 09:27:37 -0600 (MDT)
Received: from [129.148.174.103] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JZW00K6509WKFD0@mail-amer.sun.com>; Fri,
 25 Apr 2008 09:27:33 -0600 (MDT)
Date: Fri, 25 Apr 2008 11:27:32 -0400
From: Sebastien Roy <Sebastien.Roy@sun.com>
Subject: Re: [Fwd: Re: axyftp [LSARC/2008/271 Self Review]]
In-reply-to: <4811EDDB.5060201@sun.com>
Sender: Sebastien.Roy@sun.com
To: Joerg Barfurth <Joerg.Barfurth@sun.com>
Cc: Gary Winiger <gww@eng.sun.com>, John.Plocher@sun.com, lsarc-ext@sun.com
Message-id: <1209137252.17959.28.camel@strat>
Organization: Sun Microsystems
MIME-version: 1.0
X-Mailer: Evolution 2.22.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804222354.m3MNs9ig021908@marduk.eng.sun.com>
 <4811EDDB.5060201@sun.com>
Status: RO
Content-Length: 912

On Fri, 2008-04-25 at 16:42 +0200, Joerg Barfurth wrote:
> Gary Winiger schrieb:
> 
> >> Seriously.  If we don't ever intend to put any engineering effort
> >> into these things to make them work [at all, better, as expected]
> >> on OpenSolaris, we shouldn't be mixing them into the core OS source
> >> tree (aka the ON consolidation)!
> > 
> > 	I don't believe axyftp was proposed for the ON consolidation.
> > 	In fact, not that it's really architecturally relevant, 
> > 
> 
> Would this not be architecturally relevant, if the case is importing 
> Volatile or Consolidation Private interfaces? This case does import 
> Volatile interfaces (the dated 1.2 versions of GTK+,glib,gdk).

This is simply more evidence to back up the already stated assertion,
which is that this is out-dated, poorly integrated software.  So much
for "modernization", which I thought was the point of the overall
exercise.

-Seb



From sacadmin Wed Apr 30 08:50:39 2008
Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3UFodeY014707
	for <LSARC@sac.sfbay.sun.com>; Wed, 30 Apr 2008 08:50:39 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3UFoc4f002714
	for <LSARC@sac.sfbay.sun.com>; Wed, 30 Apr 2008 08:50:38 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3UFocaQ004087
	for <LSARC@sac.sfbay.sun.com>; Wed, 30 Apr 2008 15:50:38 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 <0K0500801A6SA400@mail-amer.sun.com>
 (original mail from Mark.Carlson@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed,
 30 Apr 2008 09:50:38 -0600 (MDT)
Received: from Macintosh-39.local ([71.237.94.98])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0K0500FO7ANHHG50@mail-amer.sun.com>; Wed,
 30 Apr 2008 09:50:06 -0600 (MDT)
Date: Wed, 30 Apr 2008 09:50:04 -0600
From: "Mark A. Carlson" <Mark.Carlson@Sun.COM>
Subject: Re: axyftp [LSARC/2008/271 Self Review]
In-reply-to: <200804222121.m3MLLqe3021492@marduk.eng.sun.com>
Sender: Mark.Carlson@Sun.COM
To: LSARC@sac.sfbay.sun.com
Cc: Mike.Sullivan@Sun.COM, Mark.Phalan@Sun.COM,
        Holly Vergara <Holly.Costanza@Sun.COM>,
        Charles Baker <Charles.Baker@Sun.COM>
Message-id: <4818952C.4080308@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200804222121.m3MLLqe3021492@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Status: RO
Content-Length: 185

The project team having responded to additional materials requests, this 
case remains
closed approved automatic unless someone wants to derail it to fast 
track or full case.

-- mark