I am trying to run the box upgrade command and I get the following error:
Getting stable versioning information from https://downloads.ortussolutions.com/ortussolutions/commandbox/box-repo.json
ERROR (5.9.0+00721)
Sorry, we're having troubles accessing the interwebs now or the update site is down. Please try again later
Box Repo: [Connection Failure. Status code unavailable.] Loader Repo: [Connection Failure. Status code unavailable.]
In my docker file I am running the box config set proxy.server command however I believe its not being respected when I run box upgrade. The url does not contain the proxy I am setting. Thoughts?
Hi @epochcoda The HTTP calls in that command do use CommandBox’s proxy settings and have since this command was first built
Can you show me the output of
config show proxy
In the mean time, you can disable the update check for now if it’s causing you hassle until we figure out the proxy settings.
# disable just the CLI check
config set modules.commandbox-update-check.CLIcheck=false
# disable the system modules check
config set modules.commandbox-update-check.systemModulesCheck=false
# disable all checks
config set modules.commandbox-update-check.enable=false
I’m not entirely sure what you mean. Yes, I would expect that the CFHTTP tag would work as described and using the proxy settings like it’s supposed to. I have no idea exactly what you’re expecting to “see” however. I would recommend you simply try this out! Create a simple Task Runner CFC and slap a cfhttp inside of it which hits the URL https://downloads.ortussolutions.com/ortussolutions/commandbox/box-repo.json and then add in your proxy details and see if it works! This should take no more than a couple minutes and will determine right away where the issue is.
So I agree a simple task runner would suffice however just doing a simple process in a dockerfile without any of my particular source code still wont let me get the latest using box upgrade.
I get the error listed above in the OP description.
Here is a sanitized dockerfile that I am trying to work through.
FROM ortussolutions/commandbox:lucee5 as start
RUN box server set web.SSL.certFile=/etc/ssl/certs/ca-certificates.crt
#RUN box server set jvm.args=”-Djavax.net.ssl.keyStore=/opt/java/openjdk/lib/security/cacerts”
#Update commandbox to use the proxy
RUN box config set proxy.server=url:port###/repository/
RUN box config show proxy.server
RUN box config set proxy.port=port###
RUN box config show proxy.port
RUN box config set proxy.user=$NEXUS_USERNAME
RUN box config show proxy.user
RUN box config set proxy.password=$NEXUS_PASSWORD
RUN box config show proxy.password
#upgrade commandbox to the latest version
RUN box upgrade
I am just trying to figure out ways to better debug this. If you think creating a simple task runner would still be useful in testing out this same issue and it may give a better debug output then I will give it a shot.
Background: I had this running about 8 months back. Sent off and was supposedly maintained. Someone left the original team and I was asked to bring it back online. Now nothing works and I am trying to just figure out the best way to get this upgrading so I can deploy the application (need the box upgrade so that I can resolve container vulnerabilities using the lucee5 image).
I’m not sure what the point of your test was. We already know the upgrade command isn’t working for you so continuing to find creative ways to run the upgrade command seems like a waste of time I suggested a task runner specifically because it removes the upgrade command from the picture and allows you to see if your proxy settings just work directly with the CFHTTP tag, to rule out any basic misunderstandings on your part about what proxy settings you are supposed to provide. If a stand-alone CFHTTP tag works, then we can look for differences between your code and how it differs from the code in the upgrade command. But if you can’t even get a standalone CFHTTP call to work, then we know CommandBox isn’t at fault and you may simply have the wrong proxy info or your proxy doesn’t work!
On an unrelated note, your docker files will run about 10 times faster if you combine commands!
RUN box config set proxy.server=url:port###/repository/ proxy.port=port### proxy.user=$NEXUS_USERNAME proxy.password=$NEXUS_PASSWORD
RUN box config show proxy
Also, you can eliminate the overhead of calling box at by just setting these env vars
I’m new to commandbox so I am just trying to put all of my environment on the table to make sure I am not missing something really simple.
Out of curiosity, should the url in the error reflect the added proxy information or not? That was what I was originally using to determine if the proxy was even being used. I had it documented on my end that it was and I may have mispoken.
I recognize it can go faster, we don’t really need it to go faster. The big one is that we are trying to make sure handoffs of prototyped stuff isn’t overly complicated for someone to debug. We are running this through a pipeline and having multiple commands on one line can cover up the command that is actually causing the error if one is ran into on those kinds of lines. I will make sure to add that information so that the inheriting team can make that decision and document it for their users if they want to. And I do appreciate your help and insight in all of this. All criticism and recommendations are welcome. Im just here trying to make sense of this thing so I can go back to other tasking lol.
No clue, lol. You’d need to consult the Lucee source code. I never use proxies myself so I’m not familiar with what the error messages look like, but I would assume the error messages do not reflect the proxy URL as it’s an “invisible detail”.
See, to me 8 commands instead of 2 commands is over-complicated To each their own, I guess.
As far as your task runner, simply create a file called task.cfc with the following contents
component {
function run() {
try {
http
url="https://downloads.ortussolutions.com/ortussolutions/commandbox/box-repo.json"
throwOnError=true
proxyServer="your"
proxyPort="proxy"
proxyUser="settings"
proxyPassword="here";
print.line( cfhttp )
} catch( any e ) {
print.line( e );
}
}
}
and then run
box task run
in the same directory as that task.cfc file. If this is in a Docker container, then I’d SSH into the container and run it so you can tweak the proxy settings, etc to see what’s wrong and what needs to change for it to work.
Oh, I forgot to mention this before, but what exactly are you expecting that line above to do? That is related to the server SSL cert used when starting a server, but has no bearing on the trust store used to make CFHTP calls. I’m unclear if you were expecting it to. If your network admins have some sort of SSL Snooping in place where they screw around with SLL certs on the fly, then you’ll certainly have issues with CFHTTP working out of the box regardless of whether you’re on a proxy or not.
Yeah about the cert file we have to manage some things and I forgot to remove that from the sanitized dockerfile I was sharing. As for the task run test, the debug output is wayyyy better than the error I was getting from the failed box upgrade. This is what I needed to actually find a legitimate string to pull on. It may appear that the proxy is not configured correctly and is the actual culprit. Going to pull that string and see what happens. Will update if the solution is found.
If you share the error here, I may be able to offer some help. or it may be helpful to others finding this thread in the future. I’m also curious if I can modify the upgrade command to throw a better error in the first place in this sort of scenario.
Yeah so the issue is just our proxy service is not configured correctly. So I am taking a different approach currently.
The proxy was supposed to assist in a self signed cert issue we have unique to our environment (can’t be mitigated).
I have removed the proxy, I can curl the following url successfully, “https://downloads.ortussolutions.com/ortussolutions/commandbox/box-repo.json”
However when I call task run (with proxy removed) I get the self signed cert issue I would otherwise expect. I thought I was successfully updating the cert store but I should I need to update something else to test if I have successfully added my certs?
And exactly what steps did you take to do this? As I said above, the line in your config dealing with certs will NOT affect the behavior of CFHTTP calls. You haven’t shown what steps you’ve taken to import certs into the custom cacerts file Lucee uses for its CFHTTP calls.
Also, network admins who do SSL snooping by cert swapping should be slapped. Hard. They cause so many issues like this and sort of defeat the entire purpose of how HTTPS is designed to work. [/end rant].
The fastest and easiest way to import an SSL cert into Lucee’s custom trust store is probably to run this
And then try again. Note, the CLI must exit and start fresh for Lucee to pick up the newly trusted cert. This, of course is terrible, dangerous, and opens yourself up to MITM attacks, but we have your sysadmin to blame You can also directly import a specific root cert into the cacerts file, but that is more annoying and generally involves wresting with arcane openssl commands.
Going to run the box ssl cert install work recommended above.
But I was under the impression that the following lines applied the certs to the lucee custom trust store.
RUN box server set web.SSL.certFile=/etc/ssl/certs/ca-certificates.crt
RUN box server set jvm.args=”-Djavax.net.ssl.keyStore=/opt/java/openjdk/lib/security/cacerts”
None of that has any bearing on what Lucee does. Lucee packages its own cacerts file which is separate from the JRE’s and separate from the operating system’s.
I already explained above what this option does and why it has no bearing on a CFHTTP call. And in addition to being the wrong setting, that’s not even the right file type,. You’re trying to pass an entire keystore to a setting that accepts a single cert.
This option was commented out above, so I didn’t address it. It’s hard to follow what you’re doing when I just get bits and pieces and you don’t represent what you’re doing fully
I assume you want to set javax.net.ssl.trustStore, not javax.net.ssl.keyStore. The keystore is the set of keys that represent who you are and whether remote servers wish to trust you (mostly used for client cert auth). The trust store is the set of trusted root certs from a CA. This is what controls what CFHTTP/Java will trust in regards to a remote server.
So my current issue is that I need to be able to run box upgrade
This if the log output
Step 24/28 : RUN box upgrade
---> Running in 5a287e5eef23
Getting stable versioning information from https://downloads.ortussolutions.com/ortussolutions/commandbox/box-repo.json
ERROR (5.7.0+00653)
Sorry, we're having troubles accessing the interwebs now or the update site is down. Please try again later
Box Repo: [Connection Failure. Status code unavailable.] Loader Repo: [Connection Failure. Status code unavailable.]
The command '/bin/sh -c box upgrade' returned a non-zero code: 1
I have a deployment pipeline that builds and scans the container for vulnerabilities.
There are vulnerabilities found recently and I was going back through and adding various update commands to satisfy any that may be on the OS or the CLI dependencies
Um yes… that’s what we’ve been fixing this entire time, right? I’m not entirely sure why we’re covering that ground again.
99% of the time, the upgrade command in CommandBox will simply output a message telling you there is a new version, but you need to manually download it. So… I’m not sure any of this effort is really doing anything for you, lol. That said, you are 2 minor versions behind. 5.9.0 is the latest, not 5.7.0. I’m not clear how you’re installing CommandBox though. If you used a package manager like HomeBrew or apt or yum, then you can upgrade box through that. If you manually downloaded box onto the machine as your installation mechanism, that will be your upgrade mechanism as well in most cases.
So I went back to square one and got my application building and deploying and running successfully.
I recognize the fault in expecting box upgrade to do certain tasks that it was not intended to do.
I was down the box upgrade rabbit hole because commandbox lucee5 container image is extremely vulnerable. I wanted to run an update command to try and go through and update the dependencies that are being flagged, to a more recent version.
What is the best way to update the various dependencies that are coming through in the commandbox lucee5 image?
To be clear, 99% of those vulns are in Lucee’s dependencies. Also, I know it looks bad, but I’m not aware of any actual attack vectors in any of them that’s actually exposed. Here’s a ticket that contains most of the known libraries with CVE’s in Lucee you can use to track the progress
That said, Lucee has patched MANY of these already in it’s most recent releases, which brings me back around to the point that you seem to be on an old version of the image/CommandBox/Lucee. Just running docker pull will likely improve your situation a lot
Generally speaking, you shouldn’t be trying to upgrade the CommandBox that’s inside of our docker containers anyway. We cut a new docker image version every time CommandBox releases (which always ships with the latest Lucee and Undertow, etc). So all you need to do is keep your base docker image up to date and we do a lot of the work updating things for you.
You don’t, really. Like I said, the vast majority of these are coming from Lucee’s 3rd party dependencies and these are baked into Lucee in a manner that Lucee is dependent on the specific version of them it includes. Lucee is responsible for updating them and in the days of OSGI, it’s not as simple as just replacing jar files and crossing your fingers.
If you are finding vulns in libraries bundled directly in CommandBox which aren’t Lucee AND you’re on the latest CommandBox version (5.9.0) then please post them here so I can address them in the next release.
@jclausen has been doing some tremendous work getting our CommandBox docker image up on Iron Bank-- a government list of approved software that runs some very intensive scans on them so we’re already put a lot of effort into patching what we have control over and yelling at Lucee for the things they have control over
Just to chime in, @epochcoda, if you are looking to mitigate some of those scans, I would suggest starting from ortussolutions/commandbox:lucee-light as your base image and then adding only the extensions you want using the LUCEE_EXTENSIONS_INSTALL environment variable. Lucee 5.3.10 base ( aka Light ) has zero high or critical CVE vulnerabilities and only 4 that show up on my last scan - those are either Medium or Low.
Most of the remaining CVE vulnerabilities with Luce 5.3.x are in the extensions.
I suggested a task runner specifically because it removes the upgrade command from the picture and allows you to see if your proxy settings just work directly with the CFHTTP tag, to rule out any basic misunderstandings on your part about what proxy settings you are supposed to provide. If a stand-alone CFHTTP tag works, then we can look for differences between your code and how it differs from the code in the upgrade command. But if you can’t even get a standalone CFHTTP call to work, then we know CommandBox isn’t at fault and you may simply have the wrong proxy info or your proxy doesn’t work!