Result of sprint trying to align with this version
Also Orcid client
But vulnerabilities for this version have appeared
Even the newest jena 4.4.0 still has some vulnerabilities (jackson-databind 2.13)
Question: If vulnerability mitigated in version 4 for Jena ARQ, would it be a big issue moving from 3 to 4?
Brian: Not sure. Would need to check.
Even if we mitigated vulnerability in Orcid client, vulnerability would still exist in Vitro/VIVO because of Jena ARQ dependencies
William: Primary reason for Orcid update was Swagger support
Swagger core 2.1.13 has jackson-databind (2.12.1) vulnerability
William: Remediate that by getting latest version of jackson-databind. Exclude from dependencies that may be bringing it in and update in Vitro/VIVO. Regular practice
Dragan: ARQ 3.16.0 brings in Jackson-databind problematic versions. Exclusion would not address that
William: No it wouldn’t. Might require refactoring in SPARQL engine. 3 to 4 (ARQ) is a major release and have to anticipate breaking changes.
Brian: From change log for 4.0.0 for Jena ARQ, doesn’t look too bad. Perhaps changes in IRI handling. But hopefully does not require a full dump of data as was required with 2 to 3. Does seem to require JAVA 11. Not sure if ready to do that.
Georgy: Do they still support TDB1 or requiring TDB2?
Brian: Not sure
Dragan: Lots of vulnerabilities for Orcid 0.6.3. Some seem to have been addressed. 0.6.4. Not visible on main page but will check in a day or so.
Used Vitro/VIVO release documentation. Updated ORCID and it worked. Ready to try release candidate for Vitro or VIVO
Will create pull request. VIVO API POM xml to handle ORCID API.
William: don’t want to rush 0.6.4 into next release. Required for Dynamic API feature and that isn’t really a candidate for the release. Should be a requirement for Dynamic API but not upcoming April/May release.
William: A few of the ORCID vulnerabilities are high, but will need to check which. Many are low or medium.
Brian: Like idea of timed releases. But would rather fix dependencies. Also William’s ideas of removing Spring requirements for that vulnerability. Turns out not difficult to do. Visualizations doing with dependency injection and could be easy to replace with something straightforward. Would allow us to get rid of Spring dependency. Perhaps address that vulnerability and these other vulnerabilities before putting out a release.
Dragan: Sense of time needed?
Brian: Spring dependency: probably a few hours
Not sure about time for the other dependencies
Consensus around approach to try and address vulnerabilities (Spring first) before release
Found some Selenium tests. Would be nice to have some end to end Selenium tests
Need to consider budget requirements for some small projects. Not a big budget but wondering if thinking we could use part of that budget for developing Selenium tests for Vitro/VIVO
Georgy: Selenium tests depend on user interface. If the interface is changing in the near future, wouldn’t make sense to devote time to Selenium tests for current interface.
Also, if we decouple from Freemarker, and use a single page application framework, could instead do integration tests.
Need help with technical documentation. Need to define space and then move wiki space to another.
Brian: Should be a wiki page that describes how this. Clone and then mark as future release
Dragan: Will work and then contact Georgy if there are any questions
Georgy: question about deletion of individuals
Would it be enough to check if construct query has write enabled?
Brian: Need to think about it. Could parse the query and check to see there aren’t disjointed triple patterns that don’t connect to that bound variable
Also investigated GitHub code management: templates
Dragan: Testing will be postponed while we’re waiting to see what our next user interface will be. Next week with full group should start working on plans for next sprint in last week of May
Dragan Ivanovic to investigate organizational (management) aspects of DSpace community and to prepare discussion for the next meeting what might be adopted from there (GitHub actions, labels for issues, template for issue, template for PR)
Indicating note-taker