fragments: add a 'devtool-ide-sdk' fragment

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Add a configuration fragment that enables devtool ide-sdk workflow
for development and remote debugging.
The configuration is intended to streamline the development workflow
where developers can modify recipes with devtool and debug them
remotely on target devices using IDEs like VSCode.

This also includes the EXTRA_IMAGE_FEATURES from
root-login-with-exmpty-password.conf. Ideally there would be a possibility
to define fragment dependencies, so that this fragment could just depend on
that one instead of duplicating the content here.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 .../conf/fragments/yocto/devtool-ide-sdk.conf | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 meta/conf/fragments/yocto/devtool-ide-sdk.conf

On Sat, 27 Dec 2025 at 18:23, Adrian Freihofer via
lists.openembedded.org
<adrian.freihofer=siemens.com@lists.openembedded.org> wrote:
> Add a configuration fragment that enables devtool ide-sdk workflow
> for development and remote debugging.
> The configuration is intended to streamline the development workflow
> where developers can modify recipes with devtool and debug them
> remotely on target devices using IDEs like VSCode.

There are tests for ide-sdk in
meta/lib/oeqa/selftest/cases/devtool.py, should they be adjusted to
use the fragment?

> This also includes the EXTRA_IMAGE_FEATURES from
> root-login-with-exmpty-password.conf. Ideally there would be a possibility
> to define fragment dependencies, so that this fragment could just depend on
> that one instead of duplicating the content here.

This is somewhat more worrying. Having the settings bundled into the
fragment this way quietly opens a big security hole in users'
configuration, something they did not necessarily consent to. The
original fragment at least warns the users of the dangers involved,
this one doesn't.

I would much rather take an opportunity to set up proper key-based
authentication or something else better than simply not having a
password. There was already reluctance to having the original
empty-password fragment (because it's the easy way out that only
delays solving the problem properly), and spreading these settings to
other fragments makes the situation worse.

Alex

Hi Alex

Thank you for looking into this.

On Sat, 2025-12-27 at 19:18 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> On Sat, 27 Dec 2025 at 18:23, Adrian Freihofer via
> lists.openembedded.org
> <adrian.freihofer=siemens.com@lists.openembedded.org> wrote:
> > Add a configuration fragment that enables devtool ide-sdk workflow
> > for development and remote debugging.
> > The configuration is intended to streamline the development
> > workflow
> > where developers can modify recipes with devtool and debug them
> > remotely on target devices using IDEs like VSCode.
> 
> There are tests for ide-sdk in
> meta/lib/oeqa/selftest/cases/devtool.py, should they be adjusted to
> use the fragment?

Sure, I can change that. But I have already many patches pending
against these tests which I would like to send before adding more
changes. And we need more discussion on that, as you pointed out
bellow.

> 
> > This also includes the EXTRA_IMAGE_FEATURES from
> > root-login-with-exmpty-password.conf. Ideally there would be a
> > possibility
> > to define fragment dependencies, so that this fragment could just
> > depend on
> > that one instead of duplicating the content here.
> 
> This is somewhat more worrying. Having the settings bundled into the
> fragment this way quietly opens a big security hole in users'
> configuration, something they did not necessarily consent to. The
> original fragment at least warns the users of the dangers involved,
> this one doesn't.

You are right, insecure development features must be visible and
copying this is not ideal. We need a better solution.

> 
> I would much rather take an opportunity to set up proper key-based
> authentication or something else better than simply not having a
> password. There was already reluctance to having the original
> empty-password fragment (because it's the easy way out that only
> delays solving the problem properly), and spreading these settings to
> other fragments makes the situation worse.

I think we are aiming for different goals: security versus usability
and reproducibility. All are important. We need to find implementations
where the sstate-cache, packages, MACHINE parts, and DISTRO parts are
secure by default, while still allowing developers to quickly generate
images suitable for development and testing tasks. That's what this
fragment basically does: it converts a secure-by-default image into a
developer image.

The problem: Fragments currently affect all images, not just those
intended for development.

We could introduce new variables:
- INSECURE_IMAGE_FEATURES
- INSECURE_IMAGE_CLASSES

These variables would be used exclusively by development images, such
as oe-selftest-image.

Additionally, we could add a new directory (e.g., classes-insecure)
containing bbclass files that remove security features. Classes in this
directory could set a variable to mark the image as insecure.
Checks could enforce that classes from classes-insecure can only be
added to INSECURE_IMAGE_CLASSES, not to IMAGE_CLASSES.

This approach would allow fragments to append to INSECURE_IMAGE_CLASSES
without risking the security of potentially released images.

However, that's not the right place for this discussion. Maybe the CRA,
meeting series could be. I will send a v2 which does not change the
security related parts. That will allow us to proceed and the user can
enable the existing no password fragment in addition.

Regards,
Adrian

> 
> Alex
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#228579):
> https://lists.openembedded.org/g/openembedded-core/message/228579
> Mute This Topic: https://lists.openembedded.org/mt/116962329/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

On Sun, 28 Dec 2025 at 16:17, <adrian.freihofer@gmail.com> wrote:
> > I would much rather take an opportunity to set up proper key-based
> > authentication or something else better than simply not having a
> > password. There was already reluctance to having the original
> > empty-password fragment (because it's the easy way out that only
> > delays solving the problem properly), and spreading these settings to
> > other fragments makes the situation worse.
>
> I think we are aiming for different goals: security versus usability
> and reproducibility. All are important. We need to find implementations
> where the sstate-cache, packages, MACHINE parts, and DISTRO parts are
> secure by default, while still allowing developers to quickly generate
> images suitable for development and testing tasks. That's what this
> fragment basically does: it converts a secure-by-default image into a
> developer image.

I fundamentally disagree with the notion that security and usability
for product development are at odds with each other. They're not. We
can arrive at a default that can reasonably fulfill both goals, it
just takes careful thought and design.

Given that, I am strongly against introducing nomenclature that
codifies 'secure' and 'insecure' into variables, class names, and so
on.

Alex