RSS Guard - novinky ve verzi 2.5.0

18.7.2015 19:01 | Linux |

Tak jsem relativně rychle vydal verzi 2.5.0 RSS čtečky RSS Guard. Změn není ani málo ani moc. Pojďme na to:

• Cache ikon načítaných programem se nyní po načtení většiny ikon vyprázdní, což ušetří nějakou paměť, řádově asi 1 MB.
• Adblock nyní přechroustá i sadu pravidel, která chybně začíná " [Adblock...." (mezera navíc).
• Aplikace nyní umožňuje zobrazit i jen kanály s nepřečtenými zprávami.
• Hesla ke kanálům/proxy jsou v DB zahashována.
• Přidány moderní notifikační bubliny, které zobrazují například nové aktualizace či průběh aktualizace kanálů.
• Přidána možnost změnit font pro interního prohlížeče zpráv.
• Aktualizován používaný Qt runtime (pouze Windows) na 4.8.7/5.5.0.

Uf, to bude asi vše. Hlavní novinkou pro 2.5.1 budou vstupní filtry pro kanály.        

Komentáře

[xkucf03]

Hesla ke kanálům/proxy jsou v DB zahashována.

Jak pak aplikace heslo „odhashuje“, aby ho použila pro přihlášení ke kanálu/proxy?

[skunkOS]

No, on klíč použitej pro zahashování je přímo ve zdrojáku. Hashuje se jen a jen pro to, aby ten, kdo dostane do ruky tu DB, neviděl plain-text hesla. Když zjistí, od čeho DB je a najde si algoritmus hashování ve zdrojákách a klíč, tak se k heslům samozřejmě dostane. Nic sofistikovanějšího aktuálně přidávat nejspíš nebudu.

[xkucf03]

Tak je to ale spíš šifrování, ne? Protože hashování je jednosměrné

[Heron]

Navíc šífrování s otevřeným klíčem, takže možná spíš kódování

[xkucf03]

Tak někdy to smysl má – pokud jsou šifrovaná data a klíč uloženy na různých místech a je nenulová pravděpodobnost, že někdo ukradne jedno a druhé ne (třeba logy nebo záloha databáze). Samozřejmě by útočník neměl dostat do ruky ani jedno, ale kdyby se to náhodou stalo, tak to snižuje dopad.

U desktopové aplikace by to mohlo fungovat tak, že se při instalaci vygeneruje (po-instalační skript balíčku) klíč pro daný stroj a uloží někam do /var/…. A kdyby pak někdo náhodně vyluxoval uživatelův domovský adresář nebo se dostal k zálohám, tak to nedešifruje. Ale zase uživatel musí vědět, že si při přeinstalaci systému musí zazálohovat ten klíč z /var/… nebo si hesla zadá znova.

Lepší by asi bylo použít klíčenku daného prostředí (KWallet, gnome-keyring), kde uživatel zadá heslo jednou po přihlášení.

[Heron]

V tomto případě (pokud jsem to v těch 36°C pochopil správně), je heslo ve zdrojáku, tedy pro každou instanci stejné. Útočníkovi tedy stačí získat onu db, zdroják si stáhne z gitu a data jsou pro něj otevřená. V tomto případě je to tedy ono klasické: "nechci tam vidět svoje heslo a je mi jedno jak se toho docílilo".

Kdyby se šifrovací klíč vygeneroval při prvním spuštění a uložil někam jinam (což ale v případě obyčejného uživatelského účtu moc nejde), nechal bych se ukecat (no, nenechal), že to nějaký smysl má.

[skunkOS]

To vlastně není špatný nápad. Dost možná to v 2.5.1 upravím, aby se ten klíč, kterým se to kóduje, generoval při prvním použití, pokud již neexistuje a ukládal do FS, tedy aby nebyl přímo ve zdrojáku, což sice je ztížení situace pro zákeřňáka, ale nic moc.

Taky se musí brát v potaz, že ta aplikace není jen pro Linux, na oknech a mekách gnome-keyring (či co) není, případně to minimálně na mekách nemám jak testnout.

[xkucf03]

