Summary: | sys-apps/shadow-4.0.16's login complains about GETPASS_ASTERISKS when USE=-skey | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Federico Fissore <federico> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andre, ansla80, bakirov, betelgeuse, casta, ehmsen, ford_prefect, gentoo-bugs, gentoo-bugzilla, gentoo, harrisl, ikelos, j.thrussell, jakub, m.debruijne, matrixhax0r, matteo, nathan, nbensa, news, peter, pkilian, spamlover, teidakankan, tinaught, tom, volker, will.briggs, xmit, zlin |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Federico Fissore
2006-06-07 13:37:08 UTC
Can confirm that the problem exists on ~amd64 and commenting GETPASS_ASTERISKS 0 lin in /etc/login.defs solves this problem no, that isnt the fix Same issue here, after commenting #GETPASS_ASTERISKS 0 in /etc/login.defs the problem seems to be solved! It's taken me a bit to find the reasons for this since there's no real mention of a change to "GETPASS_ASTERISKS" anywhere except the source. After looking at the release notes of shadow-4.0.16 and comparing it's source to a previous version I've found the following: Release notes mention: " by default do not use libshadow_getpass() as getpass() replacemement. Use libshadow_getpass() only when S/KEY support is enabled. Current glibc getpass() handles correctly longer than 8 characters passwords and libshadow_getpass() is used only because libc getpass() do not handles password prompting with echo enabled" looking at the source differences between shadow-4.0.15-r2 and shadow-4.0.16 in lib/getdef.c the use of GETPASS_ASTERISKS is enabled only when the use var "skey" is used. Note the code snippets as follows: shadow-4.0.15-r2 lib/getdef.c: static struct itemdef def_table[] = { {"CHFN_RESTRICT", NULL}, [...snip...] {"GETPASS_ASTERISKS", NULL}, {"GID_MAX", NULL}, [...snip...] shadow-4.0.16 lib/getdef.c: static struct itemdef def_table[] = { {"CHFN_RESTRICT", NULL}, [...snip...] #ifdef SKEY {"GETPASS_ASTERISKS", NULL}, #endif [...snip...] Hope this helps others to know why this msg occurs (I was concerned this was a "real" error) and I'm now pretty sure the msg is harmless. Now how login.defs should be corrected (by hand or ebuild) is outside my ability to say. I confirm that setting USE=-skey in /etc/make.conf, then emerge shadow, results in the following showing up in etc-update: Showing differences between /etc/login.defs and /etc/._cfg0000_login.defs --- /etc/login.defs 2006-06-08 11:41:33.000000000 +0100 +++ /etc/._cfg0000_login.defs 2006-06-12 09:54:43.000000000 +0100 @@ -1,7 +1,7 @@ # # /etc/login.defs - Configuration control definitions for the login package. # -# $Id: login.defs,v 1.6 2006/03/12 23:47:08 flameeyes Exp $ +# $Id: login.defs.4.0.16,v 1.1 2006/06/09 20:34:53 flameeyes Exp $ # # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. # If unspecified, some arbitrary (and possibly incorrect) value will @@ -199,7 +199,9 @@ # Setting GETPASS_ASTERISKS to -1 reverts to the traditional getpass() # without any new features. This is the default. # -GETPASS_ASTERISKS 0 +# This is valid only if S/Key support is enabled +# +# GETPASS_ASTERISKS 0 # # Enable setting of the umask group bits to be the same as owner bits I have USE=-skey and I didn't get an update to my login.defs when I upgraded to shadow-4.0.16. I am seeing the error message. (In reply to comment #6) Try to --sync and emerge shadow again. That just solved the issue for me. yep, flameeyes updated the ebuild http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/shadow/ChangeLog think this bug is closed Yes. Confirmed here as well. emerge --sync and emerge shadow fixed the issue. Thanks This is FIXED. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/shadow/shadow-4.0.16.ebuild?r1=1.1&r2=1.2 Closing. not really. Because the ebuild was not bumped, you do not get the fix automatically. Some people. like me, waited for a ebuild bump, so an update world would correct the situation. What is gentoo's position on altering ebuilds without changing the version? If only the ebuiold changes, without a revision bump, the people who have already installed the ebuild just do not get the fix. This is not the first time. But IMHO it is bad practice. Volker, to answer your question, you can find the versioning policy here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 You specifically want the 'Versioning and revision bumps' subsection of the 'Ebuild policy' section. As for waiting for an r-bump before updating, there is no need to do that. If you remerge it with --oneshot, the package will not be recorded in the world file so there shouldn't be any consequences Thanks for the fix Jakub. I do agree with Volker, though. It would've been nice to see a revision bump -- people wouldn't have to come searching on b.g.o to fix the problem, then. vapier: Your correction made this problem appear again: Revision 1.4 - (view) (download) (annotate) - [select for diffs] Sat Jun 24 08:05:59 2006 UTC (5 hours, 12 minutes ago) by vapier Branch: MAIN CVS Tags: HEAD Changes since 1.3: +11 -11 lines Diff to previous 1.3 fix the GETPASS_ASTERISKS bug in a less sucky fashion (Portage version: 2.1.1_pre1-r2) betelgeuse@pena /usr/portage/sys-apps/shadow $ su Password: configuration error - unknown item 'GETPASS_ASTERISKS' (notify administrator) pena shadow # emerge -pv shadow These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/shadow-4.0.16 USE="pam -nls -nousuid -skey" 0 kB Total size of downloads: 0 kB pena shadow # works fine for me $ ebuild shadow-4.0.16.ebuild clean unpack compile install $ grep GETPASS /var/tmp/portage/shadow-4.0.16/image/etc/login.defs # display a random number (in the range 1 to GETPASS_ASTERISKS) of '*' # Setting GETPASS_ASTERISKS to 1 results in more traditional behaviour - # Setting GETPASS_ASTERISKS to 0 disables the '*' characters (Backspace, # Setting GETPASS_ASTERISKS to -1 reverts to the traditional getpass() #GETPASS_ASTERISKS 0 guess issue comes up with USE=pam issue: pam sucks should be fine in cvs now |