See [DISCUSS] Ironbank topic. 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.*
