When I run the install command for neo4j-gremlin as part of the Dockerfile it generates these vulnerabilities that I filed JIRA issues for.
RUN bin/gremlin-server.sh install org.apache.tinkerpop neo4j-gremlin 3.6.2 So who owns the neo4j-gremlin plugin? I thought it was part of apache tinkerpop. https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin Can you help me out with this? Jim On Fri, Mar 3, 2023 at 10:17 AM Jim Foscue <[email protected]> wrote: > 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.*
