Genome annotation editor, with a Java servlet backend and a Javascript client that runs in a web browser as a JBrowse plugin
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.
I guess we'll see! I'd love to see json in postgres more, it's such a happy medium ground.