Add PGP keys to people #50
Labels
No Label
bug
build
cgi Scripting
design
disruptive
documentation
duplicate
easy
feature-request
help wanted
javascript
priority/low
question
system-hackers
tagging
text
translations
wait/bugfix
wait/inprogress
wait/misc
wait/proofread
wontfix
xsl
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: FSFE/fsfe-website#50
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
/about/people/people.en.xml should contain a key ID field for people, which would enable us to generate links to public key databases anywhere we show a list of people to contact. This is likely not critical for country and most issue teams, but I am sure that our visitors would appreciate an easy way to contact the council and the CARE and legal teams via encrypted means.
That could be a nice item for digging into the people.en.xml file and the respective XSL code to show it at certain places.
We would have to think about whether we link to a public keyserver site since they are often broken, or whether we just show the ID. And in this regard, we would also have to think about how many bits of the ID we want to show – more means more security, less means better look...
Alternatively, most people from Council and many teamers/staffers maintain their own profile page with GPG info anyway, so there already is some info available.
Where should we put the keys, then? As the people pages are custom the only standard place would be the people list.
Maybe another approach to solve this issue would be asking the people mentioned on the peoples page to provide their key and put it on their personal pages.
What do you think?
Yes, I think that this is better than adding additional information on the already quite crowded team page. Also, it creates some additional questions: how long shall the fingerprint be, and how do we make sure everyone updates their keys on this page of they create new ones.
Some people suggested setting up WKD for hosting keys in the @fsfe.org domain, and an additional service to enable people to upload them. It seems to me that this is the better option.
More opinions welcome though of course! :)
Personally, I do not go beyond the team page when I look up someone's e-mail address. Usually, I would like to get their PGP key at the same time as I get their e-mail address. So in my vision, the PGP key should indeed be listed on the team page. For security reasons, I think we should fit the entire key fingerprint in there. It fits on our business cards, so I see no reason why we should not be able to add it to the entries on team page. However, that requires someone with design capability to redesign the page.
I think we should also set up WKD, but I do not think WKD alone is sufficient. More people know how to compare fingerprints than know how to use WKD with their e-mail client.
As far as updating key information goes, we have to accept that sometimes people fail to update their key IDs. Sometimes they also fail to update their e-mail addresses and roles. Should we remove them because of this? The actual keys should not be uploaded by people to our web server, however. We should use the key-ID to link to the relevant entry on a publicly accessible key server.
A compromise could be the following:
An example of how this can be realised is on https://fsfe.org/tags/tags.html (Show tag keys). CSS only :)
Rather than unrolling the GPG key, we could also just link to a page that contains only the GPG key. This will make it easier to download the key, you don't have to copy and paste to a new file.
I like the suggestion of @max.mehl. @reinhard, we would unroll the full fingerprint that would also be a link to the same key on a public keyserver. Advanced users would then be able to simply copy the fingerprint, open up a terminal, type "gpg --recv-keys ", paste the fingerprint, and hit enter; users less acquainted with gpg could follow the link to the keyserver. The link could point to an ASCII-armoured plain text version of the key alone if we can find a suitable public keyserver.
So I have implemented a basic working, neat solution in the commit above. The paw prints glyph is a link to the fingerprint (
openpgp4fpr:0000111122223333444455556666777788889999) and the key glyph is a link to a key file served over https. (Restrictions currently not enforced.)Have a look at the screenshots below. If anybody wants to touch up the link style a bit, they are welcome to do so.
@max.mehl and @reinhard, let me know what you think. I'd like to merge this into master Wednesday night unless someone steps up to make improvements over the next couple of days.
@repentinus do you have a branch which we could check out to test locally?
I think the key symbol is understandable, but the paw would not make me think of something key-related. Also, two symbols for secure email messaging seem to be somewhat overkill IMHO, that's quite unexpected from a UX point of view. Instead, one symbol that – on click – offers me different verbose options, e.g. show fingerprint or link to keyserver, would be more intuitive.
As a side note: I am starting to believe that a WKD/WKS type of thing would be a more sustainable move because clients would take care of it automatically. But yes, for cross-checking, to have something on fsfe.org would also not be that bad.
https://git.fsfe.org/FSFE/fsfe-website/src/branch/people-openpgp-keys
@max.mehl, I agree that the ideal solution would at the same time
I am just not capable of implementing a solution satisfying all those criteria at once in a reasonable amount of time. This is unobtrusive and makes it easy to obtain both the fingerprint and the key, so it is good enough for me. I would be grateful for any UX improvements that simultaneously maintain the ease of obtaining the fingerprint and directly downloading the key, but I consider it security-critical to provide a uniform interface to key data.
At the moment we have a mixture of keys that are distributed more or less securely (either the fingerprint is specified on the person's profile page or the key has been committed to the web repo or a link to the key hosted on an external HTTPS site has been provided on their profile page) and those that are distributed insecurely (no fingerprint on their profile page and either a key ID or a link to a public key server by the key ID is provided – both short and long key IDs are insecure and should not be used to identify keys). Having all the key information in a single location makes it easy to identify and prevent insecure practices.
Standard profile fields would also encourage people to add their key data, so I do not need to e-mail Matthias whenever I need the key for somebody new. WKD or certain DNS records would fix this for people who use their fsfe.org addresses, but we have team members who prefer their personal address, so I believe that a web-based solution would be required even if we implemented WKD (although in this case we should ensure there are no discrepancies between the two services).