On Sun, 28 Dec 2025 at 16:17, <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#228599): https://lists.openembedded.org/g/openembedded-core/message/228599 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]] -=-=-=-=-=-=-=-=-=-=-=-
