From: "Philip K." <philipk@posteo.net>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 40354@debbugs.gnu.org
Subject: bug#40354: [PATCH] Fix Libravatar federation handling
Date: Tue, 18 Aug 2020 20:53:37 +0200 [thread overview]
Message-ID: <87y2mb3hvy.fsf@posteo.net> (raw)
In-Reply-To: <87o8n8j9g7.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 18 Aug 2020 16:49:12 +0200)
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Philip K <philip@warpmail.net> writes:
>>
>>> Previous implementation didn't correctly handle the result of
>>> dns-query, and didn't implement the necessary record selection
>>> algorithm as specified on the wiki (https://wiki.libravatar.org/api/,
>>> "Federated servers").
>>>
>>> * lisp/image/gravatar.el (gravatar--service-libravatar): Fix
>>> libravatar image host resolver algorithm.
>>
>> Looks good to me, although this didn't apply either, since the code has
>> been rewritten to be asynchronous. Could you re-spin this patch, too,
>> and I'll get it applied...
>
> Philip, have you had time to look at this?
The patch below should implement the fixes from bug#40354. I found a
libravatar user here[0], and could test it by evaluating
(gravatar--service-libravatar "who@zerokspot.com" #'message)
or
(gravatar--service-libravatar "who@gnu.org" #'message)
as an example for a domain that doesn't use libravatar. Both work as
expected, and don't lag.
[0]: https://zerokspot.com/weblog/2020/05/26/avatars-without-gravatar/
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-Libravatar-federation-handling.patch --]
[-- Type: text/x-patch, Size: 4427 bytes --]
From 9b345b965cce8f79aa31b6a8989ff466c84b6798 Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Tue, 18 Aug 2020 20:50:07 +0200
Subject: [PATCH] Fix Libravatar federation handling
Previous implementation didn't correctly handle the result of
dns-query, and didn't implement the necessary record selection
algorithm as specified on the wiki (https://wiki.libravatar.org/api/,
"Federated servers").
* lisp/image/gravatar.el (gravatar--service-libravatar): Implement
correct algorithm
---
lisp/image/gravatar.el | 49 ++++++++++++++++++++++++++++++++++++------
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/lisp/image/gravatar.el b/lisp/image/gravatar.el
index e917033562..cca737656c 100644
--- a/lisp/image/gravatar.el
+++ b/lisp/image/gravatar.el
@@ -158,18 +158,53 @@ gravatar--service-libravatar
(setq func
(lambda (result)
(cond
- (result
- (funcall callback (format "%s://%s/avatar"
- (cdar records) result)))
- ((> (length records) 1)
- (pop records)
+ ((and result ;there is a result
+ (let* ((data (mapcar (lambda (record)
+ (dns-get 'data (cdr record)))
+ (dns-get 'answers result)))
+ (priorities (mapcar (lambda (r) (dns-get 'priority r))
+ data))
+ (max-priority (if priorities
+ (apply #'max priorities)
+ 0))
+ (sum 0) top)
+ ;; Attempt to find all records with the same maximal
+ ;; priority, and calculate the sum of their weights.
+ (dolist (ent data)
+ (when (= max-priority (dns-get 'priority ent))
+ (setq sum (+ sum (dns-get 'weight ent)))
+ (push ent top)))
+ ;; In case there is more than one maximal priority
+ ;; record, choose one at random, while taking the
+ ;; individual record weights into consideration.
+ (catch 'done
+ (dolist (ent top)
+ (when (and (or (= 0 sum)
+ (<= 0 (random sum) (dns-get 'weight ent)))
+ ;; Ensure that port and domain data are
+ ;; valid. In case non of the results
+ ;; were valid, `catch' will evaluate to
+ ;; nil, and the next cond clause will be
+ ;; tested.
+ (<= 1 (dns-get 'port ent) 65535)
+ (string-match-p "\\`[-.0-9A-Za-z]+\\'"
+ (dns-get 'target ent)))
+ (funcall callback
+ (url-normalize-url (format "%s://%s:%s/avatar"
+ (cdar records)
+ (dns-get 'target ent)
+ (dns-get 'port ent))))
+ (throw 'done t))
+ (setq sum (- sum (dns-get 'weight ent))))))))
+ ((setq records (cdr records)) ;in case there are at least two methods
(dns-query-asynchronous
(concat (caar records) "._tcp." domain)
func 'SRV))
- (t
+ (t ;fallback
(funcall callback "https://seccdn.libravatar.org/avatar")))))
(dns-query-asynchronous
- (concat (caar records) "._tcp." domain) func 'SRV)))))
+ (concat (caar records) "._tcp." domain)
+ func 'SRV t)))))
(defun gravatar-hash (mail-address)
"Return the Gravatar hash for MAIL-ADDRESS."
--
2.26.2
next prev parent reply other threads:[~2020-08-18 18:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 18:03 bug#40354: [PATCH] Fix Libravatar federation handling Philip K
2020-07-01 14:55 ` Philip K.
2020-08-08 13:10 ` Lars Ingebrigtsen
2020-08-18 14:49 ` Lars Ingebrigtsen
2020-08-18 14:57 ` Philip K.
2020-08-18 18:53 ` Philip K. [this message]
2020-08-18 19:20 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2mb3hvy.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=40354@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).