emacs-devel
[Top][All Lists]
Advanced

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

Re: libnettle/libhogweed WIP


From: Lars Ingebrigtsen
Subject: Re: libnettle/libhogweed WIP
Date: Wed, 19 Apr 2017 18:49:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> Not allow them where? Just the new stuff I'm adding? Or also
> `secure-hash' and `md5' etc? Or anything that deals with crypto (which
> could also affect EPG)?

I was thinking just the new stuff you're adding, because the ship has
sailed for the older functions.  (I'd expect the older functions to
become obsolete after a while...)

By just allowing non-multibyte text as input, you avoid stuff like

---
If CODING-SYSTEM is nil or omitted, the default depends on OBJECT.  If
OBJECT is a buffer, the default for CODING-SYSTEM is whatever coding
system would be chosen by default for writing this text into a file.

If OBJECT is a string, the most preferred coding system (see the
command ‘prefer-coding-system’) is used.

If NOERROR is non-nil, silently assume the ‘raw-text’ coding if the
guesswork fails.  Normally, an error is signaled in such case.
---

in the needlessly complicated call signature to `md5'.  I mean, we
already have these functions for handling characters separately, if the
user needs to encode text, and re-stuffing them into the signatures of
the encryption functions is just confusing, I think.

That is, I think

(md5 (encode-coding-string "Héllo" 'iso-8859-1))

is a better interface than

(md5 "Héllo" nil nil 'iso-8859-1)

> If it's just the code in my patch, let me know what I need to change in
> the way it calls extract_data_from_object() and I'll adjust the code,
> the tests, and the docs. IIUC Stefan wants the call to fail if the
> string or buffer is mulibyte and Lars agreed?

Yes, but as Eli and Stefan said, perhaps there's something to be said
for just allowing encrypting the internal representation of Emacs
objects, too.  (Which is what base64-encode-string/base64-encode-region
does.)

This is more flexible, but is this a flexibility that's useful?  I'm not
sure.  I think in the base64 case, it's led to confusion over the years.

Anyway, I may have forgotten to say this: Whee!  Encryption functions in
Emacs!  Yay!  Thanks for implementing this stuff, Ted.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

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