Re: [yocto] Documentation around adding custom fetchers to layer

Alexander Kanavin <[email protected]>
Newsgroups org.yoctoproject.lists.yocto
Message-ID <CANNYZj96qN23jkWg_pKoP1aBbR7KPXeSa4kYypQ_Om+9QffX5g@mail.gmail.com>
On Wed, 17 Sept 2025 at 16:45, seth.raymond via Lists.Yoctoproject.Org
<[email protected]> wrote:
> Sure, I can share the source. It grabs secrets from our password manager (1Password) and injects them into the build system. We currently have two use cases for this:
> 1. We use AES keys for encrypting/decrypting our SWU payloads. Those key/iv pairs are held in our password manager, so we need to take one of them out at build-time and hand it to the swupdate bbclass to encrypt the payload. We do the same thing for a signing .pem key
> 2. We want to install an SSH key into our OS so that we can SSH into our devices. 1Password also acts as an SSH agent, so it makes life seamless when we store the keys in there.
>
> My source is attached. The use case in a recipe would be:
>
> SRC_URI = " \
>     op://MyVault/SSHKey/public%20key;output=ssh_key.pub \
>     optemplate://aes_key.tpl;output=aes_key \
> "
>
> The output would be:
> 1. The content of the MyVault > SSHKey > public key dumped into a file called ssh_key.pub in the $WORKDIR
> 2. Depending on the template (https://developer.1password.com/docs/cli/secrets-template-syntax/), ${WORKDIR}/aes_key would be filled in with referenced secrets

But this doesn't require a fetcher implementation. You can do it in a
task, put the task into a class, and write recipes that inherit the
class. The meat of the fetcher is this:

        cmd = f"/usr/local/bin/op read --out-file {dest} '{ud.path}'"

and this can simply write directly into ${S} from a task.

Alex
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.