Bob Matthews wrote:
Maven 3.8.1 release notes wrote:
We received a report from Jonathan Leitschuh about a vulnerability of custom repositories in dependency POMs. We’ve split this up into three separate issues:
Possible Man-In-The-Middle-Attack due to custom repositories using HTTP
More and more repositories use HTTPS nowadays, but this hasn’t always been the case. This means that Maven Central contains POMs with custom repositories that refer to a URL over HTTP. This makes downloads via such repository a target for a MITM attack. At the same time, developers are probably not aware that for some downloads an insecure URL is being used. Because uploaded POMs to Maven Central are immutable, a change for Maven was required. To solve this, we extended the mirror configuration with <blocked> parameter, and we added a new external:http:* mirror selector (like existing external:*), meaning “any external URL using HTTP”.
The decision was made to block such external HTTP repositories by default: this is done by providing a mirror in the conf/settings.xml blocking insecure HTTP external URLs.
Possible Domain Hijacking due to custom repositories using abandoned domains
Sonatype has analyzed which domains were abandoned and has claimed these domains.
Possible hijacking of downloads by redirecting to custom repositories
This one was the hardest to analyze and explain. The short story is: you’re safe, dependencies are only downloaded from repositories within their context. So there are two main questions: what is the context and what is the order? The order is described on the Repository Order page. The first group of repositories are defined in the settings.xml (both user and global). The second group of repositories are based on inheritence, with ultimately the super POM containing the URL to Maven Central. The third group is the most complex one but is important to understand the term context: repositories from the effective POMs from the dependency path to the artifact. So if a dependency was defined by another dependency or by a Maven project, it will also include their repositories. In the end this is not a bug, but a design feature.
Bob Matthews wrote:Could or should this work ?
Bit confused about (b) since instruction is to use weka package manager to install ?
Bob Matthews wrote:re org.ta4j.core package
Bottom line is I don't need this Technical Indicators section to compare results with paper approach
I don't know how to see the equivalent constructor in the official version of the package
However I would like to figure out how to remove the "missing package" message
Bob Matthews wrote:When I did this I got rid of the original folder setup and put all java files into the one folder
Bob Matthews wrote:However I can't figure out what has happened to the likes of
eu.verdelhan.ta4j.core.BaseStrategy and .Order and .Rule and .Tick