For links that have actually succumbed to bitrot (unlike https://bcnfs.org/ and https://openinventionnetwork.com/), I would recommend marking them as broken on the relevant page (new class broken or whatever and modern CSS features such as :after and content to convey the information). When possible, I would also include an alternative link to a contemporaneous archived version of the page on the Internet Archive's Wayback Machine.
Where the content still exists, typos in the link should be fixed to point to the intended URL.
I recommend prepending a character lexicographically less than any of the alphanumeric characters to the filenames, so ls will list them first.
This was part of my job to create a pr-checklist. It was wished to have a model news-item that explains everyone in a easy-to-understand and easy-to-adapt way how to write a good news-item. It is linked for example from here: https://wiki.fsfe.org/Internal/PublicationChecklist
I would put this example on the wiki page itself using the {{{code}}} syntax. This is documentation that can easily be mistaken for production content intended for publication, so it should not live in the production repository.
Alternatively or additionally the same content could be integrated into the templates of #1346 as XML comments. These would be trivial to remove using grep/sed/awk/vim and would be harmless in any case.
In any case, I recommend closing this pull request without merging into master.
@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).