Hi Rasmus,
On 2026-07-10T12:36:12, Rasmus Villemoes <[email protected]> wrote:
> binman: x509_cert: allow and parse distinguished-name subnode
>
> Currently, the ti-secure and ti-secure-rom types hardcode the contents
> of the Distinguished Name section. Those values are not necessarily
> appropriate for all boards that just happen to include a SOC produced
> by TI.
>
> Allow placing a distinguished-name subnode inside the binman node
> representing the Entry_x509_cert (or derived classes), and if present,
> use that information.
>
> Signed-off-by: Rasmus Villemoes <[email protected]>
>
> tools/binman/etype/ti_secure.py | 3 ++-
> tools/binman/etype/ti_secure_rom.py | 3 ++-
> tools/binman/etype/x509_cert.py | 5 +++++
> 3 files changed, 9 insertions(+), 2 deletions(-)
> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
> @@ -61,6 +61,11 @@ class Entry_x509_cert(Entry_collection):
> + dist_name_node = self._node.FindNode('distinguished-name')
> + if dist_name_node:
> + self.req_dist_name = dict()
> + for pname, prop in dist_name_node.props.items():
> + self.req_dist_name[pname] = prop.value
Please can you document the new distinguished-name subnode in the
class docstring, since the entry documentation is generated from
these docstrings?
The ti-secure and ti-secure-rom docstrings should mention it too,
along with a note that it overrides the default TI values.
Also, this iterates the raw props, so a property with no value (a
boolean) or one with multiple strings ends up formatted as 'True' or
as a Python list in the openssl config. I suspect it is worth
validating that each value is a single string and raising an error
otherwise, at least until the multi-value support mentioned in patch
1 is added. What do you think?
Regards,
Simon
