Re: [DISCUSS]

[Jim Foscue <ji...@jdmsolutions.com>]

See [DISCUSS] Ironbank topic.

On Wed, Dec 21, 2022 at 5:40 AM Stephen Mallette <sp...@gmail.com>
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 <ji...@jdmsolutions.com>
> 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 <fh@florian-hockmann.de
> >
> > 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 <ji...@jdmsolutions.com>
> > > Gesendet: Montag, 19. Dezember 2022 17:10
> > > An: dev@tinkerpop.apache.org
> > > 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 <spmallette@gmail.com
> >
> > > 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
> > > > <ji...@jdmsolutions.com>
> > > > 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
> > > > > jim.foscue@jdmsolutions.com <mi...@jdmsolutions.com>
> > > > >
> > > > > --
> > > > > *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.*