[yocto] Best practices for tokens/passwords that can't be versioned

Alan Martinovic alan.martinovic at senic.com
Thu Dec 13 06:29:08 PST 2018


Thanks for the feedback.
This is a very interesting use case.
By default you want to allow ssh access for the developer who built
the image, cool :)

On Thu, Dec 13, 2018 at 2:59 PM Enrico Scholz
<enrico.scholz at sigma-chemnitz.de> wrote:
>
> Alan Martinovic <alan.martinovic at senic.com> writes:
>
> > am looking for opinions on how to deal with recipes that depend on file content
> > that can't be versioned.
>
> For ssh public keys we use something like
>
>   https://github.com/sigma-embedded/meta-de.sigma-chemnitz/blob/thud/classes/elito-image.bbclass#L36-L44
>
> e.g. we take it from ${HOME}/.config/oe (which is a little bit tricky to
> expand).
>
>
> And/or incliude local/side configuration by
>
>   https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local.conf#L33-36
>
> which in turn includes something from ~/.config/oe/
>
>   https://gitlab.com/ensc-groups/bpi-router/BSP/blob/thud-next/build/conf/local_bpi-router.bigo.ensc.de.conf#L9
>
>
> > i.e.  The logging service on the embedded device needs to have a
> > certain private key
>
> Note that including private keys in the image usually weakens security
> because the key can be extracted more or less trivially.
>
>
>
> Enrico
> --
> SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
> Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
> 09128 Chemnitz


More information about the yocto mailing list