kotovalexarian-likes-gitlab
/
hagrid-keyserver--hagrid
mirror of https://gitlab.com/hagrid-keyserver/hagrid.git
1
0
Fork 0
Code Releases Activity

about: reorder FAQ entries a bit

This commit is contained in:
Vincent Breitmoser 2019-07-02 15:27:06 +02:00
parent ecef952ce3
commit 61d644beda
No known key found for this signature in database
GPG Key ID: 7BD18320DEADFA11
1 changed files with 49 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
dist/templates/about/faq.html.hbs vendored
View File

@ -2,13 +2,46 @@
<div class="about">
<center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
after verification?</a></h3>
<h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a></h3>
The <span class="brand">keys.openpgp.org</span> service is meant for key
distribution and discovery, not as a de-facto CA. Client implementations
that want to offer verified communication should rely on their own trust
model.
<p>
No. The federation model of the SKS pool has various problems in terms
of reliability, abuse-resistance, privacy, and usability. We might do
something similar to it, but <span class="brand">keys.openpgp.org</span>
will never be part of the SKS pool itself.
</p>
<h3 id="federation"><a href="#federation">Is keys.openpgp.org federated? Can I help by running an instance?</a></h3>
<p>
For the moment, no.
We do plan to decentralize <span class="brand">keys.openpgp.org</span>
at some point.
With multiple servers
run by independent operators,
we can hopefully improve the reliability
of this service even further.
</p>
<p>
Several folks offered to help out
by "running a Hagrid server instance".
We very much appreciate the offer,
but we will probably never have an "open" federation model like SKS,
where everyone can run an instance and become part of a "pool".
This is for two reasons:
</p>
<ol>
<li>
Federation with open participation requires all data to be public.
This significantly impacts the privacy of our users, because it
allows anyone to scrape a list of all e-mail addresses.
</li>
<li>
Servers run as a hobby by casual administrators do not meet our
standards for reliability and performance.
</li>
</ol>
<h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
for identities that aren't e-mail addresses?</a></h3>
@ -68,6 +101,16 @@
on a solution.
</p>
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
after verification?</a></h3>
<p>
The <span class="brand">keys.openpgp.org</span> service is meant for key
distribution and discovery, not as a de-facto CA. Client implementations
that want to offer verified communication should rely on their own trust
model.
</p>
<h3 id="revoked-uids"><a href="#revoked-uids">Why are revoked identities not
distributed as such?</a></h3>
@ -118,47 +161,6 @@
upload keys that can only sign.</li>
</ol>
<h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a></h3>
<p>
No. The federation model of the SKS pool has various problems in terms
of reliability, abuse-resistance, privacy, and usability. We might do
something similar to it, but <span class="brand">keys.openpgp.org</span>
will never be part of the SKS pool itself.
</p>
<h3 id="federation"><a href="#federation">Is keys.openpgp.org federated? Can I help by running an instance?</a></h3>
<p>
For the moment, no.
We do plan to decentralize <span class="brand">keys.openpgp.org</span>
at some point.
With multiple servers
run by independent operators,
we can further improve the reliability
of this service.
</p>
<p>
Several folks offered to help out
by "running a Hagrid server instance".
We very much appreciate the offer,
but we will probably never have an "open" federation model like SKS,
where everyone can run an instance and become part of a "pool".
This is for two reasons:
</p>
<ol>
<li>
Federation with open participation requires all data to be public.
This significantly impacts the privacy of our users, because it
allows anyone to scrape a list of all e-mail addresses.
</li>
<li>
Servers run as a hobby by casual administrators do not meet our
standards for reliability and performance.
</li>
</ol>
<h3 id="older-gnupg"><a href="#older-gnupg">
I have trouble updating some keys with GnuPG. Is there a bug?
</a></h3>