[PATCH 4/4] New configure option --disable-crypt.

[Florian Weimer]

On 06/21/2018 11:31 AM, Florian Weimer wrote:
> On 06/21/2018 12:47 AM, Zack Weinberg wrote:
>> On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com> 
>> wrote:
>>> On 05/22/2018 12:34 AM, Joseph Myers wrote:
>>>> On Mon, 21 May 2018, Zack Weinberg wrote:
>>>>> No, this is an intentional deviation from the present state of POSIX,
>>>>> anticipating the removal of those functions from the standard.
>>>>
>>>> That would only seem relevant to the _XOPEN_CRYPT value in future POSIX
>>>> modes, not current ones.
>>>
>>> So we should stop defining _XOPEN_CRYPT, but continue to declare 
>>> crypt in
>>> <unistd.h> for __USE_MISC || __USE_XOPEN?  That would work for me.
>>
>> Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT
>> in any mode.  Yes, this is an intentional deviation from POSIX, but I
>> think it is far less likely to break existing programs than the
>> alternative.
> 
> How can we resolve this conflict?
> 
> We have mostly cleaned up Fedora 28 to build with !_XOPEN_CRYPT already. 
>  Â There weren't many changes AFAICS, and they fall broadly into two 
> categories:
> 
> (1) Not including <crypt.h> for the crypt function, only <unistd.h>.
> (2) Using DES functions.
> 
> (1) was far more common than (2).
> 
> We'll keep the declaration of crypt in <unistd.h> for _DEFAULT_SOURCE, 
> so (1) will not be a problem.  (2) will not be addressed independently 
> of the definition of _XOPEN_CRYPT.
> 
> This is why I'm fine with Joseph's approach.  It may even make it 
> marginally easier to check whether you need your own DES implementation.
> 
> I would like to see a decision soon because I'm wondering if I have to 
> back out the libxcrypt switch.

In Fedora, of course.  Sorry for being unclear.

Florian