Re: About Guile crypto support

[Ludovic Courtès]

Daniel Hartwig <address@hidden> skribis:

> On 5 February 2013 23:48, Ludovic Courtès <address@hidden> wrote:
>>> The gcrypt-guile project is doing so, I'll help it if I can.
>>> But my original thought is orthogonal with gcrypt-guile, just put some
>>> common digest algorithm in libguile rather than a full-stack crypto-lib.
>>
>> We could actually use the Gnulib crypto modules.  There’s a
>> duplication/convenience trade-off: we’d provide useful functionality by
>> default, at the expense of duplicating C code in our tarballs (2500 SLOC
>> for Gnulib’s sha*.[ch] and md5.[ch].)
>>
>> Opinions?
>
> Avoiding duplication and feature creep /in the core/ is highly
> desirable.  Guildhall makes it convenient enough to pull in additional
> features; guile-lib has md5 and industria provides also sha and
> others.

Scheme implementations of these would be impractical in many cases (too
slow).

> A small core with addons has some obvious benefits, for the platform.
> Maintainers may disagree, though I notice that historic choices to
> include some modules (such as sxml, web) in the core were made before
> the advent of Guildhall.  I wonder where these modules would reside if
> they were introduced in the current situation …?

Some modules were deliberately moved from guile-lib to Guile to improve
integration, and to come with more standard APIs by default.

I’m not sure that having guildhall changes much in that respect.

>> I think I’d be more inclined to have good bindings in libgcrypt proper,
>
> Yes, this solution will have many benefits.  The currently available
> bindings are, well, not so great.  However, the API is small enough
> that building a proper set will not take much effort.

Yeah, apparently there are several half-baked bindings around.  Let’s
just polish one of them, and submit it for inclusion in libgcrypt.

Ludo’.