NicolasRouquette
commented
2 years ago There are two issues here:
1) The NPE vulnerability needs to be fixed in the code involved in the stacktrace above.
2) The logic for finding input OML files assumes that the folder where the catalog is located has only oml files.
See below where the assumption is made in the Oml2OwlApp from oml 1.0:
public void run() throws Exception {
...
OmlStandaloneSetup.doSetup();
OmlXMIResourceFactory.register();
final XtextResourceSet inputResourceSet = new XtextResourceSet();
inputResourceSet.eAdapters().add(new ECrossReferenceAdapter());
final File inputCatalogFile = new File(inputCatalogPath);
final File inputFolder = inputCatalogFile.getParentFile();
final OmlCatalog inputCatalog = OmlCatalog.create(URI.createFileURI(inputCatalogFile.toString()));
// load the OML ontologies
List<Ontology> inputOntologies = new ArrayList<>();
if (rootOntologyIri != null) {
URI rootUri = resolveRootOntologyIri(rootOntologyIri, inputCatalog);
LOGGER.info(("Reading: " + rootUri));
Ontology rootOntology = OmlRead.getOntology(inputResourceSet.getResource(rootUri, true));
inputOntologies.addAll(OmlRead.getAllImportedOntologies(rootOntology, true));
} else {
final Collection<File> inputFiles = collectOMLFiles(inputFolder); // assumption here.
for (File inputFile : inputFiles) {
final URI ontologyUri = URI.createFileURI(inputFile.getAbsolutePath());
LOGGER.info(("Reading: " + ontologyUri));
Ontology ontology = OmlRead.getOntology(inputResourceSet.getResource(ontologyUri, true));
inputOntologies.add(ontology);
}
}The function collectOMLFiles scans for all OML files in a given folder.
The problem stems from the fact that this code fails to verify that the files found would correspond to a catalog-mapped IRI to that file.
For example, consider the simple catalog:
<?xml version='1.0'?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public">
<rewriteURI uriStartString="http://" rewritePrefix="src/oml/" />
</catalog>Suppose the file layout looks like this:
./
./.history
./catalog.xml
./src
./docSuppose further that in the doc folder, there are some snippets of OML files intended for documentation purposes but these files may not be valid OML syntax because they are snippets.
A similar use case happens with a folder like .history for the popular VS Code extension git history where the .history folder will have timestamped files corresponding to local edits of OML files made in VS Code.
In both cases, the logic in Oml2OwlApp will include all *.oml files found in ./.history and ./doc even though these files are outside the intended scope of the files that should correspond to a catalog-mapped IRI.
To fix this, it is necessary to filter the results of collectOMLFiles to accept only those files whose location correspond to a catalog rewrite URI prefix.
The Scala-based OML tooling did this here:
-
The equivalent of the Oml2Owl adapter was the OML converter.
-
This involved computing an inverse mapping of the catalog to find which files would, via catalog rewrite rules, correspond to IRIs.
-
To calculate this inverse mapping, it is necessary to extend the Catalog implementation to get access at the protected rewrite rules.
dwagmuse
Description
A clear and concise description of what the bug is.
with the following in
build.gradle:in a project caught in the unpleasant OML 1.0 migration, I get:
Steps to Reproduce
Steps to reproduce the behavior:
Expected Behavior
A clear and concise description of what should be the expected behavior.
No NPE!
Additional Context
Enter any other details such as dependencies, environment, examples, etc.
Relevant screenshots
If applicable, add screenshots to help illustrate the issue.