I wonder if we should also trim spaces; this is done by other tables like system_info when they query cpuid. Normally I would keep both embedded nulls and the spaces to have a faithful representation (because embedded nulls could be used to hide data).
I guess I could add in a new PR additional base64 columns to retain the complete value.

I wonder if we should also trim spaces; this is done by other tables like system_info when they query cpuid. Normally I would keep both embedded nulls and the spaces to have a faithful representation (because embedded nulls could be used to hide data). I guess I could add in a new PR additional base64 columns to retain the complete value.

I think there's often value in trimming spaces. I don't think I have an opinion about data smuggling here, or whether or not we should have an additional raw base64 column. I'd approve it if you think it has value

I think there's often value in trimming spaces. I don't think I have an opinion about data smuggling here, or whether or not we should have an additional raw base64 column. I'd approve it if you think it has value

Yeah I was mostly weighing the usefulness of keeping the "true" display string in the cpuid table only, as for instance one can find examples of manufacturer strings here: https://en.wikipedia.org/wiki/CPUID, which are expected to potentially have leading or trailing spaces, but at the same thinking about it again you wouldn't need to query for vendor or product_name and need to differentiate them via number of spaces.

As for the data smuggling, definitely in this case there wouldn't be any adverse effect (while for instance if this was the Windows registry, that's another story), was mostly for curiosity in knowing if there was additional data or not.

In any case, I'll add the trimming.