[PATCH] services: dovecot: Rename auth-verbose-passwords?.

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Christopher Baines
Owner
unassigned
Submitted by
Christopher Baines
Severity
normal

Debbugs page

Christopher Baines wrote 6 years ago
(address . guix-patches@gnu.org)
20190503091039.12424-1-mail@cbaines.net
* gnu/services/mail.scm (dovecot-configuration)[auth-verbose-passwords?]:
Rename to auth-verbose-passwords, and change the type to a string, as this
parameter can take one of three string values.
* doc/guix.texi (Dovecot service): Update the corresponding documentation.
---
doc/guix.texi | 4 ++--
gnu/services/mail.scm | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

Toggle diff (37 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index 7cda06de5c..1fe4618742 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -15845,13 +15845,13 @@ failed.
Defaults to @samp{#f}.
@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose-passwords?
+@deftypevr {@code{dovecot-configuration} parameter} string auth-verbose-passwords
In case of password mismatches, log the attempted password. Valid
values are no, plain and sha1. sha1 can be useful for detecting brute
force password attempts vs. user simply trying the same password over
and over again. You can also truncate the value to n chars by appending
":n" (e.g.@: sha1:6).
-Defaults to @samp{#f}.
+Defaults to @samp{"no"}.
@end deftypevr
@deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug?
diff --git a/gnu/services/mail.scm b/gnu/services/mail.scm
index 0dabfed4cb..216b2c80b0 100644
--- a/gnu/services/mail.scm
+++ b/gnu/services/mail.scm
@@ -806,8 +806,8 @@ standard facilities are supported.")
"Log unsuccessful authentication attempts and the reasons why they
failed.")
- (auth-verbose-passwords?
- (boolean #f)
+ (auth-verbose-passwords
+ (string "no")
"In case of password mismatches, log the attempted password. Valid
values are no, plain and sha1. sha1 can be useful for detecting brute
force password attempts vs. user simply trying the same password over
--
2.21.0
Ludovic Courtès wrote 6 years ago
(name . Christopher Baines)(address . mail@cbaines.net)(address . 35544@debbugs.gnu.org)
87r29a5pt1.fsf@gnu.org
Hello!

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (5 lines)
> * gnu/services/mail.scm (dovecot-configuration)[auth-verbose-passwords?]:
> Rename to auth-verbose-passwords, and change the type to a string, as this
> parameter can take one of three string values.
> * doc/guix.texi (Dovecot service): Update the corresponding documentation.

I don’t use the Dovecot service but this LGTM.

The question is whether it’s OK to break the API. I’d say that with
proper documentation it probably is. Thoughts?

Longer-term we’ll need a way to gracefully handle deprecation for this
kind of change, probably at the level of the ‘define-record-type*’
kitchen sink.

Thanks,
Ludo’.
Christopher Baines wrote 6 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35544-done@debbugs.gnu.org)
877eb1o1ia.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (9 lines)
> Christopher Baines <mail@cbaines.net> skribis:
>
>> * gnu/services/mail.scm (dovecot-configuration)[auth-verbose-passwords?]:
>> Rename to auth-verbose-passwords, and change the type to a string, as this
>> parameter can take one of three string values.
>> * doc/guix.texi (Dovecot service): Update the corresponding documentation.
>
> I don’t use the Dovecot service but this LGTM.

Great, I've pushed this now.

Toggle quote (7 lines)
> The question is whether it’s OK to break the API. I’d say that with
> proper documentation it probably is. Thoughts?
>
> Longer-term we’ll need a way to gracefully handle deprecation for this
> kind of change, probably at the level of the ‘define-record-type*’
> kitchen sink.

Yeah, I'm uncertain. For long running systems, it's probably good to
update the packages, without having to adjust the service configuration
for changes like this. If there was a "stable" channel to track, which
didn't include updates to services, but did include important package
updates, then that may be useful.

Also, just making the errors relating to service configuration may be
more impactful than adding extra deprecation support.

Thanks,

Chris
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlzSg11fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE
9Xf03g/8DWhkXDeS5nXmx+dl4NOBtBB1EZxe3J+/pSACdWvlvMw1Cua6RDD5sNqn
LbRJsdubSu28dINTYwsmL9NYwhrf5GoUngEHe8Czhj6tG9IK5Z7OL1fuMx05osyc
r9WzQT9zbw80bICWR55sUXFAAfZrWkS/qLGbMCU+VKIF2V0okhNWOV6iC7Guhq3j
/6jQ4mxtEc6rlDvIa6ZW99OLHLJBv5c8xlUyzC7VKk8i9Nku2Z+tfrOxRckAXdXs
YIJZZww3lavigb1nNFV5osych+Z9g8tTWmtvK82cd8JYtCDrRQ2xhANuSWaGciBd
5lLmuzS838ZhQ3lzDPs6vGNTB4Q3We4jyShzw5TmGGl4enHzGsTK9+4qTdEH15wq
U1+X09mKNfPOWmNgNpcpLki0dg6cYPG+jMwOVq9VEf67keWvJD09gQ5fxPiVKvxP
WBN2nEbFOpIZpLEFqtmxXIld45zYyLqPxgL1Lqwq/siOJi9gABoI72AqzcXh3lpu
gyowuz5PF3BfmhhZqqnB2pdgF+Y1PRppNCgL/2AJphk0yz4FjHgnjTi1TawFeOHV
3026fGfabgxSheIVoIxvOLoAxUgqqbXBqcxoH0pTsuFLz6MaO8T2QOlDoXZuQq0K
KbL5Hep+5HVnjtkrGDTDBBlhrdmAkGtZaRfzOtl0eSu92t3PE2w=
=MeM7
-----END PGP SIGNATURE-----

Closed
Ludovic Courtès wrote 6 years ago
(name . Christopher Baines)(address . mail@cbaines.net)(address . 35544-done@debbugs.gnu.org)
87lfzhz0ot.fsf@gnu.org
Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (2 lines)
> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (16 lines)
>> The question is whether it’s OK to break the API. I’d say that with
>> proper documentation it probably is. Thoughts?
>>
>> Longer-term we’ll need a way to gracefully handle deprecation for this
>> kind of change, probably at the level of the ‘define-record-type*’
>> kitchen sink.
>
> Yeah, I'm uncertain. For long running systems, it's probably good to
> update the packages, without having to adjust the service configuration
> for changes like this. If there was a "stable" channel to track, which
> didn't include updates to services, but did include important package
> updates, then that may be useful.
>
> Also, just making the errors relating to service configuration may be
> more impactful than adding extra deprecation support.

The problem, as I see it, is that possibly weeks from now people will
try to reconfigure and will get an error about
‘auth-verbose-passwords?’. At that point they’ll have to dig to figure
out that there’s a field with a similar name and similar semantics and
to adjust their code accordingly.

But maybe the real solution is providing a “news” system, as discussed
with Tobias and others recently on guix-devel: ‘guix pull -N’ would
display a message saying that the Dovecot API has changed, etc.

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 35544@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 35544
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help