Gnus ERT tests inside Emacs (was: client certs and CRL lists for GnuTLS)

Gnus ERT tests inside Emacs (was: client certs and CRL lists for GnuTLS)

[Ted Zlatanov]

On Mon, 09 May 2011 11:00:12 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
CY> If you have ERT tests in the Gnus repository, could you arrage for
CY> these files to be placed into (or mirrored into) the Emacs
CY> repository's test/automated directory?  Then they'll be run by
CY> "make check", and will show up in the Hydra coverage build.
>> 
>> They are embedded in the gnus/*registry.el files and I'd rather not
>> extract them into separate files.  Could that work with the Emacs ERT
>> tests?

CY> What's the rationale for not putting tests in separate files?  If it has
CY> something to do with the way Gnus is developed, I can live with that,
CY> though tests for other part of Emacs should go into test/, instead of
CY> following this example.

It's more convenient IMO.  The ERT manual didn't specify tests had to be
separate, either.  For Gnus we have my tests internalized and some other
tests external...  I hope we're not forced to use just one style if
there's no technical reason for it.

CY> As for Gnus, please add a file test/automated/gnus-tests.el, and have it
CY> (require 'gnus-registry) and any other Gnus files that contain ERT
CY> tests.  Then `make check' will be able to find those tests.

I'll do mine but am not sure if the other Gnus tests (which David
Engster wrote IIRC) will work with the Emacs ERT run.  David, WDYT?  Do
you have anything that only works inside Gnus?

Ted

Re: Gnus ERT tests inside Emacs

[David Engster]

Ted Zlatanov writes:
> On Mon, 09 May 2011 11:00:12 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 
> CY> As for Gnus, please add a file test/automated/gnus-tests.el, and have it
> CY> (require 'gnus-registry) and any other Gnus files that contain ERT
> CY> tests.  Then `make check' will be able to find those tests.
>
> I'll do mine but am not sure if the other Gnus tests (which David
> Engster wrote IIRC) will work with the Emacs ERT run.  David, WDYT?  Do
> you have anything that only works inside Gnus?

No, but the NNTP test does things the Hydra guys probably aren't too
happy with (opening connection to Gmane, creation of files in /tmp), so
I'd suggest to leave it out.

-David

Re: Gnus ERT tests inside Emacs

[Ted Zlatanov]

On Mon, 09 May 2011 17:46:06 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Ted Zlatanov writes:
>> On Mon, 09 May 2011 11:00:12 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 
CY> As for Gnus, please add a file test/automated/gnus-tests.el, and have it
CY> (require 'gnus-registry) and any other Gnus files that contain ERT
CY> tests.  Then `make check' will be able to find those tests.
>> 
>> I'll do mine but am not sure if the other Gnus tests (which David
>> Engster wrote IIRC) will work with the Emacs ERT run.  David, WDYT?  Do
>> you have anything that only works inside Gnus?

DE> No, but the NNTP test does things the Hydra guys probably aren't too
DE> happy with (opening connection to Gmane, creation of files in /tmp), so
DE> I'd suggest to leave it out.

OK, I'll just leave mine (*registry.el) in.

Ted

Re: Gnus ERT tests inside Emacs

[Ted Zlatanov]

On Mon, 09 May 2011 10:58:07 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 09 May 2011 17:46:06 +0200 David Engster <deng@randomsample.de> wrote: 
DE> Ted Zlatanov writes:
>>> On Mon, 09 May 2011 11:00:12 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 
CY> As for Gnus, please add a file test/automated/gnus-tests.el, and have it
CY> (require 'gnus-registry) and any other Gnus files that contain ERT
CY> tests.  Then `make check' will be able to find those tests.

TZ> OK, I'll just leave mine (*registry.el) in.

I think I did this correctly.  I removed a bad test in registry.el on
the Gnus side but until Katsumi Yamaoka synchronizes Gnus with Emacs,
that one test will fail.

Ted

netrc field encryption in auth-source (was: Opportunistic STARTTLS in smtpmail.el)

[Ted Zlatanov]

(xposted to the Gnus mailing list and thread subject changed, finally)

On Fri, 03 Jun 2011 23:54:18 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> We'd associate a passphrase with the file, not each piece.  It should be
>> just like using a fully encrypted file, with the same passphrase caching
>> mechanism if symmetric encryption is used.

LMI> Yeah, that was what I was thinking, too.  If you've given the GPG
LMI> password to decrypt the IMAP password, it wouldn't be necessary to
LMI> repeat that to get the NNTP password.

LMI> So there would be the same amount of GPG passwords with plain-text gpg:
LMI> tokens as with the fully-encrypted .authinfo.gpg file.  The main
LMI> functional difference is that with the plain-text file you don't have to
LMI> give the GPG password immediately to see whether you even have a token
LMI> that matches your search criteria.

On Fri, 03 Jun 2011 23:50:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I understand.  But it sucks from the `auth-source-search' perspective
>> because now every secret blob has to be decoded to find out if it has
>> tokens X or Y when the search spec requires X or Y.  So I'm against it.

LMI> True, I didn't think of that.  Then I think your idea for this makes
LMI> most sense, and please go ahead and implement it.  :-)

OK, I will implement it like so in the netrc backend:

key1 val1 key2 gpg:hexdata key3 gpg:hexdata

Where hexdata encodes "((secret "thesecret") (salt "thesalt"))"

The decoding will happen late, probably in the funcall to obtain the
secret (and it will set some scoped variables to cache the data).  That
may be a little surprising to the user but it's the most secure
approach, I think.

If a user puts gpg: tokens in a .gpg file, I'll let them.

The creation process will by default create plaintext data, but maybe I
will add a y/n prompt for "secret" and "password" tokens to save them
encrypted.  I'm not sure yet, I need to try the process.

Is there a decent cipher that's built into Emacs, as a fallback if GPG
is not installed and usable?  I don't see one.

Thanks
Ted

Re: netrc field encryption in auth-source

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Is there a decent cipher that's built into Emacs, as a fallback if GPG
> is not installed and usable?  I don't see one.

It's kinda odd that Emacs doesn't have `gpg-encode-string' built in,
isn't it?  I mean, it has sha1 and stuff.  :-)

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

GPGME (was: netrc field encryption in auth-source)

[Ted Zlatanov]

On Sun, 26 Jun 2011 12:09:42 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Is there a decent cipher that's built into Emacs, as a fallback if GPG
>> is not installed and usable?  I don't see one.

LMI> It's kinda odd that Emacs doesn't have `gpg-encode-string' built in,
LMI> isn't it?  I mean, it has sha1 and stuff.  :-)

There's `epg-encrypt-string' but it still uses the GPG program under the
covers.

I hope Daiki Ueno could consider augmenting EPA/EPG with
http://www.gnupg.org/related_software/gpgme/index.en.html, which is a
library specifically designed so we can talk to GPG directly and
securely through C.

I would love to see that happen.  I would contribute to the work in any
way I can, either in EPA/EPG or as a separate effort if Daiki Ueno is
not able or interested to do it.

Ted