From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jarno Malmari Newsgroups: gmane.emacs.devel Subject: Patches for qop=auth implementation for url-digest-auth Date: Mon, 11 May 2015 22:17:20 +0300 Message-ID: <1431371843-4502-1-git-send-email-jarno@malmari.fi> References: NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1431371884 30484 80.91.229.3 (11 May 2015 19:18:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 19:18:04 +0000 (UTC) Cc: larsi@gnus.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 11 21:17:53 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YrtD6-000242-A9 for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 21:17:52 +0200 Original-Received: from localhost ([::1]:39325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtD5-0000Hv-Gj for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 15:17:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtD2-0000Hm-IO for emacs-devel@gnu.org; Mon, 11 May 2015 15:17:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrtCz-0003wh-7A for emacs-devel@gnu.org; Mon, 11 May 2015 15:17:48 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:57185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrtCy-0003wC-Sb for emacs-devel@gnu.org; Mon, 11 May 2015 15:17:45 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 20BF1205F5 for ; Mon, 11 May 2015 15:17:37 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 11 May 2015 15:17:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=malmari.fi; h=cc :date:from:in-reply-to:message-id:references:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=OLxrMms7gT4Gnjpivbc9zxzhyn4 =; b=KhPdqbrWg0zHo8K8TQL7xjRNsIi5/6q6fw1bldvxwokn8rX6u0yOn9lhg5c LFv2RpBSgwz3xR+IojqVl0B30nXm2euGOZ2IMovEqW/4Iz+3p8gY/BIxj4LutGA9 6xuolhbVtU59srM9h/6wm31e4lr0EMiecxQUsd0xap9RY7vM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:date:from:in-reply-to:message-id :references:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OLxr Mms7gT4Gnjpivbc9zxzhyn4=; b=giHrcvjNm3VTpCRAv5zDtHJ8OnS67QTTX6bz c7RAuAsbtf+nwN0j4K/ZKGAr5thQB/hqbB+h19ywdC4Ci5vWD1wYH4lQYd/TeSPy 6TPcVzFgJbJK0u2Oa4vzs5SpzMZZZDWjRiu6ucqIktgDUFCsq1p75caRIv/GPYIF 1ENA94o= X-Sasl-enc: 8EvKFCgJEpeMRPC7/BNdWpO8XM7mJYulg+lH0KR1JIRy 1431371856 Original-Received: from vabi.router067d59.com (unknown [91.155.178.71]) by mail.messagingengine.com (Postfix) with ESMTPA id 75E466800F3; Mon, 11 May 2015 15:17:36 -0400 (EDT) X-Mailer: git-send-email 2.1.0.GIT In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186429 Archived-At: I am not sure how common it is to have no backward compatibility for qop-less clients, as that is, afaik, against the standard RFC 2617. My use case and motivation for testing this is based on Gerrit servers that gave Forbidden with the old qop-less implementation, and with these patches, I can authenticate successfully. There are three patches. First, tests were created to have some stable playground to do refactoring on url-digest-auth. As new functions were added, more tests were added. Finally, implement qop=auth (with limitations, as described in the commit message). The potential risk of applying the third patch (the actual qop implementation) is that once the 'url' client reports that it supports qop, it should do it properly. If not, some servers that previously cooperated may stop to do so. Those are the servers where the backward compatibility is working ok, i.e. they are fine with clients not reporting back the "qop" field in Authorization header.