Windows auto-update

TheBlueMatt commented at 9:11 pm on June 13, 2012: member

Via gitian-downloader. Expects gitian-updater.exe to be available at $INSTDIR/gitian-updater/gitian-updater.exe and gpg2.exe at $INSTDIR/gitian-updater/GnuPG/gpg2.exe. Moves bitcoin to $INSTDIR/Bitcoin ie C:\Program Files\Bitcoin\Bitcoin\bitcoin-qt.exe

gitian-updater.exe is distributed in binary form, built via cx_Freeze, meaning it depends on the security of python binaries from http://python.org/ , cx_Freeze binaries from http://cx-freeze.sourceforge.net/ and pyyaml from http://pypi.python.org/pypi/PyYAML . gpg2.exe is in binary form from http://www.gpg4win.org/download.html .

Also depends on https://github.com/bitcoin/bitcoin.org/pull/38

laanwj commented at 9:33 pm on June 13, 2012: member

I think this needs a command-line argument to enable/disable.

Apart from that, great!

in src/qt/bitcoingui.cpp: in ca3439d261 outdated

392@@ -389,6 +393,36 @@ void BitcoinGUI::setWalletModel(WalletModel *walletModel)
393     }
394 }
395 
396+void BitcoinGUI::CheckForUpdate()

laanwj commented at 9:37 pm on June 13, 2012:

I don’t think this code belongs in the main dialog. Can we move it to updatedialog.cpp and make the functionality self-contained?

TheBlueMatt commented at 10:45 pm on June 13, 2012:

Ok, did it in a much more contained way, though I have to say delete this; is pretty ugly…

TheBlueMatt commented at 10:46 pm on June 13, 2012: member

In terms of a command-line argument to disable, Id really rather not. You can click no, and ignore the update until you next restart, but I really prefer to force people who refuse to upgrade to suffer the nagging.

laanwj commented at 5:22 am on June 14, 2012: member

I agree in principle. However, there may be reasons why someone wouldn’t want a cleartext http requrest to bitcoin.org going out every time they start bitcoin. Especially as the configured proxies are not used by Qt HTTP, so someone doing everything else through TOR would still “leak” this.

(of course it’d be even better to add proxy support into everything, but for now it’s less hassle to add an option, maybe have it disabled by default if tor is used, otherwise always enabled)

Diapolo commented at 6:24 am on June 14, 2012: none

Great idea, can’t comment on the current implementation, as I didn’t yet try this.

This only works for the installed version not the zipped one? What is gitian-downloader, does this need to be installed on the local machine (seems a little weird to me as Win user)? Is it possible to use HTTPS, as I would not like an auto-connect via HTTP every-time I start my Bitcoin-Qt or I would like to see the update-check disableable.

laanwj commented at 9:54 am on June 14, 2012: member

Qt supports https (you need to provide your own certificates though), however the problem is that bitcoin.org does not as it’s hosted on sourceforge.

I don’t think https is important here. It’s not about the data going over the connection, which is pretty boring, just a bunch of version numbers (I guess we could ECDSA sign the data if authenticity is important in the face of man-in-the-middle attacks). Even with encryption, basic traffic analysis can see that you’re connecting to bitcoin.org.

TheBlueMatt commented at 12:30 pm on June 14, 2012: member

I dont think its worth encrypting as even if someone MITM-attacks, the worst they can do is make you download the latest gitian zip, which gitian will immediately realize either isnt properly signed (assuming MITM) or not a new version and will discard it. This will work for any bitcoin, as long as you put gitian-downloader in the right place (the installer does it by default, the zip version does not contain the gitian-downloader files). Ill add proxy support to the check, but I really dont like the idea of allowing people to disable the version check…this is meant to address the upgrade-apathy a ton of bitcoin users have.

in src/qt/updatedialog.cpp: in a77fba6e45 outdated

28+    {
29+        // File is three lines:
30+        //  first line is the current highest version in CLIENT_VERSION format
31+        //  second line is the current highest version in human-readable format
32+        //  third line is the minimum version considered "secure" in CLIENT_VERSION format
33+        QList<QByteArray> list = reply->readAll().split('\n');

laanwj commented at 12:36 pm on June 14, 2012:

Maybe use ->read(MAX_UPDATE_INFORMATION_SIZE) here instead of ->readAll(); I agree that MITM attacks cannot inject any useful information, but they could be used to DDoS by sending a very large response.

TheBlueMatt commented at 1:24 pm on June 14, 2012: member

Updated.

in src/qt/updatedialog.cpp: in f1cf39b523 outdated

25+
26+void UpdateDialog::handleURLReply(QNetworkReply* reply)
27+{
28+    if(reply->error() == QNetworkReply::NoError && reply->isReadable() &&
29+       reply->attribute(QNetworkRequest::HttpStatusCodeAttribute) == 200 &&
30+       reply->bytesAvailable() < 1025)

laanwj commented at 1:30 pm on June 14, 2012:

I don’t think checking the number of bytes currently available is correct. “reply” is a stream-like object, and it is very possible that no bytes are available, but they will come in later (or, in case of a HTTP response without Content-Length header, when the total length isn’t even known in advance).

We should restrict the number of bytes read, not the number of bytes available.

(see http://qt-project.org/doc/qt-4.8/qiodevice.html:

0You can call bytesAvailable() to determine the number of bytes that are currently available for reading.

)

TheBlueMatt commented at 1:58 pm on June 14, 2012:

handleURLReply is only called with the request is “finished()” so the bytes available here is the total that is available as the connection at this point is finished.

laanwj commented at 2:10 pm on June 14, 2012:

So Qt already reads all the data to determine how many bytes are available, before emitting the finished signal? That’s scary, and I’d say unlikely, but I cannot find anything definitive about this in the documentation.

Usually, with HTTP libraries, a callback is made when the HTTP reply has been read. The payload is still an unread stream at that point. This is to support, for example, streaming internet radio, in which case “infinite” bytes are available, and it’s impossible to read them all into a buffer before calling a callback…

TheBlueMatt commented at 2:34 pm on June 14, 2012:

Meh, just went with read(100)

Diapolo commented at 2:32 pm on June 14, 2012: none

As Windows-User I really would hate to see an Auto-Update that I can’t disable … even worse if I had to kill that gitian-downloader to “disable” it. I’m fine with an info message that there is a new version available and an opt-in to always allow an auto-update.

TheBlueMatt commented at 2:34 pm on June 14, 2012: member

You can disable it. It only asks you if you want to upgrade, it doesnt force you to.

laanwj commented at 2:40 pm on June 14, 2012: member

If you implement proxy support it’s ok with me, no need to also have a disable option. Polling and asking is harmless. My only objection was the ’leaking'.

TheBlueMatt commented at 2:50 pm on June 14, 2012: member

It has proxy support

laanwj commented at 2:53 pm on June 14, 2012: member

Right, cool.

Diapolo commented at 4:11 pm on June 14, 2012: none

@TheBlueMatt Sorry, I really thought this would enforce updates :D.

in src/qt/forms/updatedialog.ui: in 06d05deaaf outdated

27+     <weight>75</weight>
28+     <bold>true</bold>
29+    </font>
30+   </property>
31+   <property name="text">
32+    <string>&lt;html&gt;&lt;head/&gt;&lt;body&gt;&lt;p&gt;An update is available for Bitcoin-Qt.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;</string>

Diapolo commented at 4:16 pm on June 14, 2012:

Can you please remove HTML here, this leads to confusion on Transifex. Just the string “An update is available for Bitcoin-Qt.” will do it :).

TheBlueMatt commented at 4:17 pm on June 14, 2012:

Heh, sorry Qt Creator did that…

in src/qt/forms/updatedialog.ui: in 06d05deaaf outdated

85+     <width>271</width>
86+     <height>16</height>
87+    </rect>
88+   </property>
89+   <property name="text">
90+    <string>&lt;html&gt;&lt;head/&gt;&lt;body&gt;&lt;p&gt;&lt;a href=&quot;http://en.bitcoin.it/wiki/Changelog&quot;&gt;http://en.bitcoin.it/wiki/Changelog&lt;/a&gt;&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;</string>

Diapolo commented at 4:19 pm on June 14, 2012:

This needs to be untranslatable and the option openExternalLinks activated. You can then use <a href="http://en.bitcoin.it/wiki/Changelog">http://en.bitcoin.it/wiki/Changelog</a> as the string.

in src/qt/forms/updatedialog.ui: in d8f2f5690c outdated

69+     <width>381</width>
70+     <height>41</height>
71+    </rect>
72+   </property>
73+   <property name="text">
74+    <string>&lt;html&gt;&lt;head/&gt;&lt;body&gt;&lt;p&gt;&lt;span style=&quot; color:#ff0000;&quot;&gt;Warning: the above update is a security update. In order to protect your security, it is highly recommended that you upgrade immediately.  See the changelog for more information.&lt;/span&gt;&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;</string>

Diapolo commented at 4:20 pm on June 14, 2012:

You should use QLabel { color: red; } as styleSheet and also remove the HTML parts and just input the raw string.

Diapolo commented at 4:25 pm on June 14, 2012: none

I’m asking myself, if your chosen layout will stay the way you intended it to be, when resizing the window. It would perhaps be a good idea to chose a verticalLayout with some horizontalLayout objects. Yes this is not coding related, but I’m always behing a clean and good UI :D.

in src/qt/optionsmodel.cpp: in d8f2f5690c outdated

303@@ -304,3 +304,36 @@ bool OptionsModel::getDisplayAddresses()
304 {
305     return bDisplayAddresses;
306 }
307+
308+QNetworkProxy OptionsModel::getProxy()

Diapolo commented at 4:30 pm on June 14, 2012:

Is the QNetworkProxy IPv6 ready?

laanwj commented at 4:49 pm on June 14, 2012:

In principle, yes, Qt supports IPv6. However that doesn’t matter now – bitcoin.org isn’t on IPv6.

Diapolo commented at 4:54 pm on June 14, 2012:

It does matter … if one sets an IPv6 proxy address to use for connecting.

in src/qt/updatedialog.cpp: in d8f2f5690c outdated

60+        QMessageBox::critical(this, tr("Error updating"),
61+                              tr("Could not find gitian-updater.exe at ") + basePath + "\\..\\gitian-updater\\gitian-updater.exe");
62+        QDialog::accept();
63+        return;
64+    }
65+    QFileInfo info2(basePath + "\\..\\gitian-updater\\GnuPG\\gpg2.exe");

