hagrid-keyserver--hagrid/templates-translated/tr/about/faq.html.hbs

183 lines
12 KiB
Handlebars
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<div class="about">
<center><h2>
<a href="/about">Hakkında</a> | <a href="/about/news">Haberler</a> | <a href="/about/usage">Kullanım</a> | SSS | <a href="/about/stats">İstatistikler</a> | <a href="/about/privacy">Mahremiyet</a>
</h2></center>
<p><strong>Yönergeler için, <a href="/about/usage">kullanma kılavuzumuza</a> bakabilirsiniz.</strong></p>
<h3 id="sks-pool"><a href="#sks-pool">Bu sunucu "SKS" havuzunun bir parçası mı?</a></h3>
<p>Hayır. SKS havuzunun federasyon modeli güvenilirlik, istismar direnci, mahremiyet ve kullanışlık bağlamında bazı sorunlar içeriyor. Ona benzer bir şey yapabiliriz ama <span class="brand">keys.openpgp.org</span>
hiç bir zaman SKS havuzunun bir parçası olmayacaktır.</p>
<h3 id="federation"><a href="#federation">keys.openpgp.org federe mi? Bir örneğini çalıştırarak yardımcı olabilir miyim?</a></h3>
<p>Şu an değil.
Bir noktada<span class="brand">keys.openpgp.org</span>'u
ademi merkeziyetçi yapmak istiyoruz.
Bağımsız işleticiler tarafından çalıştırılan
bir çok sunucuyla, umuyoruz ki
hizmetin güvenilirliğini daha da geliştirmeyi
yapabiliriz.</p>
<p>Bir çok insan "Hagrid sunucu örneği çalıştırma"
konusunda yardımcı olmayı önerdi.
Öneriyi takdirle karşılıyoruz ancak
hiç bir zaman SKS gibi, insanların bir örnek çalıştırdığı ve bir "havuzun" parçası olduğu "açık" bir federasyon modeline sahip
olacağımızı düşünmüyoruz. Bunun iki nedeni var:</p>
<ol>
<li>Açık katılımla federasyon bütün verinin kamuya açık olmasını gerektirir.
Bu kaydadeğer bir şekilde kullanıcıların mahremiyetini etkileyecektir, çünkü her isteyen kişinin e-posta adreslerini elde etmesini sağlar.</li>
<li>Sunucular, güvenilirlik ve başarım standartlarımızı karşılamayan plansız yöneticiler tarafından bir hobi olarak çalıştırılırlar.</li>
</ol>
<h3 id="non-email-uids"><a href="#non-email-uids">E-posta adresi olmayan kimlikler neden desteklenmiyor?</a></h3>
<p>Kimlik bilgisinin dağıtımı için açık bir rızaya ihtiyacımız var.
E-posta adresi olmayan kimlik bilgisi, örneğin resim veya website URL'leri, bu rızayı talep etme konusunda zorluklar çıkarır.</p>
<p>Not: Bazı OpenPGP yazılımları anahtarları doğru bir şekilde biçimlenmemiş e-posta adresleriyle yaratıyor. Bu adresler <span class="brand">keys.openpgp.org</span> üzerinde doğru bir şekilde tanımlanamayabilir.</p>
<h3 id="verify-multiple"><a href="#verify-multiple">Aynı e-posta adresi için birden fazla anahtarı doğrulayabilir miyim?</a></h3>
<p>Bir e-posta adresi ancak tek bir anahtarla eşlenebilir. Eğer bir adres yeni bii ranahtar için doğrulandığında, daha önce doğrulandığı hiç bir anahtarla birlikte listelenmez. <a href="/about">Kimlik bilgisi olmayan kısımlar</a>bütün anahtarlar için dağıtılmaya devam edecektir.</p>
<p>Bunun anlamı, e-posta adesiyle yapılan aramanın, bir çok seçenek değil, sadece bir anahtar döndüreceğidir. Bu kullanıcı için mümkün olmayan ("Acaba hangi anahtar doğrusuydu?") seçimi ortadan kaldırır ve e-posta ile anahtar keşfini oldukça elverişli kılar.</p>
<h3 id="email-protection"><a href="#email-protection">Dışa giden doğrulama e-postalarını korumak için ne yapıyorsunuz?</a></h3>
<p>Doğrulama e-postalarının güvenli bir şekilde gönderildiğinden emin olmak için EFF'nin <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a> ile birlikte <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a> adı verilen modern bir standart kullanıyoruz. Böylece teslimat sırasında gizli dinleme ve önlemeye karşı koruma sağlanıyor.</p>
<p>MTA-STS yöntemi ancak alıcının e-posta hizmeti sağlayıcısı destekliyorsa çalışır.
Desteklenmiyorsa e-postalar olağan şekilde iletilecektir.
<a href="https://www.hardenize.com/">Bu testi çalıştırıp</a>
e-posta hizmeti sağlayıcınızın destekleyip desteklemediğine bakabilirsiniz.
Eğer "MTA-STS" girdisinin solunda yeşil onay imi yoksa,
lütfen sağlayıcınızdan yapılandırmalarını güncellemelerini isteyin.</p>
<h3 id="third-party-signatures"><a href="#third-party-signatures">"Üçüncü parti imzaları" dağıtıyor musunuz?</a></h3>
<p>Kısaca: hayır.</p>
<p>"Üçüncü parti imza" bir anahtardaki başka
  bir anahtar tarafından yapılan bir imzadır.
  Çoğunlukla,
  bu imzalar "başkasının anahtarını imzalarken" üretilmiştir,
