Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 03 17:13

    garrettjstevens on Issue110

    (compare)

  • Jul 03 17:13

    garrettjstevens on main

    Delete stored files on failed i… (compare)

  • Jul 03 17:13
    garrettjstevens closed #112
  • Jul 03 17:13
    garrettjstevens closed #110
  • Jul 03 17:13
    garrettjstevens edited #112
  • Jul 03 17:04
    garrettjstevens ready_for_review #112
  • Jul 03 17:04
    garrettjstevens synchronize #112
  • Jul 03 17:04

    garrettjstevens on Issue110

    Small cleanup (compare)

  • Jul 03 16:47

    garrettjstevens on generic_subfeature

    Preserve feature location infor… Initial generic subfeature glyph (compare)

  • Jul 01 08:41
    kyostiebi assigned #115
  • Jul 01 08:41
    kyostiebi opened #115
  • Jun 30 17:40
    garrettjstevens opened #114
  • Jun 30 16:21
    kyostiebi commented #111
  • Jun 30 16:19

    kyostiebi on 111-child-location-validation

    tmp commit tmp commit Merge branch '111-child-locatio… and 5 more (compare)

  • Jun 29 15:15

    garrettjstevens on 111-child-location-validation

    Restore featureId in children (compare)

  • Jun 28 22:13

    garrettjstevens on fix_type_editing

    (compare)

  • Jun 28 22:13

    garrettjstevens on main

    Fix editing type in ApolloDetai… (compare)

  • Jun 28 22:13
    garrettjstevens closed #113
  • Jun 28 21:53
    garrettjstevens synchronize #113
  • Jun 28 21:53

    garrettjstevens on fix_type_editing

    Use previous version of workflo… (compare)

Garrett Stevens
@garrettjstevens
I think we're safe (from that at least), see a bit of discussion here: GMOD/Apollo#2640
Scott Cain
@scottcain
Sounds good. Thanks!
Curtis Ross
@cross12tamu

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.

childers
@childers
There are 2 other critical security issues with the log4j version in apollo2. It might be too old for the current crisis, but it is still vulnerable to other exploits
Helena
@hexylena:matrix.org
[m]
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
childers
@childers
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?
Nathan Dunn
@nathandunn
@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.
Helena
@hexylena:matrix.org
[m]
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.
childers
@childers
@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.
Helena
@hexylena:matrix.org
[m]
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
Helena
@hexylena:matrix.org
[m]
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/
Curtis Ross
@cross12tamu
^ can confirm :)
Nathan Dunn
@nathandunn
yikes @hexylena:matrix.org . Looks like the current method collects organisms correctly but then instead of doing a join in a single query to get counts (as you do) it performs a separate query. Wish I had time to fix.
2 replies
Helena
@hexylena:matrix.org
[m]
There aren't that many routes with this issue that a shim works fine
Scott Cain
@scottcain
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)
Garrett Stevens
@garrettjstevens
No, the Dockerfile for Apollo runs PostgreSQL. You'd probably want to set up your own Dockerfile using that one as a reference but changing the database stuff.
Scott Cain
@scottcain
I like postgresql :-)
Garrett Stevens
@garrettjstevens
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
Nathan Dunn
@nathandunn
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.
Scott Cain
@scottcain
Cool; at the moment I’m at the stage of “I feel like I should probably look into doing this” so we’ll see how things progress from here.
childers
@childers
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
Nathan Dunn
@nathandunn
@childers I don't think that you want to use log4j2 with Apollo2. The log4j1 shouldn't have the critical vulnerabilities so it shouldn't be a problem.
Also, moving it would be difficult if not impossible since a lot of the other underlying dependencies use log4j1 . .
childers
@childers
@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
Nathan Dunn
@nathandunn
@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?).
childers
@childers
@nathandunn I didn't realize that it was grails that pinned the log4j version.
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.
Scott Cain
@scottcain
@garrettjstevens do you expect that new development in Apollo will allow Chado as a persistant store for annotations?
Robert Buels
@rbuels
@scottcain no that's not in the plans right now
Ian Holmes
@ihh
@scottcain is that something that would be useful to AGR?
Nathan Dunn
@nathandunn
@scottcain , this is your chance to have Chado be THE persistant store for annotations
Scott Cain
@scottcain
@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 :-)
Nathan Dunn
@nathandunn
If you embeded a module API within Tripal to talk to Apollo you would have a lot of happy people within the GMOD community. Those modules are pretty flexible in terms of what you can add (elasticsearch, etc). Of course, you will be entering a world of PHP potentially.
Scott Cain
@scottcain
Well, crap, I had two meetings today at 8:00 and missed them both. Notifications must be messed up on my phone. Hopefully the Apollo call went well.
Robert Buels
@rbuels
Running a little late for the team meeting, I’ll be there in a sec though
Nathan Dunn
@nathandunn
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
Scott Cain
@scottcain
Certainly both interesting and of interest to me. She does great stuff!
Helena
@hexylena:matrix.org
[m]
Aw, cheers Scott!
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.
Scott Cain
@scottcain
I know that there was discussion about Chado and graph databases a few years ago, so there are probably other people in the Chado community that might find this interesting.
Helena
@hexylena:matrix.org
[m]

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.

Nathan Dunn
@nathandunn
I think that @rbuels and company are heading a different direction, but not sure. The JSON column support with postgresql might also be a great way to go, or simply a different approach to the UI.