Diapolo commented at 4:32 pm on June 14, 2012:

You set info2 here, but use info below … why not just re-use info?

laanwj commented at 4:53 pm on June 14, 2012:

Why? It’s a new file, so let’s use a new object. There’s no need to be conservative with variable usage, better be explicit, for example info_gpg and info_gitian. (the next line does have a problem, as it re-checks info.isExecutable() instead of info2.isExecutable() )

Diapolo commented at 4:56 pm on June 14, 2012:

ACK, but it was not used before :D.

TheBlueMatt commented at 4:59 pm on June 14, 2012:

Oops, yea that was a typo, fixed to use info2 the second time.

in src/qt/updatedialog.cpp: in d8f2f5690c outdated

74+    QStringList args;
75+    args << "-g" << basePath + "\\..\\gitian-updater\\GnuPG\\gpg2.exe" << "-d" << basePath;
76+    connect(process, SIGNAL(finished(int, QProcess::ExitStatus)), this, SLOT(finishedUpgrade(int, QProcess::ExitStatus)));
77+    QMessageBox::warning(this, tr("Updating"),
78+                         tr("Bitcoin-Qt is now updating in the background."), QMessageBox::Ok);
79+    process->start(basePath + "\\..\\gitian-updater\\gitian-updater.exe", args);

Diapolo commented at 4:33 pm on June 14, 2012:

Does this safely close the current running client and restart it afterwards? Okay, I see that the client closes in finishedUpgrade but now I’m asking myself how that works :D.

in src/qt/optionsmodel.cpp: in d8f2f5690c outdated

303@@ -304,3 +304,36 @@ bool OptionsModel::getDisplayAddresses()
304 {
305     return bDisplayAddresses;
306 }
307+
308+QNetworkProxy OptionsModel::getProxy()
309+{
310+    QNetworkProxy retVal;
311+    QSettings settings;
312+    if (settings.value("fUseProxy", false).toBool())

laanwj commented at 4:38 pm on June 14, 2012:

Will this work in case the proxy was set through the command line?

Diapolo commented at 4:40 pm on June 14, 2012:

I think yes, as in OptionsModel::Init() we take care of this, as command-line options override the GUI settings.

sipa commented at 4:43 pm on June 14, 2012:

GetProxy(NET_IPV4, address) is safer, I think.

TheBlueMatt commented at 4:45 pm on June 14, 2012:

I tried to use the exact same code that was used above in the file to get data for the Options Dialog.

Diapolo commented at 4:50 pm on June 14, 2012:

That would use the set proxy, so no need to check if it’s a GUI option or comman-line option as it IS the current one, sounds good to me. But stilly my IPv6 question :D. Is Qt ready for it?

Well after reading again, Matt is right. Should be safe.

TheBlueMatt commented at 5:00 pm on June 14, 2012:

bitcoin.org has no ipv6 right now, and google turns up nothing interesting for github ipv6 migration, so…

laanwj commented at 5:01 pm on June 14, 2012:

I’m pretty sure that providing a command line option does not change the setting in QSettings, so afaik it will not work. The code to get data for the options dialog reflects the current setting in the Qt settings, not the option actually in use in the core.

We should at last test it.

Diapolo commented at 5:08 pm on June 14, 2012:

You are right, providing it per command-line won’t change it in the options, but as this is for the GUI client, we can be sure that OptionsModel::Init() was called, which leads to to a consistent state, right?

laanwj commented at 5:19 pm on June 14, 2012:

No. Look again. OptionsModel::Init does not change the QSettings. It sets command-line options (using SoftSetArg) based on the QSettings, not the other way around.

TheBlueMatt commented at 5:22 pm on June 14, 2012:

Then that is another bug, the qt options dialog should, at least, show the current settings.

Diapolo commented at 5:27 pm on June 14, 2012:

This really seems like a bug then, as the comment in optionsdialog.cpp reads:

Command-line options should permanently SET GUI options.

laanwj commented at 5:34 pm on June 14, 2012:

Maybe. I think we decided against that last time, and let command-line options temporarily override GUI options. Anyway, this is not the place for that discussion.

TheBlueMatt commented at 5:46 pm on June 14, 2012:

I agree the gui settings shouldnt be permanently set by cli flags, but if you set a setting by a cli flag, the gui should show that setting, and if you change it in the gui thereafter, it should change and be set. Id say thats by far the least surprising behavior.

Diapolo commented at 5:51 pm on June 14, 2012:

… and the most complicated to implement. As the Apply and OK button need to be active then and somehow we need an info message that cli options have overridden the GUI settings. Last comment in this, perhaps one should open an issue to track this.

TheBlueMatt commented at 5:55 pm on June 14, 2012:

Actually the easiest. You dont need to bother informing the user, as they did it. The apply and ok buttons dont need to change, they just need to set the settings as they do now?

TheBlueMatt commented at 5:58 pm on June 14, 2012:

Nope, that is the way it currently works, setting -proxy=… shows up in the GUI as it should.

laanwj commented at 5:49 am on June 15, 2012:

Right, I’ve tested it. This works right for the proxy address, but not for the “proxy use” checkbox. OptionsModel::data confirms this; ProxyIP/ProxyPort query the actual state of the core with GetProxy, whereas ProxyUse and ProxySocksVersion return data from the settings (which may be “behind” the command line setting). This is indeed a bug.

TheBlueMatt commented at 4:42 pm on June 14, 2012: member

Fixed the translation stuff and now you cant resize the window :)

in src/qt/updatedialog.cpp: in dd1dbfa350 outdated

35+        //  second line is the current highest version in human-readable format
36+        //  third line is the minimum version considered "secure" in CLIENT_VERSION format
37+        QList<QByteArray> list = reply->read(100).split('\n');
38+        if (list.size() > 2 && clientModel->clientVersion() < list[0].toInt())
39+        {
40+            ui->securityUpdateLabel->setVisible(list[2].toInt() > clientModel->clientVersion());

Diapolo commented at 4:52 pm on June 14, 2012:

I think it would be rather cool to display the changelog in the update Window :). Should be possible. But that’s perhaps an idea for another commit.

in src/qt/updatedialog.cpp: in dd1dbfa350 outdated

70+        QMessageBox::critical(this, tr("Error updating"),
71+                              tr("Could not find gpg2.exe at ") + basePath + "\\..\\gitian-updater\\GnuPG\\gpg2.exe");
72+        QDialog::accept();
73+        return;
74+    }
75+    process = new QProcess();

laanwj commented at 4:55 pm on June 14, 2012:

Instead of repeating the path, which is error prone if we want to change it later, you could use info2.filePath(). Or define a constant.

luke-jr commented at 7:21 pm on June 15, 2012: member

