Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#6094 closed Enhancement (fixed)

Provide SHA256 Hashes on alternative site

Reported by: cfpp2p Owned by: John Clay
Priority: Normal Milestone: None Set
Component: Website Version: 2.92
Severity: Normal Keywords:
Cc:

Description

Providing SHA256 hashes for the release downloads on an alternative site would improve the security of the hashes.

Change History (8)

comment:1 Changed 2 years ago by John Clay

I agree with this in principle, but I'm not sure how we'd do it in a tamper-proof/resistant way.

We could link to another site that we control, but in the event the primary server is compromised that link could just be altered to point to a server that the attacker controls.

Any ideas?

Last edited 2 years ago by John Clay (previous) (diff)

comment:2 Changed 2 years ago by John Clay

  • Status changed from new to assigned

comment:3 Changed 2 years ago by cfpp2p

comment:4 Changed 2 years ago by John Clay

I like the that idea - the hashes are now links to the respective files on virustotal.com. It's not the prettiest arrangement, so still open to ideas for how to make a nicer design.

Last edited 2 years ago by John Clay (previous) (diff)

comment:5 Changed 2 years ago by John Clay

https://trac.transmissionbt.com/wiki/PreviousReleases has also been updated with SHA256 hashes/links.

comment:6 Changed 2 years ago by John Clay

  • Resolution set to fixed
  • Status changed from assigned to closed

Closing this for now, but please re-open if anyone has suggestions for improvement.

comment:7 Changed 2 years ago by wtfftw

  • Priority changed from Normal to High
  • Severity changed from Normal to Critical

Are you kidding or what? Digital signatures were invented like 20+ years ago and you do not have to keep private key on the same server as public key and signature/hashes.

So what is suggested: 1) Audit your infrastructure and practices. I guess people really want to know how malware hit you and what you've done to prevent same or other problems in future.

2) Learn to use tools like pgp/gpg, create well-known key people can use to verify your releases and use it to sign hashes. Store private key password-protected and keep it on e.g. detachable media, only plug and use it to sign release hashes. This way hackers would have hard time to steal private keys. Keeping private keys and certs in way they are available to hackers or malware is silly. This way we can be sure some particular person has signed particular file and considers self responsible for what it contains, and nobody else could tamper it without being noticed.

3) Btw, SVN is neither tamper-proof on server side, nor its protocol is protected from hijacking on network side. So I never know if I've got Transmission or some hijacked version instead. To make it even worse, trying to see what has changed between commits is a real pain in the rear in SVN, it suxx when it comes to version control. On other hand, good luck to hijack GIT, who is essentially a hash tree, and could also afford explicit GPG signatures. So trying to hijack sources tracked by git is quite unrewarding idea, to say the least.

To the date I have to admit security of your infrastructure and everything related to trust leave a lot to be desired.

comment:8 Changed 2 years ago by mike.dld

  • Priority changed from High to Normal
  • Severity changed from Critical to Normal
Note: See TracTickets for help on using tickets.