Re: About Guile crypto support

[Daniel Hartwig]

On 4 February 2013 11:12, Nala Ginrut <address@hidden> wrote:
>> If your goal is only to provide crypto. support to Guile programs,
>> then time is better spent providing a wrapper to the existing library.
>>  Concerns about adding an external dependency do not hold much weight
>> next to the advantages of directly using the library; “don't repeat
>> yourself”, and all that.
>>
>
> That's my aim, nowadays a language should provide md5/sha1 at least
> since they are very common.
>
>> Perhaps you are aware that there an extension for gcrypt under
>> development, with modules for the hash and randomize functions:
>> <https://gitorious.org/gcrypt-guile/>.
>>
>
> I have a similar project too:
> https://gitorious.org/nacre/libgcrypt-guile
>

The other project is much further along, providing direct bindings to
gcrypt and has a convenience form (quick-hash ALGORITHM DATA).
Suggest to continue working there rather than duplicating efforting.

Taking a quick look at your code, there are some problems that
immediately stand out.  The calls to gcry_control should not be in
mda, being repeated on every call; libgcrypt documents even specify
that language bindings should not handle init, which is a task for the
application.

> Write a lib-wrapper is another story, guys who needs more specific
> feature(efficiency/security) could use these packages from guildhall.
> But my opinion is to provide the common digest API in ice-9, many guys
> asked such a questions, and I suggested them use my libgcrypt-guile, but
> I can't answer why Guile doesn't has these common API. So I decide to
> add them.
>
> What do you think?

Personally I would work with the existing gcrypt-guile project.  It is
LGPL and anyone who needs such functionality can easily import it.  As
mentioned above, it already provides the quick-hash form which I
believe is what you are looking for.

I also don't any pressing need to move this in to the core Guile
distribution when it is freely available as an addon.  But I see that
we disagreed on this same point with your colorized module as well :-)

Regards