[PATCH] Prepare for additional PAC types
modelnine at modelnine.org
Fri Aug 21 07:59:22 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
Am 21.08.2015 um 02:09 schrieb Andrew Bartlett:
> Yes, we should be able to pull and push the same blob, byte for
> We prefer this standard as a way of ensuring we do not get the
> marshalling wrong. It also ensures signatures are preserved (where
I understand the latter (and already considered it), but the problem
with the corresponding UPN_DNS_INFO structure is that an
alignment/padding/non-overlap isn't fixed/required by the
specification, and neither are the contents of padding bytes, so that
it's nigh impossible to replicate the original data structure if it
wasn't normalized (padding on words, UPN/DNS order, no overlap) except
by passing it around verbatim as a DATA_BLOB.
For example, UPN_DNS_INFO allows (judging by the specification) that
the domain name isn't stored as a separate buffer, but that the
corresponding pointer simply refers to the domain part of the UPN.
Which would make the two strings overlap in the serialization and
which would have to be handled by the push/pull in a non-obvious way.
On the same note, from what I gathered the original reverse-engineered
specification which someone used to specify PAC_UNKNOWN_12 had several
padding bytes or contained the strings in NULL-terminated form (after
the structure, between the strings, after the domain string), but that
isn't required by the specification, either, and wouldn't be the
result of a "normalized" serialization based on the specs.
Considering that I haven't found a use for the structure (PAC) where
an original signature must be preserved (it's only actually
pull/pushed when the PAC is resigned anyway, otherwise it's only
pushed), is this layout-preservation actually a sensible restriction
to impose on UPN_DNS_INFO?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the samba-technical