You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a field where any character goes (like a 16 character random key), make it a ZARF_VAR
Set that ZARF_VAR to have a value like this: "g\"Rg{067[R:#^_["` in the config yaml
Render the values.yaml (assuming this causes an error, ctrl-c when Zarf starts to suffer, and the log file will still be there)
Notice how that middle " got rendered such that it broke the YAML
Expected result
Quotes that are a value not a quote are escaped before being inserted in in-place of a ZARF_VAR.
Actual Result
The quote caused a YAML parser error because it was not escaped.
Visual Proof (screenshots, videos, text, etc)
Severity/Priority
Low
Additional Context
Obviously I can avoid this here by changing my dev-secret key. However, anywhere someone auto-generates their service-to-service secret keys this issue may re-appear.
The text was updated successfully, but these errors were encountered:
I would say this is a limitation of the variable templating. It does not consider YAML syntax when adding the variables. This puts the onus on the user to make sure that the end result will be valid YAML. I am not really sure how Zarf should solve this issue right now. If you want to solve the issue right now I would suggest switching to using single quotes around the string.
Environment
Device and OS: Sys76, PopOS laptop
App version: UDS 0.11.0, Zarf 0.34.0
Kubernetes distro being used: k3d
Other: Developing harbor UDS package
Steps to reproduce
"g\"Rg{067[R:#
^_["` in the config yamlctrl-c
when Zarf starts to suffer, and the log file will still be there)"
got rendered such that it broke the YAMLExpected result
Quotes that are a value not a quote are escaped before being inserted in in-place of a ZARF_VAR.
Actual Result
The quote caused a YAML parser error because it was not escaped.
Visual Proof (screenshots, videos, text, etc)
Severity/Priority
Low
Additional Context
Obviously I can avoid this here by changing my dev-secret key. However, anywhere someone auto-generates their service-to-service secret keys this issue may re-appear.
The text was updated successfully, but these errors were encountered: