> -----Original Message----- > From: Brian Inglis > Sent: Wednesday, June 17, 2020 11:17 PM > > On 2020-06-11 11:19, Brian Inglis wrote: > > On 2020-06-11 09:59, Watson, Christian M. (GRC-V000)[Peerless Technologies > > Corp.] via Cygwin wrote: > >> My name is Christian Watson and I am a Supply Chain Risk Management > >> Coordinator at NASA Glenn > Research Center As such, I ensure that all NASA Headquarter IT purchase > requests comply with Section > 514 of the Consolidated Appropriations Act, 2018, Public Law 115-141 > (amended), enacted February 28, > 2018. To do so, the country of origin information must be obtained from the > company that develops, > produces, manufactures, or assembles the product(s). Specifically, identify > the country where each of > the following products were developed, manufactured, and assembled: > > Just checked the basis of what you are asking. > > Section 514 is about use of funds for acquisition: > Cygwin is free software so these criteria *do not apply*!
<rant>Unless Cygwin and its packages are never to be used by business and government, these are legitimate concerns. Just because some of the users and volunteers do not care or understand does not mean it is not important.</rant> Supply Chain Risk is a real issue. It has nothing to do with did you pay for it or get it for free. In the case of the OP they have a Law/Regulation/Policy to comply with - which states they cannot expend money (for labor to use and install software, to operate systems with software, to supply electricity to operate the software, to pay a human to download and install, etc) unless all the parts have been evaluated. Now, in the OPs case the "investigator" was not informed by their technical POC about "what Cygwin" is. They are evaluating it like they would evaluate Microsoft Office 2016 or Microsoft Windows XP. In those cases, the vendor has warrantied the product. This approach even scales to open source software provided by a "company" like Red Hat Enterprise Linux 7. Here the packages bundled with RHEL are curated, supported, and (hopefully) reviewed by the Red Hat company. This approach also works for single open source software projects (e.g. PuttyCAC). But this approach cannot work for Centos, Cygwin, and other collections of open source. Normally the easiest path is to 1. demonstrate that there is an active and responsive community to security issues (e.g. how often are updates made, is there a security announcement list) 2. there is source code available implement security fixes if community support is unavailable - or in the alternative obtain a support contract 3. (this is critical) enumerate EACH package to be authorized, typically with a justification for each. 4. "security scan" it. With this a waiver is easily achieved. Cygwin, Centos, etc are used in sensitive environments, successfully. In some cases we have had to go an extra mile, perform actual source code review. I personally feel it would be worthwhile to assist users like this, and I am happy to do so. I have helped write US Government policy to help adopt the usage of open source more, but it is an up hill battle. Respectfully, Jason Pyeron -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
