Report command failing in 1.9.1

[psiotwo]

robot report --input-iri http://purl.obolibrary.org/obo/chebi.owl --fail-on none -o report.json fails with

The incoming YAML document exceeds the limit: 3145728 code points.

@jamesaoverton Looks like it is connected to upgrading SnakeYaml to 1.32 which introduced 3M default for codepointlimit. See changelog.

[jamesaoverton]

Thanks for the report. They're now setting the codepointlimit at 3MB, which seems tiny. The simple thing to do is just increase the limit. I guess we can just get the size of the YAML string from toYAML().

We could also generate the JSON directly, instead of going through YAML.

[psiotwo]

Hm, so SnakeYaml seems to be used

1. during ontology loading, and also
2. (indirectly through jackson-dataformats-text) during toJSON serialization of a report .

The reported issues relates to 2, see an open issue at jackson-dataformats-text - the hotfix on their side was to downgrade SnakeYaml to 1.31.

As a hot fix downgrading SnakeYaml should be the easiest way to go forward. So my imminent proposal is this PR.

In longer run, I definitely vote for avoiding transformation to YAML inside toJSON.

[jamesaoverton]

Hmm. I upgraded to 1.3.2 because of a Dependabot advisory: "snakeYAML before 1.31 vulnerable to Denial of Service due to Out-of-bounds Write"

[psiotwo]

😄 I see ...

Looking at IOHelper I was even unaware there is a YAML serialization of an ontology ... didn't find anything in ROBOT doc either - so if this bit of code is actually used, then the vulnerability might occur, indeed. The questions is what impact such attack actually would have here ...

Anyway, would need to revert to some previous version of robot in my pipeline until this is resolved.

[jamesaoverton]

In the dawn of time, some of us played with the idea of "YAML-LD": #20 (comment). I seriously doubt that it's being used much in practice.

There is a more official YAML-LD project, I guess, https://github.com/json-ld/yaml-ld, but I don't know anything about it.

[psiotwo]

Thanks for info, interesting ...

If so, then one option also would be just to write some deprecation warning/disclaimer in the doc of YAML->JSON transformation. This might justify the downgrade and then wait until FasterXML/jackson-dataformats-text#337 is resolved.

Unless there is quick (but cleaner) way that I cannot see ...

[jamesaoverton]

Still not fix fixed upstream. I'm frustrated. I'm just going to merge your PR. Thanks!