Birçok insan GPGME'yi gerçekten anlamıyor ve muhtemelen mevcut belgelerin o sırada yazılan kod yorumu olması yardımcı olmuyor. Bununla birlikte, tüm GNU Privacy Guard paketine tam veya neredeyse tam programlı erişime izin verecektir ve ayrıca libassuan, gpg-agent ve diğer çeşitli bileşenler gibi şeylere erişime izin vermesi beklenmektedir. Bu nedenle, varsayılan olarak, 90'ların sonlarında yüksek sesle kullanan birkaç şirketin dışında neredeyse hiç kimsenin kullanmadığı S / MIME uygulamasını da içeriyor.
Şu anda GPGME, 500 ayrı işlev veya daha fazlası gibi bir şey içerir ve komut satırında GPG ile yapacağınız hemen hemen her şeyi kapsar. Bununla birlikte, daha sonra doğru yön olmadığı belirlenen önceki tasarım seçeneklerinin bazı kalıntılarını da içerir. Örneğin, bu, içinde GTK 2'nin büyük parçaları olan bir API'dir. Açıkçası, bunun gitmesi gerekiyor (ve zaman izin verdiği zaman olacak). Bugünlerde sahip olduğu bir başka sorun, belki de benimsemenin en büyük engeli, birisi "API" dediğinde, çoğu kodlayıcının, şeye erişmek için kendi kodlarıyla derlemek için derhal C başlık dosyalarını düşünmemesi; yüzleşelim, bugünlerde çoğu insan RESTful bir şey düşünüyor ya da en azından bir JSON biçimindeki verilerle etkileşime geçelim. GPGME bundan çok daha uzaktadır. ' almak mümkün. JSON ile güzel bir şekilde oynatılması mümkün olsa da, anahtarları düzenlemek mümkün olamayacağından asla RESTful olamaz. Ayrıca web üzerinden anahtarları yönetmek sadece sorun istiyor.
Ayrıca, yazılımın başında çalışan insanlar bile, bazı şeyler hala şaşırtabilecek şekilde, belgelenmemiş birçok özellik ve özellik vardır. Örneğin, resmi bir şema dışında her şeye sahip olan verilerin anahtarlanması için XML biçimi (birkaç ay önce oluşturulana kadar).
Öte yandan, Mutt'ın yaptığı tüm iyi şeyler için, bazı şok edici şeyler de yapar. Örneğin, GPGME kullansın ya da kullanılmasın, Mutt'un parolaları önbelleğe alması için hiçbir neden olmamalıdır; her iki senaryoda da GPG'ye (gpg aracılı veya aracısız) teslim edilmelidir. Aynı şekilde, ~/.gnupg/gpg.conf
dosyadaki (ve bu dizindeki diğer) yapılandırma parametrelerini de dikkate almalıdır . Elbette, komutların çağrılma şeklini değiştirmek için farklı hesaplar için alternatif bir anahtar kimliği ayarlamak veya hatta alternatif yapılandırma dosyalarını veya tüm dizinleri (ör.gpg --homedir ~/.gnupg-work/gpg.conf
). Bununla birlikte, Mutt, parola veya anahtar yönetimi gibi etkileşimde bulunduğu program tarafından zaten çözülmüş olan sorunları çözmeye çalışırken zaman harcar, ancak çoğu e-posta için harika olan GPG'nin normal özelliklerine erişime izin vermez birden çok alıcı için grup satırları kullanmak veya belirli alıcılar için anahtar seçimini geçersiz kılmak gibi (çünkü her zaman gizli anahtarını kaybetmeye devam eden veya parolayı unutan bir adam var ve şimdi UID ile aynı adrese sahip 15 ortak anahtarınız var ve varsayılan davranış, büyük olasılıkla doğru olmayan ilk eşleşmeyi seçmektir). Emacs orada biraz daha iyidir, ancak gpg.conf
genellikle istemek istediği şeylere otomatik olarak cevap veren dosyayı almayı başaramaz .
Şimdi, biraz daha kullanışlı ve teğetsel olarak ilişkili bir şey için, GPGME, gpgme-tool adı verilen başka bir şık küçük belgesiz şeyle birlikte gelir. Bir UNIX soketinde çalışacak olan GPGME için temel bir arabirimdir (ve elbette ncat veya başka bir şeyi bir ağ bağlantı noktasında oturtmak için kullanabilirsiniz). Belgelenmemiş olmasına rağmen, çalıştırıp bir süre etkileşimde bulunmanız ve yardım komutuyla başlamanız oldukça açıklayıcıdır. Alternatif olarak bu oldukça iyi çalışır:
echo help | gpgme-tool > gpgme-tool-cheatsheet.txt
Tüm temelleri mutlu bir şekilde yapacak (şifreleme, şifresini çözme, işaretleme, doğrulama, parolaları değiştirme, anahtarlar oluşturma, anahtarları listeleme, gizli anahtarları listeleme, belirli anahtarları arama veya seçme vb.). "Gizli" XML biçimini görmek istiyorsanız şunu deneyin:
echo "KEYLIST --secret-only" | gpgme-tool > secret-key-list.xml
Bu gizli anahtarları dışa aktarmaz, sadece onları ve bunlar hakkındaki verileri listeler. Ayrıca, herhangi bir şey gerçekten XML olarak tanınmadan önce filtrelenmesi gereken bazı çıktı biçimi hamleriyle dışa aktarılır (üst satırı, sonraki satırların ilk iki karakterini ve her satırın sonundan% 0A'yı silin) ). Her neyse, gpgme-aracı GPGME'nin gerçekten neler yapabileceği hakkında daha iyi bir fikir verebilir. Örneğin GPGME için PyME Python bağlamaları, GPGME işlevlerini otomatik olarak eşleştirmeye çalışır (ve genellikle bunu sorunsuz bir şekilde gerçekleştirir); pyme.core.pygpgme dosyasındaki güncel özellikler listesi 534'e geliyor. Bunu komut satırıyla karşılaştırın ve GPG 1.4.20'nin 322 seçeneği varken 2.1.11'in 347'si var (2.0'ı atladım, bu yüzden kontrol edemiyorum, ancak bu ikisi arasında bir yerde olmak).
Tuş komutlarının eşleşmesine atıfta bulunan önceki cevaba gelince, bu sadece konfigürasyon seçenekleri ve Mutt'un GPG'ye tam erişime izin verip vermemesine bağlı olmalıdır. Şu anda Mutt'u GPGME ile kullanıyorum ve belirtilen iki işlev (posta anahtarı ve ayıklama anahtarları) iyi, ancak Mutt, PGP / satır içi içeriği tanımlamış veya aldığında metin / düz içerik türünü aldıysa sorun yaşıyor bir yerlerde. Bu olduğunda evet, genellikle Emacs'a veya başka bir şeye geçmek gerekir. Yine de, Mutt'un içeriğin gerçekten sadece metin olup olmadığını veya başka türlü OpenPGP formatındaki içeriği nasıl kontrol ettiğini kontrol etme ile ilgili bir sorun gibi görünüyor. Hepimizin yerine PGP / MIME kullanmamız gerektiğini söylemekten daha iyi bir şey sevmesem de (ve olmalıyız),
Temel olarak Mutt, mesajın yalnızca çok parçalı MIME olmasına dayanıyor ve bir şey yapmak için anahtar, imzalar ve / veya şifreli içerik içeren parçalardan biri veya daha fazlası. Yalnızca eşleşen içeriği arayan düz bir e-postada arama yapmakla kalmaz, bu ne GPG'nin ne de GPGME'nin hatasıdır. Çözüm, bu özellikleri Mutt'a eklemek veya iletiyi bu özelliğe sahip bir şeyde açmaktır (örneğin, bugünlerde varsayılan olarak etkinleştirilmesi gereken EPA / EasyPG'li Emacs) veya iletiyi doğrudan bir komuta (veya gpgme-tool) iletmektir. isterseniz, ancak borulama yaparken doğrudan normal bir komuta gitmek daha kolaydır).
GPGME'ye gelince, herkesin mevcut olmadığı için, her zaman sistemde yüklü olan aynı kaynak sürümden derlenmesi gerekir. GPG'yi yükseltirseniz ve GPGME'yi eşleşecek şekilde yeniden derlemezseniz, muhtemelen sorunlar olacaktır. Öte yandan, GPG'nin kaynaktan mümkün olduğunda yüklenmesi genellikle önerilir, bu nedenle GPGME yoluna giderseniz GPG'yi güncellerken bu derlemeyi çalıştırmak iyi bir uygulamadır ve her şey yolunda olmalıdır.
Oysa sadece kendi seçtikleri dağıtımın sağladığı paketlere güvenen insanlar da bu paketlerin bakımını yapmakla uğraşabilecek her şeye tabi olacaklar ve GPG ve GPGME'nin birlikte çalışmanın gerekliliklerini her zaman anlayabilirler veya anlamayabilirler. Örneğin, GPGME için MacPorts paketi GPG 2.0.x'e bağımlı olacak şekilde ayarlanmıştır, bu da GPG 2.1.x ile çakışmaya ayarlanmıştır, bu nedenle 2.1 yükleyen çoğu kişi açıkça birlikte çalışsalar bile GPGME'yi yükleyemez. GPGME'nin bu senaryoda çalışabilmesi için MacPorts'un önerdiği şeyleri (port yönetim sistemi dışında, ancak içeride bir şeyler derlemek) yapmanız gerekir /opt/local
. Bazı Linux dağıtımlarında benzer sorunlar olabilir.
Bu nedenle, yalnızca PGP / MIME kullanacaksanız, GPGME entegrasyonunu kullanmayla ilgili herhangi bir sorun olmamalıdır ve bu, dosyanızda hiçbir zaman belirli komutları yapılandırmanız gerekmediği anlamına gelecektir .muttrc
. PGP / in-line ile uğraşıyorsanız, sorunlarla karşılaşacaksınız, ancak Mutt ile her iki şekilde de önlenemezler, bu nedenle yine de GPGME kullanmanızı tavsiye ederim.
YASAL UYARI: Ben revizyon sonrası bir şey kullanabilmek için tüm C olmayan devs için API bir API yapmak dev çalışma ile ilgili. Ayrıca PyME 0.9'u Python 2'den Python 3'e taşıdım (şu anda GPGME'nin bir kolunda ve sadece Python 2 sürümü PyPI ve pip üzerinden kullanılabilir).
GÜNCELLEME: PyME - Python 3 arasındaki bağlantı noktası şimdi GPGME'nin ana dalındadır ve PyPI'de pyme3 olarak kullanılabilir.