From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74089 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: auth-source tokens Date: Sun, 14 Nov 2010 18:59:11 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87tyjjpfkw.fsf@lifelogs.com> References: <87d3qylr29.fsf@marauder.physik.uni-ulm.de> <87fwvu5ele.fsf_-_@lifelogs.com> <87wrp4yjtk.fsf@lifelogs.com> <87eiarj0eu.fsf@lifelogs.com> <87pqu795st.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289782866 23343 80.91.229.12 (15 Nov 2010 01:01:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 01:01:06 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M22457@lists.math.uh.edu Mon Nov 15 02:01:03 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PHnRO-0003Bd-QK for ding-account@gmane.org; Mon, 15 Nov 2010 02:01:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PHnQ1-0008SJ-G3; Sun, 14 Nov 2010 18:59:37 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PHnPy-0008S4-Lw for ding@lists.math.uh.edu; Sun, 14 Nov 2010 18:59:34 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PHnPn-0004OH-Kn for ding@lists.math.uh.edu; Sun, 14 Nov 2010 18:59:34 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PHnPm-0004QM-00 for ; Mon, 15 Nov 2010 01:59:22 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PHnPm-0002V9-Ov for ding@gnus.org; Mon, 15 Nov 2010 01:59:22 +0100 Original-Received: from c-24-14-16-248.hsd1.il.comcast.net ([24.14.16.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 01:59:22 +0100 Original-Received: from tzz by c-24-14-16-248.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 01:59:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-24-14-16-248.hsd1.il.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:fcFXAZW61Rpm7wrfSpu0uUmSdSg= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74089 Archived-At: On Sun, 14 Nov 2010 18:24:50 +0100 Michael Albinus wrote: MA> Ted Zlatanov writes: >> On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus wrote: >> >>>> A string value is matched as a regex for the >>>> file (netrc) backend and literally by the Secrets API. A symbol >>>> is matched as its string value. All the SPEC values can be >>>> single values or lists. >> MA> Hmm, maybe we shall extend secrets.el to support also regexp search? >> >> It would be nice to make the interface consistent. MA> OK. I'll check next days whether secrets.el can be extended this MA> way. The Secrets API doesn't support it, it checks the attribute values MA> "... via case-sensitive string equality". That means all token must be MA> retrieved using only attribute matches which are *not* a regex. From the MA> resulting tokens those must be removed, whose attributes with regex do MA> not match. Hrrrrm. I guess we can pass "" and then examine the results directly. But it sucks. OTOH I don't see a need for substring or regex searching for secrets anyhow, now that I think about it. Is it really necessary? MA> I still have a comment: ... MA> How do you handle attributes which have a regex as value in SPEC? They MA> shouldn't be created with that value. Good catch. I was thinking of them in Perl terms, where a regex is a distinct kind of object and forgot ELisp doesn't have that luxury. So either we go with the plan above to allow only exact matching or we create a special kind of object that can be passed to the search function to indicate a regex search (and said object can carry the creation value). My vote is to do exact matching only. It will produce simpler code and will be easier to understand in the manual. If it's going to be used all over Emacs, it should be so. Ted