From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76423 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.gnus.general Subject: Re: tzz-auth-source-rewrite branch Date: Sun, 06 Feb 2011 21:36:32 +0100 Message-ID: <87r5bkc33j.fsf@gmx.de> References: <87ei7nivte.fsf@lifelogs.com> <87zkq9tdi7.fsf_-_@lifelogs.com> <87bp2p3t56.fsf@gmx.de> <87lj1tt0u4.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297024667 8936 80.91.229.12 (6 Feb 2011 20:37:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2011 20:37:47 +0000 (UTC) Cc: ding@gnus.org To: Ted Zlatanov Original-X-From: ding-owner+M24771@lists.math.uh.edu Sun Feb 06 21:37:37 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 1PmBMU-0000tH-Rm for ding-account@gmane.org; Sun, 06 Feb 2011 21:37:35 +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 1PmBLg-000081-SP; Sun, 06 Feb 2011 14:36:44 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PmBLf-00007r-IK for ding@lists.math.uh.edu; Sun, 06 Feb 2011 14:36:43 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PmBLd-0006DB-Kh for ding@lists.math.uh.edu; Sun, 06 Feb 2011 14:36:43 -0600 Original-Received: from mailout-de.gmx.net ([213.165.64.23]) by quimby.gnus.org with smtp (Exim 4.72) (envelope-from ) id 1PmBLc-0000X7-RF for ding@gnus.org; Sun, 06 Feb 2011 21:36:40 +0100 Original-Received: (qmail invoked by alias); 06 Feb 2011 20:36:33 -0000 Original-Received: from p57BBD44E.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.212.78] by mail.gmx.net (mp055) with SMTP; 06 Feb 2011 21:36:33 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18UUoEjJBsU7kNPkvdqoauh6n0Sc8VaguabfZGMRU FpBO4SwJmjZFde In-Reply-To: <87lj1tt0u4.fsf@lifelogs.com> (Ted Zlatanov's message of "Sun, 06 Feb 2011 13:33:23 -0600") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76423 Archived-At: Ted Zlatanov writes: > 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. Yes. I'll grab whether we could do it better. > Am I correct in assuming that substring/regex searches on the attributes > are not possible? Yes. The Secret Service API claims: "During a lookup, attribute names and values are matched via case-sensitive string equality." > 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. No problem. Mid-term, we could improve the returned function to check/add caches as well. > 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? Once I've heard that Firefox will use it as well. I haven't seen it. I know that it is used by Nautilus, UbuntuOne, Desktop Couch, Deja Dup backup, some IRC clients, ... Open your seahorse client, and have a look on it. > Ted > > p.s. Sorry about the multiple merge and commit messages on this branch. No problem. That's why we have git :-) Best regards, Michael.