Udělal bych tam nějakou abstrakci a moduly pro jednotlivé klíčenky – program by detekoval, co je k dispozici a dal uživateli vybrat + by tam byl modul, který by hesla ukládal normálně konfigurace programu.

[Josef Kufner]

Tak, tak. Buď použít systémovou klíčenku, nebo se na to vybodnout a nechat je prostě v plaintextu (a varovat uživatele, ať si na ten soubor dá pozor). Třetí možnost je implementovat vlastní šifrování toho souboru jedním master heslem (např. na to zavolat gnupg), ale to mi přijde jako ztráta času.

[skunkOS]

Tohle ještě domyslím do 2.5.1.

[Odin1918]

#define DUMMY_DUMMY_DUMMY 0xaec852f1

Neni nad vystizna pojmenovani.

[Odin1918]

Zdroj

[Odin1918]

Neberte to prosim tak, ze se nejak vysmivam. Vas program se mi libi. Jen mne pobavil nazev onoho makra.

[skunkOS]

Mě taky. :) Proto jsem ho tak pojmenoval.

[Dirka]

jako super, jen tak dal ... ale kdyzs zrusil (planovanou) podporu tt-rss, z myho pohledu rss je neco co chcu sbirat porad, ne jen kdyz jede klient (desktop) ... teda planujes nakej non-gui lehkej sync master, kterej muzu nasadit na server bez x a pak se k nemu z desktopu pripojit? bez toho ztraci desktop klient pro me smysl. dik

[PanZvedavy]

ale nech ho prosimte, vzdyt ten program dela hlavne pro sebe jak rikal a on tt nepotrebuje.

[skunkOS]

Došel jsem k závěru, že pro sebe to skutečně zatím nepotřebuju, používám ten MySQL backend. Časově easy by bylo přidat i PostgreSQL backend, ale o ten asi nestojíte. :)

[Dirka]

Vsak v poho, chapu, ze kdyz to nechces pro sebe, tak to delat nebudes, jen to ber jako podnet, co by mohlo tvuj projekt trochu odzvlastnit od davu. Jestli je backend v pg nebo mysql je imo na neco takto trivialniho celkem jedno (kor kdyz to jede na desktopu, kde je vykonu dostatek).

[skunkOS]

No tak jsou lidi, co maj RSS Guard na více počítačích (dokonce i v jiných městech/státech) a chtějí mít jen jedny data, proto MySQL. Vzhledem k tomu, že TT-RSS je v podstatě to samé, tak uvidíme. Kvůli TT-RSS bych musel určitou relativně malou část aplikace lehce upravit, a to nejspíš způsobem, který když by měl vést k elegantnímu a dobře strukturovanému kódu, by nejspíš vedl k poklesu výkonu (jde zejména o označování zpráv/kanálů jako přečtených a podobné operace).

Jak je to TT-RSS rychlé? Dejme tomu, že bych měl TT-RSS na localhostu a v něm 500 kanálů. Při spuštění RSS Guardu by se prováděl sync-in seznamu těch kanálů. Dál vidím, že API poskytuje metodu getArticle, která bere seznam IDček těch zpráv, které se mají fetchnout, může někdo ověřit, jak rychlé by bylo volání tédle metody řekněme se seznamem 300 IDček? Dále by mě také zajímalo, jak velká je režie TT-RSS v metodě updateFeed. Píšou, že "This operation is not performed in the background, so it might take considerable time and, potentially, be aborted by the HTTP server.". Takže ta metoda dělá ještě něco navíc kromě stažení nových zpráv těch kanálů do svého uložiště?

Aktuálně mám pro 2.5.1 vybrané ty D-Bus notifikace a vstupní filtry, ale vidím, že po tom TT-RSS jdou lidi jako po uzeným.

[Dirka]

Zkusim naky tyhle veci otestovat a hodim sem vysledky ...

Jinak presne tohle je muj scenar, mam ctecku na vic lokacich a chcu mit jen jedny data ... z myho pohledu to nemusi byt nutne pres tt-rss, ale klidne udelej vlastni server modul (bez zavislosti na X), ke kterymu se proste z klienta pripojim. Na druhou stranu bude asi tt univerzalnejsi, ponevadz ma i mobilni klienty etc (byt toto me osobne nezajima).

[skunkOS]

Pak přece není problém alespoň zkusit MySQL backend, což. Ale zkus sem mrsknout nějaky ty TT-RSS výsledky, uvidíme.

[Dirka]

Muzes to rozvest? Dovoluje ten sql backend bezet na servru bez X? De me o to jestli se chapeme, desktop nebezi porad, rss feedy chcu agregovat permanentne a selektivne k tomu co jsem nasbiral pristupuju z ruznych pocitacu v ruznou dobu (tuto agregaci momentalne resi tt a pristup pak prohlizec).

[skunkOS]

To nedovoluje, ale dovoluje držet data na jednom místě.

[xkucf03]

A nešla by část programu vyčlenit do knihovny, která by se pak dala použít v démonu běžícím na serveru bez X?

[skunkOS]

No, zcela jistě šla. Vidím to tak, že nějaká optimalizace v tomdle směru a TT-RSS budou asi hlavními body dalšího vývoje... Uvidíme. Provedu žádnou revizi kódu a trošku to zabstrahuju, aby tam to TT-RSS šlo pěkně napasovat.

[Josef Kufner]

Já používám rss2email. Čtečka běží na serveru a posílá mi novinky e-mailem. Filtr ve schránce to zařadí do vyhrazené složky a já si to mohu přes IMAP přečíst na čemkoliv.

[Dirka]

je to z lokalu vuci wedos VPS, fetch 1000 clanku:

time curl -k -d '{"sid":"ID","op":"getArticle","article_id":"TISIC_CLANKU"}' https://mojettrss/api/; echo ""

real	0m4.143s
user	0m0.083s
sys	0m0.026s

pro eliminaci bufferu termu zapis do souboru

time curl -k -d '{"sid":"ID","op":"getArticle","article_id":"TISIC_CLANKU"}' https://mojettrss/api/ > soubor.rss

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 2082k    0 2076k  100  6063  1636k   4778  0:00:01  0:00:01 --:--:-- 1668k

real	0m1.279s
user	0m0.081s
sys	0m0.024s

takze ~1sec ...

[Dirka]

A k tomu updatefeed, predpokladam, ze to pouziva i interne, tady casy za dnesek updatu

