From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Mon, 17 Aug 2020 14:03:52 +0100 Message-ID: References: <875z9p5hnc.fsf@mat.ucm.es> <87364pbkn0.fsf@gnus.org> <87lfihe0zf.fsf@mat.ucm.es> <874kp55l8t.fsf@gnus.org> <36ed8579.3c38.173fb016f00.Coremail.m_pupil@163.com> <20200817082315.GB13459@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22084"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 17 15:04:40 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k7eoa-0005cO-9e for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 15:04:40 +0200 Original-Received: from localhost ([::1]:52568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7eoZ-00051Q-Bo for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 09:04:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46760) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7enu-0004Yc-Oo for emacs-devel@gnu.org; Mon, 17 Aug 2020 09:03:58 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:45830) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7ent-00031y-0I for emacs-devel@gnu.org; Mon, 17 Aug 2020 09:03:58 -0400 Original-Received: from [192.168.1.103] (87-198-55-78.ptr.magnet.ie [87.198.55.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA 4" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id D16463C069 for ; Mon, 17 Aug 2020 13:03:53 +0000 (UTC) In-Reply-To: <20200817082315.GB13459@tuxteam.de> Content-Language: en-US Received-SPF: pass client-ip=65.99.215.13; envelope-from=david@harpegolden.net; helo=harpegolden.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/17 09:03:54 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253877 Archived-At: On 17/08/2020 09:23, tomas@tuxteam.de wrote: > On Mon, Aug 17, 2020 at 02:00:41PM +0800, 范凯 wrote: >> Is it possiable to just use the application specific password? > > This is Gregory's option (2), right? > No, "app specific passwords" are a separate end-user facility google in particular currently offers (other providers certainly may not allow anything similar), where the end-user can generate secondary passwords distinct from their main one, for use with non-oauth2-supporting apps that use traditional username+password auth methods. Using their "app specific passwords" facility requires enabling the "2 step verification" facility with its own issues*, and then disables the ability to use the general "less secure apps" (google terminology) facility that allows traditional username/user-main-password auth. App specific passwords are relatively complex and manual for the end-user to manage, and google may withdraw the facility one day too (well that surely applies to anything google does anyway). Personally I have no idea from the various recent announcements around "less secure apps" how long they will continue to allow such "app specific passwords" in the sense of such username/app-specific-password plain auth (at the protocol level, not any out of band 2-step shenanigans) even after disallowing overall "less secure apps" (google terminology) in the sense of username/user-main-password plain auth. I expect they would continue ...in the short term... to avoid completely locking out users of old mobile devices if nothing else. Even so, once their usage stats drop below some level, they may move to phase them out - they're clearly annoying, error-prone and complex for users to manage compared to fully-implemented oauth2 flow (user-exposed complexity of manual token fetches and stuff is not normal even if emacs users are currently doing it) (* perhaps not because it's bad in principle, simple password auth has its known issues, but because google initially requires and encourages a notoriously weak phone-sms method by default (subject to recent and high-profile attacks by "sim swap" social engineering and the like at other providers). Though you can configure e.g. totp instead afterward [1]) [1] https://support.google.com/accounts/thread/5185475?hl=en