LSARC, This case could have been automatically approved as a Familiarity case if it hadn't been for the fact that it does not support IPv6. Is the committee OK with the project not supporting IPv6?
Thanks, John Alan Coopersmith wrote: > I am sponsoring this case for Stuart Kreitman of the X team. > The timeout is set for next Monday, Sept. 21, 2009. > > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering > > FCL--FOSS Check List > 0. Introduction > 0.1 Document History > Version Author Changes > Date > 0.1 John Fischer Initial Draft > 01/11/2008 > 0.2 John Fischer Modified based upon feedback from ARC > members 01/29/2008 > 0.3 John Fischer Modified based upon feedback during > committee 02/12/2008 > review > 0.4 John Fischer Modified based upon SAC review feedback > 04/01/2008 > 0.5 John Fischer Modified based upon LSARC business > meeting 06/10/2008 > adding familiarity question and mod dates. > 0.6 John Fischer Modified based upon user feedback about > 06/20/2008 > sections that were unanswerable. > > 0.2 Purpose > Architecture review at Sun has allowed the company to evolve our projects > within multiple disjoint groups while still maintaining a cohesive product > line. Each architecture review was conducted within Sun's control. With > the advent of Free Open Source Software processes the control that Sun as > a company can wield has been diminished. Now that Sun is moving to a more > fluid delivery mechanism with project Indiana we need to evolve the > architecture review process. This document is meant to aid in the > architecture review process. Each new project must complete this check > list > to help ensure that the overall resulting product conforms to Sun product > standards. If the project deviates from these standards further review > would be necessary by an architecture review committee. > > After the check list is completed the project team should be able to > determine if a project can be automatically approved. This will occur > if all checks result in no "ARC review required" answers. A committee > member will assist the project team in filing the automatically approved > fast track. An automatically approved fast track is still required in > order > to record the interfaces for future reference. If the project needs to > have further review then follow the regular process for getting projects > reviewed. > > 1.0 Project Information > 1.1 Name of project/component > Synergy - Mouse/Keyboard sharing > 1.3.1, April 02-2006 > > 1.2 Author of document > Stuart Kreitman > > 2.0 Project Summary > 2.1 Project Description > Synergy lets you easily share a single mouse and keyboard between > multiple computers with different operating systems, each with its own > display, without special hardware. It's intended for users with multiple > computers on their desk since each system uses its own monitor(s). > > Redirecting the mouse and keyboard is as simple as moving the mouse off the > edge of your screen. Synergy also merges the clipboards of all the systems > into one, allowing cut-and-paste between systems. Furthermore, it > synchronizes screen savers so they all start and stop together and, if screen > locking is enabled, only one screen requires a password to unlock them all. > > 2.2 Release binding > What is is the release binding? > (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) > [ ] Major > [X] Minor > [ ] Patch or Micro > [ ] Unknown -- ARC review required > > 2.3 Type of project > Is this case a Linux Familiarity project? > [X] Yes > [ ] No > > 2.4 Originating Community > 2.4.1 Community Name > Synergy is hosted on Sourceforge. http://synergy2.sourceforge.net > > 2.4.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 > [ ] N/A > > Are these components already in the Solaris WOS? > [ ] Yes > [ ] No - continue with next section (section 3.2) > > 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 Exported Libraries > Are libraries being delivered by this project? > [ ] Yes > [X] No - continue with next section (section 3.3) > > Are 64-bit versions of the libraries being delivered? > [ ] Yes > [ ] No - ARC review required > > Are static versions of the libraries being delivered? > [ ] Yes - ARC review required > [ ] 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 there any network services provided by this project? > [X] Yes > [ ] No - continue with the next section (section 3.4.2) > > 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 > [X] No - ARC review required > [ ] N/A > > Is inbound data checked to prevent content-based attacks? > [ ] Yes > [X] No - ARC review required > [ ] N/A > > Is the outbound receiver authenticated? > [ ] Yes > [X] No - ARC review required. > Synergy provides no security, but can be configured to run > through ssh. > See http://synergy2.sourceforge.net/security.html > [ ] N/A > > Is the receiver authenticated prior to receiving any sensitive outbound > communication? > [ ] Yes > [X] No - ARC review required > See above > [ ] 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 (section 3.4.3) > > 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 (section 3.4.4) > > (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 (section 3.4.5) > > 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? > [ ] Yes > [X] No - continue to next section (section 3.4.6) > > If yes are these passwords entered via the CLI or environment? > [ ] Yes - ARC review required > [ ] No > > Are passwords stored within the file system for the component? > [ ] Yes > [ ] No - continue to next section (section 3.4.6) > > If yes are the permissions on the file such to protect exposing the > password(s)? > [ ] Yes > [ ] No - ARC review required > > 3.4.6 General Security Questions > (see > http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for > details) > Are there any network protocols used by this project? > [X] Yes > [ ] No - continue with the next section (section 3.5) > > 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? > [ ] Yes - explain below > [X] No > [ ] N/A > > Do the components make use of secret information during authentication > and/or > authorization? > [ ] Yes - explain below > [X] No > [ ] N/A > > 3.5 Networking > Do the components access the network? > [X] Yes > [ ] No - continue with the next section (section 3.6) > > If yes do the components support IPv6? > [ ] Yes > [X] 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 > --------------------------- ------------------- > --------------------------- > synergys(1) Committed version 1.3.1 > synergyc(1) Committed version 1.3.1 > > 4.2 Imported Interfaces > Interface Name Classification Comments > --------------------------- -------------------- > -------------------------- > > > Brief Interface Classifications - See Appendix C for definitions > Volatile - interfaces are fluid and will follow a rapidly changing > community > Uncommitted - interfaces are still evolving in the community and might > follow > the community > Committed - interfaces are stable in the community > Project Private - no review required, just document 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: > X Consolidation (Desktop C-Team) > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open >
