This message was deleted.
# community-support
s
This message was deleted.
j
What part of the build is making the request?
d
Looks like configuration. See attached log from the build.
e
d
But what is making gradle reach out to the CDN on port 80 and is there a way to prevent it from doing that?
e
maybe a buildscript repository? hard to say without seeing more of your configuration
d
I packaged up our pretty complex gradle configuration in the attached. The key files are the top level build.gradle, settings.gradle and the product/ear/ear.gradle.
there is a buildscript in the top level build.gradle
e
stubbing it out to the best of my ability and running through a sniffing proxy, configuring that doesn't result in any insecure HTTP fetches for me
perhaps your maven server is redirecting some assets to other HTTP URLs
v
Also, in your posted log you do not show the request that is made that should be logged on
--info
or possibly
--debug
and a
--stacktrace
would maybe also be helpful to see where exactly the request is coming from.
Btw. be aware that you just published passwords
d
oh dear 😞
I tried the various info debug stacktrace and scan options but none yielded any additional info
thanks for looking at this guys!
v
Are you sure there is no additional info? Sometimes, you are just not seeing it, but people with more experience reading Gradle logs might see additional information. Especially the
--stacktrace
output must provide additional helpful information, as in your shown output there is no information at all where the issue comes from.
d
Thanks for being so helpful Vampire. Attaching a full log with --debug and --stacktrace
v
There, all necessary info is in the stacktrace. 🙂 While Gradle tries to parse
product/ear/src/main/application/META-INF/application.xml
this exception happens. So it should be something in your descriptor that references that URL that is accessed.
d
oh excellent. One of my colleagues just hypothesized the same thing when he looked at it! You the man vampire!
j
Was the XML parser loading a DTD over HTTP or something?
d
That's the hypothesis. About to test
j
Running in
--offline
mode was how I found this vulnerability in Checkstyle: https://nvd.nist.gov/vuln/detail/CVE-2019-9658
d
this did indeed prove to be the solution. Thanks so much folks!
👌 1