Bug 5675

If I remember correctly, "usermod -p" expects a DES encrypted password which is limited to 8 characters.  For users that want to use a longer root password, I think we'd want a different mechanism for setting the password.  Maybe have ROOT_PASSWD accept a string like "encryption_type:cleartext_password" that can be used for calling passwd or chpasswd?

I would prefer ROOT_PASSWORD_type like syntax instead for such features. I like avoiding "raw strings" as much as possible, and would prefer put the qualifier into the variable.

Using a ROOT_PASSWD_type syntax does make more sense.  I propose the following:

1. ROOT_PASSWD_des uses DES encryption.  This will then be limited to 8 character passwords.  The user will be able to put in a password longer than 8 characters, but the system will truncate it to the first 8 characters and post a QA warning that the password was truncated.
2. ROOT_PASSWD defaults to ROOT_PASSWD_des.
3. ROOT_PASSWD_md5 used MD5 encryption.
4. ROOT_PASSWD declarations expects a plaintext password.  It is expected that the ROOT_PASSWD declaration will occur in an image recipe, which for a custom system belongs in a user's private layer.  This means the root password can be kept safe from those who are not expected to know the root password.
5. If multiple ROOT_PASSWD declarations exits, only the last one is used.  For example, if an image recipe contains:
  ROOT_PASSWD_des = "password"
  ROOT_PASSWD_md5 = "second_password"
then the system would set the root password to "second_password" and encrypt it using the MD5 algorithm.  We may want a QA warning if multiple ROOT_PASSWD declarations are found so the user knows that the root password may not be what they expect.
6. ROOT_PASSWD cannot be appended.  For example:
  ROOT_PASSWD = "pass"
  ROOT_PASSWD += "word"
results in an error.
7. Add the ROOT_PASSWD variable to the Yocto Project manual and a few examples of usage.

I'm not sure if other encryption methods would be necessary.  Busybox supports only DES and MD5, but I know other password managers support SHA256 and SHA512.  It would depend on what demand people had for more options.

Yes, that is more or less inline with what I thought, too. Although, I would make it possible to load the root password from file, e.g. ROOT_PASSWD_file = /path/to/my/password/file.

The question is: would anyone be willing to implement it any soon?

Hello
I'm looking for some unassigned bugs to try start contributing and this looks reasonably to do. Do you think above feature description is up to date? Any hints where this should be implemented (new bbclass, existing class, somewhere else?).
Regards

I believe its possible to do this already using image post processing commands, we should document those better and give an example of doing this. The details will vary case to case which is why no one default will work in general.

This could be achieved by using extrausers. There's no need to use another ROOT_PASSWD feature. Besides, as the clear password support has been removed from oe-core, the ROOT_PASSWD is also not appropriate any more.