bu işlem "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Güven Ağı</a>"nın temelidir.
  Çeşitli nedenlerden dolayı,
  bu imzalar şimdilik <span class="brand">keys.openpgp.org</span>
  üzerinden dağıtılmıyor.</p>
<p>En önemli neden <strong>spam</strong>.
Üçüncü parti imzaları herhangi bir kimsenin anahtarına keyfi veri eklenmesine olanak sağlar.
Böylece kötü niyetli bir kimsenin megabaytlarca yığını bir anahtara eklemesini
ve böylece onu kullanışsızlaştırmasını
engelleyecek hiç bir imkan yoktur.
Daha da kötüsü,
saldırgan veya yasadışı içerik de ekleyebilirler.</p>
<p>Bu sorunu çözmeye yönelik fikirler var.
Örneğin, imzalar, imza sahibi yerine sahibi onaylayan
imzacıyla birlikte dağıtılabilir.
Alternatif olarak, dağıtımdan önce imza sahibinden
<a href="https://wiki.debian.org/caff" target="_blank">caff türü</a> iş akışını desteklemek için
çapraz imzalama
istenebilir.
Eğer yeterli bir ilgi varsa,
OpenPGP projeleriyle birlikte bir çözüm üzerinde
çalışmaya açığız.</p>
<h3 id="no-sign-verified"><a href="#no-sign-verified">Neden anahtarlar doğrulama
sonrası imzalanmıyor?</a></h3>
<p><span class="brand">keys.openpgp.org</span> hizmeti anahtar dağımı ve
keşfi içindir, fiili bir onay kurumu değildir.
Doğrulanmış iletişim sağlamak isteyen istemci gerçekleştirimleri
kendi güven modeline dayanmalıdır.</p>
<h3 id="revoked-uids"><a href="#revoked-uids">İptal edilen kimilkler neden bu
şekilde dağıtılmıyor?</a></h3>
<p>Bir OpenPGP anahtarı kimliklerinden birini iptal edilmiş
olarak işaretlediğinde, bu kimlik artık anahtar için geçerli
olarak kabul edilmemeli ve bu bilgi, halihazırda bu yeni
iptal edilmiş kimliğe ilişkin bilgiye sahip tüm OpenPGP
istemcilerine dağıtılmalıdır.</p>
<p>Maalesef, iptalleri dağıtmaya ilişkin, iptal edilen kimliğin
kendisini de açığa vurmayan iyi bir yöntem yok. İptal edilmiş
kimlikleri dağıtmak istemiyoruz, dolayısıyla kimliğin kendisini
hiç dağıtamayız.</p>
<p>Kimliğin kendisini açığa vurmadan iptallerin dağıtımına olanak
sağlayacak bazı yöntemler öneriliyor. Ancak henüz bitmiş bir
belirtim veya OpenPGP yazılımında destek yok. Yakın gelecekte
bir çözümün ortaya konulacağını düşünüyoruz ve öyle bir durumda
<span class="brand">keys.openpgp.org</span>tarafından da mümkün
olduğunca çabuk destek eklenecektir.</p>
<h3 id="search-substring"><a href="#search-substring">Neden alan adında yapabildiğimiz gibi e-posta adresinin bir kısmıyla arama yapamıyoruz?</a></h3>
<p>Bazı anahtar sunucuları e-posta adresinin bir kısmıyla anahtar aramasına izin veriyor.
Bu sadece anahtarların değil, ayrıca "adres at gmail nokta com anahtarları" gibi bir sorguyla, adreslerin de bulunmasına yol açar.
Bu etkin olarak bu anahtar sunucusundaki tüm anahtarların adreslerini bir bakıma herkese açık hale getirir.</p>
<p><span class="brand">keys.openpgp.org</span> üzerinde e-posta adresiyle aramalar ancak tam eşleştiği e-posta adresinin anahtarını geri döndürür.
Böylece, normal bir kullanıcı halihazırda bildiği herhangi bir adresle ilişkili anahtarı keşfedebilirken, yeni e-posta adreslerini keşfedemez.
Bu, kötü niyetli kullanıcıların veya spamcıların sunucu üzerindeki tüm e-posta adreslerinin bir listesini edinmesini önler.</p>
<p>Bu kısıtlamayı <a href="/about/privacy">gizlilik politikamızın</a> bir parçası yaptık,
böylece kullanıcıların rızasını almadan bu kısıtlamayı değiştiremeyiz.</p>
<h3 id="tor"><a href="#tor">Tor destekliyor musunuz?</a></h3>
<p>Elbette!
Eğer Tor kuruluysa,
<span class="brand">keys.openpgp.org</span> adresine anonim olarak
bir
<a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">onion hizmeti</a> şeklinde erişebilirsiniz:
<br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>
<h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">
Neden doğrulama e-postalarını şifrelemiyorsunuz?</a></h3>
Çeşitli nedenler:
<ol>
<li>Çok daha karmaşıktır, hem kullanıcılar hem de bizim için.</li>
<li>Saldırıları engellemiyor, bir saldırganın, erişimi olmadığı
bir anahtarı yüklemekten bir kazancı olmuyor.</li>
<li>Silme anahtar kaybolduğunda bile mümkün olacaktır.</li>
<li>Sadece imzalamaya yarayan anahtarları yüklemek, farklı (ve çok daha
karışık) bir yöntem gerektirecektir.</li>
</ol>
<h3 id="older-gnupg"><a href="#older-gnupg">
GnuPG ile bazı anahtarları güncellemekte sorun yaşıyorum, bu bir hata mıdır?
</a></h3>
<p>GnuPG kimlik bilgisi içermeyen anahtarları geçersiz olarak kabul eder ve onları içe aktarmayı reddeder.
Ancak, <a href="/about">doğrulanmış e-posta adresleri</a> içermeyen bir anahtar da yararlı bir bilgi içerebilir.
Özellikle anahtarın hükümsüz olup olmadığını denetlemek mümkündür.</p>
<p>2019 yılı Haziran ayında, <span class="brand">keys.openpgp.org</span> ekibi GnuPG'nin kimlik bilgisi içermeyen anahtarlardan güncelleme almasını sağlayan bir yama oluşturdu.
Bu yama GnuPG'nin bir çok alt sürümünde (Debian, Fedora, NixOS ve macOS için GPG Suite) çabucak kullanılmaya başlandı.</p>
<p>2020 yılı Mart ayında GnuPG ekibi yamayı reddetti ve hata kaydının durumunu "Düzeltilmeyecek" olarak güncelledi.
Bunun anlamı <strong>yamalanmamış GnuPG sürümlerinin, doğrulanmış herhangi bir e-posta adresi içermeyen anahtarlar için <span class="brand">keys.openpgp.org</span> sitesinden güncelleme alamayacağıdır</strong>.
Bu karar hakkında daha fazla bilgiyi, GnuPG hata takip sistemindeki <a href="https://dev.gnupg.org/T4393#133689">T4393</a> hata kaydında okuyabilirsiniz.</p>
<p>GnuPG sürümünüzün etkilenip etkilenmediğini aşağıdaki yönergelerle denetleyebilirsiniz:</p>
<blockquote>
<span style="font-size: larger;">Deneme anahtarını içe aktarın:</span><br><br>
$ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" imported<br>
gpg: Total number processed: 1<br>
gpg: imported: 1<br><br>
</blockquote>
<blockquote>
<span style="font-size: larger;">Yamayla, yerel olarak biliniyorsa anahtar güncellenmektedir:</span><br><br>
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" not changed<br>
gpg: Total number processed: 1<br>
gpg: unchanged: 1<br><br>
</blockquote>
<blockquote>
<span style="font-size: larger;">Yama olmadan, kimlik bilgisine sahip olmayan bir anahtar her zaman reddedilmektedir:</span><br><br>
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID<br>
</blockquote>
</div>