Update checker #2626

issue ghost openend this issue on May 7, 2013
  1. ghost commented at 3:24 pm on May 7, 2013: none

    I think it would be good the the ecosystem if at least the GUI client had client version update checker to notify users when a new version is released. Doesnt have to be a full on auto-update, just an update checker and notify user new version is available.

    Suggestion is to use the RAW feature of github to host the latest version at github.com/bitcoin.org, something this:

    https://raw.github.com/bitcoin/bitcoin.org/master/README.md which makes use of both SSL and git versioning (which makes it not only difficult to change, but tamper evident).

  2. laanwj commented at 6:16 pm on May 7, 2013: member
    There’s code for that in this pull request (it’s a fully-fledged auto updater actually) #1453
  3. ghost commented at 8:54 pm on May 7, 2013: none
    If I could just suggest a really simply implementation for the time being. Use have a simple latest_version.txt stored on bitcoin.org with the version number. When the bitcoin client loads it can query this file and do a version compare and then notify the user. The command line client could write out message to the console (on startup) if that’s OK to do.
  4. sipa commented at 9:00 pm on May 7, 2013: member

    In general we are very ware about depending on centralized services in the reference client. The result of someone hijacking github, controlling people’s connections, or holding one of the developers with access at gunpoint could be very problematic. Of course, that problem exists now too, but without mechanism to explicitly push out new releases, such an attempt would be delayed significantly.

    The plan for auto-updating involved requiring several independent signatures from developers (and perhaps others), including the ability to sign a message against a particular version. This would make such an attack much harder, but also complicates the implementation of an auto-update scheme.

  5. gmaxwell commented at 9:35 pm on May 7, 2013: contributor

    @drak Because you push a malicious version, and then update the autoupdate notice and then very rapidly you have stolen the wallets of tens of thousands of people before anyone clueful has had a chance to notice.

    So far we’ve had pretty good adoption rates of new versions— this hasn’t been a major problem (http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html). And we can use the alert system if there is something urgent. The alert system also has the benefit that if the key is compromised something actually can be done about a malicious alert.

  6. Diapolo commented at 5:30 pm on May 8, 2013: none
    I would say this is not that bad compared to the Windows systems vulnerable because of outdated Java Runtimes or Flash Player versions. But you ARE right, this percentage should be way lower!
  7. laanwj commented at 9:03 am on May 9, 2013: member

    @drak With your simple implementation there is the problem of bitcoin.org still not supporting HTTPS, so it would be trivial to MITM. This is not so much a problem for the version notice itself, but if you refer them to that site to download a new version they will download a potentially infected client from the attacker.

    I remember some FinFisher scandal in which they pushed fake updates (to some software already on the user’s computer) to install malware, so this threat is not hypothetical. And even with SSL it would still be relying on a single point of failure…

    For any auto-update, the client has to do the downloading + dev signature verification at least. Installation should be left to the user voluntarily (ie, “this is the list of changes, click here if you want to upgrade”) .

    Maybe we could use a form of signing that does not require a complete GPG to be packaged? Or is there some lightweight library that allows verifying GPG signatures?

  8. laanwj commented at 10:50 am on May 9, 2013: member
    Read my other point; even adding SSL does not solve the problem. It should also add an independent mechanism to check the developer’s signatures.
  9. jonasschnelli commented at 1:56 pm on May 13, 2013: contributor

    my (maybe stupid) suggestion would be: -> deliver new clients with multiple developers (at least 3) GPG public key/cert -> deliver new clients with one bitcoin “official” public key -> create a centralized rss feed somewhere (example bitcoin.org) -> the rss feed contains multiple items which all represent one update/version. -> each update/version has multiple binary locations (URLs). Could be sourceforge, etc. (round robin, take next when one is not available) -> each update/version has a hash of the binary signed with the “bitcoin official” key -> each update/version has multiple developers signatures (at least 3). -> rss feed will be used to determine if a update is available

    During update: -> Binary will be downloaded -> Binary will be changed/verified against local available developers public key (at least 3) -> Binary will be changed/verified against local available bitcoin official key -> Binary will be extracted -> (some optional checks) -> Binary, etc. will be replaced -> Bitcoin client will be relaunched.

    Potential attacks: -> Someone could compromise the RSS feed. But without developers and “bitcoin official” private keys, hacked binaries will not get installed -> Someone could compromise a binary at sourceforge, etc. But it wont get installed because of invalid binary hashes. -> Someone changes local installed public keys (trojan) and also changes the RSS feed (by hacking the installed binary and changing the RSS URL or compromising the remote RSS Feed).

    MITM should not be possible (or at least they would need a lot of effort).

    Deployment: -> when having a final RC, the releasemanager could send the binary to different developers to get the signature in return. The signature then must be included in the RSS feed.

    Problems: -> The deployment process might gets more complex.

  10. MorbZ commented at 3:50 pm on January 25, 2014: none
    If relying on centralized services is not an option you could add version detection by checking what version messages other clients send. Together with some statistical analysis, e.g. when >= xx% of the last 100 connected clients send a version header higher than the version of the running client, show an alert that states that the running clients version may not be the latest version.
  11. gmaxwell commented at 3:54 pm on January 25, 2014: contributor
    Thats really easy to trigger as a nuisance though.
  12. sipa commented at 4:56 pm on January 25, 2014: member

    Clients don’t expose their version number to the network (only protocol version), and even if they did it would be trivial to lie about this.

    This would augment a sybil attack to a remote code execution …

    In general, Bitcoin full nodes are designed not to require trust in any peer for almost all of its decisions. Let’s keep it that way.

    EDIT: If it’s not full auto-update it’s technically not remote code execution, but I’m not convinced there is much difference in practice.

  13. MorbZ commented at 7:11 pm on January 25, 2014: none
    The original client sends something like “Satoshi:0.8.6”, so I assume they expose their version. It’s not about trusting anyone, just give the user a hint that many/most of the other clients use a higher version, no further action involved. If such a notification would be shown once per new version (ignoring RC) and assuming there is no large-scale version faking (from which no one would benefit) that alert would come up every 1-2 month (based on recent releases). Not that much of a nuisance I think.
  14. handsomegui commented at 3:39 am on September 12, 2014: none
    It’s been over one year later, what’s new on this topic?
  15. TheBlueMatt commented at 3:50 am on September 12, 2014: member
    Someone probably needs to implement gitian-downloader in a binary-limited way on Windows, plus implement NAKs.
  16. laanwj added the label Feature on Jan 29, 2016
  17. laanwj removed the label Priority Medium on Jan 29, 2016
  18. laanwj removed the label Refactoring on Jan 29, 2016
  19. MarcoFalke added the label Brainstorming on Oct 23, 2018
  20. MarcoFalke removed the label Feature on Oct 23, 2018
  21. MarcoFalke commented at 1:59 pm on October 14, 2019: member

    Bitcoin Core is probably not the right place to put this functionality and there already exist a bunch of solutions outside of Bitcoin Core:

  22. MarcoFalke commented at 2:00 pm on October 14, 2019: member
    Unless there are objections, I am going to close this issue as out-of-scope in about four weeks.
  23. MarcoFalke closed this on Oct 30, 2019
  24. MarcoFalke locked this on Dec 16, 2021


ghost laanwj sipa gmaxwell Diapolo jonasschnelli MorbZ handsomegui TheBlueMatt MarcoFalke

Labels
Brainstorming

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-22 00:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me