Re: [gentoo-portage-dev] [PATCH] emake: explicitly set SHELL
> On 26 Jul 2022, at 04:00, Sam James wrote:
>
>
>
>> On 25 Jul 2022, at 16:28, Fabian Groffen wrote:
>>
>> bin/ebuild-helpers/emake: force SHELL to be set
>>
>> On Prefix systems /bin/sh can be anything, including very ancient. So
>> ensure we're running with bash, since that's what Gentoo Linux is
>> expecting /bin/sh to be (by default, at least).
>>
>> Provide a fallback for the (near impossible) case that we use a bash
>> that doesn't set BASH, or when we don't use bash at all. This is not
>> expected, though, as we explicitly require bash throughout all Portage,
>> so we don't really care about using a non-Prefixed one, for this really
>> shouldn't happen.
>>
>> Signed-off-by: Fabian Groffen
>>
>> diff --git a/bin/ebuild-helpers/emake b/bin/ebuild-helpers/emake
>> index 60718a2e4..21da85845 100755
>> --- a/bin/ebuild-helpers/emake
>> +++ b/bin/ebuild-helpers/emake
>> @@ -12,7 +12,7 @@
>> source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
>>
>> cmd=(
>> -${MAKE:-make} ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
>> +${MAKE:-make} SHELL="${BASH:-/bin/bash}" ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
>> )
>>
>> if [[ ${PORTAGE_QUIET} != 1 ]] ; then
>>
>
> I don't think I agree with this as it is. Why not just ${EPREFIX}/bin/sh to
> avoid using
> an ancient host sh?
>
Sorry, ${BROOT}, I guess.
> I might use Bash for Portage but my /bin/sh is dash usually.
>
>> --
>> Fabian Groffen
>> Gentoo on a different level
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-portage-dev] [PATCH] 80libraries: add support for Darwin targets
> On 26 Jul 2022, at 00:33, Mike Gilbert wrote:
>
> On Mon, Jul 25, 2022 at 11:38 AM Fabian Groffen wrote:
>>
>> bin/install-qa-check.d/80libraries: support Darwin/Mach-O objects
>>
>> Check for dylib on Darwin, so on everything else.
>>
>> Signed-off-by: Fabian Groffen
>>
>> diff --git a/bin/install-qa-check.d/80libraries
>> b/bin/install-qa-check.d/80libraries
>> index 8dc35bb87..a477ec9cb 100644
>> --- a/bin/install-qa-check.d/80libraries
>> +++ b/bin/install-qa-check.d/80libraries
>> @@ -140,7 +140,9 @@ lib_check() {
>>local abort="no"
>>local a s
>>for a in "${ED%/}"/usr/lib*/*.a ; do
>> - s=${a%.a}.so
>> + [[ ${CHOST} == *-darwin* ]] \
>> + && s=${a%.a}.dylib \
>> + || s=${a%.a}.so
>
> I would find this much easier to read if you converted it to an
> if/else statement instead of chaining && and ||.
Yes, please.
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-portage-dev] [PATCH] emake: explicitly set SHELL
> On 25 Jul 2022, at 16:28, Fabian Groffen wrote:
>
> bin/ebuild-helpers/emake: force SHELL to be set
>
> On Prefix systems /bin/sh can be anything, including very ancient. So
> ensure we're running with bash, since that's what Gentoo Linux is
> expecting /bin/sh to be (by default, at least).
>
> Provide a fallback for the (near impossible) case that we use a bash
> that doesn't set BASH, or when we don't use bash at all. This is not
> expected, though, as we explicitly require bash throughout all Portage,
> so we don't really care about using a non-Prefixed one, for this really
> shouldn't happen.
>
> Signed-off-by: Fabian Groffen
>
> diff --git a/bin/ebuild-helpers/emake b/bin/ebuild-helpers/emake
> index 60718a2e4..21da85845 100755
> --- a/bin/ebuild-helpers/emake
> +++ b/bin/ebuild-helpers/emake
> @@ -12,7 +12,7 @@
> source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
>
> cmd=(
> - ${MAKE:-make} ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
> + ${MAKE:-make} SHELL="${BASH:-/bin/bash}" ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
> )
>
> if [[ ${PORTAGE_QUIET} != 1 ]] ; then
>
I don't think I agree with this as it is. Why not just ${EPREFIX}/bin/sh to
avoid using
an ancient host sh?
I might use Bash for Portage but my /bin/sh is dash usually.
> --
> Fabian Groffen
> Gentoo on a different level
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-portage-dev] [PATCH] phase-functions: make ED, EROOT read-only
On Mon, Jul 25, 2022 at 1:03 PM Fabian Groffen wrote: > > bin/phase-functions.sh: make ED and EROOT read-only too > > Like D, make ED and EROOT read-only vars. Makes sense.
Re: [gentoo-portage-dev] [PATCH] misc-functions: Prefix fixes
On Mon, Jul 25, 2022 at 12:47 PM Fabian Groffen wrote: > > bin/misc-functions.sh: some Prefix fixes > > - ED needs not to exist, whereas D does, so ensure we check for that, > and create ED if absent, necessary for further checks to succeed > - use EPREFIX in INSTALL_MASK Seems good to me.
Re: [gentoo-portage-dev] [PATCH] world-writable: tune for Prefix
On Mon, Jul 25, 2022 at 12:41 PM Fabian Groffen wrote: > > bin/install-qa-check.d/90world-writable: include EPREFIX in reports > > It is much less confusing and consistent to report full paths including > the leading EPREFIX. Makes sense to me.
Re: [gentoo-portage-dev] [PATCH] multilib-strict: fix for Prefix
On Mon, Jul 25, 2022 at 12:26 PM Fabian Groffen wrote:
>
> bin/install-qa-check.d/80multilib-strict: use file/find from Prefix
>
> diff --git a/bin/install-qa-check.d/80multilib-strict
> b/bin/install-qa-check.d/80multilib-strict
> index afd223250..3db4ecce3 100644
> --- a/bin/install-qa-check.d/80multilib-strict
> +++ b/bin/install-qa-check.d/80multilib-strict
> @@ -1,7 +1,7 @@
> # Strict multilib directory checks
> multilib_strict_check() {
> if has multilib-strict ${FEATURES} && \
> - [[ -x /usr/bin/file && -x /usr/bin/find ]] && \
> + [[ -x ${EPREFIX}/usr/bin/file && -x ${EPREFIX}/usr/bin/find ]] && \
>[[ -n ${MULTILIB_STRICT_DIRS} && -n ${MULTILIB_STRICT_DENY} ]]
> then
> rm -f "${T}/multilib-strict.log"
Seems good to me.
Re: [gentoo-portage-dev] [PATCH] emake: explicitly set SHELL
On Mon, Jul 25, 2022 at 11:28 AM Fabian Groffen wrote: > > bin/ebuild-helpers/emake: force SHELL to be set > > On Prefix systems /bin/sh can be anything, including very ancient. So > ensure we're running with bash, since that's what Gentoo Linux is > expecting /bin/sh to be (by default, at least). > > Provide a fallback for the (near impossible) case that we use a bash > that doesn't set BASH, or when we don't use bash at all. This is not > expected, though, as we explicitly require bash throughout all Portage, > so we don't really care about using a non-Prefixed one, for this really > shouldn't happen. I'm a little on the fence about this: in theory, Makefiles should use POSIX-compatible shell commands unless the author explicitly chooses to use bash. I guess we can get away with this since ebuilds always require bash anyway.
Re: [gentoo-portage-dev] [PATCH] 80libraries: add support for Darwin targets
On Mon, Jul 25, 2022 at 11:38 AM Fabian Groffen wrote:
>
> bin/install-qa-check.d/80libraries: support Darwin/Mach-O objects
>
> Check for dylib on Darwin, so on everything else.
>
> Signed-off-by: Fabian Groffen
>
> diff --git a/bin/install-qa-check.d/80libraries
> b/bin/install-qa-check.d/80libraries
> index 8dc35bb87..a477ec9cb 100644
> --- a/bin/install-qa-check.d/80libraries
> +++ b/bin/install-qa-check.d/80libraries
> @@ -140,7 +140,9 @@ lib_check() {
> local abort="no"
> local a s
> for a in "${ED%/}"/usr/lib*/*.a ; do
> - s=${a%.a}.so
> + [[ ${CHOST} == *-darwin* ]] \
> + && s=${a%.a}.dylib \
> + || s=${a%.a}.so
I would find this much easier to read if you converted it to an
if/else statement instead of chaining && and ||.
Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check
Could you please create a PR at https://github.com/gentoo/portage so that the CI system can test the changes for this patch series?
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
Hi! Am 22.07.2022 um 21:10 schrieb Mikhail Koliada: What do you think? I like the idea and would like to see that change. Conrad
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Sat, Jul 23, 2022 at 08:55:14PM -0400, Mike Gilbert wrote: > On Fri, Jul 22, 2022 at 3:10 PM Mikhail Koliada wrote: > > > > Hello! > > > > This idea has been fluctuating in my head for quite a while given that the > > migration had happened > > a while ago [0] and some other major distributions have already adopted > > yescrypt as their default algo > > by now [1]. For us switching is as easy as changing the default use flag in > > pambase and rehashing the password > > with the ‘passwd’ call (a news item will be required). > > > > What do you think? > > Seems like a reasonable idea to me. Just giving my +1 to that, no strong opinion but reading about it sounds like a reasonable choice to me. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 7/25/2022 16:29, John Helmert III wrote: > On Mon, Jul 25, 2022 at 03:59:59PM -0400, Joshua Kinard wrote: >> On 7/25/2022 15:30, Joshua Kinard wrote: >> [snip] >> >>> >>> Some really quick looking around, I'm not finding any substantive >>> discussions on why yescrypt is better than argon2. It so far seems that it >>> just got implemented in libxcrypt sooner than argon2 did, so that's why >>> there is this sudden push for it. >>> >>> E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend >>> yescrypt instead. Anyway, it has to be implemented in libcrypt.", but >>> provides no justification for why they recommend yescrypt. Since we're >>> dealing with a fairly important function for system security, I kinda want >>> something with much more context that presents pros and cons for this >>> algorithm over others, especially argon2. >> >> So there is this question and three answers on Crypto StackExchange. It is >> about five years-old, but it's got more detail on why argon2 won the PHC >> instead of one of the other contenders. It is still subjective information, >> but more thorough: >> https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc >> >> There's some more info if one continues to deep-dive on CSE, but I am >> noticing a lot of the info is several years old. Some more recent things >> make references to a newer algo called Balloon, but that seems to be going >> off into side-tangents. >> >> Anyways, I guess I am just being paranoid. If a change to hashing algos is >> made, it should be based on facts and not popularity contests or feelings. > > I'm not sure it's fair to suggest this change is based on "popularity > contests or feelings". The facts were given in the original mail, just > because one finds them unconvincing doesn't mean those facts aren't > real and convincing to others. > My wording could sometimes be done better, but that's my takeaway in a nutshell. Facts, presented objectively and well, should convince just about anyone. But the Fedora page just doesn't do that for me. It really only presents positives and no negatives of yescrypt. Are there any? I don't know. I assume there have to be, but I'm not a crypto-expert. I've only done a light, cursory search on Google for something basic like "argon2 vs yescrypt", and that gets a few interesting results. A few links to github, one to the PHC website, another to the the now-dead openwall ML posts, and Debian's bug for switching pam_linux over to using yescrypt. The most recent discussion-wise result are the comments on a Hacker News article that is 11 months old[1]. 1. https://news.ycombinator.com/item?id=28181350 -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Mon, Jul 25, 2022 at 03:59:59PM -0400, Joshua Kinard wrote: > On 7/25/2022 15:30, Joshua Kinard wrote: > [snip] > > > > > Some really quick looking around, I'm not finding any substantive > > discussions on why yescrypt is better than argon2. It so far seems that it > > just got implemented in libxcrypt sooner than argon2 did, so that's why > > there is this sudden push for it. > > > > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend > > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but > > provides no justification for why they recommend yescrypt. Since we're > > dealing with a fairly important function for system security, I kinda want > > something with much more context that presents pros and cons for this > > algorithm over others, especially argon2. > > So there is this question and three answers on Crypto StackExchange. It is > about five years-old, but it's got more detail on why argon2 won the PHC > instead of one of the other contenders. It is still subjective information, > but more thorough: > https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc > > There's some more info if one continues to deep-dive on CSE, but I am > noticing a lot of the info is several years old. Some more recent things > make references to a newer algo called Balloon, but that seems to be going > off into side-tangents. > > Anyways, I guess I am just being paranoid. If a change to hashing algos is > made, it should be based on facts and not popularity contests or feelings. I'm not sure it's fair to suggest this change is based on "popularity contests or feelings". The facts were given in the original mail, just because one finds them unconvincing doesn't mean those facts aren't real and convincing to others. > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 7/25/2022 15:30, Joshua Kinard wrote: [snip] > > Some really quick looking around, I'm not finding any substantive > discussions on why yescrypt is better than argon2. It so far seems that it > just got implemented in libxcrypt sooner than argon2 did, so that's why > there is this sudden push for it. > > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but > provides no justification for why they recommend yescrypt. Since we're > dealing with a fairly important function for system security, I kinda want > something with much more context that presents pros and cons for this > algorithm over others, especially argon2. So there is this question and three answers on Crypto StackExchange. It is about five years-old, but it's got more detail on why argon2 won the PHC instead of one of the other contenders. It is still subjective information, but more thorough: https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc There's some more info if one continues to deep-dive on CSE, but I am noticing a lot of the info is several years old. Some more recent things make references to a newer algo called Balloon, but that seems to be going off into side-tangents. Anyways, I guess I am just being paranoid. If a change to hashing algos is made, it should be based on facts and not popularity contests or feelings. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 7/25/2022 15:34, John Helmert III wrote: > On Mon, Jul 25, 2022 at 03:30:08PM -0400, Joshua Kinard wrote: [snip] >> >> "yescrypt" is an odd name for a hashing algorithm. I looked it up on >> Wikipedia, and it just redirects to the 2013 Password Hashing Competition >> (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa, >> and lyra2). The winner was argon2. So unless something has changed in the >> last nine years or there is more recent information, wouldn't it make more >> sense to go with the winner of such a competition (argon2) instead of a >> runner-up? I know marecki said Fedora was waiting for an official RFC for >> argon2, but the wait for that ended almost a year ago in Sept 2021 when >> RFC9106[2] was released. >> >> Some really quick looking around, I'm not finding any substantive >> discussions on why yescrypt is better than argon2. It so far seems that it >> just got implemented in libxcrypt sooner than argon2 did, so that's why >> there is this sudden push for it. >> >> E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend >> yescrypt instead. Anyway, it has to be implemented in libcrypt.", but >> provides no justification for why they recommend yescrypt. Since we're >> dealing with a fairly important function for system security, I kinda want >> something with much more context that presents pros and cons for this >> algorithm over others, especially argon2. >> >> That said, there does appear to be an open pull request on libxcrypt for >> argon2[4], so maybe that is something to follow to see where it goes? >> >> 1. https://en.wikipedia.org/wiki/Password_Hashing_Competition >> 2. https://datatracker.ietf.org/doc/html/rfc9106 >> 3. https://github.com/linux-pam/linux-pam/issues/45 >> 4. https://github.com/besser82/libxcrypt/pull/150 >> >> tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because >> it seems popular. I would prefer something that's been thoroughly tested. >> The scant info I've found thus far, that points to argon2, not yescrypt. > > There's justification for this in one of the references in zlogene's > original mail: > > https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow#Detailed_Description > Yeah, I did read that bit, but it still feels like it is written as someone's opinion rather than as an objective comparison. It also states that yescrypt is "based on NIST-approved primitives", whereas argon2 is based on Blake2 (which I assume is not NIST-approved" at this time). But just because something uses a NIST-approved mechanism does not mean it inherits that approval, so that argument doesn't completely convince me. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Mon, Jul 25, 2022 at 03:30:08PM -0400, Joshua Kinard wrote: > On 7/25/2022 14:44, Sam James wrote: > > > > > >> On 22 Jul 2022, at 20:10, Mikhail Koliada wrote: > >> > >> Hello! > >> > >> This idea has been fluctuating in my head for quite a while given that the > >> migration had happened > >> a while ago [0] and some other major distributions have already adopted > >> yescrypt as their default algo > >> by now [1]. For us switching is as easy as changing the default use flag > >> in pambase and rehashing the password > >> with the ‘passwd’ call (a news item will be required). > >> > >> What do you think? > >> > >> P.S. surely, I am only speaking about the local auth method based on > >> shadow and also about the pam-based systems as the change is going > >> to mainly impact the pam_unix.so calls in the pam’s stack. > >> Pamless or the systems with an alternative auth methods is a different > >> story. > >> > >> [0] - > >> https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html > >> [1] - > >> https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow > > > > It's fine with me although I guess I'm a bit reluctant when the libxcrypt > > stuff is still biting > > some users. > > > > My preference would be to wait a few more months, but I don't feel strongly > > about it, > > and won't object if we want to move forward sooner. > > > > Overall though, it's a good idea, although I'd welcome Jason's input > > on alternatives first. CC'd. > > > > Best, > > sam > > "yescrypt" is an odd name for a hashing algorithm. I looked it up on > Wikipedia, and it just redirects to the 2013 Password Hashing Competition > (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa, > and lyra2). The winner was argon2. So unless something has changed in the > last nine years or there is more recent information, wouldn't it make more > sense to go with the winner of such a competition (argon2) instead of a > runner-up? I know marecki said Fedora was waiting for an official RFC for > argon2, but the wait for that ended almost a year ago in Sept 2021 when > RFC9106[2] was released. > > Some really quick looking around, I'm not finding any substantive > discussions on why yescrypt is better than argon2. It so far seems that it > just got implemented in libxcrypt sooner than argon2 did, so that's why > there is this sudden push for it. > > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but > provides no justification for why they recommend yescrypt. Since we're > dealing with a fairly important function for system security, I kinda want > something with much more context that presents pros and cons for this > algorithm over others, especially argon2. > > That said, there does appear to be an open pull request on libxcrypt for > argon2[4], so maybe that is something to follow to see where it goes? > > 1. https://en.wikipedia.org/wiki/Password_Hashing_Competition > 2. https://datatracker.ietf.org/doc/html/rfc9106 > 3. https://github.com/linux-pam/linux-pam/issues/45 > 4. https://github.com/besser82/libxcrypt/pull/150 > > tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because > it seems popular. I would prefer something that's been thoroughly tested. > The scant info I've found thus far, that points to argon2, not yescrypt. There's justification for this in one of the references in zlogene's original mail: https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow#Detailed_Description > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 7/25/2022 14:44, Sam James wrote: > > >> On 22 Jul 2022, at 20:10, Mikhail Koliada wrote: >> >> Hello! >> >> This idea has been fluctuating in my head for quite a while given that the >> migration had happened >> a while ago [0] and some other major distributions have already adopted >> yescrypt as their default algo >> by now [1]. For us switching is as easy as changing the default use flag in >> pambase and rehashing the password >> with the ‘passwd’ call (a news item will be required). >> >> What do you think? >> >> P.S. surely, I am only speaking about the local auth method based on shadow >> and also about the pam-based systems as the change is going >> to mainly impact the pam_unix.so calls in the pam’s stack. >> Pamless or the systems with an alternative auth methods is a different story. >> >> [0] - >> https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html >> [1] - >> https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow > > It's fine with me although I guess I'm a bit reluctant when the libxcrypt > stuff is still biting > some users. > > My preference would be to wait a few more months, but I don't feel strongly > about it, > and won't object if we want to move forward sooner. > > Overall though, it's a good idea, although I'd welcome Jason's input > on alternatives first. CC'd. > > Best, > sam "yescrypt" is an odd name for a hashing algorithm. I looked it up on Wikipedia, and it just redirects to the 2013 Password Hashing Competition (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa, and lyra2). The winner was argon2. So unless something has changed in the last nine years or there is more recent information, wouldn't it make more sense to go with the winner of such a competition (argon2) instead of a runner-up? I know marecki said Fedora was waiting for an official RFC for argon2, but the wait for that ended almost a year ago in Sept 2021 when RFC9106[2] was released. Some really quick looking around, I'm not finding any substantive discussions on why yescrypt is better than argon2. It so far seems that it just got implemented in libxcrypt sooner than argon2 did, so that's why there is this sudden push for it. E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend yescrypt instead. Anyway, it has to be implemented in libcrypt.", but provides no justification for why they recommend yescrypt. Since we're dealing with a fairly important function for system security, I kinda want something with much more context that presents pros and cons for this algorithm over others, especially argon2. That said, there does appear to be an open pull request on libxcrypt for argon2[4], so maybe that is something to follow to see where it goes? 1. https://en.wikipedia.org/wiki/Password_Hashing_Competition 2. https://datatracker.ietf.org/doc/html/rfc9106 3. https://github.com/linux-pam/linux-pam/issues/45 4. https://github.com/besser82/libxcrypt/pull/150 tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because it seems popular. I would prefer something that's been thoroughly tested. The scant info I've found thus far, that points to argon2, not yescrypt. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
> On 22 Jul 2022, at 20:10, Mikhail Koliada wrote: > > Hello! > > This idea has been fluctuating in my head for quite a while given that the > migration had happened > a while ago [0] and some other major distributions have already adopted > yescrypt as their default algo > by now [1]. For us switching is as easy as changing the default use flag in > pambase and rehashing the password > with the ‘passwd’ call (a news item will be required). > > What do you think? > > P.S. surely, I am only speaking about the local auth method based on shadow > and also about the pam-based systems as the change is going > to mainly impact the pam_unix.so calls in the pam’s stack. > Pamless or the systems with an alternative auth methods is a different story. > > [0] - > https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html > [1] - > https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow It's fine with me although I guess I'm a bit reluctant when the libxcrypt stuff is still biting some users. My preference would be to wait a few more months, but I don't feel strongly about it, and won't object if we want to move forward sooner. Overall though, it's a good idea, although I'd welcome Jason's input on alternatives first. CC'd. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
> On 25 Jul 2022, at 15:35, Peter Stuge wrote: > > Mikhail Koliada wrote: >> This idea has been fluctuating in my head for quite a while given >> that the migration had happened a while ago [0] and some other >> major distributions have already adopted yescrypt as their default algo >> by now [1]. > > Please only do that based on proven merit and nothing else. > > Fedora or anyone else for that matter making a change is a truly > terrible reason to take any action whatsoever, since other > organizations are driven by /their/ interests - with Fedora in > particular being driven by the business interests of Red Hat. > > I consider Gentoo a leader in many regards and it makes me really > sad whenever Gentoo changes based on nothing more than "others did it". > A fair part of the motivation for the libxcrypt migration was allowing use of tougher hashing algorithms like yescrypt. While your concern may be valid in some contexts, it's not what's happening here, as Rich notes. Maybe zlogene's email should have explicitly stated that yescrypt has desirable security properties, but it's not being done simply because "Fedora did it". > > Thanks and kind regards > > //Peter > Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check
> On Mon, 25 Jul 2022, Fabian Groffen wrote:
> @@ -50,6 +51,16 @@ if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]];
> then
> __helpers_die "${helper} used with \${D} or \${ED}"
> exit 1
> fi
> +if [[ -n ${EPREFIX} && \
> + ${_E_INSDESTTREE_#${EPREFIX}} != "${_E_INSDESTTREE_}" ]];
The semicolon is redundant.
> +then
> + __vecho "---" 1>&2
> + __vecho "You should not use \${EPREFIX} with helpers." 1>&2
> + __vecho " --> ${_E_INSDESTTREE_}" 1>&2
> + __vecho "---" 1>&2
> + __helpers_die "${helper} used with \${EPREFIX}"
> + exit 1
> +fi
signature.asc
Description: PGP signature
[gentoo-portage-dev] [PATCH] phase-functions: make ED, EROOT read-only
bin/phase-functions.sh: make ED and EROOT read-only too Like D, make ED and EROOT read-only vars. Signed-off-by: Fabian Groffen diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh index ccf7eeea7..212b19fc1 100644 --- a/bin/phase-functions.sh +++ b/bin/phase-functions.sh @@ -12,7 +12,7 @@ PORTAGE_READONLY_METADATA="BDEPEND DEFINED_PHASES DEPEND DESCRIPTION PDEPEND RDEPEND REPOSITORY RESTRICT SLOT SRC_URI" PORTAGE_READONLY_VARS="D EBUILD EBUILD_PHASE EBUILD_PHASE_FUNC \ - EBUILD_SH_ARGS EMERGE_FROM FILESDIR MERGE_TYPE \ + EBUILD_SH_ARGS ED EMERGE_FROM EROOT FILESDIR MERGE_TYPE \ PM_EBUILD_HOOK_DIR \ PORTAGE_ACTUAL_DISTDIR PORTAGE_ARCHLIST PORTAGE_BASHRC \ PORTAGE_BINPKG_FILE PORTAGE_BINPKG_TAR_OPTS PORTAGE_BINPKG_TMPFILE \ -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] misc-functions: Prefix fixes
bin/misc-functions.sh: some Prefix fixes
- ED needs not to exist, whereas D does, so ensure we check for that,
and create ED if absent, necessary for further checks to succeed
- use EPREFIX in INSTALL_MASK
Signed-off-by: Fabian Groffen
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index c8bac08e7..8fcc23588 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -19,6 +19,8 @@ source "${PORTAGE_BIN_PATH}/ebuild.sh" || exit 1
install_symlink_html_docs() {
if ! ___eapi_has_prefix_variables; then
local ED=${D}
+ else
+ [[ ! -d ${ED} && -d ${D} ]] && dodir /
fi
cd "${ED}" || die "cd failed"
# Symlink the html documentation (if DOC_SYMLINKS_DIR is set in
make.conf)
@@ -83,7 +87,7 @@ install_qa_check() {
local EPREFIX= ED=${D}
fi
- cd "${ED}" || die "cd failed"
+ cd "${D}" || die "cd failed"
# Collect the paths for QA checks, highest prio first.
paths=(
@@ -367,7 +718,7 @@ preinst_mask() {
local f x
for f in man info doc; do
if has no${f} ${FEATURES}; then
- INSTALL_MASK+=" /usr/share/${f}"
+ INSTALL_MASK+=" ${EPREFIX}/usr/share/${f}"
fi
done
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-portage-dev] [PATCH] world-writable: tune for Prefix
bin/install-qa-check.d/90world-writable: include EPREFIX in reports
It is much less confusing and consistent to report full paths including
the leading EPREFIX.
Signed-off-by: Fabian Groffen
diff --git a/bin/install-qa-check.d/90world-writable
b/bin/install-qa-check.d/90world-writable
index 820683bd6..90b961a86 100644
--- a/bin/install-qa-check.d/90world-writable
+++ b/bin/install-qa-check.d/90world-writable
@@ -2,7 +2,7 @@
world_writable_check() {
# Now we look for all world writable files.
- local unsafe_files=$(find "${ED}" -type f -perm -2 | sed -e
"s:^${ED}:/:")
+ local unsafe_files=$(find "${ED}" -type f -perm -2 | sed -e
"s:^${D}:/:")
local OLDIFS x prev_shopts=$-
OLDIFS=$IFS
@@ -19,7 +21,7 @@ world_writable_check() {
eqawarn
fi
- local unsafe_files=$(find "${ED}" -type f '(' -perm -2002 -o -perm
-4002 ')' | sed -e "s:^${ED}:/:")
+ local unsafe_files=$(find "${ED}" -type f '(' -perm -2002 -o -perm
-4002 ')' | sed -e "s:^${D}:/:")
if [[ -n ${unsafe_files} ]] ; then
eqawarn "QA Notice: Unsafe files detected (set*id and world
writable)"
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-portage-dev] [PATCH] multilib-strict: fix for Prefix
bin/install-qa-check.d/80multilib-strict: use file/find from Prefix
diff --git a/bin/install-qa-check.d/80multilib-strict
b/bin/install-qa-check.d/80multilib-strict
index afd223250..3db4ecce3 100644
--- a/bin/install-qa-check.d/80multilib-strict
+++ b/bin/install-qa-check.d/80multilib-strict
@@ -1,7 +1,7 @@
# Strict multilib directory checks
multilib_strict_check() {
if has multilib-strict ${FEATURES} && \
- [[ -x /usr/bin/file && -x /usr/bin/find ]] && \
+ [[ -x ${EPREFIX}/usr/bin/file && -x ${EPREFIX}/usr/bin/find ]] && \
[[ -n ${MULTILIB_STRICT_DIRS} && -n ${MULTILIB_STRICT_DENY} ]]
then
rm -f "${T}/multilib-strict.log"
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-portage-dev] [PATCH] 80libraries: add support for Darwin targets
bin/install-qa-check.d/80libraries: support Darwin/Mach-O objects
Check for dylib on Darwin, so on everything else.
Signed-off-by: Fabian Groffen
diff --git a/bin/install-qa-check.d/80libraries
b/bin/install-qa-check.d/80libraries
index 8dc35bb87..a477ec9cb 100644
--- a/bin/install-qa-check.d/80libraries
+++ b/bin/install-qa-check.d/80libraries
@@ -140,7 +140,9 @@ lib_check() {
local abort="no"
local a s
for a in "${ED%/}"/usr/lib*/*.a ; do
- s=${a%.a}.so
+ [[ ${CHOST} == *-darwin* ]] \
+ && s=${a%.a}.dylib \
+ || s=${a%.a}.so
if [[ ! -e ${s} ]] ; then
s=${s%usr/*}${s##*/usr/}
if [[ -e ${s} ]] ; then
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Mon, Jul 25, 2022 at 11:11 AM Marek Szuba wrote: > > On 2022-07-25 15:35, Peter Stuge wrote: > > > Please only do that based on proven merit and nothing else. > > https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ > , https://www.password-hashing.net/ , the fact we still us the default > number of rounds (i.e. 5000) with SHA512 which is *ridiculously* weak > for modern hardware, lack of Argon2 support in libxcrypt for the time > being due to upstream having decided to wait for an official RFC. You > can probably find more yourself if you look. The fedora link in the original email details why they changed it. I don't think regurgitating the argument will add to it. By all means point out if there is a concern with their reasoning though. My initial question was whether this was some vanity hash change but the changes are intended to greatly increase the cost of cracking attacks. I'm in no position to evaluate their merit but their proposal contains various citations to people who presumably are. -- Rich
[gentoo-portage-dev] [PATCH] emake: explicitly set SHELL
bin/ebuild-helpers/emake: force SHELL to be set
On Prefix systems /bin/sh can be anything, including very ancient. So
ensure we're running with bash, since that's what Gentoo Linux is
expecting /bin/sh to be (by default, at least).
Provide a fallback for the (near impossible) case that we use a bash
that doesn't set BASH, or when we don't use bash at all. This is not
expected, though, as we explicitly require bash throughout all Portage,
so we don't really care about using a non-Prefixed one, for this really
shouldn't happen.
Signed-off-by: Fabian Groffen
diff --git a/bin/ebuild-helpers/emake b/bin/ebuild-helpers/emake
index 60718a2e4..21da85845 100755
--- a/bin/ebuild-helpers/emake
+++ b/bin/ebuild-helpers/emake
@@ -12,7 +12,7 @@
source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
cmd=(
- ${MAKE:-make} ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
+ ${MAKE:-make} SHELL="${BASH:-/bin/bash}" ${MAKEOPTS} "$@" ${EXTRA_EMAKE}
)
if [[ ${PORTAGE_QUIET} != 1 ]] ; then
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] usage of /bin/bash in shebangs
On 25-07-2022 08:09:02 -0700, Zac Medico wrote: > On 7/24/22 23:17, Fabian Groffen wrote: > > On 24-07-2022 13:58:31 -0700, Zac Medico wrote: > >> On 7/24/22 12:29, Fabian Groffen wrote: > >>> Hi, > >>> > >>> Quick question, I noticed that portage uses /bin/bash hardcoded in > >>> shebang of scripts, while it uses /usr/bin/env python for python > >>> executable files. > >>> > >>> Is there anything against using /usr/bin/env bash for shell scripts? > >>> Changing this would help for Prefix. > >> > >> > >> I can't think of any reason not to do this. > > > > Do you want to see a patch, or is it OK to push this myself? > > It's OK to just push this yourself. Thanks! Pushed, thanks, b716e3591 -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check
bin/ebuild-helpers/doins: fix D check, add EPREFIX check
ED = D/EPREFIX, so checking for ED includes EPREFIX, which when this is
absent fails to check for D. Simply check for D instead, which catches
both the case for D and ED.
Add check for usage of EPREFIX, like for using D with helpers.
Signed-off-by: Fabian Groffen
diff --git a/bin/ebuild-helpers/doins b/bin/ebuild-helpers/doins
index 24fe48121..4315a038f 100755
--- a/bin/ebuild-helpers/doins
+++ b/bin/ebuild-helpers/doins
@@ -42,7 +42,7 @@ if ! ___eapi_has_prefix_variables; then
export ED="${D}"
fi
-if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]]; then
+if [[ ${_E_INSDESTTREE_#${D}} != "${_E_INSDESTTREE_}" ]]; then
__vecho "---" 1>&2
__vecho "You should not use \${D} or \${ED} with helpers." 1>&2
__vecho " --> ${_E_INSDESTTREE_}" 1>&2
@@ -50,6 +51,16 @@ if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]];
then
__helpers_die "${helper} used with \${D} or \${ED}"
exit 1
fi
+if [[ -n ${EPREFIX} && \
+ ${_E_INSDESTTREE_#${EPREFIX}} != "${_E_INSDESTTREE_}" ]];
+then
+ __vecho "---" 1>&2
+ __vecho "You should not use \${EPREFIX} with helpers." 1>&2
+ __vecho " --> ${_E_INSDESTTREE_}" 1>&2
+ __vecho "---" 1>&2
+ __helpers_die "${helper} used with \${EPREFIX}"
+ exit 1
+fi
if ___eapi_doins_and_newins_preserve_symlinks; then
DOINS_ARGS+=( --preserve_symlinks )
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 2022-07-25 15:35, Peter Stuge wrote: Mikhail Koliada wrote: This idea has been fluctuating in my head for quite a while given that the migration had happened a while ago [0] and some other major distributions have already adopted yescrypt as their default algo by now [1]. Please only do that based on proven merit and nothing else. https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ , https://www.password-hashing.net/ , the fact we still us the default number of rounds (i.e. 5000) with SHA512 which is *ridiculously* weak for modern hardware, lack of Argon2 support in libxcrypt for the time being due to upstream having decided to wait for an official RFC. You can probably find more yourself if you look. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-portage-dev] usage of /bin/bash in shebangs
On 7/24/22 23:17, Fabian Groffen wrote: On 24-07-2022 13:58:31 -0700, Zac Medico wrote: On 7/24/22 12:29, Fabian Groffen wrote: Hi, Quick question, I noticed that portage uses /bin/bash hardcoded in shebang of scripts, while it uses /usr/bin/env python for python executable files. Is there anything against using /usr/bin/env bash for shell scripts? Changing this would help for Prefix. I can't think of any reason not to do this. Do you want to see a patch, or is it OK to push this myself? It's OK to just push this yourself. Thanks! -- Thanks, Zac OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
Mikhail Koliada wrote: > This idea has been fluctuating in my head for quite a while given > that the migration had happened a while ago [0] and some other > major distributions have already adopted yescrypt as their default algo > by now [1]. Please only do that based on proven merit and nothing else. Fedora or anyone else for that matter making a change is a truly terrible reason to take any action whatsoever, since other organizations are driven by /their/ interests - with Fedora in particular being driven by the business interests of Red Hat. I consider Gentoo a leader in many regards and it makes me really sad whenever Gentoo changes based on nothing more than "others did it". Thanks and kind regards //Peter
Re: [gentoo-dev] Up for grabs: net-misc/anydesk, net-misc/vde
On 2022/07/24 18:36, Sam James wrote: > The following packages are up for grabs b/c of inactivity: > net-misc/anydesk https://github.com/gentoo/gentoo/pull/26587 Kind Regards, Jaco
[gentoo-dev] Last-rites: kde-apps/kalarmcal
# Andreas Sturmlechner (2022-07-25) # Merged into kde-apps/kalarm since 22.04.3, no other revdeps, obsolete. # Masked for removal on 2022-08-08. kde-apps/kalarmcal signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] usage of /bin/bash in shebangs
On 24-07-2022 13:58:31 -0700, Zac Medico wrote: > On 7/24/22 12:29, Fabian Groffen wrote: > > Hi, > > > > Quick question, I noticed that portage uses /bin/bash hardcoded in > > shebang of scripts, while it uses /usr/bin/env python for python > > executable files. > > > > Is there anything against using /usr/bin/env bash for shell scripts? > > Changing this would help for Prefix. > > > I can't think of any reason not to do this. Do you want to see a patch, or is it OK to push this myself? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
