-
Notifications
You must be signed in to change notification settings - Fork 320
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
xml reserved chars are not escaped #519
Comments
I think this should only effect:
the above failing tests were setting For now, I think I would only do context-attribute name and value, since it is unlikely? (@mhennerich ?) that the kernel would have a attribute name or channel id with those chars in them? |
I have something that seems to work, but it still fails when using iio_genxml (it can read the context, but then when re-encoding things - it fails. - I think what it suppose to happen is to set xmlEncodeEntitiesReentrant in the appropriate places. I will work on it a little more tomorrow. |
@mhennerich thinks this is a recent thing, so checking.... as far as I can tell - this has always been there, According to git history, on Nov 18, 2016 : 04bc3e5 was when Testing on 0.9 :
Testing v0.14 (29 Jan 2018, about a year later), exactly the same failures local works, remote fails.
v0.18 (06 May 2019) nearly another year later - still the same error.
master is the same. so I think this has been there since the beginning. |
…utes Per #519, xml entities (<, >, ", ', and &) were not encoded properly, and if used in the libiio.ini file (which was added in 77568c7 ) cause the libiio library to fail. This fixed that by adding a generic way to encode things in xml.c and uses them in context.c Right now, we only encode context attributes. In theory this could also effect: - attribute name - buffer-attribute name - channel id - context name - debug-attribute name - device id - scan-element index Since most of those are encoded in file names, we shouldn't have those chars anyway. Now that we know the issue, and understand the fix, if anyone sees any issues, please feel free to report. Tested on Zed + FMCOMMS3, with both 0.19 (with fix) and old libraries without fix. As long as the the version which is reading the file has the fix - it works with older libraries (is backwards compatible). Signed-off-by: Robin Getz <[email protected]>
This is now fixed in #526
network with same version:
network with older version (without the fix):
so closing here. |
…utes Per #519, xml entities (<, >, ", ', and &) were not encoded properly, and if used in the libiio.ini file (which was added in 77568c7 ) cause the libiio library to fail. This fixed that by adding a generic way to encode things in xml.c and uses them in context.c Right now, we only encode context attributes. In theory this could also effect: - attribute name - buffer-attribute name - channel id - context name - debug-attribute name - device id - scan-element index Since most of those are encoded in file names, we shouldn't have those chars anyway. Now that we know the issue, and understand the fix, if anyone sees any issues, please feel free to report. Tested on Zed + FMCOMMS3, with both 0.19 (with fix) and old libraries without fix. As long as the the version which is reading the file has the fix - it works with older libraries (is backwards compatible). Signed-off-by: Robin Getz <[email protected]>
…utes Per #519, xml entities (<, >, ", ', and &) were not encoded properly, and if used in the libiio.ini file (which was added in 77568c7 ) cause the libiio library to fail. This fixed that by adding a generic way to encode things in xml.c and uses them in context.c Right now, we only encode context attributes. In theory this could also effect: - attribute name - buffer-attribute name - channel id - context name - debug-attribute name - device id - scan-element index Since most of those are encoded in file names, we shouldn't have those chars anyway. Now that we know the issue, and understand the fix, if anyone sees any issues, please feel free to report. Tested on Zed + FMCOMMS3, with both 0.19 (with fix) and old libraries without fix. As long as the the version which is reading the file has the fix - it works with older libraries (is backwards compatible). Signed-off-by: Robin Getz <[email protected]>
If a attribute has an xml reserved char, we don't escape it, and it causes the xml parser to blow up.
We get errors like:
OR
OR
This isn't an issues for most kernel attributes, as they are pure numbers, but it is a problem on some of the new ini file processing, which can contain more free text.
<
<
>
>
"
"
'
'
&
&
We also don't verify that Element and Attribute names can NOT contain characters
<
,>
,"
,'
, or&
escaped or otherwise. (per the xml standard).The text was updated successfully, but these errors were encountered: