Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1187361 > unrolled thread

Bug#1064617: Passwords should not be changed frequently

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1064617: Passwords should not be changed frequently Matthew Wilcox <willy@infradead.org> - 2024-02-25 01:50 +0100
    Bug#1064617: Passwords should not be changed frequently Pascal Hambourg <pascal@plouf.fr.eu.org> - 2024-02-25 23:50 +0100
      Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-02-29 21:10 +0100
        Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-02-29 23:20 +0100
          Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-01 00:40 +0100
            Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-01 07:00 +0100
              Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-01 15:50 +0100
              Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-01 21:00 +0100
                Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-01 22:40 +0100
                  Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-02 21:10 +0100
                    Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-02 23:00 +0100
                    Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-03 00:50 +0100
                      Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-04 06:30 +0100
                        Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-04 10:50 +0100
                          Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-04 16:10 +0100
                            Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-04 22:40 +0100
                              Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-04 23:00 +0100
                          Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-04 22:10 +0100
    Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-05 16:20 +0100
      Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-05 18:00 +0100
        Bug#1064617: Passwords should not be changed frequently Cyril Brulebois <kibi@debian.org> - 2024-03-05 19:40 +0100
          Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-05 20:40 +0100
            Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-05 21:50 +0100
              Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-05 22:30 +0100
                Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-05 23:00 +0100
                  Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-06 08:40 +0100
                    Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-06 09:20 +0100
                      Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-06 11:20 +0100
                        Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-06 13:30 +0100
                          Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-06 14:00 +0100
                          Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-06 16:00 +0100
                            Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-07 09:00 +0100
                              Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-07 20:30 +0100
                              Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-08 20:10 +0100
                                Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-08 23:20 +0100
                                Bug#1064617: Passwords should not be changed frequently Justin B Rye <justin.byam.rye@gmail.com> - 2024-03-09 14:00 +0100
                                Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-09 16:40 +0100
          Bug#1064617: Passwords should not be changed frequently Philip Hands <phil@hands.com> - 2024-03-05 20:50 +0100
            Bug#1064617: Passwords should not be changed frequently Holger Wansing <hwansing@mailbox.org> - 2024-03-06 19:50 +0100
    Bug#1064617: Passwords should not be changed frequently Diederik de Haas <didi.debian@cknow.org> - 2024-03-05 19:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1189192

[Multipart message — attachments visible in raw view] — view raw

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.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1189194

Hi all,

Am 5. März 2024 19:28:25 MEZ schrieb Cyril Brulebois <kibi@debian.org>:
>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.

Good idea.

@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>

There was some (more) discussion / various attempts on finding
the correct wording, most of which can be found in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064617>


Maybe we should have put d-l10n-english into the loop earlier, sorry for not
doing that.


Holger


-- 
Sent from /e/ OS on Fairphone3

[toc] | [prev] | [next] | [standalone]

#1189199

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.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189203

[Multipart message — attachments visible in raw view] — view raw

Justin B Rye <justin.byam.rye@gmail.com> writes:

> 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?

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.

I'm OK with the way you've phrased it, although my personal preference
would be to simply drop the "disastrous" sentence if we use this
version, because I think it breaks the straightforward flow of the text
laying out the choice we're trying to get the user to make between the
two available options. (I also rather doubt that anything we say at this
point in the install will have the slightest influence on people's
choice of password).

> 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.

Well done -- I kept noticing that, and somehow didn't get round to
fixing it. I've now deleted it, so thanks for pointing it out again. :-)

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189204

Philip Hands wrote:
> Justin B Rye <justin.byam.rye@gmail.com> writes:
>> 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?
> 
> 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".

> I'm OK with the way you've phrased it, although my personal preference
> would be to simply drop the "disastrous" sentence if we use this
> version, because I think it breaks the straightforward flow of the text
> laying out the choice we're trying to get the user to make between the
> two available options. (I also rather doubt that anything we say at this
> point in the install will have the slightest influence on people's
> choice of password).

I can imagine people might be more likely to heed something shorter;
maybe it could be boiled down to

    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.

-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189220

[Multipart message — attachments visible in raw view] — view raw

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.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189224

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).

-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189238

[Multipart message — attachments visible in raw view] — view raw

Justin B Rye <justin.byam.rye@gmail.com> writes:

> 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.)

No, as I said, what that's trying to say is that there needs to exist a
password that one way or the other will let one get access to the root
account (since otherwise one is not going to be able to admin the
machine), but that is not neccesarily the same thing as a "root
password", because the password being refered to might well be the
initial user's password, as long as they end up in the sudo group.

If it comes across as meaning that there needs to be a "root password",
then it's not succeeding in expressing the nuance of the situation
correctly, and we probably need to fix that (assuming that we can come
up with a better wording that still fits in the space available).

>    .
>    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).

This is certainly better than good enough, so I'd be fine with this too.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189247

Philip Hands wrote:
>> 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.)
> 
> No, as I said, what that's trying to say is that there needs to exist a
> password that one way or the other will let one get access to the root
> account (since otherwise one is not going to be able to admin the
> machine), but that is not neccesarily the same thing as a "root
> password", 
> 
> If it comes across as meaning that there needs to be a "root password",
> then it's not succeeding in expressing the nuance of the situation
> correctly, and we probably need to fix that (assuming that we can come
> up with a better wording that still fits in the space available).

