Add PGP keys to people #50

New Issue

2017-12-07T05:03:17Z

repentinus commented

2017-12-07 05:03:17 +00:00

/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.

/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.

repentinus added the feature-request label 2017-12-07 05:03:17 +00:00

reinhard removed the due date - 2019-04-29 21:04:14 +00:00

max.mehl commented

2019-05-22 09:58:35 +00:00

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.

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.

repentinus self-assigned this 2019-05-25 12:13:58 +00:00

repentinus added this to the Hackathon1905 milestone 2019-05-25 12:14:18 +00:00

mweimann commented

2019-10-05 12:20:45 +00:00

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?

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?

max.mehl commented

2019-10-05 18:46:32 +00:00

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.

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! :)

> 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. 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! :)

repentinus commented

2019-10-05 21:21:17 +00:00

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.

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.

max.mehl commented

2020-09-01 13:49:45 +00:00

A compromise could be the following:

we store the full GPG ID in people.en.xml
The full ID is not displayed by default on the team page to not clutter things
However, each person with stored GPG ID has a small icon next to them. Clicking this, the full GPG key unrolls

An example of how this can be realised is on https://fsfe.org/tags/tags.html (Show tag keys). CSS only :)

A compromise could be the following: * we store the full GPG ID in people.en.xml * The full ID is not displayed by default on the team page to not clutter things * However, each person with stored GPG ID has a small icon next to them. Clicking this, the full GPG key unrolls An example of how this can be realised is on https://fsfe.org/tags/tags.html (Show tag keys). CSS only :)

reinhard commented

2020-09-02 06:42:08 +00:00

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.

repentinus commented

2020-09-02 13:52:23 +00:00

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.

👍 1

repentinus referenced this issue from a commit

2020-09-27 01:55:37 +00:00

OpenPGP improvements for people (#50) Two new fields have been added to person elements: * fingerprint * keyhref fingerprint takes a hexadecimal OpenPGP key fingerprint without any spaces, converts this to an openpgp4fpr URI, and adds a link pointing to this URI to the person's profile. keyhref takes a URL to a plain-text, ASCII-armoured OpenPGP public key and adds a link pointing to the URL to the person's profile. These fields are not yet explicitly restricted to valid contents. fingerprints and keyhrefs have been added for all team members whose keys are stored in the repository or securely linked to from their profile page. It was not possible to determine Greve's preferred key, so fingerprint was omitted for Greve.

repentinus commented

2020-09-27 02:00:13 +00:00

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.

Firefox:
Chromium:

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. * Firefox: ![Screenshot on Firefox](https://git.fsfe.org/attachments/985de919-2c85-45e9-bdc2-d4e86fc6d245) * Chromium: ![Screenshot on Chromium](https://git.fsfe.org/attachments/46fcd975-5aaf-4445-b79f-5b2e79069caa)

127.0.0.80_8000_about_team.en.html (1).png

3.2 MiB

Screenshot_2020-09-27 About Free Software Foundation Europe - Team - FSFE.png

866 KiB

max.mehl commented

2020-09-28 08:32:25 +00:00

@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.

@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.

repentinus commented

2020-09-28 09:17:23 +00:00

https://git.fsfe.org/FSFE/fsfe-website/src/branch/people-openpgp-keys

repentinus commented

2020-09-28 19:10:38 +00:00

@max.mehl, I agree that the ideal solution would at the same time

be unobtrusive,
display the fingerprint,
and link to an ASCII-armored key.

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).

@max.mehl, I agree that the ideal solution would at the same time 1. be unobtrusive, 2. display the fingerprint, 3. and link to an ASCII-armored key. 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).

repentinus referenced this issue from a commit

2020-10-01 00:53:21 +00:00

OpenPGP improvements for people (#50) Two new fields have been added to person elements: * fingerprint * keyhref fingerprint takes a hexadecimal OpenPGP key fingerprint without any spaces, converts this to an openpgp4fpr URI, and adds a link pointing to this URI to the person's profile. keyhref takes a URL to a plain-text, ASCII-armoured OpenPGP public key and adds a link pointing to the URL to the person's profile. These fields are not yet explicitly restricted to valid contents. fingerprints and keyhrefs have been added for all team members whose keys are stored in the repository or securely linked to from their profile page. It was not possible to determine Greve's preferred key, so fingerprint was omitted for Greve.

repentinus closed this issue

2020-10-01 01:01:47 +00:00

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: FSFE/fsfe-website#50