I just did an installation with the 2024-02-24 debian-testing-amd64-netinst.iso image. I forget the exact wording
used, but when setting up a user, d-i printed advice that user passwords should be changed frequently. This is no longer current good advice
(since 2017):
On 25/02/2024 at 01:17, Matthew Wilcox wrote:
I just did an installation with the 2024-02-24
debian-testing-amd64-netinst.iso image. I forget the exact wording
used, but when setting up a user, d-i printed advice that user passwords
should be changed frequently. This is no longer current good advice
(since 2017):
This topic has some history, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656509> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868869> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998408> <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7>
Depending upon whether we think it's worth using translators' time on
this subject, we can then select one or both commits, and finally close
these bugs.
You can see my latest attempt here:
https://openqa.debian.net/tests/238094#step/passwords/1
in which I'm recommending setting no password for root, which then gives
the initial user 'sudo' membership[1].
in which I'm recommending setting no password for root, which then gives the initial user 'sudo' membership[1].
What about the "Allow login as root?" question (only shown in expert mode), which is asked directly before the above mentioned dialog?
Having helped people to install Linux for ~30 years, I'd say that it's
the norm for people to be almost incapable of coming up with a decent password if they were not expecting the question.
If you want to make a constructive contribution, how about suggesting a wording that reflects the advice that you think would be most useful to
the people that actually read the advice?
It is possible (and generally recommended) to lock the 'root' (system administrative) account, thus preventing direct password-based logins to 'root'.
If you want to make a constructive contribution, how about suggesting a wording that reflects the advice that you think would be most useful to
the people that actually read the advice?
Philip Hands <phil@hands.com> wrote (Fri, 01 Mar 2024 06:46:27 +0100):
If you want to make a constructive contribution, how about suggesting a wording that reflects the advice that you think would be most useful to
the people that actually read the advice?
I would like to make a proposal, leaving the default setting as is
(aka: default to an enabled root account, no sudo), with only some wording changings.
Patch attached.
What do you think?
Hi,
On Friday, 1 March 2024 20:46:49 CET Holger Wansing wrote:
Philip Hands <phil@hands.com> wrote (Fri, 01 Mar 2024 06:46:27 +0100):
If you want to make a constructive contribution, how about suggesting a
wording that reflects the advice that you think would be most useful to
the people that actually read the advice?
I would like to make a proposal, leaving the default setting as is
(aka: default to an enabled root account, no sudo), with only some wording >> changings.
Patch attached.
What do you think?
I think it's an improvement and I have some suggestions, which hopefully makes
it even better. I don't have a git-diff, but hopefully this works too.
I'm not a native English speaker or particularly good at this, so it's more the direction then the exact wording that's important. Others can undoubtedly
improve upon it.
_Description: Root password:
"You need to set a password for 'root', the system administrative account.
I don't actually care very much whether we encourage sudo use.
The other thing that I was trying to ensure is that people are reassured
that they'll get to specify a password that will get them root access even
if they decide to leave the root password unset. This is because I've seen people become quite uncertain about what to expect at this point in the install.
I've found that it is not easy to come up with things that include much nuance about this, while still fitting in the space available, which is
why I decided to try a more opinionated approach.
This sentence is the thing that prompted me to change things in the
first place, because it is not true. One does not _need_ to set a root >password.
I don't actually care very much whether we encourage sudo use. My
wording ended up (after many variations) quite strongly encouraging it
mostly as an antidote to the implication that comes from having a
question dedicated to setting the root password, but I'd be happy with
any wording that makes sure that people understand that both options are >totally fine.
The other thing that I was trying to ensure is that people are reassured
that they'll get to specify a password that will get them root access even if >they decide to leave the root password unset. This is because I've seen >people become quite uncertain about what to expect at this point in the >install.
I've found that it is not easy to come up with things that include much >nuance about this, while still fitting in the space available, which is
why I decided to try a more opinionated approach.
One could soften what I wrote by replacing "generally recommended" with >something like "often appropriate" -- how does that seem to people?
One can of course tinker with this stuff indefinitely. I actually spent
a fair amount of time wondering how best to describe not setting a root >password for instance -- should one say "leave the password unset", "set
an empty password", "enter no password", or something like "just hit ><RETURN>"? (and does that last one actually apply to all the available
UIs?).
The same goes for how you say that the password is not going to get
shown (unless you ask for it to be shown), which in the GTK UI gets >characters replaced with dots, IIRC in the text UI its with asterisks,
and I'd guess it just gets completely hidden in the speech install.
Hi,
Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands <phil@hands.com>:
This sentence is the thing that prompted me to change things in the
first place, because it is not true. One does not _need_ to set a root >>password.
It should be understood as
"If you want to enable login as root, you have to set a root password now."
And in expert mode it is in fact working this way:
At first, you are asked if you want to enable login as root. If you answer yes
here, you are prompted to set a root password.
And at that point it is indeed required to set a root password, since you chose to enable root login in the first question and the installer does not allow an empty password for root.
To make it work in default install, we could change the question as
in above citation.
I don't actually care very much whether we encourage sudo use. My
wording ended up (after many variations) quite strongly encouraging it >>mostly as an antidote to the implication that comes from having a
question dedicated to setting the root password, but I'd be happy with
any wording that makes sure that people understand that both options are >>totally fine.
The sudo possibility is also mentioned:
'The root user should not have an empty password. If you leave this
empty, the root account will be disabled and the system's initial user account will be given the power to become root using the "sudo"
command.'
I have rephrased that a bit, see below.
The other thing that I was trying to ensure is that people are reassured >>that they'll get to specify a password that will get them root access even if >>they decide to leave the root password unset. This is because I've seen >>people become quite uncertain about what to expect at this point in the >>install.
I've found that it is not easy to come up with things that include much >>nuance about this, while still fitting in the space available, which is
why I decided to try a more opinionated approach.
One could soften what I wrote by replacing "generally recommended" with >>something like "often appropriate" -- how does that seem to people?
Your proposal too much focusses on the sudo way IMO.
We risk getting complains from people, who miss advise regarding the
enabled root login.
I have rephrased the dialog a bit, to make the sudo way more visible and better understandable.
One can of course tinker with this stuff indefinitely. I actually spent
a fair amount of time wondering how best to describe not setting a root >>password for instance -- should one say "leave the password unset", "set
an empty password", "enter no password", or something like "just hit >><RETURN>"? (and does that last one actually apply to all the available >>UIs?).
The same goes for how you say that the password is not going to get
shown (unless you ask for it to be shown), which in the GTK UI gets >>characters replaced with dots, IIRC in the text UI its with asterisks,
and I'd guess it just gets completely hidden in the speech install.
I think that's not much of a problem. People are used to the situation,
that passwords are not shown, but replaced by asterisks or similar.
And we have the checkbox for showing it in clear text, that should be
enough.
Updated patch attached.
Holger
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..7393511 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -34,21 +34,19 @@ Template: passwd/root-password
Type: password
# :sl1:
_Description: Root password:
- You need to set a password for 'root', the system administrative
- account. A malicious or unqualified user with root access can have
+ If you want to allow login as root, you need to set a password for 'root', + the system administrative account now.
+ A malicious or unqualified user with root access can have
disastrous results, so you should take care to choose a root password
- that is not easy to guess. It should not be a word found in dictionaries,
- or a word that could be easily associated with you.
+ that cannot be guessed. It should not be a word found in dictionaries,
+ or something that could be easily associated with you.
.
- A good password will contain a mixture of letters, numbers and punctuation - and should be changed at regular intervals.
+ You can also leave the password for root empty here, to disable the root
+ account; the system's initial user account (which will be set up in the next
+ step) will then be given the power to become root using the "sudo" command.
.
- The root user should not have an empty password. If you leave this
- empty, the root account will be disabled and the system's initial user
- account will be given the power to become root using the "sudo"
- command.
- .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
Template: passwd/root-password-again
Type: password
@@ -110,8 +108,7 @@ Template: passwd/user-password
Type: password
# :sl1:
_Description: Choose a password for the new user:
- A good password will contain a mixture of letters, numbers and punctuation - and should be changed at regular intervals.
+ Make sure to select a strong password, that cannot be guessed.
Template: passwd/user-password-again
Type: password
I found that there were some phrases that I was avoiding for various
reasons, a couple of which I see you've used, so I'll say why I was avoiding >them and see if I have a persuasive argument for doing so.
"allow/deny login/access as root":
The problem here is that not having a password for root only prevents
one from getting direct access to root by using a password. Indirect
access is still available via sudo, and direct access is still
available via key bassed ssh. I was also avoiding saying things like
"disable the root account" for the same reason.
This is why I ended up with the phrasing:
direct password-based logins to 'root'.
"using the 'sudo' command":
This I was avoiding becuase it might give the impression that one MUST
use sudo, whereas most people will actually get their root acces via a
GUI prompting them for their own pasword (because it's checked that
they're in the sudo group) when doing things like unlocking their
network or printer settings. I thought it was worth mentining the
'sudo' group explicitly because that gives something to search for if
they want to find out more, but telling people they need to use the
sudo command seemed like a step too far.
Regarding the password advice, I ended up concluding that it's pretty >unlikely that anything we say at this point will have any effect on
people's behaviour, but then I'm probably just an old cynic. Also, I
failed when trying to come up with a wording which I was happy with,
which is why I ended up discarding the advice entirely.
If we want to keep the password advice in then I think what you wrote is >(mostly) OK, although I think it implies that one should be choosing a
single "password" (although, not a word in any normal sense), which
could be argued to steer people away from the perfectly decent xkcd
approach of using several dictionary words. Saying "Password or
Passphrase" at least once would probably address that.
Regarding the password advice, I ended up concluding that it's pretty >unlikely that anything we say at this point will have any effect on >people's behaviour, but then I'm probably just an old cynic. Also, I
failed when trying to come up with a wording which I was happy with,
which is why I ended up discarding the advice entirely.
If we want to keep the password advice in then I think what you wrote is >(mostly) OK, although I think it implies that one should be choosing a >single "password" (although, not a word in any normal sense), which
could be argued to steer people away from the perfectly decent xkcd >approach of using several dictionary words. Saying "Password or
Passphrase" at least once would probably address that.
Ok, makes it a bit longer, but it could be worth it.
Hi,
Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands <phil@hands.com>:
I found that there were some phrases that I was avoiding for various >reasons, a couple of which I see you've used, so I'll say why I was avoiding >them and see if I have a persuasive argument for doing so.
"allow/deny login/access as root":
The problem here is that not having a password for root only prevents
one from getting direct access to root by using a password. Indirect
access is still available via sudo, and direct access is still
available via key bassed ssh. I was also avoiding saying things like
"disable the root account" for the same reason.
This is why I ended up with the phrasing:
direct password-based logins to 'root'.
Ok, seems fair. I would change to that then.
"using the 'sudo' command":
This I was avoiding becuase it might give the impression that one MUST
use sudo, whereas most people will actually get their root acces via a
GUI prompting them for their own pasword (because it's checked that
they're in the sudo group) when doing things like unlocking their
network or printer settings. I thought it was worth mentining the
'sudo' group explicitly because that gives something to search for if
they want to find out more, but telling people they need to use the
sudo command seemed like a step too far.
Correct so far. Maybe a bit more technical and therefore probably
not the easiest choice for newbies, but I have no problem using that.
Regarding the password advice, I ended up concluding that it's pretty >unlikely that anything we say at this point will have any effect on >people's behaviour, but then I'm probably just an old cynic. Also, I
failed when trying to come up with a wording which I was happy with,
which is why I ended up discarding the advice entirely.
If we want to keep the password advice in then I think what you wrote is >(mostly) OK, although I think it implies that one should be choosing a >single "password" (although, not a word in any normal sense), which
could be argued to steer people away from the perfectly decent xkcd >approach of using several dictionary words. Saying "Password or
Passphrase" at least once would probably address that.
Ok, makes it a bit longer, but it could be worth it.
I will prepare a new patch with above.
On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote:
Regarding the password advice, I ended up concluding that it's pretty >unlikely that anything we say at this point will have any effect on >people's behaviour, but then I'm probably just an old cynic. Also, I >failed when trying to come up with a wording which I was happy with, >which is why I ended up discarding the advice entirely.
If we want to keep the password advice in then I think what you wrote is >(mostly) OK, although I think it implies that one should be choosing a >single "password" (although, not a word in any normal sense), which
could be argued to steer people away from the perfectly decent xkcd >approach of using several dictionary words. Saying "Password or >Passphrase" at least once would probably address that.
Ok, makes it a bit longer, but it could be worth it.
https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to remember URL and we'd have all the space we need to give proper advise?
https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to remember URL and we'd have all the space we need to give proper advise?
Would need to check if that fits in the relevant screens (I want to avoid having a scroll bar on that screens).
Here are my latest attempts:
Hi,
Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands <phil@hands.com>:
Here are my latest attempts:
"Be aware that that a ..."
doubled "that"
"... (unless you select to show it)"
missing fullstop.
Otherwise: looks good to me.
Philip Hands <phil@hands.com> (2024-03-05):
Cool, in that case I'll fix those two things and then use the result
for the MR[1], and if the openQA test runs look OK, will merge that.
Only skimmed over it, but that looks sensible, thanks all.
Is it worth getting d-l-english involved in a final review before
getting that translated? Contrary to a lot of not-so-critical l10n
material, that particular screen is crucial, and I'd hate it if we
wasted translator efforts due to a missed typo or obvious improvement.
Cool, in that case I'll fix those two things and then use the result
for the MR[1], and if the openQA test runs look OK, will merge that.
Cool, in that case I'll fix those two things and then use the result
for the MR[1], and if the openQA test runs look OK, will merge that.
Only skimmed over it, but that looks sensible, thanks all.
Is it worth getting d-l-english involved in a final review before
getting that translated? Contrary to a lot of not-so-critical l10n
material, that particular screen is crucial, and I'd hate it if we
wasted translator efforts due to a missed typo or obvious improvement.
Philip Hands <phil@hands.com> (2024-03-05):
Cool, in that case I'll fix those two things and then use the result
for the MR[1], and if the openQA test runs look OK, will merge that.
Only skimmed over it, but that looks sensible, thanks all.
Is it worth getting d-l-english involved in a final review before
getting that translated? Contrary to a lot of not-so-critical l10n
material, that particular screen is crucial, and I'd hate it if we
wasted translator efforts due to a missed typo or obvious improvement.
Holger Wansing wrote:
@d-l10n-english: hey guys, we would like to get a proposal reviewed,
which aims to improve the root/user password screens in the installer.
Please find the related merge request at
<https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7>
It needs a small amount of rephrasing, but the most important problem
is that it starts by saying you need to set a password and then goes
on to suggest that you might not need to set a password. Maybe that
can be fixed by rearranging things slightly...
Template: passwd/root-password
Type: password
# :sl1:
_Description: Root password/passphrase:
To allow direct password/passphrase-based access to the 'root'
(system administrative) account you can set it up here.
The results can be disastrous if a malicious or incompetent user
obtains root access, so you should not set one that can be guessed,
found in dictionaries, or easily associated with you.
.
Alternatively, you can lock root's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
to become root. This will be enabled for you
by adding that user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
Does this still feel like the same advice?
Otherwise the only thing I see is:
Template: passwd/user-password
Type: password
# :sl1:
_Description: Choose a password/passphrase for the new user:
Make sure to select a strong password/passphrase, that cannot be guessed.
No comma needed there.
Philip Hands wrote:...
Justin B Rye <justin.byam.rye@gmail.com> writes:
The reason behind that structure was supposed to be that one definitely
needs _a_ password, but not necessarily a root password, so the password
advice applies to whichever password you'll decide to grant root access
to, which might not be set here.
This template is specifically about the "Root password/passphrase";
probably I should have quoted the patch I was looking at, which starts
with "One needs a password/passphrase that grants access to the 'root' (system administrative) account" but goes on to say "Alternatively,
you can lock root's password by leaving this setting empty".
Philip Hands wrote:
Justin B Rye <justin.byam.rye@gmail.com> writes:
Philip Hands wrote:
Justin B Rye <justin.byam.rye@gmail.com> writes:> ...
The reason behind that structure was supposed to be that one definitely >>>> needs _a_ password, but not necessarily a root password, so the password >>>> advice applies to whichever password you'll decide to grant root access >>>> to, which might not be set here.
This template is specifically about the "Root password/passphrase";
Well, sort-of, except that the user's response (whether to leave this
blank or not) modifies what happens with the user account's permissions,
so it's also about explaining the way that logic works in the installer
and what that will do to the target system.
probably I should have quoted the patch I was looking at, which starts
with "One needs a password/passphrase that grants access to the 'root'
(system administrative) account" but goes on to say "Alternatively,
you can lock root's password by leaving this setting empty".
I'm intimately familiar with the patches you're reading, so I feel like
this comment suggests that we may be talking past one another somehow.
Yes, this is a common problem: you're so familiar with what we need
it to say that you aren't noticing what the text currently does say. https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
Template: passwd/root-password
Type: password
# :sl1:
_Description: Root password/passphrase:
One needs a password/passphrase that grants
access to the 'root' (system administrative) account.
Be aware that a malicious or unqualified user
that obtains root access can have disastrous results,
so you should choose a password/passphrase that cannot be guessed.
It should not be a word found in dictionaries,
or something that could be easily associated with you.
(Summary: You DO need a root password.)
.
To allow direct password-based access to root,
you should set the 'root' password/passphrase here.
.
Alternatively, you can lock root's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
to become root. This will be enabled for you
by adding that user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
(Summary: You DON'T need a root password.)
Suggested rewrite (short version):
_Description: Root password/passphrase:
To allow direct password/passphrase-based access to the 'root'
(system administrative) account you can set it up here.
To protect your system you should not use one that can be guessed.
.
Alternatively, you can lock root's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
to become root. This will be enabled for you
by adding that user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"? I'm not sure. Oh, and we might
even want to mention the word "superuser", or then again we might not.
Post-coffee (also fixing that wobbly indent):
Some account needs to have system administrative privileges. The
password/passphrase for that account should be something that
cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
Alternatively, you can lock root's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
to become root. This will be enabled for you
by adding that user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"? I'm not sure. Oh, and we might
even want to mention the word "superuser", or then again we might not.
BTW I don't know much about how the translation side of things works,
but given that there are many ways of getting the fine detail of this to
be incorrect in various ways, is there a standard method for adding
hints for translators, and should that be done?
Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"? I'm not sure. Oh, and we might
even want to mention the word "superuser", or then again we might not.
I think Diederik's suggestion of using 'root' for the account and
'super-user' for the privileges might be the way to go.
Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:
- Some account needs to have system administrative privileges. The
- password/passphrase for that account should be something that
- cannot be guessed.
+ Some account needs to be available with administrative super-user
+ privileges. The password/passphrase for that account should be
+ something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
- Alternatively, you can lock root's password
+ Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
- to become root. This will be enabled for you
- by adding that user to the 'sudo' group.
+ to gain administrative privileges. This will be enabled for you by
+ adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
Philip Hands wrote:
Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"? I'm not sure. Oh, and we might
even want to mention the word "superuser", or then again we might not.
I think Diederik's suggestion of using 'root' for the account and
'super-user' for the privileges might be the way to go.
Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:
- Some account needs to have system administrative privileges. The
- password/passphrase for that account should be something that
- cannot be guessed.
+ Some account needs to be available with administrative super-user
+ privileges. The password/passphrase for that account should be
+ something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
- Alternatively, you can lock root's password
+ Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
- to become root. This will be enabled for you
- by adding that user to the 'sudo' group.
+ to gain administrative privileges. This will be enabled for you by
+ adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).
IMO Having the 'password/passphrase' throughout makes it awkward to
read, and actually we've got one place where it still just says
password, and fixing that would make it slightly worse IMO.
How about dropping the passphrase stuff?
IMO Having the 'password/passphrase' throughout makes it awkward to
read, and actually we've got one place where it still just says
password, and fixing that would make it slightly worse IMO.
How about dropping the passphrase stuff?
https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 11:40:32 |
| Calls: | 6,706 |
| Files: | 12,236 |
| Messages: | 5,350,923 |