From: "Łukasz Sowa" <kontakt@lukaszsowa.pl>
To: Solar Designer <solar@openwall.com>
Cc: Lukasz Sowa <kontakt@lukaszsowa.pl>, musl@lists.openwall.com
Subject: Re: crypt* files in crypt directory
Date: Sun, 22 Jul 2012 18:23:32 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.02.1207221813200.1457@localhost.localdomain> (raw)
In-Reply-To: <20120721171102.GA16724@openwall.com>
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
next prev parent reply other threads:[~2012-07-22 16:23 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 15:23 Łukasz Sowa
2012-07-21 17:11 ` Solar Designer
2012-07-21 20:17 ` Rich Felker
2012-07-22 16:23 ` Łukasz Sowa [this message]
2012-07-25 7:57 ` Rich Felker
2012-08-08 2:24 ` Rich Felker
2012-08-08 4:42 ` Solar Designer
2012-08-08 5:28 ` Rich Felker
2012-08-08 6:27 ` Solar Designer
2012-08-08 7:03 ` Daniel Cegiełka
2012-08-08 7:24 ` Solar Designer
2012-08-08 7:42 ` Daniel Cegiełka
2012-08-08 21:48 ` Rich Felker
2012-08-08 23:08 ` Isaac Dunham
2012-08-08 23:24 ` John Spencer
2012-08-09 1:03 ` Isaac Dunham
2012-08-09 3:16 ` Rich Felker
2012-08-09 3:36 ` Solar Designer
2012-08-09 7:13 ` orc
2012-08-09 7:28 ` Rich Felker
2012-08-09 7:29 ` Solar Designer
2012-08-09 10:53 ` Solar Designer
2012-08-09 11:58 ` Szabolcs Nagy
2012-08-09 16:43 ` Solar Designer
2012-08-09 17:30 ` Szabolcs Nagy
2012-08-09 18:22 ` Rich Felker
2012-08-09 23:21 ` Rich Felker
2012-08-10 17:04 ` Solar Designer
2012-08-10 18:06 ` Rich Felker
2012-08-09 21:46 ` crypt_blowfish integration, optimization Rich Felker
2012-08-09 22:21 ` Solar Designer
2012-08-09 22:32 ` Rich Felker
2012-08-10 17:18 ` Solar Designer
2012-08-10 18:08 ` Rich Felker
2012-08-10 22:52 ` Solar Designer
2012-08-08 7:52 ` crypt* files in crypt directory Szabolcs Nagy
2012-08-08 13:06 ` Rich Felker
2012-08-08 14:30 ` orc
2012-08-08 14:53 ` Szabolcs Nagy
2012-08-08 15:05 ` orc
2012-08-08 18:10 ` Rich Felker
2012-08-09 1:51 ` Solar Designer
2012-08-09 3:25 ` Rich Felker
2012-08-09 4:04 ` Solar Designer
2012-08-09 5:48 ` Rich Felker
2012-08-09 15:52 ` Solar Designer
2012-08-09 17:59 ` Rich Felker
2012-08-09 21:17 ` Rich Felker
2012-08-09 21:44 ` Solar Designer
2012-08-09 22:08 ` Rich Felker
2012-08-09 23:33 ` Rich Felker
2012-08-09 6:03 ` Rich Felker
-- strict thread matches above, loose matches on Subject: below --
2012-07-17 9:40 Daniel Cegiełka
2012-07-17 17:51 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.02.1207221813200.1457@localhost.localdomain \
--to=kontakt@lukaszsowa.pl \
--cc=musl@lists.openwall.com \
--cc=solar@openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).