Some users want to be extra sure they've gotten a proper version of ThinLinc and not something malicious. Our downloads are protected by TLS, but for some that is not enough as a browser trusts a lot of CAs and compromise of any one could lead to an attack.
These users would like something that is cryptographically signed to use as verification. They can then take extra steps to verify the key initially, but every download after that can be verified simply by checking the signature.
(One such extra step could be to download the key from multiple locations around the world, since it is unlikely an attacker is able to intercept connections at every location)
What to sign is still undecided. It could be the packages (see bug 2960) themselves. However that mostly works for RPM as DPKG doesn't have the same signature infrastructure, instead opting for signing the repositories. It could also be signing a file containing hashes of the software.
For reference, here is how Ubuntu does it:
A redhat system in fips mode will also not accept unsigned or poorly signed packages. That is one reason to sign the packages themselves.
Note that simply signing our packages will not help for most users as they will not have that key as a trusted key. So this feature will most likely only be for users willing to do some extra steps to verify things.