[00:33:21/11873] Processed 120 feeds in 139.1050 (sec), 1.1592 (sec/feed avg)
[01:03:02/14667] Processed 120 feeds in 120.3881 (sec), 1.0032 (sec/feed avg)
[01:33:31/18054] Processed 120 feeds in 149.6807 (sec), 1.2473 (sec/feed avg)
[02:03:56/20939] Processed 120 feeds in 175.3368 (sec), 1.4611 (sec/feed avg)
[02:32:47/27373] Processed 120 feeds in 95.7112 (sec), 0.7976 (sec/feed avg)
[03:02:31/5830] Processed 120 feeds in 87.1405 (sec), 0.7262 (sec/feed avg)
[03:32:29/9303] Processed 120 feeds in 87.2269 (sec), 0.7269 (sec/feed avg)
[04:02:31/12095] Processed 120 feeds in 89.8186 (sec), 0.7485 (sec/feed avg)
[04:33:11/15279] Processed 120 feeds in 129.6962 (sec), 1.0808 (sec/feed avg)
[05:02:54/20333] Processed 120 feeds in 111.9520 (sec), 0.9329 (sec/feed avg)
[05:32:18/23544] Processed 120 feeds in 77.0656 (sec), 0.6422 (sec/feed avg)
[06:03:11/26334] Processed 120 feeds in 130.7213 (sec), 1.0893 (sec/feed avg)
[06:32:24/29511] Processed 120 feeds in 83.1172 (sec), 0.6926 (sec/feed avg)
[07:02:49/32304] Processed 120 feeds in 108.0906 (sec), 0.9008 (sec/feed avg)
[07:32:49/3026] Processed 120 feeds in 107.9802 (sec), 0.8998 (sec/feed avg)
[08:02:50/5829] Processed 120 feeds in 109.3831 (sec), 0.9115 (sec/feed avg)
[08:32:41/9325] Processed 120 feeds in 99.8791 (sec), 0.8323 (sec/feed avg)
[09:02:26/12157] Processed 120 feeds in 84.5948 (sec), 0.7050 (sec/feed avg)
[09:32:15/15666] Processed 120 feeds in 73.6584 (sec), 0.6138 (sec/feed avg)
[10:02:43/18455] Processed 120 feeds in 101.1940 (sec), 0.8433 (sec/feed avg)
[10:32:39/21589] Processed 120 feeds in 97.5197 (sec), 0.8127 (sec/feed avg)
[11:02:52/24383] Processed 120 feeds in 110.8489 (sec), 0.9237 (sec/feed avg)
[11:32:35/27568] Processed 120 feeds in 93.7882 (sec), 0.7816 (sec/feed avg)
[12:03:01/30356] Processed 120 feeds in 119.4838 (sec), 0.9957 (sec/feed avg)
[12:32:44/1052] Processed 120 feeds in 103.1649 (sec), 0.8597 (sec/feed avg)
[13:02:36/3868] Processed 120 feeds in 94.0091 (sec), 0.7834 (sec/feed avg)
[13:32:52/7232] Processed 120 feeds in 110.7098 (sec), 0.9226 (sec/feed avg)
[14:02:36/10025] Processed 120 feeds in 94.6923 (sec), 0.7891 (sec/feed avg)
[14:32:41/13192] Processed 120 feeds in 100.5884 (sec), 0.8382 (sec/feed avg)
[15:02:28/15981] Processed 120 feeds in 87.2601 (sec), 0.7272 (sec/feed avg)
[15:32:40/18817] Processed 120 feeds in 98.7385 (sec), 0.8228 (sec/feed avg)
[16:02:38/21605] Processed 120 feeds in 96.3068 (sec), 0.8026 (sec/feed avg)
[16:32:40/24424] Processed 120 feeds in 98.5168 (sec), 0.8210 (sec/feed avg)
[17:02:15/27218] Processed 120 feeds in 74.1751 (sec), 0.6181 (sec/feed avg)
[17:32:29/30438] Processed 120 feeds in 87.7357 (sec), 0.7311 (sec/feed avg)
[18:02:32/762] Processed 120 feeds in 90.5626 (sec), 0.7547 (sec/feed avg)
[18:32:13/3613] Processed 120 feeds in 72.2621 (sec), 0.6022 (sec/feed avg)
[19:02:26/6432] Processed 120 feeds in 84.2084 (sec), 0.7017 (sec/feed avg)

opet z vps, ne lokal ...

[skunkOS]

Díky! To jsou docela pozitivní čísla. Já se na to asi faktu budu muset podívat.

[alium]

Ty moderní notifikační bubliny jsou fajn, ale pro KDE bych raději použil notifikační bubliny systému (KDE), protoženepasují úplně přesně graficky. Jde to nějak nastavit?

[skunkOS]

Jdou jen vypnout, pak se použijou standardní Qt bubliny. Nemám KDE, ale podpora pro KDE notifikace by měla jít velmi lehce přidat. Přístup k notifikacím je v aplikaci jen na jednom místě.

Bohužel, nemám KDE, ale jestli se mě bude hodně chtít, tak to dodělám a testnu ve VBoxu. Kdyžtak ale postni bug report na bitbucketu, jinak to zapadne.

[skunkOS]

Každopádně bych od nějakého KDEčkaře (sám sem nasraně před pár měsíci přešel na Cinnamon) potřeboval vědět, jaké třídy se pro notifikování z toho jejich API používají.

Asi toto?

[s0]

nebo si otestuj, jestli běží dbus služba org.freedesktop.Notifications (tuším, teď u linuxu nesedím), pak můžeš přes QtDbus posílat nativní notifikace všude (na linuxu). Anebo libnotify.

[alium]

Rozumím. Já přešel z právě opačně, z Cinnamonu na KDE.

Když notifikace vypnu, tak se neukazují vůbec žádné bubliny

[skunkOS]

Měly by se ukazovat bubliny u tray ikony. Je-li tray ikona vypnutá, skutečně se nebude ukazovat nic.