| Summary: | sys-libs/uclibc: enable sha512 crypt support by default (since shadow[-pam] uses it) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sven E. <dark> |
| Component: | [OLD] Unspecified | Assignee: | Embedded Gentoo Team <embedded> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blueness |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge-uclibc.info | ||
|
Description
Sven E.
2016-05-26 00:20:36 UTC
emerge-x86_64-pc-linux-uclibc -pqv =sys-apps/shadow-4.2.1-r2 [ebuild R ] sys-apps/shadow-4.2.1-r2 to /usr/x86_64-pc-linux-uclibc/ USE="acl cracklib xattr -audit (-nls) (-pam) (-selinux) -skey" LINGUAS="-cs -da -de -es -fi -fr -hu -id -it -ja -ko -pl -pt_BR -ru -sv -tr -zh_CN -zh_TW" * IMPORTANT: 5 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. Created attachment 435406 [details]
emerge-uclibc.info
emerge --info
not really a regression. shadow has been defaulting to sha512 since 4.1.3, and uclibc's default config has never enabled this option (afaict). (In reply to SpanKY from comment #3) > not really a regression. shadow has been defaulting to sha512 since 4.1.3, > and uclibc's default config has never enabled this option (afaict). two comments: 1) i'm still building the stages with a savedconfig where i turn on most options. i will move away from this and put *no* custom files in /etc/portage when i finish pushing out uclibc-ng. anyhow, in that savedconfig file, i do turn on UCLIBC_HAS_SHA512_CRYPT_IMPL and 256 and lots of other stuff. 2) i can go ahead and add "kconfig_q_opt y UCLIBC_HAS_SHA512_CRYPT_IMPL" to our current ebuilds but that would unconditionally add this making it unavoidable bloat. so should we have another USE flag like USE=crypto that turns on sha256, sha512 and any other crypto stuff? (i'm not even sure what i'd call the flag.) As I pointed out in another bug using -savedconfig is quite difficult. And the way things are handled with uclibc would require quite an amount of USE flags to handle all that. I assume this is in no way better with uclibc-ng? The question is, on what level of granularity should this be done anyway? You could still call it extra_crypto, maybe, or something along these lines. (In reply to Anthony Basile from comment #4) > (In reply to SpanKY from comment #3) > > not really a regression. shadow has been defaulting to sha512 since 4.1.3, > > and uclibc's default config has never enabled this option (afaict). > > two comments: > > 1) i'm still building the stages with a savedconfig where i turn on most > options. i will move away from this and put *no* custom files in > /etc/portage when i finish pushing out uclibc-ng. anyhow, in that > savedconfig file, i do turn on UCLIBC_HAS_SHA512_CRYPT_IMPL and 256 and lots > of other stuff. > > 2) i can go ahead and add "kconfig_q_opt y UCLIBC_HAS_SHA512_CRYPT_IMPL" to > our current ebuilds but that would unconditionally add this making it > unavoidable bloat. so should we have another USE flag like USE=crypto that > turns on sha256, sha512 and any other crypto stuff? (i'm not even sure what > i'd call the flag.) (In reply to Anthony Basile from comment #4) the default config created by the ebuild should align with most of the packages in the tree. in this case, we'll want to turn UCLIBC_HAS_SHA512_CRYPT_IMPL on. i don't think putting it behind USE=crypto makes sense since shadow still won't work as-is, and i don't think it's an option that most people will care about. if people are super concerned about size, they can always USE=savedconfig and tweak it however they want (including options that might not play well with other packages in the tree). (In reply to SpanKY from comment #6) > (In reply to Anthony Basile from comment #4) > > the default config created by the ebuild should align with most of the > packages in the tree. in this case, we'll want to turn > UCLIBC_HAS_SHA512_CRYPT_IMPL on. i don't think putting it behind USE=crypto > makes sense since shadow still won't work as-is, and i don't think it's an > option that most people will care about. if people are super concerned > about size, they can always USE=savedconfig and tweak it however they want > (including options that might not play well with other packages in the tree). Wouldn't it be sane then to enable SHA256 aswell? I guess crypt() is not just used by shadow, but also by daemons etc. that do auths against other credential databases (or passwd/shadow for that matter). And certainly there's quite some passwd files and creds DBs covering everything from MD5 to SHA512, I'd assume. But that's just my POV. (In reply to Sven E. from comment #7) > Wouldn't it be sane then to enable SHA256 aswell? yes (In reply to Anthony Basile from comment #8) > (In reply to Sven E. from comment #7) > > > Wouldn't it be sane then to enable SHA256 aswell? > > yes enjoy! commit 633d56fbf4d1e22d4179c378edb16bdb3762ad94 Author: Anthony G. Basile <blueness@gentoo.org> Date: Thu Jun 2 19:58:55 2016 -0400 sys-libs/uclibc: ensable SHA256 and 512 by default, bug #584140 Package-Manager: portage-2.2.28 diff --git a/sys-libs/uclibc/uclibc-0.9.33.2-r15.ebuild b/sys-libs/uclibc/uclibc-0.9.33.2-r15.ebuild index 626fc8c..49979af 100644 --- a/sys-libs/uclibc/uclibc-0.9.33.2-r15.ebuild +++ b/sys-libs/uclibc/uclibc-0.9.33.2-r15.ebuild @@ -155,6 +155,8 @@ src_config() { UCLIBC_HAS_LIBUTIL UCLIBC_HAS_PROGRAM_INVOCATION_NAME UCLIBC_HAS_RESOLVER_SUPPORT + UCLIBC_HAS_SHA256_CRYPT_IMPL + UCLIBC_HAS_SHA512_CRYPT_IMPL UCLIBC_HAS_TZ_FILE_READ_MANY UCLIBC_HAS_UTMPX UCLIBC_SUPPORT_AI_ADDRCONFIG |
