- [Update the table of contents](#update-the-table-of-contents)
- [Download](#download)
- [Get the public key](#get-the-public-key)
- [Download the repository](#download-the-repository)
- [Check the signature](#check-the-signature)
- [Run the checksums](#run-the-checksums)
- [Extract](#extract)
- [Software](#software)
- [fpyutils](#fpyutils)
- [Repository](#repository)
@ -35,10 +39,11 @@ permalink: /software/
This page is the only *real* trusted source of some of my software.
Here you will find methods to assert the authenticity of the presented software packages. You may contact me directly
to obtain a copy of the public key(s) used for the signatures.
to obtain a copy of the public key(s) used for the signatures, instead of downloading them
from here.
The following extract is from a [post by Mike Gerwitz](https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits#trust):
> Git Host
>>
>> Git hosting providers are probably the most easily overlooked trustees—providers like Gitorious, GitHub, Bitbucket, SourceForge, Google Code, etc. Each provides hosting for your repository and “secures” it by allowing only you, or other authorized users, to push to it, often with the use of SSH keys tied to an account. By using a host as the primary holder of your repository—the repository from which most clone and push to—you are entrusting them with the entirety of your project; you are stating, “Yes, I trust that my source code is safe with you and will not be tampered with”. This is a dangerous assumption. Do you trust that your host properly secures your account information? Furthermore, bugs exist in all but the most trivial pieces of software, so what is to say that there is not a vulnerability just waiting to be exploited in your host’s system, completely compromising your repository?
@ -47,11 +52,19 @@ The following extract is from a [post by Mike Gerwitz](https://mikegerwitz.com/2
