Our current implementation does not serve the function of verifying that the package comes from us. The main issue is that we ship our public key in-band with the package to be verified, and don't explicitly provide any way of trusting that key. This actually ends up being worse than doing nothing at all, since we now allow for third-party distribution of the server software (bug #8155). This makes it trivial for a malicious actor to distribute a package which can be falsly "verified" as genuine, at least according to the way in which we currently intend our public key to be used. While other approaches may be imperfect, they at least give users a way to determine for themselves how much they trust the key. They also don't provide attackers with an opportunity to exploit an incorrect implementation of PKI (and we avoid the poor optics of promoting one). Such approaches are familiar and commonly used. We should stop shipping our public key in the server bundle, as doing so provides no benefit to users and introduces a potential vulnerability. We can then consider other means of distributing our public key for those users who want to verify the RPM signature.
To facilitate better public key distribution hygiene, I have: - Added the public key fingerprint to the download page: https://www.cendio.com/thinlinc/download/ - Uploaded the public key to the web server: https://www.cendio.com/resources/security/THINLINC-GPG-KEY - Added notes to the release process to update these two when the key is rotated There is also improved documentation around verifying the RPMs landing in the TAG soon. All in all, I think the above three bullet points (and the improved documentation) should be enough to consider this bug fixed.
As of fixing bug 8420 and bug 8421, we deem the main issue in this bug to be fixed as well. These two closed bugs fixes things to a point where the only point that remain is the fact that we ship the public key in the bundle ZIPs. As we no longer mention the existence of this bundled public key in the docs, let's consider that part a WONTFIX and this bug as CLOSED.
