Replies: 6 comments 3 replies
-
Interesting point. While it's possible to write a temporary script that has the burn command (plus password) in it, which you'd then delete after the burn, that still leaves the password exposed in a (presumably appropriately protected) script file during the long-running burn. I'll have a look into this as well. Haven't thought much about it, but may need to add a switch to request password prompting. Would that work for you? |
Beta Was this translation helpful? Give feedback.
-
Current thinking is to add If a user is created during customization with |
Beta Was this translation helpful? Give feedback.
-
V7.2 implements this. You must enter a password, a null password is not allowed. |
Beta Was this translation helpful? Give feedback.
-
I've been thinking about this as well, although not an burning (🤣) issue for me personally, I've not been totally happy with leaving the passwords there. It looks pretty simple to redact the passwords from I'll get this in soon...likely next week. |
Beta Was this translation helpful? Give feedback.
-
Simple (context-free) reaction is in V7.3, posted this afternoon. |
Beta Was this translation helpful? Give feedback.
-
For completeness, note that /etc/sdm is protected 700, so non-root users can't casually access it without |
Beta Was this translation helpful? Give feedback.
-
I've noticed that if the user is specified during customization, but not a password switch, I am prompted for a password, which is great because the password doesn't have to be stored in the script file I typically use to execute sdm. This doesn't work during --burn though.
I generally use different passwords on each of my Pi's so ideally wouldn't need to specify one during customization, but only during the burn. I can use a default password for the customization and then override it during the burn, but have to include it on the command line (I found out the hard way what happens if I just include the --password-user switch with no password parameter (:-) ).
I have scripts from which I like to execute sdm so I'm sure I'm using all the necessary parameters, but it would be bad practice to store passwords in such a script (and a nuisance to have to edit it for each burn of a different system). I've been copying the burn command from my script file, pasting it into the terminal, and then editing in the password copied from my password manager, but it would be much more convenient if the --burn process prompted for an unspecified password like --customize.
Beta Was this translation helpful? Give feedback.
All reactions