GnuPG GUI?

Mivel mindenképpen shell parancsokat kell használnom, ezért maradok a shell-nél, és a régi megoldásomat pofozom át kicsit.

Most xdg-open-t használok a fájl megnyitására, így a kiterjesztés alapján automatikusan a hozzátartozó alkalmazásban nyitja meg a fájlt. Publikus kulcsú .gpg fájlokhoz van.

Forráskód itt. Példa:

echo hello > szia.txt
gpg -e -r nevem szia.txt
rm szia.txt
./gpg_open.sh szia.txt.gpg

Itt feljön a pinentry és bekéri a jelszót, majd kibontja a fájlt és hozzányitja az alkalmazást. A progim megnézi, hogy milyen kulcs ID-vel lett eredetileg titkosítva, és az alkalmazás bezárása után ugyanazzal titkosítja vissza.

Még tesztelem. Ami nem szép, viszont legalább csúnya megoldás, az az, hogy nem találtam módot rá egy .gpg fájlról információt kinyerni, hogy megtudjam, milyen módon lett betitkosítva. Úgymint publikus vagy szimmetrikus titkosítás, illetve az előbbinél a kulcs id stb.

Ezt jelenleg úgy oldom meg, hogy parsolom a gpg stderr kimenetét. Egyetlen szépséghibája, hogy ha szimmetrikus (jelszavas) titkosításra futtatjuk, akkor csak a pinentry-s jelszó bekérés után tudom dobni a hibaüzenetet, hogy a fájl nem publikus kulcsú titkosítású.

Csak publikus kulcsú titkosítással készített fájlt akarok támogatni 3 ok miatt:
1) a pinentry-ből nem tudom kinyerni a közben beírt jelszót ami a visszatitkosításhoz kellene - és saját pinentry-t zenity-vel meg hasonló gányolással nem akarok csinálni
2) a publikus kulcsú titkosításnál a becsomagoláshoz nem kell jelszó
3) a publikus kulcsú titkosítás erőssége a kulcsunktól függ, nem a jelszó hosszától

Meg van az első grafikus felület alatt is teljesen működő verzió. Az szivatott meg, hogy gpg-nek kell a --no-tty kapcsoló, hogy ne oda akarja kinyomni az output-ot, mivel nincs ilyen eszköz ilyenkor.

Most már működik úgyis, hogy a grafikus felület alatt hozzátársítom a .gpg típusú fájlokhoz a script-emet.

Újabb változás: mostantól nézi a script, hogy konzolból vagy GUI-ból lett-e indítva. Ha előbbi, akkor a terminálba printeli a hibaüzenetet (ha van), ha utóbbi, akkor zenity-vel dobom ki a képernyőre.

Ez is kell mindenképpen, mert GUI alól ezelőtt nem volt látható, ha volt hibaüzenet.

Kieg.: ezt az alábbi paranccsal vizsgálom:

if [ -z $(stty) ]; then

Vagyis stty kimenete zero-e vagy sem. Van ennél szabványosabb megoldás, hogy megtudjuk, konzolból lett-e futtatva a script?

Jujj de szívtam az xdg-open paranccsal. Ez azt csinálja, hogy megnyitja a fájlhoz az alkalmazást, de nem vár, hanem egyből kilép. Ráadásul nem ő forkolja az új folyamatot, ezért arról sehonnét nem tudok infót gyűjteni, és ezért nem tudok várakozni enenk a folyamatnak a végére. Tehát ez nem működik sehogy:

xdg-open file.txt && wait

Ezért az xdg-mime paranccsal kell kibányásznom lépésenként az infót, hogy milyen típus fajta, ahhoz milyen .desktop tartozik, majd ez milyen binárist tartalmaz. Itt látható a patch.

Még finomítanom kell rajta, mert Debian / XFCE környezetben nem működik megfelelően - de nem a script-em, hanem az xdg-mime nem adja vissza a megfelelő típust.

