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