Binaries don’t belong in git. Provide a link to the gitian build instructions and make them an input.
Moving Bitcoin-Qt to a new subdirectory under its own program directory is silly. Why can’t it stay where it is?
Why remove the RSS thing?
Shouldn’t link to SourceForge for Linux distros with proper package management. How about a qmake option to show another (HTML-formatted) message?

TheBlueMatt commented at 8:15 pm on June 15, 2012: member

Meh, no they dont really, but building the cx_Freeze gitian-updater in gitian is a huge change…you would have to build the full list of binaries in that list in gitian, including python and gpg. But feel free to do that.
because gitian requires a destination dir to install to.
Because it requires yet another binary dep, and this one doesnt have official binaries.
None of this effects Linux.

luke-jr commented at 8:29 pm on June 15, 2012: member

or just use the official Python and GPG binaries from their websites as inputs
$INSTDIR works fine for that…?
I don’t see any #ifdefs…?

TheBlueMatt commented at 8:43 pm on June 15, 2012: member

Admittedly haven’t tried (because I dont have gitian), though I would doubt they are deterministic.
The current gitian files dont output a gitian-updater. If they were changed to do so, we could use $INSTDIR for the target, as it stands, we cannot.
https://github.com/bitcoin/bitcoin/pull/1453/files#L30R288

luke-jr commented at 8:48 pm on June 15, 2012: member

We already use non-deterministic official Ubuntu binaries.
IMO they should.

TheBlueMatt commented at 9:00 pm on June 15, 2012: member

The launchpad ppa isnt official.
Fair enough, but, again, as I dont have gitian right now, there isnt much I can do there.

luke-jr commented at 9:01 pm on June 15, 2012: member

I was referring to all the gitian builds.

Diapolo commented at 9:14 pm on June 15, 2012: none

I love the update-idea, but I dislike that whole dependencies … wouldn’t it be a nice start to receive a notification for new updates, with a changelog and a direct download link displayed?

TheBlueMatt closed this on Jun 16, 2012

laanwj commented at 6:20 am on June 16, 2012: member

I really think this is fine now. Things can be improved later.

luke-jr commented at 6:25 am on June 16, 2012: member

IMO, the way this is right now completely defeats the point of gitian and permanently bloats the git repository… until that is fixed (at least by moving the non-deterministic dependencies to gitian inputs), it really seems not having it at all is an improvement.

laanwj commented at 6:31 am on June 16, 2012: member

Well yes big executables do not need to be in the git repository, and could be moved to some other place (just keep their hashes in the repository to check during build that you have the right files). Apart from that I think BlueMatt is on the right track and we need to go on with this.

Using gitian-downloader is much safer than just displaying a download link. That’d basically be a joke asking for MITM attacks. As we’ve seen with Flame et al, hijacked autoupdaters are no hypothetical risk.

in src/qt/updatedialog.cpp: in 7b8ca2a89e outdated

