[off topic] RE: [cygwin] Re: Country Of Origin Verification - 8944

[off topic] RE: [cygwin] Re: Country Of Origin Verification - 8944

[Jason Pyeron]

> -----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

Re: [off topic] RE: Re: Country Of Origin Verification - 8944

[ASSI]

Jason Pyeron writes:
> <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>

Well, even if any user or volunteer does care and understand, that still
does not put them into a position to provide the information that was
asked.

For the original question: It is clear from earlier communication on
this list that Cygwin is in use by various branches of the
U.S. government, so if you can get hold of the people who've done that
before you'll likely be able to re-use their trail(s) and get 80…90% of
your answers by copy&paste.

> Supply Chain Risk is a real issue.
[…]
> But this approach cannot work for Centos, Cygwin, and other
> collections of open source.

Right.  For Cygwin in particular, there is the additional issue that it
is very much a rolling distribution, and packages come and go and change
versions all the time.  So by the time you've cut through all the red
tape you'll have to start over again.

I use Cygwin in environments that need to be auditable.  While the
actual auditing thankfully has not yet been necessary, I've put in place
some of the preparations for that nevertheless:

1. The install is from a local repository and setup has been modified to
allow only signed installs and been outfitted with a different signing
key so users can't go around the local repo and install from the
internet (yes, they've tried).

2. The install will always leave you with the same set of packages when
successful for each type of installation supported and the install
script knows which type of installation belongs on each machine.  I
could nail that part down harder, but at the moment it suffices. All
add-on software for Cygwin that is not in the upstream repository is
properly packaged locally and put into the local repository

3. If proper auditing ever becomes necessary I can switch to a phased
install model where I can keep certain machines to whatever the audited
state is and keep updating the other installs as I do at the moment for
all of them.  Right now I just have a staging repo that I update
frequently and gets copied to the live repo when I tested the staging
install OK.

4. I've convinced myself that I could build all packages from source if
I had to, but I've not actually done it yet.  That would not be a
requirement for us anyway, but as requirements change all the time it's
better to have that fallback in place.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs