Look at 32/64 bit interop between shibd and the webserver plugins
Description
Environment
Activity
Rod Widdowson September 28, 2017 at 2:49 PM
20e7abc
Scott Cantor September 28, 2017 at 2:16 PM
I guess the alternative, aside from using the new C types we won't have everywhere, is to test based on the size of int or long and rely on INT_MAX/LONG_MAX, but if the code works, I don't have a better idea.
FWIW, I believe 0x80000000 is just going to be negative in the 32-bit case, that's INT/LONG_MIN, I believe. You can't negate that back to a positive without overflowing.
Rod Widdowson September 28, 2017 at 12:57 PMEdited
After a log of playing around I came up with this monstrosity
I did not want to have to play around with config and this is safe for all widths of longs. Basically we clear the sign bit and then check the 32 bit sign bit and the upper 4 octets. This works for all values except 0x80000000 in the "long is 32 bits" case which (apart from the obvious optimization) is why we have the sizeof check too. Mind you 0x80000000 is a odd 32 bit number...... (because he negative of itself is inexpressable - does that make it positive or negative?)
Is this too hideous?
Rod Widdowson September 26, 2017 at 3:12 PM
— Yay, threaded comments are back.
Excellent.
— sender and receiver are ultimately both sides I had actually written "shibd" and "webserver" til I realized that its very much a 2 way street...
— I would do it on the sender side I think. Which has the benefit of being nice and easy
Scott Cantor September 26, 2017 at 2:59 PM
Yay, threaded comments are back.
Note that (I assume this is obvious) sender and receiver are ultimately both sides, not just the shibd side. But yes, I think it's true that one could enforce this at the marshalling or unmarshalling boundary (sender or receiver makes right).
I don't think we should add checks to all the code creating DDF objects given that it's been serializing longs such that it would have broken on large values anyway at least on Windows. If it's marshalling to 32 bits than we should just check it.
I would do it on the sender side I think.
Scott
— It's pretty much all confined to the API for shibsp/remoting/ddf.h and the serialization inside that implementation. And indeed, it uses "long" as the integral type. We'll have to either come up with a portable type that works everywhere (impossible), or a type indirection (ddf_int_t) scheme. There's no question it can be made safe on any given platform, it just requires defining that to a known size.
On Windows a long is always 4 octets so we dodge the bullet. Further Windows appears to be the platform where it is an issue (is there any 32/64 bit coexistance on Linux? ISRT that OSX is 64 bit ony)
At least Due Diligence needed.