From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76422 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: tzz-auth-source-rewrite branch Date: Sun, 06 Feb 2011 13:33:23 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87lj1tt0u4.fsf@lifelogs.com> References: <87ei7nivte.fsf@lifelogs.com> <87zkq9tdi7.fsf_-_@lifelogs.com> <87bp2p3t56.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297020831 22835 80.91.229.12 (6 Feb 2011 19:33:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2011 19:33:51 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M24770@lists.math.uh.edu Sun Feb 06 20:33:44 2011 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 1PmAMi-00031t-1u for ding-account@gmane.org; Sun, 06 Feb 2011 20:33:44 +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 1PmAMe-0008Iy-JG; Sun, 06 Feb 2011 13:33:40 -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 1PmAMd-0008Ic-4y for ding@lists.math.uh.edu; Sun, 06 Feb 2011 13:33:39 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PmAMb-0004z9-MG for ding@lists.math.uh.edu; Sun, 06 Feb 2011 13:33:39 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PmAMa-000844-V2 for ding@gnus.org; Sun, 06 Feb 2011 20:33:36 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PmAMa-0002zY-HW for ding@gnus.org; Sun, 06 Feb 2011 20:33:36 +0100 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Feb 2011 20:33:36 +0100 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Feb 2011 20:33:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.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:2dwdl9KkdHPsSBMLGA0CsMlqnMw= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76422 Archived-At: On Sun, 06 Feb 2011 19:38:45 +0100 Michael Albinus wrote: MA> Ted Zlatanov writes: >> I added Secrets API support (search only, no create or delete) and >> `auth-source-user-or-password' compatibility, plus I rebased the >> branch. I think the Secrets API should use the :max parameter if >> possible so we don't get too many results at the top level. Also it >> seems quite slow to get the results one by one so maybe we can optimize >> `secrets-search-items'. MA> `secrets-search-items' returns already a list of results. It is slow to MA> get all attributes and secret strings of the items sequentially; MA> unfortunately there is no D-Bus method to get them in a bunch (for MA> several items at once). I'll leave it that way for now because it will be cached, but that seems like a painful limitation long-term. Am I correct in assuming that substring/regex searches on the attributes are not possible? MA> I've changed `auth-source-secrets-search' such a way that it does not call MA> `secrets-get-secret', this call is moved to the returned function. This MA> should reduce the number of D-Bus calls in MA> `auth-source-secrets-search'. Yes, but now every time the user wants the secret they will get a surprise call and caching won't work. So I would prefer to call `secrets-get-secret' early. I left that bit out of the patch, I hope you don't mind. >> Finally, Google Chrome stores passwords in there but with a different >> scheme. I wonder if it's useful to add specific support for mapping >> those to the auth-source tokens (host, protocol, user) or if I should >> put that special code in url.el only. MA> This is a disadvantage of the Secret Service API (IMO): it defines MA> access methods for the storage, but it does not define default MA> keys/attributes. Every application is free to use its own MA> attributes. For reuse of existing, we must either do some assumptions, MA> or we must inspect which attributes are already used, and apply them. I think we should support the Google Chrome schema, at least: username_value => user origin_url => protocol (using the protocol piece of the URL) and host (using the host piece) Those values won't work for creation (meaning we won't be able to create valid Chrome entries without user assistance), but at least there's a good chance that the user can reuse their Chrome passwords. Is that reasonable? Do you know of any other software that has its own schema like Chrome does? Ted p.s. Sorry about the multiple merge and commit messages on this branch.