From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: oauth2 support for Emacs email clients Date: Tue, 03 Aug 2021 12:55:45 +0000 Message-ID: References: <52589.36892.953561.24840@gargle.gargle.HOWL> <871r7aubp5.fsf@ucl.ac.uk> <87lf5ircmd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36442"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 03 14:56:56 2021 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 1mAtya-0009F4-Ct for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 14:56:56 +0200 Original-Received: from localhost ([::1]:50080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAtyY-0002A9-S4 for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 08:56:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40836) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAtxW-0001Lt-5T for emacs-devel@gnu.org; Tue, 03 Aug 2021 08:55:50 -0400 Original-Received: from heytings.org ([95.142.160.155]:37882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAtxT-0005aZ-Rc for emacs-devel@gnu.org; Tue, 03 Aug 2021 08:55:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1627995345; bh=ZMOsYKjIrQFbz/7oGNeFV82a93mOZ0R55u//Of1JnBU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gsx2MnRPmtK59HrJYn3W/nXIEqN6eg9OC1vE8GcOmPDg9za6Gg5Qf0SWIXe8m9bkb g20ehsl8Tnuwg45PLRwvD/L5RdQeXUEVEieETl1GEFENIhRaCnvwAviNryLvuAJDYS ztewxoz0o6SU2StcFA7aL2K8KbRYlQNihaI36kefnjY8xmSl8gMPNmJxEx0ug5/Wsr g8dS0FYjeU/NUzJiVf0LWndtGfsHWU7KnX8LVxUAEqzpgHypll7t4+I8upMwERvnCU k9LMTP5OcWMJJbkFiBnJFOcKrsvD281NfExq0IOQPzNYoUXJ0xXtNY6CWYJY3pNnZx UryEcVOTw4baQ== In-Reply-To: <87lf5ircmd.fsf@gmail.com> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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:271970 Archived-At: > > I also wonder if the 'ban' on putting credentials into the source > (public) is that 'clear cut'. > Again, IANAL, but I at least would never take the risk to deliberately and publicly violate the terms of a contract I signed with Google or Microsoft (or, for that matter, with anyone else). > > From what I've read, the 'applicaiton key', was never supposed to be > secret - this was apparently an oversight in the initial oauth specs > It is indeed "security through obscurity". But it is (a kind of) security nonetheless. The application key is used by the provider to identify the application that requests access to the resources (in this case emails). If Mr. Black Hat copies the application key of (say) Gnus in his malware (which he obviously did not submit for approval to Google), its users will see an approval screen "Do you allow Gnus to access your emails?". If Mr. Black Hat's names its application "Gnus", its users will believe its application is a legitimate and approved one, and will click "OK". > > Of course, the chance of getting a decision from the right person at > either google or MS is next to zero, so I guess we are stuck. > Indeed. > > I guess in the end, all we can really do is try to find a way of > streamlining the process to get a developer key for each user as this > seems to be the main barrier to a more straight-forward setup. > I fear that's not possible either, each email provider has their own process to create an application key, which they adapt from time to time (at least from a user experience viewpoint). > > The good news is that once you have that key, the oauth2.el library > seems to take care of renewal of session tokens, so once setup, things > should just work. > Indeed.