guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About Guile crypto support


From: Nala Ginrut
Subject: Re: About Guile crypto support
Date: Mon, 04 Feb 2013 12:15:40 +0800

On Mon, 2013-02-04 at 11:35 +0800, Daniel Hartwig wrote:
> 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.
> 

libgcrypt-guile is old and earlier than grcypt-guile one year. 
I need digest things and there's no guildhall, so I have to write a
buggy one. I'm glad there's a better choice for it. ;-) 

> > 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 :-)
> 

Well, I think there's a little difference to add module to core between
us. My opinion is to add very common thing to core, though sometimes
these things maybe not a very proper core API.
But anyway, considering guildhall works in the long term, these two
opinions difference are trivial. ;-)

I don't against anything about gcrypt-guile, it's fine.
But I think adding common digest APIs into core is a considerable topic.
If folks need more powerful crypto things, finding other more expert
packages in the guildhall is a better choice. But most of the time, they
just need md5/sha since doing some hash work is very common nowadays.
Users don't have to download & compile another project, or install
guildhall for that if they just need md5. They will choice a pipe for
'md5sum' instead. I do think Guile should provide convenience for such
issue. 

What do you think?

> Regards





reply via email to

[Prev in Thread] Current Thread [Next in Thread]