Genome annotation editor, with a Java servlet backend and a Javascript client that runs in a web browser as a JBrowse plugin
I did not see the issue before, thanks for the post.
"Upper IT" at aTm is very involved right now, and some of it is about 1.X. However, I just got out of a meeting and I'll know over the next few days about how much they want to treat it as an actual problem. I'll keep y'all posted on what is found out.
Yeah, the latest one applies under non standard configuration with something related to JMS toggled. I added it to that GitHub issue, but probably not affecting most folks
Once we've seen that there are many critical and high issues, we can't ignore it. I am really unqualified in terms of Java development, but am tryin to slog through updating components. Is there anyone on the JBrowse/Apollo dev team or other developers that are interested in coming together to help update test these updates?
@childers it is using 1.2.17 . . . not sure all of the risks, but here: https://logging.apache.org/log4j/2.x/security.html . . mostly log4j 1 isn't affected for most of these.
No, not suggesting ignoring it, just that the exploit not applying to most users means it's a lot lower of a priority. The list Colin posted was definitely full of things to address, but for a lot we shouldn't discard that the exploits simply don't work for many instances, that should factor in the "panic patching" calculation a bit.
@hexylena:matrix.org Apologies for my language there, I didn't think that the list of errors was being ignored, it's good to see that there is interest to bring the dependencies up to date. I am concerned because I read the earlier statements as dismissive of the critical and high vulnerabilities. Just because the log4j is not impacted by this critical vulnerability, there is another critical vulnerability that affects the version that is being used.
Oh no worries, apologies for coming across dismissive, I can see that interpretation for sure. I wish I had bandwidth to work on any of these myself
I think I personally am stuck with defense in depth and locking it down as much as possible, not sure what else we can do, it's such a long list
And worse it looks like less than half have a fix available which is not great
I can't remember if we posted it or not, but for other large Apollo users, we built this to work around slow loading of large large organism lists. For hundreds of organisms it can take load times from 10 minutes to 30 seconds. https://github.com/galaxy-genome-annotation/apolpi/
2 replies
There aren't that many routes with this issue that a shim works fine
I’m going to create an Apollo instance for AGR that has the NIH origanisms in it (human, rat, mouse, zebrafish, worm, fly and yeast) in it, and (presumably) back it with Chado as a demonstration with the idea of promoting it as the tool to be used by sequence curators at the respective MODs to use. Can I just fire up docker-compose with Apollo and Chado and I’m off to the races?
(actually, the only organisms in it might be yeast, worm and fly, at least to start)
If you want to use the postgresql db it sets up that's fine, I was just thinking your DB would be in your Chado docker image instead. TBH I don't really know how to integrate Apollo and Chado, but looking at the docs you might still need the buildt-in postgresql since Chado is just for exporting: https://genomearchitect.readthedocs.io/en/latest/ChadoExport.html
FYI @scottcain @hexylena:matrix.org had one setup long ago that used a compose file if that helps. However like @garrettjstevens said Chado should be baked in already. Looks like its using 1.31 here: https://github.com/GMOD/Apollo/blob/develop/Dockerfile#L37 . . if you just fix this line you can get one here, but converting these to use docker compose shouldn't be that hard either.
I've been trying to move the log4j issues in apollo2.x forward with really limited success. Right now I'm trying to use the bridge files to get Apollo2 to the current log4j version without having to recode anything but it isn't working. It's building, and the deploy says it works, but the deployed WAR isn't recognized.
https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html
https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html
Also, moving it would be difficult if not impossible since a lot of the other underlying dependencies use log4j1 . .
@nathandunn Log4j1 has been EOL since 2015, and while it doesn't have any critical security issues, The one issue it has will not be fixed. Colin introduced me to grype, an awesome tool for finding vulnerabilities in a project. Apollo has 16 Critical and 75 High rated vulnerabilities. I'm just trying to get ahead of any possible IT security issues.
I forgot to say that I've been requested to make sure all log4j instances are up to date, hence me trying to sort out the bridging 1-> files
@childers oh for sure. I think Grails 2 (what Apollo 2 is built on) has been EOL'd https://objectcomputing.com/products/grails/grails-version-support-schedule . here is a relevant question here: https://stackoverflow.com/questions/70426705/upgrade-log4j-to-last-version
I guess what I am thinking are: (1) fixing log4j1 may not have a vulnerability and (2) it may not be possible to remove it from Grails 2 / Apollo 2 (3) hopefully most of the other critical issues are either fixable or not applicable, but its hard to say (4) it may make more sense to work with @garrettjstevens / @rbuels on pushing forward the next version of Apollo (1-2 years?).
and also thanks for this response, I think I can maybe justify the log4j1 if there are no vulnerabilities. I'll focus on some of the other issues.
@ihh That’s kind of an open question at the moment (usefulness to AGR); there has been some discussion that having a persistent store for sequence and structural annotations with some sort of API sitting on top of it would be nice, and it occurred to me that the combo of Chado and Tripal would give that (I think Tripal provides a swagger-like api for chado, I have to make sure of that). But if whatever Apollo chooses as a persistent store provided an API, that might be good too.
BUT—I will say that there are lots of small MODs that use Chado and some that use Apollo, so making sure that data can easily move between them is pretty important.
Also @nathandunn yes, of course :-)
passing this along from @hexylena:matrix.org (who else) as its several cool things at once, though not sure if it is better here or in the JBrowse group: https://github.com/hexylena/jbrowse-chado-postgraphql + https://github.com/hexylena/chado-postgraphql + https://github.com/hexylena/jbrowse-chado-postgraphql/blob/c8b1296277611a5c804329e5f60c8dbae2e0f774/js/Store/SeqFeature/GraphQL.js#L115 . . .. not sure if of interest (or just interesting) to @scottcain / @rbuels / @garrettjstevens
It's a bit of a hack, but postgraphql was pretty neat and I wanted to try graphql at the time
I'm not sure I'm convinced by it in the end but, it's definitely potentially interesting.
Yeah, definitely. If the choice is between switching to a graph DB, and postgres+this, I'd love to see how far we can get with hacks like this before swapping out the DB
Postgres scales so much better, there are orders of magnitude more folks who understand postgres scaling, and I don't need to buy an expensive license for neo4j if it turns out I need to shard or scale.