31+       reply->attribute(QNetworkRequest::HttpStatusCodeAttribute) == 200)
32+    {
33+        // File is three lines:
34+        //  first line is the current highest version in CLIENT_VERSION format
35+        //  second line is the current highest version in human-readable format
36+        //  third line is the minimum version considered "secure" in CLIENT_VERSION format

luke-jr commented at 4:41 pm on June 16, 2012:

This is way too simplistic. 0.4.7 is secure, but 0.5.0 isn’t.

TheBlueMatt commented at 4:43 pm on June 27, 2012:

For users on the main branch, thats fine. For users on a stable branch, the stable branch’s file can provide information on which versions in that branch are or are not secure.

in src/qt/updatedialog.cpp: in 7b8ca2a89e outdated

19+
20+    mNetworkManager = new QNetworkAccessManager(this);
21+    mNetworkManager->setProxy(clientModel->getOptionsModel()->getProxy());
22+    connect(mNetworkManager, SIGNAL(finished(QNetworkReply*)), this, SLOT(handleURLReply(QNetworkReply*)));
23+
24+    QUrl url("http://bitcoin.org/latestversion.txt");

luke-jr commented at 4:44 pm on June 16, 2012:

bitcoin.org is vendor-neutral, and shouldn’t contain any Bitcoin-Qt specific stuff any more than specific wiki/forums/etc
For automated updates, this should point to a branch-specific file such as latest-0.6.txt or similar; another line (or file?) can be used to recommend upgrading across branches

TheBlueMatt commented at 4:43 pm on June 27, 2012:

put it wherever, I dont care
It is assumed that people on the mainline branch wish to upgrade with the mainline branch. For people on stable branches, I would say you should rename the above line to point to a stable-specific file.

TheBlueMatt reopened this on Jun 27, 2012

TheBlueMatt closed this on Jun 27, 2012

TheBlueMatt reopened this on Jun 27, 2012

mikehearn commented at 11:01 am on July 1, 2012: contributor

I just wanted to say thanks for doing this. It’s hugely important.

FWIW, we’re starting to look at something similar for bitcoinj based apps and will likely just check the compiled dependencies into git. We’re more concerned about somebody inserting a backdoor into an upstream compiled JAR though, so the threat model is a bit different.

Diapolo commented at 1:52 pm on July 1, 2012: none

Are we somewhere telling the user that we are installing gitian-updater binaries? I think we should ensure the whole process is as transparent as possible.

What happens, when there is a security flaw in the gitian-updater itself, are we then shipping new versions of it automatically, too?

Edit: What happens to the stand-alone version (Zip-file)? The update-code is in there too, but it won’t work as there is no gitian-updater installed on those machines.

Fix Bitcoin-Qt proxy settings to always display the current setting 22e96a1aee

TheBlueMatt commented at 10:04 pm on July 1, 2012: member

Im not so sure people a. really care what the underlying updater we are using is or b. care to research how we are installing it. If anyone is looking into the inner workings of bitcoin-qt, its all very clearly documented in the source…
If bitcoin-qt finds a gitian-updater folder installed to where it is, it will move that up to the gitian-updater it uses. The gitian scripts don’t yet support it, but if we ever need it, it wont be hard. We cant just run from the gitian-updater in the Bitcoin dir, as windows doesn’t let you replace exes while they are running (AFAIK).
for stand-alone users, they will get the update available popup, and then an error about missing gitian-updater, which I think is the appropriate result. You could update their installs too, but I dont really like touching a stand-alone copy. Also, if the update succeeds, it will update the windows registry with the new version installed, which defeats the purpose of the stand-alone portable version.

Add support for auto-updating to Bitcoin-Qt on Windows. 1ca7ee2c40

Update bitcoin version in registry after update. 7c9bbbada3

Update release-process.txt instructions. a633bc9e6e

Change Bitcoin-Qt install path to $INSTDIR\Bitcoin. 2da1cf95e4

Remove RSS and add Sourceforge link to win32 download config. fd32549850

Install gitian-updater binaries. f1c27f90d5

BitcoinPullTester commented at 11:42 pm on August 9, 2012: none

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/f1c27f90d5b7acf58645761b903d0539930ec78e for test log.

This pull does not merge cleanly onto current master

TheBlueMatt commented at 1:43 am on September 5, 2012: member

Closing for lack of interest.

TheBlueMatt closed this on Sep 5, 2012

laanwj commented at 5:31 am on September 5, 2012: member

I don’t agree with closing this. It’s still nice to have once the issues get resolved.

To prevent binaries in the repo we could put the binaries in a specific repo, or eventually build them with gitian too…

mikehearn commented at 11:22 am on September 5, 2012: contributor

I’m interested. Auto-update is still very important.

TheBlueMatt commented at 3:02 pm on September 5, 2012: member

@laanwj afaik there were no remaining issues. There are no binaries in this pull. s/lack of interest/lack of ACKs/

luke-jr commented at 3:39 pm on September 5, 2012: member

Only one remaining issue AFAIK: it still hijacks bitcoin.org for client-specific stuff.

Doesn’t SourceForge have a direct-download webspace?

gmaxwell commented at 5:35 pm on September 5, 2012: contributor

I’m interested too— though as not a windows user I can’t contribute much except blather. In spite of the many cautions and concerns I’ve raised, I think update facilities are very important. Right now it takes forever to get a fix widely deployed and when people finally do update the overwhelming majority of them just pull some file off a website and do nothing to verify its authenticity. This is a very bad situation and improving it is important.

laanwj reopened this on Sep 5, 2012

gavinandresen commented at 11:15 pm on November 10, 2012: contributor

Matt: can you put together a little whitepaper, written for somebody who won’t read the code, explaining how this works? Something like:

Every startup (shutdown? day? week?), by default Bitcoin-Qt (?)…. fetches something from somewhere ?
If that something says that there is a new version, then… ?gitian-updater is run ? After shutdown or before next startup or… ?
gitian-updater… fetches a new binary and signatures, then makes sure the binary corresponds to the signatures and that the signatures ?match a list of built-in signatures ?

A discussion of possible attacks (MITM intercepts fetching of ’latestversion’… binary on the server gets replaced… are there any other interesting attacks?) would also be helpful.

I’d find that very useful, and I think so would users who are going to be very suspicious of this feature.

TheBlueMatt commented at 6:56 pm on November 21, 2012: member

Note first that this needs rebased quite a bit, if people are interested in merging, I can do it. Not sure where you want this, but here goes:

Every application launch (maybe it should be week…) Win32 versions of Bitcoin-Qt will download http://bitcoin.org/latestversion.txt and compare its contents with the version currently in use. If an update is found, a dialog box appears informing the user that a new update is available (possibly with a note that the version currently in use is considered somehow “insecure”). Iff the user decides to upgrade, gitian-updater is launched which then downloads the new version (via a hardcoded path) and verifies signatures. If the newly downloaded version has valid signatures from at least 3 developers, the installed files are replaced with the new version and, when the process is complete, the user is notified and Bitcoin-Qt is restarted. Note that the auto-upgrade system will not work on non-installed versions of Bitcoin, however the upgrade available dialog will still appear.

Potential Attacks:

If bitcoin.org is compromised or otherwise gets bogus data, it is possible that the attacker can make users see the upgrade available dialog box, however, even if the user opts to upgrade, the process will simply download the “new version” and fail when verifying signatures, deleting the new data.
There has been discussion of making gitian-updater quarantine new upgrades for some period, during which a list of people can sign “NACKs” which signify that they have found an issue in the upgrade. Though there was some consensus on implementing something like this system, there was never any implementation and a consensus on exact details was never reached (AFAIR).

mikehearn commented at 11:13 am on November 22, 2012: contributor

It’s really cool and important. My only comment - have the download and checking of the new version happen in the background before the user is notified. Then the user can simply be told there WILL be an upgrade and the node can restart very quickly. This is usually a better ux because otherwise users tend to cancel updates on the grounds that they don’t want to wait or be interrupted at some random future point.

Diapolo commented at 12:25 pm on November 22, 2012: none

@mikehearn I would vote for at least a one time informational message that the client will behave that way (for installed versions only) or even a possibility to opt-out of background-updates and make it an explicit check. I really dislike all that crappy update services that todays software uses / installs without letting me now what they intend to do in the background.

jonasschnelli commented at 6:35 pm on May 7, 2013: contributor

would this somehow also works for mac?

ghost commented at 7:14 pm on May 7, 2013: none

Could someone please review this PR, I think it’s quite an important feature for the longevity of the bitcoin ecosystem, especially as we get more users. Being able to quickly upgrade the ecosystem to new protocol version in a timely fashion is essential. refs #2626

gmaxwell commented at 7:54 pm on May 7, 2013: contributor

@drak Why so interested? Someone give you an exploit against the sourceforge download site? :p

ghost commented at 8:38 pm on May 7, 2013: none

@gmaxwell - no idea what you are talking about, given bitcoin protocol lives by having a majority of a given version, it’s imperative as the ecosystem grows that the network can upgrade. It makes sense to at least have the client inform users of a new download being available. I would not rely on something like sourceforge either, possibly have the version string stored on a github repo hosted page - that way there is version integrity,

TheBlueMatt commented at 8:44 pm on May 7, 2013: member

@drak If you want to get this merged, I’m sure it needs tons of updates, so feel free to help out :)

TheBlueMatt closed this on May 7, 2013

ghost commented at 8:47 pm on May 7, 2013: none

Sorry, C programmer I am not unfortunately, or I would do it.

Diapolo commented at 8:51 pm on May 7, 2013: none

I need to ask, if we are aware of a certain version containing a security problem, do we issue an alert that all those clients receive and urge to update or are we just doing this “sometimes” (for a massive problem for example)?

suprnurd referenced this in commit 3efcb755e3 on Dec 5, 2017

lateminer referenced this in commit 786c1d18c5 on Jan 22, 2019

lateminer referenced this in commit 195d46690c on May 6, 2020

DrahtBot locked this on Sep 8, 2021

Windows auto-update #1453