Kicsit okosítottam az xdg-open implementációm: az adott kiterjesztéshez tartozó MIME típusnál az összes bejegyzett alkalmazást végignézi hátulról előre (hogy a legfrisebb társítást vegye előre), és az első létező alkalmazás nevét adja vissza.

Még azon tűnődök, hogy nem lehetne valamit a signal-okkal játszani? A poliing-ot akarom mindenképpen elkerülni. Vagy valami file descriptor-t kihámozni a /proc/PID/-ből, aztán bele írni úgy, hogy valami módon a művelet addig várakozzon, amíg be nem zár az alkalmazás.

Hogy lehetne idegen folyamatra vagy PID-re várakozni standard módon polling nélkül?

Végre sikerült minden szempontból megoldanom azokat a kérdéseket, amelyeket fontosnak tartottam. Tesztelés hiányzik még, esetleg KDE 4 alatt ha megnézné valaki, hálás lennék.

Először is Köszi Lacos! :D Durva mód örültem a megoldásnak, mert szerettem volna mindenképpen egy olyat is, ahol nem feltétlen kell polling, és már pár napja szívtem vele. :) Habár teszteltem, és a mappa létezésére való kérés (valószívűleg csak egy stat rendszerparancs a Ruby részéről a File.directory? kérés) nem eszik "semmit".

Az strace hack egyáltalán nem zavar. Akkor hívom csak meg, ha létezik a rendszeren. Egyébként pedig polling-olok, vagyis kicsit várva sleep-el újra kérdezem a /proc/PID lista alapján, hogy melyik az az alkalmazás, amelyik megnyitotta az xdg-open-nel a fájlomat.

A működésről:

Ez egy GUI megoldás. A célom, hogy egy file.ods.gpg vagy akármilyen .gpg kiterjesztésű fájlra klikkelve desktop-on bekérje a jelszót, és nyissa meg a fájl típusához tartozó programot - majd ha a felhasználó bezárja a programot, akkor titkosítsa vissza a fájlt kérdés nélkül. Ezért a .gpg kiterjesztéshez érdemes hozzátársítani a script-emet.

A GUI-hoz kell működő megoldott gpg agent. Ez Gnome alatt működik - XFCE alatt nincs alapból, de beállítható. Ha nincs agent, attól még továbbra is működik a program terminálból indítva - ez is megoldás ekkor, csak a parancsikont nem Application, hanem Application in terminal vagy hasonló módon kell létrehozni - ekkor csak annyi a csúnyaság, hogy az alkalmazás idejére ott figyel egy terminál is a háttérben. Ez nem gond. Vagy ez, vagy állítsunk be gpg agent-et. Egyébként Gnome alatt amin tesztelem, akkor is létrehozza az agent-et gpg, ha nem fut. Tehát asztali környezet függő.

Megjegyzések:

1) Tettem a Ruby verzióba is trap kódot - vagyis ha kap egy INT vagy TERM jelet, akkor törli a kicsomagolt titkosítatlan fájlt (alapból a rendszertől kérek temp fájlt, amely a /tmp alatt jön létre, és a nevébe beleveszem az open_gpg nevet, erre lehet keresni is, elvileg KILL jelet kivéve sosem szabad hátra maradni ennek a 2 fájlnak, amely közül egyik a kicsomagolt fájl, a másik pedig a gpg STDERR kimenete)

2) A temp fájlok végéhez hozzáteszem a kiterjesztést, mert úgy láttem, hogy előfordulhat, hogy ha nincs bejegyezve alkalmazás az adott kiterjesztéshez, attól még így jobban ki tudja találni xdg-open a szükséges app nevét.

3) Ugye az általam egyszerűnek gondolt dolgot 3 fő probléma akasztotta meg, amelyre nem számítottam:

