Good news! Removing the neo4j from the Dockerfile did remove a lot of the vulnerabilities. I'll close the JIRA tickets.
Thanks Jim On Thu, Mar 2, 2023 at 2:49 PM Stephen Mallette <[email protected]> wrote: > I definitely think it would be good to not include neo4j in that image. Not > only does it remove some (all?) of these dependency issues IronBank is > flagging, but it's probably best to keep the image Apache 2 compliant. > Neo4j is not licensed that way and we've gone through a fair number of > pains to maintain separation (like forcing folks to explicitly use that > command to "install" neo4j so that they have to consciously make the choice > to do so). Looking forward to hearing if your removal of that line fixed > things and if some JIRAs can be closed as a result. > > > > On Wed, Mar 1, 2023 at 4:58 PM Jim Foscue <[email protected]> > wrote: > > > Following up, Ironbank is building its own image from the Dockerfile we > > give it. > > > > ARG BASE_REGISTRY=registry1.dso.mil > > ARG BASE_IMAGE=ironbank/redhat/ubi/ubi8 > > ARG BASE_TAG="8.7" > > > > FROM ${BASE_REGISTRY}/${BASE_IMAGE}:${BASE_TAG} > > > > USER root > > > > RUN dnf install unzip -y && \ > > useradd gremlin && \ > > dnf update -y --nodocs && \ > > dnf install -y java-11-openjdk && \ > > dnf clean all && \ > > rm -rf /var/cache/dnf > > > > WORKDIR /opt/gremlin-server > > > > COPY ["apache-tinkerpop-gremlin-server-3.6.2-bin.zip", "."] > > COPY ["apache-tinkerpop-gremlin-console-3.6.2-bin.zip", "."] > > RUN set -eux; \ > > unzip apache-tinkerpop-gremlin-server-3.6.2-bin.zip; \ > > unzip apache-tinkerpop-gremlin-console-3.6.2-bin.zip; \ > > cp -R apache-tinkerpop-gremlin-server-3.6.2/* /opt/gremlin-server; \ > > cp -R apache-tinkerpop-gremlin-console-3.6.2/* /opt/gremlin-server; \ > > rm apache-tinkerpop-gremlin-server-3.6.2-bin.zip; \ > > rm apache-tinkerpop-gremlin-console-3.6.2-bin.zip; \ > > rm -rf apache-tinkerpop-gremlin-server-3.6.2; \ > > rm -rf apache-tinkerpop-gremlin-console-3.6.2 > > > > > > RUN bin/gremlin-server.sh install org.apache.tinkerpop neo4j-gremlin > 3.6.2 > > > > COPY config/* conf > > COPY config/gremlin-server-neo4j.yaml ./conf/gremlin-server.yaml > > COPY scripts/docker-entrypoint.sh /usr/bin > > RUN chown -R gremlin . > > USER gremlin > > > > HEALTHCHECK NONE > > > > ENTRYPOINT ["docker-entrypoint.sh"] > > > > > > > > On Wed, Mar 1, 2023 at 1:59 PM Stephen Mallette <[email protected]> > > wrote: > > > > > I saw the JIRAs. Most of those seem like transient dependencies that > are > > > being problematic. Like, this one: > > > > > > https://issues.apache.org/jira/browse/TINKERPOP-2883 > > > > > > refers to netty 3.x being a problem. But we specifically use netty 4.x: > > > > > > https://github.com/apache/tinkerpop/blob/3.5.5/pom.xml#L177 > > > > > > The only reference to 3.x that I can think of would come from maybe > > > hadoop-gremlin. we could probably make some effort to sort out these > > > transitive dependency issues, but i'm curious as to why direct > > dependencies > > > like hadoop, neo4j, etc. are a problem for IronBank. we don't package > > them > > > in Docker images (which i'd come to understand IronBank was interested > > in) > > > nor are they packaged in our binary zip distributions of Gremlin Server > > or > > > Console which you alluded to here: > > > > > > https://lists.apache.org/thread/vsmrms1sy62sd1z3b7mcmzc9kh4gq5tk > > > > > > So, why is the IronBank scanner picking up these issues? I guess > > something > > > still isn't connecting for me in what IronBank is doing. > > > > > > > > > > > > On Mon, Feb 27, 2023 at 5:10 PM Jim Foscue < > [email protected]> > > > wrote: > > > > > > > I've added some JIRA tickets with the Label Ironbank. > > > > > > > > They all involve updating various libraries as part of the build. > > > > > > > > Jim > > > > > > > > On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue < > > [email protected] > > > > > > > > wrote: > > > > > > > > > I can definitely add JIRA issues and share the findings. > > > > > > > > > > I’ll start with version 3.6.2. Could take a couple of days to get > > this > > > > > going in Ironbank but I’ll keep you updated. > > > > > > > > > > Jim > > > > > > > > > > > On Feb 22, 2023, at 11:23 AM, Stephen Mallette < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > > ok - thanks for clarifying. i hope you'll feel free to issue > > > PRs/JIRAs > > > > > and > > > > > > just generally interact with the community to help us get > TinkerPop > > > > > > IronBank-ready. it would be nice if you kept us apprised of > > releases > > > > that > > > > > > were accepted there. i assume we could add a link somewhere to > the > > > > place > > > > > > TinkerPop is hosted in ironbank if there is such a direct link > > > publicly > > > > > > available and you could share it? > > > > > > > > > > > >> On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue < > > > > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > >> What you're saying makes sense to me. We can be the custodians > of > > > the > > > > > >> Ironbank process/image since we have access. > > > > > >> > > > > > >> I'm not sure I understand your release process. The ironbank > > build > > > > > pulls > > > > > >> in the files from https://dlcdn.apache.org/tinkerpop/. > > > > > >> > > > > > >> For example > > > > > >> # List of resources to make available to the offline build > context > > > > > >> resources: > > > > > >> - url: " > > > > > >> > > > > > >> > > > > > > > > > > > > > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-server-3.6.1-bin.zip > > > > > >> " > > > > > >> filename: "apache-tinkerpop-gremlin-server-3.6.1-bin.zip" > > > > > >> validation: > > > > > >> type: sha512 > > > > > >> value: > > > > > >> > > > > > >> > > > > > > > > > > > > > > > 4930e79caeed0ea019bf52da9d78d3440a0e6805b3232763b774116c10e7ee38dbe5ac9bb3873acf318c65349d00b204d7ec89c60324eda9a4aaaa2c2998053b > > > > > >> - url: " > > > > > >> > > > > > >> > > > > > > > > > > > > > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-console-3.6.1-bin.zip > > > > > >> " > > > > > >> filename: "apache-tinkerpop-gremlin-console-3.6.1-bin.zip" > > > > > >> validation: > > > > > >> type: sha512 > > > > > >> value: > > > > > >> > > > > > >> > > > > > > > > > > > > > > > 3516b601298427e78580665016f6d29bf5ad39bfeeafe9e4cd762bb7a9454d844e131df4935b4fa61fb2f9d749eb5f2fa4b56df2908a8067825a203423b958c5 > > > > > >> > > > > > >> So when do these get updated? Is it when there is a new release > or > > > bug > > > > > >> fixes? Whenever these are updated is when we would get the > fixes. > > > > > >> > > > > > >> Thoughts? > > > > > >> > > > > > >> Jim > > > > > >> > > > > > >> On Wed, Feb 22, 2023 at 9:15 AM Stephen Mallette < > > > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > >>> Unless I'm not understanding something there isn't much change > to > > > > > process > > > > > >>> for TinkerPop. You spot a problem in IronBank and either > submit a > > > PR > > > > to > > > > > >> fix > > > > > >>> or create a JIRA for someone else to fix if you don't have the > > > > ability > > > > > to > > > > > >>> do it yourself. It gets merged and presumably you can get your > > > image > > > > > into > > > > > >>> IronBank. > > > > > >>> > > > > > >>> What I don't understand is how you consume that fix. Let's say > > > > IronBank > > > > > >> had > > > > > >>> a problem in 3.6.2. TinkerPop fixes it. Now what? Do you have > to > > > wait > > > > > >> until > > > > > >>> we release 3.6.3 to get that into IronBank and hope you don't > hit > > > > more > > > > > >>> problems? Is there a way to test an image ahead of a TinkerPop > > > > > release? I > > > > > >>> guess I'm trying to confirm that there really isn't any change > to > > > > > >> anything > > > > > >>> TinkerPop does in the normal process of reviewing pull request > > and > > > > > fixing > > > > > >>> security problems because it seems pretty normal/simple > > otherwise. > > > No > > > > > one > > > > > >>> at TinkerPop can release anything to IronBank so this is > purely a > > > > > >>> third-party maintained convenience which you are handling for > the > > > > wider > > > > > >>> community. Is that a fair depiction of what were looking at > here? > > > > > >>> > > > > > >>> So, if there's nothing out of the ordinary to do from > TinkerPop's > > > > side > > > > > >> then > > > > > >>> I guess you should feel free to let the PRs/JIRAs fly (or maybe > > > just > > > > > call > > > > > >>> attention to existing ones if dependabot is already on it). > > Perhaps > > > > you > > > > > >>> should ensure you comment on these that they are "IronBank" > > related > > > > so > > > > > >> that > > > > > >>> they perhaps get some visibility that way. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> On Wed, Feb 22, 2023 at 9:48 AM Jim Foscue < > > > > > [email protected]> > > > > > >>> wrote: > > > > > >>> > > > > > >>>> I would like to bring this discussion back up. > > > > > >>>> > > > > > >>>> Has anyone given this any more thought? My team is willing to > > > help > > > > > but > > > > > >>> we > > > > > >>>> have not participated in the development of any of tinkerpop > so > > it > > > > > >> would > > > > > >>> be > > > > > >>>> a huge effort on our part to get involved in the development. > > We > > > > are > > > > > >>>> developers but not our main language is C#. > > > > > >>>> > > > > > >>>> Thanks > > > > > >>>> Jim Foscue > > > > > >>>> > > > > > >>>> On Wed, Dec 21, 2022 at 5:40 AM Stephen Mallette < > > > > > [email protected] > > > > > >>> > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> From what I'm gathering, this doesn't sound as if it changes > > much > > > > of > > > > > >>> how > > > > > >>>>> things operate here or the release process. It sounds as > though > > > Jim > > > > > >>>> simply > > > > > >>>>> needs to submit dependency related PRs to TinkerPop. They > would > > > be > > > > > >>>> reviewed > > > > > >>>>> and merged in similar fashion to any PR that arrived. As > these > > > > would > > > > > >> be > > > > > >>>>> security related PRs, they probably wouldn't generate > > > > > >>> objections/concerns > > > > > >>>>> and would merge quickly. > > > > > >>>>> > > > > > >>>>> There is still something I don't quite understand. 3.6.1 > > scanned > > > by > > > > > >>>>> IronBank shows problems. Jim submits PRs to TinkerPop to fix > > > those > > > > > >>>> issues. > > > > > >>>>> What version ultimately lands in IronBank? IronBank has to > wait > > > > for a > > > > > >>>> 3.6.2 > > > > > >>>>> as 3.6.1 can't pass their scanners? Can IronBank scanners > work > > > from > > > > > >>>>> SNAPSHOT? Ideally, IronBank would be working on > 3.6.2-SNAPSHOT > > > > right > > > > > >>> now > > > > > >>>> as > > > > > >>>>> release is arriving within the next few weeks. Then you could > > > have > > > > a > > > > > >>>> clean, > > > > > >>>>> pre-tested artifact in 3.6.2 to push into IronBank when it > > > > releases. > > > > > >>> This > > > > > >>>>> way IronBank would align with DockerHub and the rest of the > > > > release. > > > > > >>>>> Putting some kind of patched version of 3.6.1 in IronBank > seems > > > > like > > > > > >> it > > > > > >>>>> could cause confusion imo. > > > > > >>>>> > > > > > >>>>> On Tue, Dec 20, 2022 at 12:51 PM Jim Foscue < > > > > > >>> [email protected] > > > > > >>>>> > > > > > >>>>> wrote: > > > > > >>>>> > > > > > >>>>>> I believe most of the critical/high vulnerabilities are a > > result > > > > of > > > > > >>>>>> outdated dependencies. > > > > > >>>>>> > > > > > >>>>>> Another thing to consider is that to participate as an > active > > > > > >>> developer > > > > > >>>>> on > > > > > >>>>>> Ironbank the user must have a DoD CAC which allows them > access > > > to > > > > > >> the > > > > > >>>>>> Ironbank repository and the vulnerabilities. I'm not sure > if > > > > > >> anyone > > > > > >>>> here > > > > > >>>>>> has one but I do. I was able to get the process started > with > > > the > > > > > >>> 3.6.1 > > > > > >>>>>> version and there are a number of critical and highs. Some > of > > > the > > > > > >>>>> examples > > > > > >>>>>> are: > > > > > >>>>>> Apache Shiro before 1.5.3, when using Apache Shiro with > Spring > > > > > >>> dynamic > > > > > >>>>>> controllers, a specially crafted request may cause an > > > > > >> authentication > > > > > >>>>>> bypass. > > > > > >>>>>> Neo4j through 3.4.18 (with the shell server enabled) exposes > > an > > > > RMI > > > > > >>>>> service > > > > > >>>>>> that arbitrarily deserializes Java objects, e.g., through > > > > > >>>>>> setSessionVariable. An attacker can abuse this for remote > code > > > > > >>>> execution > > > > > >>>>>> because there are dependencies with exploitable gadget > chains. > > > > > >>>>>> HttpObjectDecoder.java in Netty before 4.1.44 allows a > > > > > >> Content-Length > > > > > >>>>>> header to be accompanied by a second Content-Length header, > or > > > by > > > > a > > > > > >>>>>> Transfer-Encoding header. > > > > > >>>>>> > > > > > >>>>>> Looks like the Apache Shiro library is one of the problem > > spots. > > > > > >>>>>> > > > > > >>>>>> I do agree with your assessment that including a scanner in > > the > > > > > >>> normal > > > > > >>>>>> build process would help a lot. > > > > > >>>>>> > > > > > >>>>>> Jim > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> On Tue, Dec 20, 2022 at 3:08 AM Florian Hockmann < > > > > > >>>> [email protected] > > > > > >>>>>> > > > > > >>>>>> wrote: > > > > > >>>>>> > > > > > >>>>>>> It would be good to know what kind of vulnerabilities > > Ironbank > > > > > >> can > > > > > >>>>> find. > > > > > >>>>>>> Most of such scanners I know simply use a database of known > > > > > >>>>>> vulnerabilities > > > > > >>>>>>> that include the libraries and their versions that are > > > affected. > > > > > >>> The > > > > > >>>>>>> Log4Shell vulnerability from last year is a good example > that > > > > > >> could > > > > > >>>> be > > > > > >>>>>>> found by such a scanner. > > > > > >>>>>>> > > > > > >>>>>>> In general I think that we should ideally try to include > > such a > > > > > >>>> scanner > > > > > >>>>>>> into our usual dev process so we can find those > > vulnerabilities > > > > > >>> early > > > > > >>>>> and > > > > > >>>>>>> then fix them. Fixing them will probably most of the time > > just > > > > > >> mean > > > > > >>>>>>> updating a dependency. > > > > > >>>>>>> If we just add Ironbank as an additional release channel > > behind > > > > > >> our > > > > > >>>>> usual > > > > > >>>>>>> release process, then we just get notified about > > > vulnerabilities > > > > > >>>> after > > > > > >>>>> we > > > > > >>>>>>> just have released a version with these vulnerabilities. I > > > think > > > > > >>> that > > > > > >>>>>> would > > > > > >>>>>>> only lead to additional pain for us as we would have to fix > > > them > > > > > >>> and > > > > > >>>>> then > > > > > >>>>>>> start another release process to perform a release without > > the > > > > > >>>>>>> vulnerability. > > > > > >>>>>>> > > > > > >>>>>>> GitHub already offers such a vulnerability scanner that > works > > > > > >>>> together > > > > > >>>>>>> with Dependabot. This means that Dependabot will create a > PR > > to > > > > > >>>> update > > > > > >>>>> a > > > > > >>>>>>> dependency if that contains a known vulnerability. These > > > security > > > > > >>>>> related > > > > > >>>>>>> PRs will be marked as such, but in a way that is only > visible > > > to > > > > > >>>>>>> maintainers of the repo. So, we can prioritize these > security > > > > > >>> related > > > > > >>>>> PRs > > > > > >>>>>>> over the usual Dependabot PRs that sometimes overwhelm us > due > > > to > > > > > >>> the > > > > > >>>>> high > > > > > >>>>>>> number of dependencies we have. > > > > > >>>>>>> This improves the security of TinkerPop in general and I > > think > > > > > >> that > > > > > >>>> it > > > > > >>>>>>> also improves our dev process as we currently get tickets > for > > > > > >> such > > > > > >>>>>> security > > > > > >>>>>>> problems manually created by users who probably already > > execute > > > > > >>> such > > > > > >>>>>>> scanners on our JARs / Docker images (two recent examples: > > > > > >>>>>>> TINKERPOP-2843[1] and TINKERPOP-2826[2]) and then they are > > > > > >> usually > > > > > >>>> also > > > > > >>>>>>> addressed by someone who manually updates the dependency. > > > > > >>>>>>> If the Ironbank scanner works in a similar way, then this > > would > > > > > >>> also > > > > > >>>>> make > > > > > >>>>>>> it a lot easier to publish our images to the Ironbank > > registry > > > as > > > > > >>>> that > > > > > >>>>>>> should ideally not uncover any new vulnerabilities since > they > > > > > >> have > > > > > >>>>>> already > > > > > >>>>>>> been found and fixed by our own process (like GitHub > security > > > > > >>>> scanning > > > > > >>>>> + > > > > > >>>>>>> Dependabot). > > > > > >>>>>>> > > > > > >>>>>>> By the way, I think this is the documentation of Ironbank: > > > > > >>>>>>> https://p1.dso.mil/products/iron-bank > > > > > >>>>>>> And here is a list of available Docker images: > > > > > >>>>>> https://repo1.dso.mil/dsop > > > > > >>>>>>> Unfortunately, the repos seem to be private so we can't see > > > much, > > > > > >>> but > > > > > >>>>> the > > > > > >>>>>>> list at least gives an idea of what kind of projects are > > > already > > > > > >>>>>> available > > > > > >>>>>>> there. > > > > > >>>>>>> > > > > > >>>>>>> [1]: https://issues.apache.org/jira/browse/TINKERPOP-2843 > > > > > >>>>>>> [2]: https://issues.apache.org/jira/browse/TINKERPOP-2826 > > > > > >>>>>>> > > > > > >>>>>>> -----Ursprüngliche Nachricht----- > > > > > >>>>>>> Von: Jim Foscue <[email protected]> > > > > > >>>>>>> Gesendet: Montag, 19. Dezember 2022 17:10 > > > > > >>>>>>> An: [email protected] > > > > > >>>>>>> Betreff: Re: [DISCUSS] > > > > > >>>>>>> > > > > > >>>>>>> Yes, Ironbank is an approved DoD dockerhub. There is no > > > > > >>> requirement > > > > > >>>>> for > > > > > >>>>>>> the releases on Ironbank to be in sync with the releases in > > > > > >>>>>>> Apache/Tinkerpop. The major requirement for Ironbank is > for > > > > > >> there > > > > > >>>> not > > > > > >>>>> to > > > > > >>>>>>> be any critical/high vulnerabilities in the docker image. > If > > > > > >> there > > > > > >>>> are > > > > > >>>>>>> vulnerabilities that "pop" up they should be addressed > > quickly. > > > > > >>>>>>> > > > > > >>>>>>> My team can help with that process but it would be hard for > > us > > > to > > > > > >>> fix > > > > > >>>>> the > > > > > >>>>>>> vulnerabilities without knowing the code. > > > > > >>>>>>> > > > > > >>>>>>> Jim > > > > > >>>>>>> > > > > > >>>>>>> On Mon, Dec 19, 2022 at 5:36 AM Stephen Mallette < > > > > > >>>> [email protected] > > > > > >>>>>> > > > > > >>>>>>> wrote: > > > > > >>>>>>> > > > > > >>>>>>>> Hi Jim, thanks for bringing this discussion here. > > > > > >>>>>>>> > > > > > >>>>>>>> Generally speaking, it sounds like a reasonable idea to > open > > > > > >>>>> TinkerPop > > > > > >>>>>>>> opportunities to the DoD environment. Would it be fair to > > call > > > > > >>>>>>>> IronBank a DoD approved DockerHub? Would the idea be that > > > > > >>> TinkerPop > > > > > >>>>>>>> would release to IronBank in the same cadence as is done > > with > > > > > >> the > > > > > >>>>>>>> standard release schedule that publishes to DockerHub? > > > > > >>>>>>>> > > > > > >>>>>>>> If so, I think a concern would be that supporting IronBank > > > > > >>> creates > > > > > >>>> a > > > > > >>>>>>>> hurdle to releasing that may be high and thus delay > releases > > > > > >> that > > > > > >>>>>>>> might otherwise be acceptable outside of that space. I > don't > > > > > >> know > > > > > >>>> if > > > > > >>>>>>>> it makes sense, but perhaps releasing to IronBank should > be > > > > > >>>> decoupled > > > > > >>>>>>> from standard releases? > > > > > >>>>>>>> Like 3.5.5 would go out the door and then a separate > process > > > > > >>> would > > > > > >>>> go > > > > > >>>>>>>> under way to harden 3.5.5 to meet IronBank needs? Of > course, > > > > > >> then > > > > > >>>> the > > > > > >>>>>>>> 3.5.5 in IronBank isn't necessarily the 3.5.5 in DockerHub > > so > > > > > >>> that > > > > > >>>>>>>> could be problematic. Do you happen to know how other > major > > > > > >> open > > > > > >>>>>>>> source projects do this? > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> On Wed, Dec 14, 2022 at 4:51 PM Jim Foscue > > > > > >>>>>>>> <[email protected]> > > > > > >>>>>>>> wrote: > > > > > >>>>>>>> > > > > > >>>>>>>>> Ironbank discussion > > > > > >>>>>>>>> > > > > > >>>>>>>>> I would like to suggest making tinkerpop/gremlin > available > > on > > > > > >>> the > > > > > >>>>>>>>> DoD Ironbank docker registry (https://ironbank.dso.mil). > > > > > >>>>>>>>> > > > > > >>>>>>>>> Ironbank is a DoD docker registry that maintains publicly > > > > > >>>> available > > > > > >>>>>>>> docker > > > > > >>>>>>>>> container images that have been "hardened' and given the > ok > > > > > >> to > > > > > >>>> use > > > > > >>>>>>>>> on DoD contracts. The process of hardening an image > > involves > > > > > >>>>>>>>> running the docker container image through a > vulnerability > > > > > >>>> scanning > > > > > >>>>>>>>> process. Any critical > > > > > >>>>>>>> and > > > > > >>>>>>>>> high vulnerabilities have to be addressed before getting > > the > > > > > >>>> docker > > > > > >>>>>>>>> container image approved for DoD use. > > > > > >>>>>>>>> > > > > > >>>>>>>>> My team has been using the publicly available > > tinkerpop/graph > > > > > >>> on > > > > > >>>> a > > > > > >>>>>>>>> DoD contract that is a prototype. But to continue using > it > > > > > >> in > > > > > >>> a > > > > > >>>>>>>>> more > > > > > >>>>>>>> official > > > > > >>>>>>>>> process we have to have it approved by Ironbank. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Therefore, I am trying to get the tinkerpop developer > > > > > >>> community > > > > > >>>> to > > > > > >>>>>>>>> get onboard to push this to Ironbank so that we and other > > DoD > > > > > >>>>>>>>> contracts can > > > > > >>>>>>>> use > > > > > >>>>>>>>> it. > > > > > >>>>>>>>> > > > > > >>>>>>>>> We have access to the Ironbank system (which requires a > US > > > > > >>>>>>>>> government > > > > > >>>>>>>> CAC) > > > > > >>>>>>>>> and are willing to help guide the process. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Please consider this request and provide any feedback to > me > > > > > >> at > > > > > >>>> your > > > > > >>>>>>>>> convience. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Regards, > > > > > >>>>>>>>> > > > > > >>>>>>>>> Jim Foscue > > > > > >>>>>>>>> JDM Solutions > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> -- > > > > > >>>>>>>>> *Jim Foscue*, Software Engineer > > > > > >>>>>>>>> *JDM Solutions* > > > > > >>>>>>>>> 256.694.9387 > > > > > >>>>>>>>> [email protected] < > > > > > >> [email protected] > > > > > >>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> -- > > > > > >>>>>>>>> *This e-mail and any attachements are for the intended > > > > > >>>> recipient(s) > > > > > >>>>>>>>> only and may contain information proprietary or private > to > > > > > >> JDM > > > > > >>>>>>> Solutions, LLC. > > > > > >>>>>>>>> If you are not the intended recipient **please delete > > without > > > > > >>>>>>>>> copying and kindly advise the sender by e-mail of the > > mistake > > > > > >>> in > > > > > >>>>>>>>> delivery. This > > > > > >>>>>>>> email > > > > > >>>>>>>>> may be personal in communication from the sender and as > > such > > > > > >>> does > > > > > >>>>>>>>> not represent the views of the company.* > > > > > >>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> -- > > > > > >>>>>>> *This e-mail and any attachements are for the intended > > > > > >> recipient(s) > > > > > >>>>> only > > > > > >>>>>>> and may contain information proprietary or private to JDM > > > > > >>> Solutions, > > > > > >>>>> LLC. > > > > > >>>>>>> If you are not the intended recipient **please delete > without > > > > > >>> copying > > > > > >>>>> and > > > > > >>>>>>> kindly advise the sender by e-mail of the mistake in > > delivery. > > > > > >>> This > > > > > >>>>>> email > > > > > >>>>>>> may be personal in communication from the sender and as > such > > > does > > > > > >>> not > > > > > >>>>>>> represent the views of the company.* > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>>> -- > > > > > >>>>>> *This e-mail and any attachements are for the intended > > > > recipient(s) > > > > > >>>> only > > > > > >>>>>> and may contain information proprietary or private to JDM > > > > > >> Solutions, > > > > > >>>> LLC. > > > > > >>>>>> If you are not the intended recipient **please delete > without > > > > > >> copying > > > > > >>>> and > > > > > >>>>>> kindly advise the sender by e-mail of the mistake in > delivery. > > > > > >> This > > > > > >>>>> email > > > > > >>>>>> may be personal in communication from the sender and as such > > > does > > > > > >> not > > > > > >>>>>> represent the views of the company.* > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>>> -- > > > > > >>>> *This e-mail and any attachments are for the intended > > recipient(s) > > > > > only > > > > > >>>> and > > > > > >>>> may contain information proprietary or private to JDM > Solutions, > > > > LLC. > > > > > >> If > > > > > >>>> you are not the intended recipient **please delete without > > copying > > > > and > > > > > >>>> kindly advise the sender by e-mail of the mistake in delivery. > > > This > > > > > >>> email > > > > > >>>> may be personal in communication from the sender and as such > > does > > > > not > > > > > >>>> represent the views of the company.* > > > > > >>>> > > > > > >>> > > > > > >> > > > > > >> -- > > > > > >> *This e-mail and any attachments are for the intended > recipient(s) > > > > only > > > > > >> and > > > > > >> may contain information proprietary or private to JDM Solutions, > > > LLC. > > > > > If > > > > > >> you are not the intended recipient **please delete without > copying > > > and > > > > > >> kindly advise the sender by e-mail of the mistake in delivery. > > This > > > > > email > > > > > >> may be personal in communication from the sender and as such > does > > > not > > > > > >> represent the views of the company.* > > > > > >> > > > > > > > > > > > > > -- > > > > *This e-mail and any attachments are for the intended recipient(s) > only > > > > and > > > > may contain information proprietary or private to JDM Solutions, LLC. > > If > > > > you are not the intended recipient **please delete without copying > and > > > > kindly advise the sender by e-mail of the mistake in delivery. This > > > email > > > > may be personal in communication from the sender and as such does not > > > > represent the views of the company.* > > > > > > > > > > > -- > > *This e-mail and any attachments are for the intended recipient(s) only > > and > > may contain information proprietary or private to JDM Solutions, LLC. If > > you are not the intended recipient **please delete without copying and > > kindly advise the sender by e-mail of the mistake in delivery. This > email > > may be personal in communication from the sender and as such does not > > represent the views of the company.* > > > -- *This e-mail and any attachments are for the intended recipient(s) only and may contain information proprietary or private to JDM Solutions, LLC. If you are not the intended recipient **please delete without copying and kindly advise the sender by e-mail of the mistake in delivery. This email may be personal in communication from the sender and as such does not represent the views of the company.*
