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 > <[email protected]> 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 (#228586): https://lists.openembedded.org/g/openembedded-core/message/228586 Mute This Topic: https://lists.openembedded.org/mt/116962329/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
