`receive --dump` doesn't escape some outputs

[bmillwood]

The ones I ran into are the from parameter in clone (code), and data for set_xattr. Maybe xattr names also strictly speaking need to be escaped?

This makes it impossible to perfectly parse receive --dump programmatically because paths can contain whitespace and equals signs, and some xattr values on my system even contain newline characters.

It looks like this is already handled for some other commands, by using PRINT_DUMP_NO_NEWLINE and then print_path_escaped, so I bet this would be a pretty easy fix. (I could possibly do it myself but I'm hoping to avoid all the overhead of learning how to compile and test this stuff for the first time :) )

[kdave]

Thanks for the report. The path in clone is indeed missing the encoding. I can't find any defined constraints for the xattr names, values can be expected to be any value so this needs to be escaped.

[kdave]

Ok, it is possible to create xattr with eg. a newline:

$ setfattr -n "user.$(echo -ne 'hi\nthere')" -v 123 xattr
$ getfattr -d xattr
user.hi\012there="123"

[kdave]

Fixed in devel.

[bmillwood]

thanks :)

(doesn't seem essential, but I wonder if print_path_escaped should be renamed now it's used for non-path strings as well?)

[kdave]

Yes, that's a good point, feel free to send a patch to rename it.

[kdave]

Fix released in v6.9.1.