Setting token hashing to greater than sha256 will not work with the SQL token backend

[Morgan Fainberg]

The SQL Token backend sets the ID of the token to a 64 column. sha512 will generate a 128 character (byte) string.

>>> a =hashlib.sha512('test').hexdigest()
>>> a
'ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ff'
>>> len(a)
128
>>>

[Adam Young (ayoung)]

Is there anything wrong with letting end users somehow migtrate the table size to be larger than 64 characters? Ideally, the token ID would not be stored in database tables anywhere but in keystone. We could realistically max out the table size to (I think) 255 chars long without any negative impact.

[Morgan Fainberg (mdrnstm)]

The only real concern about migrating the token table (at all) due to the size of it in many places (tons and tons and tons and tons of rows).

I don't disagree that we could go to 255 easily.

[Dolph Mathews (dolph)]

How is this a bug and not just a wishlist item? (support for SHA512)

As mentioned, this would require a very expensive migration (or to truncate the token table first), which doesn't seem desirable in the face of non-persistent PKI tokens.

[Morgan Fainberg (mdrnstm)]

The fix is actually probably a KSC bug and limiting the hashtypes to SHA256. The move to support 'any hash that hashlib can do' is the real culprit here.