Bug 7637 - Users cannot verify client/server bundle authenticity
Summary: Users cannot verify client/server bundle authenticity
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on: 2960
Blocks:
  Show dependency treegraph
 
Reported: 2021-02-04 13:23 CET by Pierre Ossman
Modified: 2021-12-16 16:39 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2021-02-04 13:23:14 CET
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.
Comment 2 Pierre Ossman cendio 2021-02-04 13:25:42 CET
For reference, here is how Ubuntu does it:

https://ubuntu.com/tutorials/how-to-verify-ubuntu
Comment 3 Patrik Pira 2021-12-16 14:53:06 CET
A redhat system in fips mode will also not accept unsigned or poorly signed packages. That is one reason to sign the packages themselves.
Comment 4 Pierre Ossman cendio 2021-12-16 15:25:00 CET
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.

Note You need to log in before you can comment on or make changes to this bug.