985097 - Should Input.Read(uint16_t&) deal with endianness?

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Something I noticed while writing tests ... I don't think Input.Read(uint16_t&) correctly deals with big-endian systems. Not sure if this is relevant, but important enough to double check.

(We do have people who still make builds for big endian systems. Like Sparc and PowerPC)

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Stefan Arentz [:st3fan] from comment #0)
> Something I noticed while writing tests ... I don't think
> Input.Read(uint16_t&) correctly deals with big-endian systems. Not sure if
> this is relevant, but important enough to double check.

AFAICT, the code is endian-agnostic:

  Result Read(uint16_t& out)
  {
    if (input == end || input + 1 == end) {
      return Fail(SEC_ERROR_BAD_DER);
    }
    out = *input++;
    out <<= 8u;
    out |= *input++;
    return Success;
  }

More specifically, DER encoding is *always* big-endian, so this code is always converting big-endian encoding to native byte order, regardless of what the native byte order is, AFAICT.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Please see my comment above. Shouldn't we make this RESOLVED INVALID?

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Yeah I think you are right Brian. I'll flip this to RESOLVED INVALID.