- az egyik az, hogy "xdg-open fájlneve" parancsot meghívva megnyitja a fájlt a típusa alapján hozzárendelt alapértelmezett alkalmazásban, de _nem vár_. Tehát a system parancsnál tovább fut a kódom, mert az csak az xdg-open befejezésére vár, de itt még nem áll meg a történet, mert az tovább nyitja az alkalmazást, ami viszont nem gyermek folyamat lesz, és ezért nem lehet rá várakozni a rendszer vagy shell "wait" funkciójával. Ha gyermek folyamat lenne, akkor nem lett volna szívés és egy wait elég lett volna. De szép is lett volna :)

- a másik annak kiderítése, hogy mi lett végül a PID-je annak a folyamatnak, amelyet xdg-open hozzányitott a fájlhoz. A megnyitott alkalmazás megállapítását végezetül nem process group ID alapján teszem meg, hanem a /proc/PID/cmdline alapján. Ez tartalmazza a temp fájlom nevét. Pl. geany./tmp/XXXXXXXX.txt. És mivel véletlen szerű a név, ezért csak ez fogja tartalmazni, tehát megbízható megoldásnak tartom.

- a harmadik, hogy nem tudom megállapítani egy .gpg fájlról, hogy milyen módon lett betitkosítva. Az kell nekem, hogy szimmetrikus, vagy asszimetrikus módon lett-e. Ugye azt már leírtam, hogy a praktikussága és biztonsága miatt akarok csak publikus kulcsú titkosítást támogatni, mert egyrészt a gpg-agent-ben jobban megbízok a kulcs tárolására, mintha zenity-vel én implementálok le valamit és memóriában tartom a jelszót, ami ugye kell a program befejeztekor, hogy vissza tudjam titkosítani a tartalmat. Ez publikus kulcsúnál nem áll fent ugye, mert a titkosításhoz nem kell a privát jelszó, mivel a publikus kulccsal titkosít. Megunknak meg vegyük a fáradságot létrehozni egy kulcsot, és azt használni mindenhova a különböző gyenge jelszavak helyett. Szóval ennek a módját a gpg STDERR kimenetéből állapítom meg, amiben szerepen a "public key is" mondat, amely után megtalálom a kulcs ID-t. Remélem, hogy ez régóta standard a gpg verziókban és nem változik sűrűn.

4) Ha nincs gpg-agent, akkor ikon-ból indítva ez segíthet: "xterm -e '/home/user/open_gpg.rb file.valami.gpg'"

5) A program végén visszadob egy üzenetet a sikeres visszatitkosításról - úgy gondolom ez is fontos. Ekkor már törölve van a kritikus kicsomagolt fájl.

6) Van lehetőség fix alkalmazás név megadására is, ekkor a script utáni első paraméter nem a fájl neve, hanem az alkalmazás neve, és után jön a fájl neve, tehát pl:. :/open_gpg.rb gedit hello.txt.gpg

A kód itt található.

Felmerült még egy nehéz kérdés: ha több .gpg-s fájlt nyitok meg, és a kiterjesztésük egyforma, és ha a másik fájlt ugyanabban az app-ban nyija meg, akkor az app cmdline stringje már nem fogja tartalmazni a második fájlt, mivel a cmdline már nem is fog változni - mert ugye még mindig ugyanaz az app fut, csak benyitott még egy fájt.

És sajnos nem megállapítható általánosságban egy fájlról, hogy egy GUI app által nyitva van-e, mert megnyitás után valszeg azonnal lazárja a fájlt. Ezért se fuser, se lsof nem segít.

Illetve másik gond: a system() hívás csak az új app megnyitásánál vár. Tehát ha pl futtatunk egy ilyet: system("gedit file1.txt"), majd egy teljesen új shellben egy másik text fájlt nyitunk: system("gedit file2.txt"), akkor csak az első system hívásnál várakozik az app bezárására. A másodiknál is belenyitja a fájlt, de átszalad rajta. Tehát még az sem lenne megoldás, hogy megadnám az app nevét.

Egyelőre ezért több egyforma fájl megnyitásánál nem működik megfelelően a progim egyelőre.