GNOME Bugzilla – Bug 350248
Schemas validity error: Invalid value for integer
Last modified: 2021-07-05 13:20:33 UTC
Please describe the problem: Validating xml digital signature results in this error: podpisXAdES-A-2.xml:107: element X509SerialNumber: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}X509SerialNumber': '48148227804797807743377971039962384207' is not a valid value of the atomic type 'xs:integer'. It seems 38 digits is too much for libxml2 to handle, however http://www.w3.org/TR/xmlschema-2/#integer-lexical-representation says that integer is countably infinite and unbounded in compare to int or long type. See http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
The definition you point to says: "[Definition:] integer is ·derived· from decimal by fixing the value of ·fractionDigits· to be 0and disallowing the trailing decimal point. " and points to the definition of decimal which also says: http://www.w3.org/TR/xmlschema-2/#decimal Note: All ·minimally conforming· processors ·must· support decimal numbers with a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number ·must· be clearly documented. libxml2 should be fine up to 24 digits. Yours has 38 which exceeds our limit and probably the limits of a number of processors. I guess you never use that value as a numeric, it should be really defined as a string composed of numbers. Daniel
XML Digital signature schema (dtd and xsd, link provided above) is defined by W3C and we can't just change it. This value represents certificate serial number, that are not limited by length. We are handling this value as hugeint (or BigDecimal in java). Other implementations don't have such shortcomings (msxml and/or apache xalan+xerces). Note for limiting number of digits is applicable only for minimally conforming processors. Therefor I would recommend to mark this as feature request, since we don't want to be only minimally conforming, right? http://www.w3.org/TR/xmlschema-2/#d0e11239 This link shows that integer is defined as unbounded (if you don't want to support schema as min conforming as noted before). That's why, there is a reason for existence of int and long schema types. Matej
If it's a serial number it's used as a identifying string not as a numeric value, then the schemas sounds inadequate to me. Reopening anyway, no garantee that this will ever be fixed because I will not add support for numeric values of arbitrary lenght, if you really need it use something else. Daniel
I dare insist (and CC aleksey on this bug) that this bug is really annoying, they are few use of really large integer in schemas, but that one is significant. All Verisign issued certificates have large serial numbers, similar to the one in this bug. In fact, x509 certificate serial numbers are limited to 20 byte (in 2-complement binary representation). Currently the libxml2 schema code stores the integer value in three long variable, which results in a limit at 24 digits. My hand calculation is that if you expand to using five long variables, it would be enough to handle dsig's X509SerialNumber field.
Propose a patch which works on the existing regression tests, provide examples to test your need, and post them on the list or attach them to this bug, and this is very likely to go forward. I still think using arbitrary long strings for numeric values is an error, it makes people who uses the right type for the right kind of value (in that case your correct type is a string with a facet limiting to numerical characters, you do not care about the discrete and ordering property value of the integer, I still maintain the schemas is just buggy, result of people just trying a couple of tools available instead of thinking about what they were doing, if that's not the case tell me where you use ordering in x509 certificate, otherwise sorry this is BS!) Tell me why everybody using integer for what they are should be paying the extra cost because someone designed a schemas wrong ? Where is the annoyance really ? Anyway provide a patch, tests, and I may apply it, but fundamentally there is something wrong in the schemas you are using. Daniel
Adding link to now closed dup: http://bugzilla.gnome.org/show_bug.cgi?id=434557 comment from dup: From working draf http://www.w3.org/TR/xmlschema11-2/#conformance When either of these is so, a conforming processor must indicate to the user and/or downstream application that it cannot process the input data with assured correctness (much as it would indicate if it ran out of memory). When the datatype validity of a value or literal is uncertain because it exceeds the capacity of a partial implementation, the literal or value must not be treated as invalid, and the unsupported value must not be quietly changed to a supported value.
In my case, I have a number with 2 digits before the decimal point and 29 after. libxml2 fails to validate it. I believe this is a legit example.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxml2/-/issues/ Thank you for your understanding and your help.