Fix liferea support

81b9ee7c

to be upstream

kaiyou
Le code de Lifera me fait mal à mon petit coeur...
cyrinux
J'ai eu la nausé perso 😄
kaiyou
Genre : https://github.com/lwindolf/liferea/blob/master/src/fl_sources/google_source_feed.c#L204
Plutôt que de stocker le token dans une string, on stocke la chaîne retournée par l'API, qui contient un header, et on fait un substring à base d'arithmétique de pointeurs et de strlen
C'est des vulns qui n'attendent que d'être exploitées ça :x
Genre le serveur retourne une chaîne plus courte qu'attendu, et y'a du stack bof dans tous les coins >.>
En l'espèce là si c'est exploitable, un serveur malicieux peut leak de la mémoire client en mode read overrun
Je sais même pas si j'ai envie de report :x
Je vais passer ça à un hunter qui sera content d'une cve pas trop dure si c'est exploitable
kaiyou
(Done, y'a un stagiaire quelque part qui va jouer avec ça)
En attendant j'ai compris la 400 et son origine
J'arrive à la reproduire en tout cas.
Globalement liferea demande la liste des ids des posts du feed, puis il fait une requête pour demander le contenu pour ces ids
Et sur la deuxième il prend un : googlereader: no items returned from the database for item IDs
Et j'arrive à le reproduire en passant certains IDs
Et clairement ça ressemble au souci de base10/base16 déjà mentionné
Ce que je ne comprends pas c'est que c'est censé être fix
Quand je demande l'id 69446 je prends l'erreur {"error_message":"googlereader: no items returned from the database for item IDs: [431174]"}
Donc euh il l'a clairement parse en base16
Donc 1. dans quel univers ça marche avec d'autres clients ? 2. pourquoi un truc fix en 2022 est toujours problématique ?
Plot thinkens.
Le code Liferea est là : https://github.com/lwindolf/liferea/blob/master/src/fl_sources/google_source_feed.c#L206
Il prend le json retourné par la première requête, qui a des ints, et les passe sauvagement en chaîne dans la requête POST suivante.
Vais voir ce que fait RSSGuard

RssGuard le code est un poil plus dur à lire (C++ <3), mais globalemen les ids sont

    utilisés là en brut : https://github.com/martinrotter/rssguard/blob/master/src/librssguard-greader/src/greadernetwork.cpp#L547
    générés là : https://github.com/martinrotter/rssguard/blob/master/src/librssguard-greader/src/greadernetwork.cpp#L230

Et donc encodés en base16
J'y comprends plus rien
Et du coup, ben Miniflux attend bien du base16 : https://github.com/miniflux/v2/blob/main/internal/googlereader/handler.go#L375
La "doc" est là : https://github.com/mihaip/google-reader-api/blob/master/wiki/ItemId.wiki
Donc l'API Google Reader a deux formes d'ids, des longs et des courts. Les longs sont ont l'id en suffixe en base16 et le même id en court est juste représenté tel quel en base10.
La première API en GET doit retourner du base10 : https://github.com/mihaip/google-reader-api/blob/master/wiki/ApiStreamItemsIds.wiki
La doc de l'API en POST ne dit pas le format de l'id en input : https://github.com/mihaip/google-reader-api/blob/master/wiki/ApiStreamItemsContents.wiki
Et donc Miniflux, quand il implémente l'API GET, retourne bien du base10 : https://github.com/miniflux/v2/blob/main/internal/googlereader/handler.go#L1485
Et quand il implémente le POST il attend du base16 même si c'est des short : https://github.com/miniflux/v2/blob/main/internal/googlereader/handler.go#L1485
J'ai l'impression que l'API est pas très spécifique, Google Reader lui même est mort depuis longtemps, et l'implem qu'en fait Miniflux est... douteuse, mais bon.
Je fais reconfirmer ma compréhension du comportement de RSSGuard
kaiyou
Sinon je me suis trompé dans l'analyse de RSSGuard, j'ai maté du code spécifique à Reedah
cyrinux
T'avais dis que c'était un poil plus dur a lire rssguard x)
kaiyou
La vraie référence pour RSSGuard est là, et il envoie des long ids : https://github.com/martinrotter/rssguard/blob/master/src/librssguard-greader/src/greadernetwork.cpp#L183
Je teste avec un longId en string
Et donc finalement, le code de Miniflux est pas mal : https://github.com/miniflux/v2/blob/main/internal/googlereader/handler.go#L371
Je cherche juste à comprendre son fonctionnement, mais il semble essayer de prendre en compte des short et des long ids
Sauf qu'il me semble que la logique de Miniflux est inversée non ?
C'est comme s'il parsait en base10 quand y'a le tag Google et en base16 sinon, alors que la doc de Google dit l'inverse
Ce qui est mystérieux, c'est que si Miniflux est si fucké que ça, comment RSSGuard y arrive ?
Non ok j'ai compris.
Le code de Miniflux parse correctement les long ids. Il lit du base16 comme il faut.
Mais pour les short ids il parse du base16 alors qu'il faudrait pas.
C'est bien ce que dit cette issue effectivement : https://github.com/miniflux/v2/issues/1498
Et donc ce fix était bon : https://github.com/miniflux/v2/pull/1517/files
Mais somehow il a pas survécu.
C'est le moment de git blame :D
Hmmm : https://github.com/miniflux/v2/commit/3eb3ac06b66f2b0e7cef085831cd6aaeb8ddc9c8

Fix temporaire de cyrinux : 3aa7f2e9

Issue upstream pour faire plus pérenne : https://github.com/miniflux/v2/issues/2960

déployé sous le tag 2.2.3+tedomum.2

added Progression / En cours label