Attention is currently required from: neels, fixeria, pespin.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hlr/+/33098 )
Change subject: db: extend database schema to support 256bit K and/or OP[c] values ......................................................................
Patch Set 4:
(4 comments)
File src/db.c:
https://gerrit.osmocom.org/c/osmo-hlr/+/33098/comment/45910aef_7cf57744 PS4, Line 550: 6
Another approach to ensure the correct version is printed is the logging might be: […]
Done
File src/hlr_vty_subscr.c:
https://gerrit.osmocom.org/c/osmo-hlr/+/33098/comment/25dd023a_2052f46b PS4, Line 479: * below for real 3G AKA algorithms. */
(120 line width)
I don't think its *mandatory* that we use that line length. We just permit it up to 120? Also, 118 is cutting it really close. Most classic 80-character line-wraps are IMHO done at 72, for example. But I changed it .
https://gerrit.osmocom.org/c/osmo-hlr/+/33098/comment/92675ee7_bf696abe PS4, Line 510: *maxlen_opc = MILENAGE_KEY_LEN;
will there ever be minlen_opc < maxlen_opc?
we don't know what future 3GPP algorithms come up with. TS 33.102 doesn't state any constraint for OP/OPc value length, only for K/RAND/SQN/AK/AMF/CK/IK/RES.
For TUAK, TOP[c] is fixed at 32 bytes, for MILENAGE its fixed at 16 bytes.
It was easy enough to prepare the function for situations where it may not be a fixed single valid length value.
https://gerrit.osmocom.org/c/osmo-hlr/+/33098/comment/18f963ba_84930936 PS4, Line 703: vty_out(vty, "%% Unknown auth algorithm: '%s'%s", "xor", VTY_NEWLINE);
this change looks non-related?
indeed. no idea how this happeend. I guess some rebase artefact.