[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.02.1207221813200.1457@localhost.localdomain>
Date: Sun, 22 Jul 2012 18:23:32 +0200 (CEST)
From: Łukasz Sowa <kontakt@...aszsowa.pl>
To: Solar Designer <solar@...nwall.com>
cc: Lukasz Sowa <kontakt@...aszsowa.pl>, musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
Hi again, thanks for your reply.
On Sat, 21 Jul 2012, Solar Designer wrote:
> Hi,
>
> I suggest that you subscribe to the list, so that if someone does not CC
> you on a message yet you want to reply, you don't happen to start a new
> thread (again).
Sorry about that, I've already subscribed to the list.
>> However, there are some consts arrays used inside functions which may
>> clutter
>> stack like flags_by_subtype from BF_crypt(), test_key, test_setting,
>> test_hash
>> from _crypt_blowfish_rn(). I think that they can be pulled up to global
>> static
>> consts but we haven't done that yet. What do you think about this?
>
> I think that they are in .rodata as long as you have "const" on them,
> and thus there's no reason to move them to global scope. They don't
> clutter the stack.
Yes, that's what I thought about at first, so we didn't moved the code to global
but my fault I didn't simply checked it in generated code. Code looks nicer if
they're function's static so we should leave it as is.
>
>> +++ b/include/crypt.h
>> @@ -13,6 +13,19 @@ struct crypt_data {
>> char *crypt(const char *, const char *);
>> char *crypt_r(const char *, const char *, struct crypt_data *);
>>
>> +char *_crypt_gensalt_traditional_rn(const char *prefix, unsigned long count,
>> + const char *input, int size, char *output, int output_size);
>> +char *_crypt_gensalt_extended_rn(const char *prefix, unsigned long count,
>> + const char *input, int size, char *output, int output_size);
>> +char *_crypt_gensalt_md5_rn(const char *prefix, unsigned long count,
>> + const char *input, int size, char *output, int output_size);
>> +
>> +int _crypt_output_magic(const char *setting, char *output, int size);
>> +char *_crypt_blowfish_rn(const char *key, const char *setting,
>> + char *output, int size);
>> +char *_crypt_gensalt_blowfish_rn(const char *prefix, unsigned long count,
>> + const char *input, int size, char *output, int output_size);
>> +
>> #ifdef __cplusplus
>> }
>> #endif
>
> None of the interfaces you've added above were supposed to be exported
> by a libc. They're not in Owl's glibc, for example, although it does
> include crypt_blowfish.
>
> Instead, you need to roll crypt_blowfish support into crypt() and
> crypt_r() wrappers. You may also add similarly hash type agnostic
> crypt_rn(), crypt_ra(), crypt_gensalt(), crypt_gensalt_rn(), and
> crypt_gensalt_ra(). The crypt.3 man page included with crypt_blowfish
> documents them - perhaps it can also become the man page for musl's.
>
> See crypt_blowfish's wrapper.c and modify it for use in musl or at least
> reuse code from it.
>
I think it's up to Rich what to do with this code. We (Daniel and me) don't have
clear idea about it.
Best Regards,
Lukasz Sowa
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