Yes; even reading it suspecting that that might be what it was meant
to be saying I found it hard to read that interpretation into it.  The
line starting "One needs a password..." implies that this dialogue
deals with the need for the particular *password* that gives access to
the root *account* - the obvious interpretation is that it's talking
about the "Root password/passphrase" in the Description.  It takes some
mental contortions to see that my own login password might also be
thought of as doing that, and further, that this dialogue can be seen
as creating (or no, I mean causing the existence of) such a password.

But I notice now that the way I've phrased it means users aren't
implicitly warned that a sudo-privileged user account needs a good
password, so maybe I need another coffee and a think...

>>    .
>>    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).
> 
> This is certainly better than good enough, so I'd be fine with this too.

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.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189251

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, 6 March 2024 13:19:04 CET Justin B Rye 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.

How about using 'root' for the user/account and super-user for the privileges?
The 'root' user has super-user privileges all the time and the normal user can 
get those privileges via (the) sudo (mechanism).

FTR: that *is* a slight diversion from what's said here:
https://www.debian.org/releases/bookworm/amd64/ch06s03.en.html#di-user-setup

Whatever terminology we use, I think it's important that we use the same 
terminology in both the d-i screens and the Trixie Installation Guide.
Updating the Installation Guide should probably be done separately?

Cheers,
  Diederik

[toc] | [prev] | [next] | [standalone]

#1189260

[Multipart message — attachments visible in raw view] — view raw

Justin B Rye <justin.byam.rye@gmail.com> writes:

...
> 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).

I like that version better than mine, so commited it[1], and re-ran the
test to give a screenshot:

  https://openqa.debian.net/tests/239766#step/passwords/1

> 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.

Cheers, Phil.

[1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7/diffs?commit_id=2668d06de4f2de4735404a0671ecfb33f7bbd159
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189347

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).

-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189402

Hi,

Am 7. März 2024 08:50:25 MEZ schrieb Justin B Rye <justin.byam.rye@gmail.com>:
>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).

All the above looks like an improvement to me.


Holger


-- 
Sent from /e/ OS on Fairphone3

[toc] | [prev] | [next] | [standalone]

#1189475

[Multipart message — attachments visible in raw view] — view raw

Justin B Rye <justin.byam.rye@gmail.com> writes:

> 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:

Thanks for that.

> -   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).

That can be seen here:

  https://salsa.debian.org/philh/user-setup/-/commit/a684977100e6746725372f8294f271f890c50430
&
  https://openqa.debian.net/tests/240580#step/passwords/1

I think I prefer the previous version better for some reason.

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
&
  https://openqa.debian.net/tests/240582#step/passwords/1

which I think is more readable (and is probably fine now that we've
dropped the stuff about password selection which could be read as
suggesting that a password is expected to be a single word).

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189499

[Multipart message — attachments visible in raw view] — view raw

On Friday, 8 March 2024 19:58:56 CET Philip Hands wrote:
> 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?

I agree with dropping it. It does look odd and it'll likely raise (more) 
questions then it answers. And most/all people are familiar with password.

Explaining passwords/passphrases is better suited to some educational 
resource.

[toc] | [prev] | [next] | [standalone]

#1189550

Philip Hands wrote:
> 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
> &
>   https://openqa.debian.net/tests/240582#step/passwords/1
> 
> which I think is more readable (and is probably fine now that we've
> dropped the stuff about password selection which could be read as
> suggesting that a password is expected to be a single word).

It all looks fine to me; as the screenshot shows, we use "password" as
a general cover-term all over the user interface anyway.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#1189565

Hi,

Am 8. März 2024 19:58:56 MEZ schrieb Philip Hands <phil@hands.com>:
>
>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

Well, the idea was, to mention that 'passphrase' thing one time in the dialog.

Now having it at all places is indeed not strictly an improvement.
Feel free to drop it.


Holger




-- 
Sent from /e/ OS on Fairphone3

[toc] | [prev] | [next] | [standalone]

#1189195

[Multipart message — attachments visible in raw view] — view raw

Cyril Brulebois <kibi@debian.org> writes:

> 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.

I'm happy with doing that, and we might as well get it right given that
it's been ~12 years since the first bug, so a few more days makes no
odds.

I'm pretty sympathetic with the idea of simply dropping the password
advice (as just mentioned by Diederik) but it seems that Holger prefers
to keep it in -- either is fine with me.

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?

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#1189290

Hi,

Am 5. März 2024 20:44:52 MEZ schrieb Philip Hands <phil@hands.com>:
>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?

Such hints for translators can be added to the templates file, as in
<https://salsa.debian.org/installer-team/apt-setup/-/blob/master/debian/apt-setup-udeb.templates?ref_type=heads#L3>
They will then end up in translator's po files.


Do you have some specific sentence in mind, which deserves a
special hint?
I noticed that my English is not good enough to formulate such details.


Holger


-- 
Sent from /e/ OS on Fairphone3

[toc] | [prev] | [next] | [standalone]

#1189191

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, 5 March 2024 19:28:25 CET Cyril Brulebois wrote:
> 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.

I had started a reply before I had to get out the door, so I'll just keep it 
to one suggestion, which may seem a bit 'radical':

How about getting rid of the password advise entirely from the d-i screen?

We could still make educational resources with f.e. tips on passwords/
passphrases in f.e. the wiki, but it's not the job or the (best) place to put 
such things in the d-i screens?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.bugs.dist

csiph-web