Upgrade to SnakeYAML 2.1

[lread]

See commits for details.

Up for debate: my approach to dealing with unsafe YAML should be questioned.

An interesting alternative would be to also expose the new TagInspectors when using clj-yaml's :unsafe option. But, I think (correct me if I am wrong) we might already have this feature-wise via :unknown-tag-fn.

Closes #86

[lread]

New nvd scan CVEs are suppressed for SnakeYAML 1.33, I'll suppress them for SnakeYAML 2.0 as well. Or maybe all versions of SnakeYAML.

[borkdude]

@lread If I understand correctly, you passed unsafe to the loader and made the change there to make the existing tests pass, right?

[lread]

@lread If I understand correctly, you passed unsafe to the loader and made the change there to make the existing tests pass, right?

Thanks for asking @borkdude.
Yes, but only for :unsafe mode.
I've modified clj-yaml :unsafe behaviour to mimic SnakeYAML 1.33 behaviour.
SnakeYAML 2.0 now has tag inspectors.
The default tag inspector will deny all global tags.
When using :unsafe we mimic SnakeYAML 1.33 and allow all global tags via the TrustedTagInspector

[borkdude]

That seems a good solution to me. Is there anything you are uncertain about?

[lread]

That seems a good solution to me. Is there anything you are uncertain about?

I've claimed that clj-yaml's :unknown-tag-fn is equivalent-ish feature-wise to what SnakeYAML's 2.0 tag inspectors offer. I haven't fully validated that claim.

But... as long as :unknown-tag-fn continues to work, that's probably not important at this time.

[lread]

I think it might be a good idea to let the dust settle a bit on the SnakeYAML 2.0 release.

Maybe wait a week? Is anybody in a hurry?

For example, this new commit removes a new SnakeYAML class I used in this PR. Easy to adapt, but there might be other things like this coming in the near term.

[borkdude]

Yes, let's wait a month.

[frenchy64]

Just to confirm my understanding: this PR is not necessary to resolve any security vulnerabilities because it's already safe to use snakeyaml 1.33 via clj-yaml 1.0.26 since clj-yaml is untrusting by default?

[borkdude]

@frenchy64 by default, yes

[lread]

@frenchy64, yup, that's our understanding and position.

We do plan to upgrade to SnakeYAML 2, but felt it best to wait for the dust to settle.

[frenchy64]

Thanks. Is there any way to parse untrusted yaml with clj-yaml 1.0.26? Want to audit my code base for such code so I can definitively rule out CVE-2022-1471.

[lread]

Thanks. Is there any way to parse untrusted yaml with clj-yaml 1.0.26?

See the user guide: https://github.com/clj-commons/clj-yaml/blob/master/doc/01-user-guide.adoc#unsafe

[borkdude]

Yes, via an option:

:unsafe true
:unknown-tag-fn ...

Check docs for more info.

[geekingfrog]

FYI: don't forget to change the project version there
I'm currently using this branch in our builds and had to patch it with sed. (not complaining, it's really a filthy workaround for the security scanner at my org)

[lread]

FYI: don't forget to change the project version there

@geekingfrog, do you mean the clj-yaml version?
If so, that is automatically handled by the clj-yaml release workflow and therefore automatically updated when we next release.

[geekingfrog]

Yes, the clj-yaml version. I missed this workflow, so you're all good.

[lread]

@borkdude, it has been about a month... but maybe we'll just wait until SnakeYAML 2.1 is released?

In the short term, for this PR, I'll adapt to current 2.1 changes and sync with master.

[borkdude]

Yes. I also want to downgrade ordered before a new clj-yaml release since it had some issues with native image.

[lread]

Yes. I also want to downgrade ordered before a new clj-yaml release since it had some issues with native image.

If I get all the privs I need, we'll get a release out of ordered with your fix for clj-commons/ordered#71 for native-image sometime soon.

[lread]

Seems like we can finally merge this one! Agreed @borkdude?

[borkdude]

Yeap!