Re: lisp/url/url-https.el

[Simon Josefsson]

Stefan Monnier <address@hidden> writes:

>> I am willing to work with any standards Emacs has, but there has to be
>> some way to allow a willing user to plug in encryption code easily
>> into Gnus, once that code is downloaded.  As it is, and according to
>> what you have told Lars Magne Ingebrigtsen and he has relayed to the
>> Gnus developers, not even empty wrapper functions that could be used
>> for encryption are allowed.  That makes my life much harder.
>
> My understanding is that the problems only show up for code that's meant
> specifically for encryption.
> So you should be able to provide hooks as long as they are not specifically
> for encryption.
>
> I know nothing about your specific problem so I'm probably talking
> non-sense, but why should .authinfo and Gnus be so special?
>
> Can't we write a generic "auto-decrypt-mode" which works similarly to
> auto-compress-mode (or maybe even a patch to auto-compress-mode which
> allows "compression using gpg") ?
> This package wouldn't be distributable with Emacs but it doesn't have
> anything specific to do with Gnus and can distributed separately
> (e.g. from a non-US location).
>
> Or maybe we can even make the patch to jka-compr.el generic enough (allow
> "(de)compression with a program that requires interactive user input")
> to make it acceptable for inclusion in Emacs.
>
> Wait isn't something like that already available?

There is crypt++, but when it was discussed in the context of Gnus, I
think it was decided it was not really good enough, the programmatic
elisp API insufficient, and that we could never get copyright papers
for it anyway.  I believe it was suggested to make a generic package
for this.  This same problem does indeed occur in many situations.  I
thought, but perhaps I have just been secretly wishing it, that Ted
was working on something like that.