The plane isn't the target. Sure, if someone blew up an unoccupied airplane sitting in a hangar somewhere there'd be people mad about it - but as long as there's little danger to the common man, nobody but the insurance agent *really* cares. The true terror target is the people on the plane. Airplanes are effective since there's a few hundred people in a pretty confined space and those people have very little chance of surviving even a moderately successful attack.
So all these security measures will theoretically make it impossible to get anything dangerous on a plane, which is great. But it seems to me we've created another target with the same characteristics - the hundreds of people standing in a queue to go through the screening machines. In fact, there's probably more people in queue at rush times than there are on a single plane, and they're closer together. And there's no real defense since any non-instant bomb detection is sure going to result in long lines.
Kind of ironic that we spend all this time and effort to protect ourselves but wind up creating an even juicier target.
Robertson's argument is, "It's a work in progress. We're hopeful our first release will happen around the middle of the year. When we release an official version, all the GPL pieces will be properly distributed".
There is no clause in the GPL saying, "This license only applies to official release software. Betas are exempt." A binary release is a binary release.
If the beta tag is enough to circumvent the GPL, what's to stop companies from following the ICQ plan: everything is a beta. Despite being around for years and having (relatively) stable software and user-friendly feature set, ICQ remains "Beta" and is likely to do so forever.
The key words in articles 3a, 3b, and 3c of the GPL are "Accompany it." This means accompany *every binary release* with the source (or a link to get it) at the time of release, not promise to provide it later.
that the developers who were working with the product, under the assurance that it was Open Source Software, never really got the source code. All they got were promises that they'd get the source code Real Soon Now.
Not much you can do, when you've got no source code to use under the EPL. Just move on and use someone else's product.
Get a bunch of people working on the same project, and keep track of who did what, and when? That's pretty close to the project goal of CVS. Just have each class member log into a CVS repository to make their code changes and commits. Then, an audit of the history would show who did what, and who didn't.
I use it here at work to see which of our production artists screws up my ASP/PHP code with their WYSIWYG HTML editor the most often, and then, of course, fix it.:)
I have to say that I can't see how this affects anyone.
Those that want to use Linux, use Linux. Those that don't, don't.
There is no war to win. Linux cannot die as long as there's someone interested in keeping it alive. There's no reason we have to 'win the war for the desktop' today or next week, or next year. There's no endgame where all the scores are tallied and a victor is announced.
As linux becomes easier for Joe User to get around in and be productive in, it will gain market share. And if it doesn't, it's still a heck of a server platform. It may not be great on the desktop today but in a year? two years? There's nothing to prevent it from being great.
There's no way to 'lose the war' until the product is dead, and there's no way to kill this product. We can't lose as long as we try.
If I send the people that make these things a letter, and in that letter, include my address and the following notice:
"This letter contains valuable marketing material in the form of my name and address. By opening this letter you have agreed to send me 15% of your company's annual revenue in exchange for this information."
Sure, it's outrageous, but what's the difference between their shrinkwrap licenses and this, except direct monetary compensation?
None, methinks. So I think I'm gonna produce some letters in short order.:)
The following text identifies specific criteria that must be satisfied for DII COE Kernel Platform certification.
To the extent that automated test suites can verify satisfaction of a subset of these criteria, submission of certificates from recognized testing organizations shall be considered sufficient evidence of conformance. For manual procedures, submission of valid and successful test results shall be considered sufficient evidence of conformance. For many criteria, applicant claim of satisfaction may be accepted, with the provision that if found to be in error, the vendor applicant will bring the application platform into compliance within 180 calendar days in accordance with the provisions of section 2.5, "Changes in DII COE Kernel Platform Certification Status". Detailed definition of procedures and decision criteria are found in the referenced specifications and appendices.
In addition to the all other criteria defined below, the applicant vendor shall ensure that the application platform, as configured for DII COE Kernel Platform Certification is Year 2000 compliant. Year 2000 compliant means that the submitted application platform accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations. Furthermore, Year 2000 compliant information technology, when used in combination with other information technology, shall accurately process date/time data if the other information technology properly exchanges date/time data with it.
3.1 Integration and Run-Time Specification (I&RTS) Certification Criteria
The DII COE platform must comply with relevant I&RTS requirements applicable to the 8 levels of conformance. These criteria include all platform specific requirements in the document, with emphasis on those identified in the checklist for I&RTS Appendix B.
The specific I&RTS Appendix B criteria applicable to the DII COE Kernel Platform Certification Program are listed in Appendix B of this document. In most cases, the requirement is copied verbatim from the I&RTS. In some cases the text reflects an interpretation, either to clarify the aspect of the I&RTS requirement that applies to the application platform, or to make explicit an implied requirement. In all cases, no modification of the I&RTS requirement is intended, and where conflict arises, the current version of the I&RTS shall have precedence.
DII COE Kernel Platform Certification requires the application platform implementation to be in conformance with the following specifications. Supporting documentation requirements are identified in Appendix C of this document. Citations below are drawn from "Department of Defense Joint Technical Architecture", Version 1.0, 22 Aug 1996 .
The following standards contain provisions which, through direct references in this text, constitute criteria for DII COE Kernel Platform Certification. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties of interest are encouraged to investigate the applicability of the most recent editions of the standards listed below. However, DII COE Kernel Platform Certification criteria include conformance only to the specific versions listed below.
Application Program Interface
The application platform implementation shall be in conformance with the following Application Program Interface specifications. An application executing on the application platform implementation shall have simultaneous access to all services associated with the following standards:
Operating System API
The following standards are required:
ISO/IEC 9945-1: 1996, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 1: System Application Program Interface (API) [C language]*, (as profiled by FIPS PUB 151-2: 1994)
Communications Service API
IEEE 1003.1g: 1996 Draft 6.6, POSIX - Part 1: System Application Program Interface (API) Amendment 2: Protocol Independent Interfaces (Sockets) [C Language]*, Sockets portion only
Human computer Interaction API
FIPS Pub 158-1: 1993, User Interface Component of the Application Portability Profile X-Windows Version 11, Release 5
OSF Motif Application Environment Specification (AES), Release 1.2, 1992
X/Open C323, Common Desktop Environment (CDE); XCDE Services and Applications - Version 1.0, April 1995.
X/Open C324, Common Desktop Environment (CDE); XCDE Definitions and Infrastructure - Version 1.0, April 1995.
Note: * - The reference to C Language is part of the formal title of these standards. It denotes the language used to define the standard.
Human Computer Interface
The application platform implementation shall be in conformance with the following Human Computer Interface specifications:
OSF/Motif Style Guide, Revision 1.2 (OSF 1992).
OSF/Motif Inter Client Communications Convention Manual (ICCCM) for communication between Graphical User Interface (GUI) client applications
ISO 9945-2: 1993, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 2: Shell and Utilities, (as profiled by FIPS PUB 189: 1994)
Communications Service Interface
The application platform implementation shall be in conformance with the following Communications Service Interface specifications:
IETF Standard 7/RFC-793, Transmission Control Protocol, 1 September 1981. In addition, TCP shall implement the PUSH flag and the Nagle Algorithm, as defined in IETF Standard 3.
RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 24, 1997
IETF Standard 6/RFC-768, User Datagram Protocol, 28 August 1980.
IETF Standard 5/ RFC-791/RFC-950/RFC-919/RFC-922/RFC-792/RFC-1112,, Internet Protocol, 1 September 1981. In addition, all implementations of IP must pass received Type-of-Service (TOS) values up to the transport layer.
IETF Standard 13/RFC-1034/RFC-1035, Domain Name System, 1 November 1987.
IETF Standard 9/RFC-959, File Transfer Protocol, 1 October 1985, with the following FTP commands mandated for reception: Store unique (STOU) and Abort (ABOR).
IETF Standard 8/RFC-854/RFC-855, TELNET Protocol, 1 May 1983.
IETF Standard 15/RFC-1157, Simple Network Management Protocol (SNMP), 10 May 1990.
IAB Standard 16/ RFC-1155, RFC-1212, Structure of Management Information, May 1990.
IAB Standard 17/RFC-1213, Management Information Base-II (MIB), 26 March 1991.
IETF RFC 1757, Remote Network Monitoring Management Information Base, 10 February, 1995.
RFC-951, Bootstrap Protocol, September 1, 1985.
RFC-1533, DHCP Options and BOOTP Vendor Extensions, October 8, 1993.
RFC-1541, Dynamic Host Configuration Protocol, October 27, 1993.
RFC-1542, Clarifications and Extensions for the Bootstrap Protocol, October 27, 1993.
RFC-1305, Network Time Protocol (V3), April 9, 1992.
3.3 Government Supplied Software Certification Criteria
Government supplied source code is provided which implements functionality not available on many commercial platforms. Government supplied source code implementation also assures that human-computer interfaces are functionally identical across multiple application platforms. This tends to reduce training cost and potential for operator error.
The following software elements described in "DII COE Baseline Specifications" [2] are currently implemented by government supplied source code, and must be ported by the applicant to the candidate application platform. The full set of tools called for in the DII COE I&RTS [1] are not yet implemented, and the set of Government supplied source code base will expand as more tools become available. The current set of software elements, as described in reference [1], includes:
Printing Services
Print Services 1.0 Provide the basic heterogeneous print capability of the system. It provides such functions as user selection of a default printer, printer administration, and a common way of accessing print resources from an application program. It also includes print queue management and remote printer administration.
Security Management Services
Deadman 1.2 Locks the user's terminal if the keyboard and mouse have been idle for longer than a configurable time, defaulting to 5 minutes.
Console 1.2 Provides a read-only console window for the use of applications which need it to display output written to stdout.
Password Allows users to change their own passwords in accordance with established guidelines.
X Display Manager (XDM) An element of the X-window system which controls access to the system from the login screen. This software element is a modified version of the publicly available implementation.
Note: Government supplied Security Management Services are written in the C programming language, and contains approximately 90,000 lines of source code. Approximately 15,000 lines of code are associated with XDM.
System Management Services
Account Groups & Profiles Used to set profile configuration, create or edit local and global user profiles, and create or edit local and global user accounts. The security administrator's account group sets the security administrator's environment in order to execute the profiles and accounts. The Security Administration function also provides a facility to update internal profile and user account data structures through command line programs.
Executive Manager 1.1 Establishes session characteristics during initiation of a DII session based on user-selected roles.
Note: The government supplied "System Management Services" source code is written in the C Programming language, and contains approximately 6500 lines of source code.
DII COE Run-Time Tools
The system administrator uses the COE Runtime Tools support to install, configure, and de-install systems. The tools also provide the developers with a means to communicate with the operator during segment installation. These tools include:
COEAskUser Display a message to the user, and have the user click on a button (Yes/No, True/False, Accept/Cancel, etc.) in response to the message.
COEFindSeg Return information about a requested segment. The tool sets status and writes the pathname, segment name, segment prefix, and segment type information to stdout.
COEInstaller Display a list of variants or segments that may be installed from tape, disk, or other electronic media. It is normally executed by an operator who selects it from a System Administrator menu to install or de-install segments.
COEInstError Display an error message to the user from within a Pre-Install, Post-Install, or De-Install script signaling installation termination or de-installation of the segment.
COEMsg Display a message to the user and have the user click on the "OK" button to continue. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEPrompt Display a message to the user and have the user enter a response to the message. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEPromptPasswd Prompt user to enter a password. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEUpdateHome Update the home environment variable within a script file to point to where a segment was actually installed.
DII COE Developers Tools
DII COE Developers' Tools support application software development and delivery, but are not delivered to operational sites. All interfaces to these tools are at the command line; none of them have a GUI interface. These tools include:
CalcSpace computes the space required for the segment specified and updates the hardware descriptor accordingly. The segment referred to must not be compressed and must not contain any files that do not belong with the segment (e.g., source code) at run-time. The amount of space required is written to stdout in K bytes.
CanInstall tests a segment to see if it can be installed, which means that all required segments must already be on the disk, and the disk cannot have any conflicting segments.
ConvertSeg examines segment descriptors and converts them to the latest format. The original segment descriptor directory is not modified. The output is in a directory created by the tool and called SegDescrip.NEW. This directory will be located directly underneath the segment's home directory at the same level as SegDescrip. ConvertSeg is not location sensitive and may be moved to any directory desired for development.
MakeAttribs creates the descriptor file FileAttribs. It recursively traverses every subdirectory beneath the segment home directory and creates a file containing permits, owner, group, and filename information.
MakeInstall writes one or more segments to an installation medium, or packages the segments for distribution over the SIPRNET. MakeInstall checks to see if VerifySeg has been run successfully on each of the segments, and aborts with an error if it has not.
TestInstall temporarily installs a segment that already resides on disk. There must be no other COE processes running when TestInstall is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.
TestRemove removes a segment that was installed by TestInstall. There must be no other COE processes running when TestRemove is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.
TimeStamp puts the current time and date into the VERSION descriptor.
VerifySeg validates that a segment conforms to the rules for defining a segment. It uses information in the SegDescrip subdirectory and must be run whenever the segment is modified.
VerUpdate updates the segment version number, date, and time in the VERSION descriptor.
Government supplied source code includes approximately 175,000 lines of C programming language code.
To assess the degree of satisfaction of the functional requirements associated with the government supplied software, functional testing of the applicant port or implementation is required. Any available automated and manual testing of COE kernel government supplied software will be provided to aid in assuring proper function. Appendix D identifies applicable test technology, manual test procedures, and acceptance criteria.
3.4 Security Certification Criteria
This document identifies security-related criteria for DII COE Kernel Platform certification. Service, agency and system unique requirements are outside the scope of this document, as are the overall security requirements of systems built using DII COE Kernel Platforms. These criteria are drawn from "Defense Information Infrastructure (DII) Common Operating Environment (COE) Security Software Requirements Specification (SRS)", Version 2.0 - 8 July 1996 .
This evaluation verifies the presence and configuration of basic DII COE Kernel Platform security features and capabilities as identified in Appendix E of this document. These security features and capabilities are grouped into the following categories:
1. Identification and Authentication (I&A)
2. Security Audit
3. Service Availability
4. Discretionary Access Control
5. Object Reuse
6. Data Integrity
7. System Integrity
8. System Architecture
9. Trusted Facility Management
10. Other Requirements
DII COE Kernel Platform Certification security evaluation and criteria supporting DII COE Kernel Platform Certification does not replace or satisfy security testing required by Department of Defense Directive 5200.28 (1988).
The vendor applicant will also develop and deliver a security checklist as an aid in assuring that the candidate application platform satisfies the security criteria in Appendix E, Part 1. A sample security checklist specifically developed for the Solaris 2.4 DII COE platform is provided to applicants in part 2 of Annex E to accelerate the process of checklist development.
DISA security personnel will evaluate the suitability of the checklist provided by the vendor. This evaluation will be performed by the government at no charge to the vendor applicant. If the checklist is found to be an functionally equivalent to the existing checklist, and an effective method for demonstrating satisfaction of the criteria in Appendix E, the checklist will be accepted. The checklist for this platform will then be executed to assure that the application platform implements those features and capabilities.
Issue: Evaluation of the security checklist will be time and skill intensive.
3.5 Internet Interoperability Demonstration Certification Criteria
These simple demonstrations provide a basic, yet cost-effective, verification of TCP/IP interoperability, and basic BSD sockets API support. They also provide assurance of application level interoperability for several key services and protocols, such as File Transfer Protocol (FTP) and Hyper-Text Transfer Protocol (HTTP). The scope of each test is limited, but DISA investment in more formal testing can be made over time to expand the scope of assurance, as needed. Test plans in Appendix F are used to demonstrate that the candidate application platform supports the following capabilities:
TCP/IP "Ping" Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides an initial assurance of application level interoperability prior to demonstration of other services and protocols.
The Ping utility sends a request for simple acknowledgment and displays the result to the user. is used to assure connectivity to a DISA remote validation platform.
Domain Name Service (DNS) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Domain Naming Service (DNS) services and protocols.
This demonstration shows that hostnames are resolved via DNS and can be converted from standard format to DNS format.
File Transfer Protocol (FTP) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key File Transfer Protocol (FTP) services and protocols.
The demonstration suite for FTP uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. Test files located on the remote DISA test platform are transferred to the candidate, and key FTP capabilities are exercised from the candidate platform. Test files located on the candidate platform are then transferred to the remote DISA test platform, and key FTP capabilities are exercised from the remote platform.
Network File System (NFS) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Network File System (NFS) services and protocols.
The demonstration suite for NFS uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. A volume located on the remote DISA test platform is mounted on the local platform under test, and key NFS capabilities are exercised from the candidate platform. A volume located on the candidate platform is then mounted on the remote DISA test platform, and key NFS capabilities are exercised from the remote platform.
Electronic Mail Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Simple Mail Transport Protocol (SMTP) services and protocols.
The demonstration of SMTP electronic mail uses the 'mailx' commands required by the ISO/IEC 9945-2 (Posix) specification. An electronic mail message is read in from a file, sent to a mail reflector located on a DISA supplied test platform, and is reflected back to the platform under test. The returned message is displayed and saved to a file. This provides some level of assurance that the candidate platform can support both sending and receipt of electronic mail.
World Wide Web (WWW) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Hyper-Text Transfer Protocol (HTTP) services and protocols.
The demonstration of WWW services uses an HTTP 1.0 conforming browser to retrieve a series of HTML 3.2 conforming web pages to and display them on the application platform being certified. The test pages exercise key Hyper-Text Markup Language (HTML), HTTP and forms related capabilities.
Note: The browser is supplied by the vendor as part of the validation suite, not as part of the kernel platform software.
A VPN is a virtual LAN - allowing your computer to tunnel traffic to another point on the internet and exchange traffic as if you were on the same local network.
What you describe could be termed as NAT or PAT, or IP masquerade.
Although I agree that it's stupid to forbid VPN no matter which definition you apply.:)
If in fact this is a hoax, what right does Apple have to ask that it be taken down? After all, it's not revealing what their trade secrets *are*, but rather, what they *aren't*. Which, I suppose, can be equally damaging in the right situations.
Perhaps one tactic they could use is to protest the misuse of the Apple logo.
Not having seen the letter, this is all pure speculation.
on everything, but it looks like they were quick to silence this article (unless it's a freak accident on./'s end...).
Anyone care to clue me in on what it was about? I think I've got the jist of it, but I'd like to make sure. (Gov't trying to restrict weak encryption within our borders as well?)
If the court decides in Universal's favor, wouldn't that mean that I could no longer tell my froend Steve to look at page 45 in the latest edition of XYZ Magazine? After all, I'm looking at copyrighted material, skipping past all the ads and b.s. they sprinkle throughout, and I could even loan Steve the magazine so he wouldn't have to pay for it!
I suppose they'd wanna give me 10 years for a violation so gross.
And what about bibliographies? I write a research paper 70 pages long and reference Book.Q by Author.Z, page 125. Same concept?
A link is a link. Whether I link to domain.com or domain.com/foo/bar/baz/quux/quuux/null.htm, the link is entirely my property (I wrote the HTML independently of any content they may have). It's hosted on my page. With the code I write there, I'm not violating any copyrights, nor am I depriving them of revenue (I'm sending someone to/their/ website to view material that is profitable, not to me, but to them).
I agree that tags directly to their server is copyright infringement (like cutting out a picture from a XYZ magazine and using it in my own magazine) but if I link to their page, unedited, its their responsibility to incorporate their corporate identity.
What the lawyers need (it seems) to realize is that link != duplicate. Without duplication, there is no copyright infringement. Dictionary.com reports the following definition of copyright:
The right of an author or his assignee, under statute, to print and publish his literary or artistic work, exclusively of all other persons.
A link neither prints nor publishes. Therefore, it's not copyright infringement.
I rest my case. (besides, my fingers are tired, and I need a beer.:)
Slashdot Mirror
The plane isn't the target. Sure, if someone blew up an unoccupied airplane sitting in a hangar somewhere there'd be people mad about it - but as long as there's little danger to the common man, nobody but the insurance agent *really* cares. The true terror target is the people on the plane. Airplanes are effective since there's a few hundred people in a pretty confined space and those people have very little chance of surviving even a moderately successful attack.
So all these security measures will theoretically make it impossible to get anything dangerous on a plane, which is great. But it seems to me we've created another target with the same characteristics - the hundreds of people standing in a queue to go through the screening machines. In fact, there's probably more people in queue at rush times than there are on a single plane, and they're closer together. And there's no real defense since any non-instant bomb detection is sure going to result in long lines.
Kind of ironic that we spend all this time and effort to protect ourselves but wind up creating an even juicier target.
Robertson's argument is, "It's a work in progress. We're hopeful our first release will happen around the middle of the year. When we release an official version, all the GPL pieces will be properly distributed".
There is no clause in the GPL saying, "This license only applies to official release software. Betas are exempt." A binary release is a binary release.
If the beta tag is enough to circumvent the GPL, what's to stop companies from following the ICQ plan: everything is a beta. Despite being around for years and having (relatively) stable software and user-friendly feature set, ICQ remains "Beta" and is likely to do so forever.
The key words in articles 3a, 3b, and 3c of the GPL are "Accompany it." This means accompany *every binary release* with the source (or a link to get it) at the time of release, not promise to provide it later.
-e
that the developers who were working with the product, under the assurance that it was Open Source Software, never really got the source code. All they got were promises that they'd get the source code Real Soon Now.
Not much you can do, when you've got no source code to use under the EPL. Just move on and use someone else's product.
-e
Get a bunch of people working on the same project, and keep track of who did what, and when? That's pretty close to the project goal of CVS. Just have each class member log into a CVS repository to make their code changes and commits. Then, an audit of the history would show who did what, and who didn't.
:)
I use it here at work to see which of our production artists screws up my ASP/PHP code with their WYSIWYG HTML editor the most often, and then, of course, fix it.
-e
I have to say that I can't see how this affects anyone.
Those that want to use Linux, use Linux. Those that don't, don't.
There is no war to win. Linux cannot die as long as there's someone interested in keeping it alive. There's no reason we have to 'win the war for the desktop' today or next week, or next year. There's no endgame where all the scores are tallied and a victor is announced.
As linux becomes easier for Joe User to get around in and be productive in, it will gain market share. And if it doesn't, it's still a heck of a server platform. It may not be great on the desktop today but in a year? two years? There's nothing to prevent it from being great.
There's no way to 'lose the war' until the product is dead, and there's no way to kill this product. We can't lose as long as we try.
-e
I gotta wonder:
:)
If I send the people that make these things a letter, and in that letter, include my address and the following notice:
"This letter contains valuable marketing material in the form of my name and address. By opening this letter you have agreed to send me 15% of your company's annual revenue in exchange for this information."
Sure, it's outrageous, but what's the difference between their shrinkwrap licenses and this, except direct monetary compensation?
None, methinks. So I think I'm gonna produce some letters in short order.
The following text identifies specific criteria that must be satisfied for DII COE Kernel Platform certification.
, Internet Protocol, 1 September 1981. In addition, all implementations of IP must pass received Type-of-Service (TOS) values up to the transport layer.
To the extent that automated test suites can verify satisfaction of a subset of these criteria, submission of certificates from recognized testing organizations shall be considered sufficient evidence of conformance. For manual procedures, submission of valid and successful test results shall be considered sufficient evidence of conformance. For many criteria, applicant claim of satisfaction may be accepted, with the provision that if found to be in error, the vendor applicant will bring the application platform into compliance within 180 calendar days in accordance with the provisions of section 2.5, "Changes in DII COE Kernel Platform Certification Status". Detailed definition of procedures and decision criteria are found in the referenced specifications and appendices.
In addition to the all other criteria defined below, the applicant vendor shall ensure that the application platform, as configured for DII COE Kernel Platform Certification is Year 2000 compliant. Year 2000 compliant means that the submitted application platform accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations. Furthermore, Year 2000 compliant information technology, when used in combination with other information technology, shall accurately process date/time data if the other information technology properly exchanges date/time data with it.
3.1 Integration and Run-Time Specification (I&RTS) Certification Criteria
The DII COE platform must comply with relevant I&RTS requirements applicable to the 8 levels of conformance. These criteria include all platform specific requirements in the document, with emphasis on those identified in the checklist for I&RTS Appendix B.
The specific I&RTS Appendix B criteria applicable to the DII COE Kernel Platform Certification Program are listed in Appendix B of this document. In most cases, the requirement is copied verbatim from the I&RTS. In some cases the text reflects an interpretation, either to clarify the aspect of the I&RTS requirement that applies to the application platform, or to make explicit an implied requirement. In all cases, no modification of the I&RTS requirement is intended, and where conflict arises, the current version of the I&RTS shall have precedence.
3.2 Commercial Specification Certification Criteria
DII COE Kernel Platform Certification requires the application platform implementation to be in conformance with the following specifications. Supporting documentation requirements are identified in Appendix C of this document. Citations below are drawn from "Department of Defense Joint Technical Architecture", Version 1.0, 22 Aug 1996 .
The following standards contain provisions which, through direct references in this text, constitute criteria for DII COE Kernel Platform Certification. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties of interest are encouraged to investigate the applicability of the most recent editions of the standards listed below. However, DII COE Kernel Platform Certification criteria include conformance only to the specific versions listed below.
Application Program Interface
The application platform implementation shall be in conformance with the following Application Program Interface specifications. An application executing on the application platform implementation shall have simultaneous access to all services associated with the following standards:
Operating System API
The following standards are required:
ISO/IEC 9945-1: 1996, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 1: System Application Program Interface (API) [C language]*, (as profiled by FIPS PUB 151-2: 1994)
Communications Service API
IEEE 1003.1g: 1996 Draft 6.6, POSIX - Part 1: System Application Program Interface (API) Amendment 2: Protocol Independent Interfaces (Sockets) [C Language]*, Sockets portion only
Human computer Interaction API
FIPS Pub 158-1: 1993, User Interface Component of the Application Portability Profile X-Windows Version 11, Release 5
OSF Motif Application Environment Specification (AES), Release 1.2, 1992
X/Open C323, Common Desktop Environment (CDE); XCDE Services and Applications - Version 1.0, April 1995.
X/Open C324, Common Desktop Environment (CDE); XCDE Definitions and Infrastructure - Version 1.0, April 1995.
Note: * - The reference to C Language is part of the formal title of these standards. It denotes the language used to define the standard.
Human Computer Interface
The application platform implementation shall be in conformance with the following Human Computer Interface specifications:
OSF/Motif Style Guide, Revision 1.2 (OSF 1992).
OSF/Motif Inter Client Communications Convention Manual (ICCCM) for communication between Graphical User Interface (GUI) client applications
ISO 9945-2: 1993, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 2: Shell and Utilities, (as profiled by FIPS PUB 189: 1994)
Communications Service Interface
The application platform implementation shall be in conformance with the following Communications Service Interface specifications:
IETF Standard 7/RFC-793, Transmission Control Protocol, 1 September 1981. In addition, TCP shall implement the PUSH flag and the Nagle Algorithm, as defined in IETF Standard 3.
RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 24, 1997
IETF Standard 6/RFC-768, User Datagram Protocol, 28 August 1980.
IETF Standard 5/ RFC-791/RFC-950/RFC-919/RFC-922/RFC-792/RFC-1112,
IETF Standard 13/RFC-1034/RFC-1035, Domain Name System, 1 November 1987.
IETF Standard 9/RFC-959, File Transfer Protocol, 1 October 1985, with the following FTP commands mandated for reception: Store unique (STOU) and Abort (ABOR).
IETF Standard 8/RFC-854/RFC-855, TELNET Protocol, 1 May 1983.
IETF Standard 15/RFC-1157, Simple Network Management Protocol (SNMP), 10 May 1990.
IAB Standard 16/ RFC-1155, RFC-1212, Structure of Management Information, May 1990.
IAB Standard 17/RFC-1213, Management Information Base-II (MIB), 26 March 1991.
IETF RFC 1757, Remote Network Monitoring Management Information Base, 10 February, 1995.
RFC-951, Bootstrap Protocol, September 1, 1985.
RFC-1533, DHCP Options and BOOTP Vendor Extensions, October 8, 1993.
RFC-1541, Dynamic Host Configuration Protocol, October 27, 1993.
RFC-1542, Clarifications and Extensions for the Bootstrap Protocol, October 27, 1993.
RFC-1305, Network Time Protocol (V3), April 9, 1992.
3.3 Government Supplied Software Certification Criteria
Government supplied source code is provided which implements functionality not available on many commercial platforms. Government supplied source code implementation also assures that human-computer interfaces are functionally identical across multiple application platforms. This tends to reduce training cost and potential for operator error.
The following software elements described in "DII COE Baseline Specifications" [2] are currently implemented by government supplied source code, and must be ported by the applicant to the candidate application platform. The full set of tools called for in the DII COE I&RTS [1] are not yet implemented, and the set of Government supplied source code base will expand as more tools become available. The current set of software elements, as described in reference [1], includes:
Printing Services
Print Services 1.0 Provide the basic heterogeneous print capability of the system. It provides such functions as user selection of a default printer, printer administration, and a common way of accessing print resources from an application program. It also includes print queue management and remote printer administration.
Security Management Services
Deadman 1.2 Locks the user's terminal if the keyboard and mouse have been idle for longer than a configurable time, defaulting to 5 minutes.
Console 1.2 Provides a read-only console window for the use of applications which need it to display output written to stdout.
Password Allows users to change their own passwords in accordance with established guidelines.
X Display Manager (XDM) An element of the X-window system which controls access to the system from the login screen. This software element is a modified version of the publicly available implementation.
Note: Government supplied Security Management Services are written in the C programming language, and contains approximately 90,000 lines of source code. Approximately 15,000 lines of code are associated with XDM.
System Management Services
Account Groups & Profiles Used to set profile configuration, create or edit local and global user profiles, and create or edit local and global user accounts. The security administrator's account group sets the security administrator's environment in order to execute the profiles and accounts. The Security Administration function also provides a facility to update internal profile and user account data structures through command line programs.
Executive Manager 1.1 Establishes session characteristics during initiation of a DII session based on user-selected roles.
Note: The government supplied "System Management Services" source code is written in the C Programming language, and contains approximately 6500 lines of source code.
DII COE Run-Time Tools
The system administrator uses the COE Runtime Tools support to install, configure, and de-install systems. The tools also provide the developers with a means to communicate with the operator during segment installation. These tools include:
COEAskUser Display a message to the user, and have the user click on a button (Yes/No, True/False, Accept/Cancel, etc.) in response to the message.
COEFindSeg Return information about a requested segment. The tool sets status and writes the pathname, segment name, segment prefix, and segment type information to stdout.
COEInstaller Display a list of variants or segments that may be installed from tape, disk, or other electronic media. It is normally executed by an operator who selects it from a System Administrator menu to install or de-install segments.
COEInstError Display an error message to the user from within a Pre-Install, Post-Install, or De-Install script signaling installation termination or de-installation of the segment.
COEMsg Display a message to the user and have the user click on the "OK" button to continue. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEPrompt Display a message to the user and have the user enter a response to the message. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEPromptPasswd Prompt user to enter a password. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.
COEUpdateHome Update the home environment variable within a script file to point to where a segment was actually installed.
DII COE Developers Tools
DII COE Developers' Tools support application software development and delivery, but are not delivered to operational sites. All interfaces to these tools are at the command line; none of them have a GUI interface. These tools include:
CalcSpace computes the space required for the segment specified and updates the hardware descriptor accordingly. The segment referred to must not be compressed and must not contain any files that do not belong with the segment (e.g., source code) at run-time. The amount of space required is written to stdout in K bytes.
CanInstall tests a segment to see if it can be installed, which means that all required segments must already be on the disk, and the disk cannot have any conflicting segments.
ConvertSeg examines segment descriptors and converts them to the latest format. The original segment descriptor directory is not modified. The output is in a directory created by the tool and called SegDescrip.NEW. This directory will be located directly underneath the segment's home directory at the same level as SegDescrip. ConvertSeg is not location sensitive and may be moved to any directory desired for development.
MakeAttribs creates the descriptor file FileAttribs. It recursively traverses every subdirectory beneath the segment home directory and creates a file containing permits, owner, group, and filename information.
MakeInstall writes one or more segments to an installation medium, or packages the segments for distribution over the SIPRNET. MakeInstall checks to see if VerifySeg has been run successfully on each of the segments, and aborts with an error if it has not.
TestInstall temporarily installs a segment that already resides on disk. There must be no other COE processes running when TestInstall is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.
TestRemove removes a segment that was installed by TestInstall. There must be no other COE processes running when TestRemove is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.
TimeStamp puts the current time and date into the VERSION descriptor.
VerifySeg validates that a segment conforms to the rules for defining a segment. It uses information in the SegDescrip subdirectory and must be run whenever the segment is modified.
VerUpdate updates the segment version number, date, and time in the VERSION descriptor.
Government supplied source code includes approximately 175,000 lines of C programming language code.
To assess the degree of satisfaction of the functional requirements associated with the government supplied software, functional testing of the applicant port or implementation is required. Any available automated and manual testing of COE kernel government supplied software will be provided to aid in assuring proper function. Appendix D identifies applicable test technology, manual test procedures, and acceptance criteria.
3.4 Security Certification Criteria
This document identifies security-related criteria for DII COE Kernel Platform certification. Service, agency and system unique requirements are outside the scope of this document, as are the overall security requirements of systems built using DII COE Kernel Platforms. These criteria are drawn from "Defense Information Infrastructure (DII) Common Operating Environment (COE) Security Software Requirements Specification (SRS)", Version 2.0 - 8 July 1996 .
This evaluation verifies the presence and configuration of basic DII COE Kernel Platform security features and capabilities as identified in Appendix E of this document. These security features and capabilities are grouped into the following categories:
1. Identification and Authentication (I&A)
2. Security Audit
3. Service Availability
4. Discretionary Access Control
5. Object Reuse
6. Data Integrity
7. System Integrity
8. System Architecture
9. Trusted Facility Management
10. Other Requirements
DII COE Kernel Platform Certification security evaluation and criteria supporting DII COE Kernel Platform Certification does not replace or satisfy security testing required by Department of Defense Directive 5200.28 (1988).
The vendor applicant will also develop and deliver a security checklist as an aid in assuring that the candidate application platform satisfies the security criteria in Appendix E, Part 1. A sample security checklist specifically developed for the Solaris 2.4 DII COE platform is provided to applicants in part 2 of Annex E to accelerate the process of checklist development.
DISA security personnel will evaluate the suitability of the checklist provided by the vendor. This evaluation will be performed by the government at no charge to the vendor applicant. If the checklist is found to be an functionally equivalent to the existing checklist, and an effective method for demonstrating satisfaction of the criteria in Appendix E, the checklist will be accepted. The checklist for this platform will then be executed to assure that the application platform implements those features and capabilities.
Issue: Evaluation of the security checklist will be time and skill intensive.
3.5 Internet Interoperability Demonstration Certification Criteria
These simple demonstrations provide a basic, yet cost-effective, verification of TCP/IP interoperability, and basic BSD sockets API support. They also provide assurance of application level interoperability for several key services and protocols, such as File Transfer Protocol (FTP) and Hyper-Text Transfer Protocol (HTTP). The scope of each test is limited, but DISA investment in more formal testing can be made over time to expand the scope of assurance, as needed. Test plans in Appendix F are used to demonstrate that the candidate application platform supports the following capabilities:
TCP/IP "Ping" Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides an initial assurance of application level interoperability prior to demonstration of other services and protocols.
The Ping utility sends a request for simple acknowledgment and displays the result to the user. is used to assure connectivity to a DISA remote validation platform.
Domain Name Service (DNS) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Domain Naming Service (DNS) services and protocols.
This demonstration shows that hostnames are resolved via DNS and can be converted from standard format to DNS format.
File Transfer Protocol (FTP) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key File Transfer Protocol (FTP) services and protocols.
The demonstration suite for FTP uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. Test files located on the remote DISA test platform are transferred to the candidate, and key FTP capabilities are exercised from the candidate platform. Test files located on the candidate platform are then transferred to the remote DISA test platform, and key FTP capabilities are exercised from the remote platform.
Network File System (NFS) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Network File System (NFS) services and protocols.
The demonstration suite for NFS uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. A volume located on the remote DISA test platform is mounted on the local platform under test, and key NFS capabilities are exercised from the candidate platform. A volume located on the candidate platform is then mounted on the remote DISA test platform, and key NFS capabilities are exercised from the remote platform.
Electronic Mail Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Simple Mail Transport Protocol (SMTP) services and protocols.
The demonstration of SMTP electronic mail uses the 'mailx' commands required by the ISO/IEC 9945-2 (Posix) specification. An electronic mail message is read in from a file, sent to a mail reflector located on a DISA supplied test platform, and is reflected back to the platform under test. The returned message is displayed and saved to a file. This provides some level of assurance that the candidate platform can support both sending and receipt of electronic mail.
World Wide Web (WWW) Interoperability
This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Hyper-Text Transfer Protocol (HTTP) services and protocols.
The demonstration of WWW services uses an HTTP 1.0 conforming browser to retrieve a series of HTML 3.2 conforming web pages to and display them on the application platform being certified. The test pages exercise key Hyper-Text Markup Language (HTML), HTTP and forms related capabilities.
Note: The browser is supplied by the vendor as part of the validation suite, not as part of the kernel platform software.
You've got the wrong definition there, Rob.
:)
A VPN is a virtual LAN - allowing your computer to tunnel traffic to another point on the internet and exchange traffic as if you were on the same local network.
What you describe could be termed as NAT or PAT, or IP masquerade.
Although I agree that it's stupid to forbid VPN no matter which definition you apply.
If in fact this is a hoax, what right does Apple have to ask that it be taken down? After all, it's not revealing what their trade secrets *are*, but rather, what they *aren't*. Which, I suppose, can be equally damaging in the right situations.
Perhaps one tactic they could use is to protest the misuse of the Apple logo.
Not having seen the letter, this is all pure speculation.
on everything, but it looks like they were quick to silence this article (unless it's a freak accident on ./'s end...).
Anyone care to clue me in on what it was about? I think I've got the jist of it, but I'd like to make sure. (Gov't trying to restrict weak encryption within our borders as well?)
-e
Of course, I meant:
decides in LucasFilm's favor,
and
agree that tags directly to
-e
How true.
/their/ website to view material that is profitable, not to me, but to them).
:)
If the court decides in Universal's favor, wouldn't that mean that I could no longer tell my froend Steve to look at page 45 in the latest edition of XYZ Magazine? After all, I'm looking at copyrighted material, skipping past all the ads and b.s. they sprinkle throughout, and I could even loan Steve the magazine so he wouldn't have to pay for it!
I suppose they'd wanna give me 10 years for a violation so gross.
And what about bibliographies? I write a research paper 70 pages long and reference Book.Q by Author.Z, page 125. Same concept?
A link is a link. Whether I link to domain.com or domain.com/foo/bar/baz/quux/quuux/null.htm, the link is entirely my property (I wrote the HTML independently of any content they may have). It's hosted on my page. With the code I write there, I'm not violating any copyrights, nor am I depriving them of revenue (I'm sending someone to
I agree that tags directly to their server is copyright infringement (like cutting out a picture from a XYZ magazine and using it in my own magazine) but if I link to their page, unedited, its their responsibility to incorporate their corporate identity.
What the lawyers need (it seems) to realize is that link != duplicate. Without duplication, there is no copyright infringement. Dictionary.com reports the following definition of copyright:
The right of an author or his assignee, under statute, to print and publish his literary or artistic work, exclusively of all other persons.
A link neither prints nor publishes. Therefore, it's not copyright infringement.
I rest my case. (besides, my fingers are tired, and I need a beer.
-eric