Bug 1476028 - Id Cert Serial number should be less than 53 bits wide or be a string in JSON response
Id Cert Serial number should be less than 53 bits wide or be a string in JSON...
Status: NEW
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: candlepin-bugs
Katello QA List
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2017-07-27 17:09 EDT by Shayne Riley
Modified: 2017-08-03 10:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Shayne Riley 2017-07-27 17:09:53 EDT
Description of problem:

The ID certificate serial number is a long (64-bits). It gets serialized into JSON, and returned to the client. The client may deserialize this into a double, which can only have an int up to 53-bits long before precision gets lost.

This is a problem because some tools and libraries, most notably any modern browser, node.js, jq, and probably more, will load numerical values not as a long, but as a double, and the serial number is now incorrect.

Since it is entirely possible for a javascript client to exist which would handle consumer payloads, the ID certificate serial number should either:

- fit in 53-bits
- be a string

And if we're changing the "serial" value, we should change the "id" value too, since they both are equal, from what I see.

How reproducible:


Steps to Reproduce:
1. Get any consumer from candlepin, which should include the id-cert serial number.
2. Grab the id-cert serial number. Here's an example one: 2549664266108101582
3. Open your browser's developer tools window (ctrl+shift+I)
4. Paste this into the console prompt: JSON.stringify(JSON.parse('{"idCert": {"serial": {"id": 2549664266108101582}}}'));

Actual results:
You get this output:


Expected results:
Well, that's the thing, is this is expected since we're treating the serial as a number, rather than as a string. If it were a string, we wouldn't worry about precision loss.
Comment 1 Kevin Howell 2017-07-31 13:12:04 EDT
Al, we wanted your thoughts on this one...
Comment 2 Alex Wood 2017-08-01 11:14:31 EDT
Yeah, providing it as a string in the JSON response seems reasonable to me.  It may be tricky with Jackson though since I imagine we will still want it to be a long internally but we'll need to tell Jackson to serialize it as a string.  We'll also need to look through subscription-manager and see where/how it uses the serial.  My instinct is that subscription-manager will be agnostic toward the data type.

Nice catch, Shayne.

Note You need to log in before you can comment on or make changes to this bug.