fix base64 encoding of key field in config

[fmoessbauer]

The security.privateKey and security.publicKey fields are of type bytes, but the protobuf MessageToDict converts them to base64 encoded strings. When importing the config again, this is read as a string, which breaks the import. Instead, the value needs to be prefixed with "base64:", so the type handling logic on import kicks in and decodes the value to a bytes array again.

Fixes: #678

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Project coverage is 60.49%. Comparing base (da7fa31) to head (dfaf1a2).
Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
meshtastic/__main__.py	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #696      +/-   ##
==========================================
- Coverage   60.62%   60.49%   -0.13%     
==========================================
  Files          24       24              
  Lines        3774     3782       +8     
==========================================
  Hits         2288     2288              
- Misses       1486     1494       +8     

Flag	Coverage Δ
unittests	60.49% <0.00%> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ianmcorvidae]

Cool, thanks for the PR! It might be good if we eventually do this for any bytes field, but I think that's a task for another time. Not letting the perfect be the enemy of the good and all that.

[fmoessbauer]

Cool, thanks for the PR! It might be good if we eventually do this for any bytes field, but I think that's a task for another time. Not letting the perfect be the enemy of the good and all that.

Agree, I had a look into that as well. The root-cause is the type incorrectness of google.protobuf.json_format.MessageToDict. AFAIK there is no way to conserve the type. By that, we can either fix it for all well-known types manually, or we write a heuristic that checks if a string "could be" a base64 value and convert it back (or prefix it with base64:, which is BTW also non standard). IMHO this is quite risky as we can have arbitrary user-supplied strings.

A probably better solution is to interface with the protobuf definitions using the class interface instead of passing around plain dicts. This should conserve all types. But this requires a major refactoring.