Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

YAML frontmatter cannot have a folded scalar #2024

Closed
SirNate0 opened this issue Dec 22, 2023 · 1 comment · Fixed by gollum/gollum-lib#454
Closed

YAML frontmatter cannot have a folded scalar #2024

SirNate0 opened this issue Dec 22, 2023 · 1 comment · Fixed by gollum/gollum-lib#454

Comments

@SirNate0
Copy link

SirNate0 commented Dec 22, 2023

Describe the bug
Including a folded scalar in the YAML results in an error, "Failed to load YAML frontmatter: (<unknown>): did not find expected alphabetic or numeric character while scanning an anchor at...".

To Reproduce
Add front matter such as the following

---
Literal Scalar: |
  abc
  
  123
Folded Scalar: >
  abc
  
  123
Escaped: "abc\n\n123"
---

You will get as the output

errors
Failed to load YAML frontmatter: (<unknown>): did not find expected alphabetic or numeric character while scanning an anchor at line 6 column 16

Expected behavior
The yaml should be parsed successfully. The folded scalar should have different whitespace than the others (only one newline instead of two), though keeping the present behavior where new lines seem to be turned into spaces is acceptable, I suppose, as long as it doesn't give an error.

Environment Info

Gollum 5.3.2
Running on: x86_64-linux-gnu with Ruby version 3.0.2
Using:
rugged 1.7.1
gollum-rugged_adapter 2.1.0
gollum-lib 5.2.4
Markdown rendering gem: kramdown
Other renderering gems:
none
@dometto
Copy link
Member

dometto commented Dec 27, 2023

Thanks for the report. I was able to reproduce and write a test case. The problem was we were HTML escaping the entire YAML string before loading it, so the > was getting scrubbed, invalidating the YAML.

See gollum/gollum-lib#454 for the test case and fix.

Instead of trying to handle this one exception, I thought it might be better to go for a robust approach and not touch the YAML before we parse it. I think the new approach is robust and secure, but of course it will be slower. Feedback very welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants