Windows auto-update #1453

Closed
wants to merge 7 commits into
from

Conversation

Projects
None yet
10 participants
Contributor

TheBlueMatt commented Jun 13, 2012

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 bitcoin/bitcoin.org#38

Owner

laanwj commented Jun 13, 2012

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

Apart from that, great!

src/qt/bitcoingui.cpp
@@ -389,6 +393,36 @@ void BitcoinGUI::setWalletModel(WalletModel *walletModel)
}
}
+void BitcoinGUI::CheckForUpdate()
@laanwj

laanwj Jun 13, 2012

Owner

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

TheBlueMatt Jun 13, 2012

Contributor

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

Contributor

TheBlueMatt commented Jun 13, 2012

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.

Owner

laanwj commented Jun 14, 2012

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 Jun 14, 2012

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.

Owner

laanwj commented Jun 14, 2012

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.

Contributor

TheBlueMatt commented Jun 14, 2012

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.

src/qt/updatedialog.cpp
+ // first line is the current highest version in CLIENT_VERSION format
+ // second line is the current highest version in human-readable format
+ // third line is the minimum version considered "secure" in CLIENT_VERSION format
+ QList<QByteArray> list = reply->readAll().split('\n');
@laanwj

laanwj Jun 14, 2012

Owner

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.

Contributor

TheBlueMatt commented Jun 14, 2012

Updated.

src/qt/updatedialog.cpp
+{
+ if(reply->error() == QNetworkReply::NoError && reply->isReadable() &&
+ reply->attribute(QNetworkRequest::HttpStatusCodeAttribute) == 200 &&
+ reply->bytesAvailable() < 1025)
@laanwj

laanwj Jun 14, 2012

Owner

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:

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

)

@TheBlueMatt

TheBlueMatt Jun 14, 2012

Contributor

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

laanwj Jun 14, 2012

Owner

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

TheBlueMatt Jun 14, 2012

Contributor

Meh, just went with read(100)

Diapolo commented Jun 14, 2012

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.

Contributor

TheBlueMatt commented Jun 14, 2012

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

Owner

laanwj commented Jun 14, 2012

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'.

Contributor

TheBlueMatt commented Jun 14, 2012

It has proxy support

Owner

laanwj commented Jun 14, 2012

Right, cool.

Diapolo commented Jun 14, 2012

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

src/qt/forms/updatedialog.ui
+ </font>
+ </property>
+ <property name="text">
+ <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

Diapolo Jun 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

TheBlueMatt Jun 14, 2012

Contributor

Heh, sorry Qt Creator did that...

src/qt/forms/updatedialog.ui
+ </rect>
+ </property>
+ <property name="text">
+ <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

Diapolo Jun 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.

src/qt/forms/updatedialog.ui
+ </rect>
+ </property>
+ <property name="text">
+ <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

Diapolo Jun 14, 2012

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

Diapolo commented Jun 14, 2012

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.

@@ -304,3 +304,36 @@ bool OptionsModel::getDisplayAddresses()
{
return bDisplayAddresses;
}
+
+QNetworkProxy OptionsModel::getProxy()
@Diapolo

Diapolo Jun 14, 2012

Is the QNetworkProxy IPv6 ready?

@laanwj

laanwj Jun 14, 2012

Owner

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

@Diapolo

Diapolo Jun 14, 2012

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

src/qt/updatedialog.cpp
+ QDialog::accept();
+ return;
+ }
+ QFileInfo info2(basePath + "\\..\\gitian-updater\\GnuPG\\gpg2.exe");
@Diapolo

Diapolo Jun 14, 2012

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

@laanwj

laanwj Jun 14, 2012

Owner

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

Diapolo Jun 14, 2012

ACK, but it was not used before :D.

@TheBlueMatt

TheBlueMatt Jun 14, 2012

Contributor

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

src/qt/updatedialog.cpp
+ connect(process, SIGNAL(finished(int, QProcess::ExitStatus)), this, SLOT(finishedUpgrade(int, QProcess::ExitStatus)));
+ QMessageBox::warning(this, tr("Updating"),
+ tr("Bitcoin-Qt is now updating in the background."), QMessageBox::Ok);
+ process->start(basePath + "\\..\\gitian-updater\\gitian-updater.exe", args);
@Diapolo

Diapolo Jun 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.

src/qt/optionsmodel.cpp
+{
+ QNetworkProxy retVal;
+ QSettings settings;
+ if (settings.value("fUseProxy", false).toBool())
@laanwj

laanwj Jun 14, 2012

Owner

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

@Diapolo

Diapolo Jun 14, 2012

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

@sipa

sipa Jun 14, 2012

Owner

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

@TheBlueMatt

TheBlueMatt Jun 14, 2012

Contributor

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

@Diapolo

Diapolo Jun 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

TheBlueMatt Jun 14, 2012

Contributor

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

Diapolo Jun 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

TheBlueMatt Jun 14, 2012

Contributor

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

TheBlueMatt Jun 14, 2012

Contributor

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

@laanwj

laanwj Jun 15, 2012

Owner

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.

Contributor

TheBlueMatt commented Jun 14, 2012

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

+ QList<QByteArray> list = reply->read(100).split('\n');
+ if (list.size() > 2 && clientModel->clientVersion() < list[0].toInt())
+ {
+ ui->securityUpdateLabel->setVisible(list[2].toInt() > clientModel->clientVersion());
@Diapolo

Diapolo Jun 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.

src/qt/updatedialog.cpp
+ QDialog::accept();
+ return;
+ }
+ process = new QProcess();
@laanwj

laanwj Jun 14, 2012

Owner

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.

Member

luke-jr commented Jun 15, 2012

  • 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?
Contributor

TheBlueMatt commented Jun 15, 2012

  1. 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.
  2. because gitian requires a destination dir to install to.
  3. Because it requires yet another binary dep, and this one doesnt have official binaries.
  4. None of this effects Linux.
Member

luke-jr commented Jun 15, 2012

  1. or just use the official Python and GPG binaries from their websites as inputs
  2. $INSTDIR works fine for that...?
  3. I don't see any #ifdefs...?
Contributor

TheBlueMatt commented Jun 15, 2012

  1. Admittedly haven't tried (because I dont have gitian), though I would doubt they are deterministic.
  2. 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.
  3. https://github.com/bitcoin/bitcoin/pull/1453/files#L30R288
Member

luke-jr commented Jun 15, 2012

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

TheBlueMatt commented Jun 15, 2012

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

luke-jr commented Jun 15, 2012

  1. I was referring to all the gitian builds.

Diapolo commented Jun 15, 2012

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?

Owner

laanwj commented Jun 16, 2012

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

Member

luke-jr commented Jun 16, 2012

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.

Owner

laanwj commented Jun 16, 2012

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.

+ // File is three lines:
+ // first line is the current highest version in CLIENT_VERSION format
+ // second line is the current highest version in human-readable format
+ // third line is the minimum version considered "secure" in CLIENT_VERSION format
@luke-jr

luke-jr Jun 16, 2012

Member

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

@TheBlueMatt

TheBlueMatt Jun 27, 2012

Contributor

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.

+ mNetworkManager->setProxy(clientModel->getOptionsModel()->getProxy());
+ connect(mNetworkManager, SIGNAL(finished(QNetworkReply*)), this, SLOT(handleURLReply(QNetworkReply*)));
+
+ QUrl url("http://bitcoin.org/latestversion.txt");
@luke-jr

luke-jr Jun 16, 2012

Member
  1. bitcoin.org is vendor-neutral, and shouldn't contain any Bitcoin-Qt specific stuff any more than specific wiki/forums/etc
  2. 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

TheBlueMatt Jun 27, 2012

Contributor
  1. put it wherever, I dont care
  2. 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 TheBlueMatt reopened this Jun 27, 2012

@TheBlueMatt TheBlueMatt reopened this Jun 27, 2012

Contributor

mikehearn commented Jul 1, 2012

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 Jul 1, 2012

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.

Contributor

TheBlueMatt commented Jul 1, 2012

  1. 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...

  2. 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).

  3. 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.

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

Contributor

TheBlueMatt commented Sep 5, 2012

Closing for lack of interest.

@TheBlueMatt TheBlueMatt closed this Sep 5, 2012

Owner

laanwj commented Sep 5, 2012

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...

Contributor

mikehearn commented Sep 5, 2012

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

Contributor

TheBlueMatt commented Sep 5, 2012

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

Member

luke-jr commented Sep 5, 2012

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

Doesn't SourceForge have a direct-download webspace?

Member

gmaxwell commented Sep 5, 2012

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 laanwj reopened this Sep 5, 2012

Contributor

gavinandresen commented Nov 10, 2012

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.

Contributor

TheBlueMatt commented Nov 21, 2012

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).
Contributor

mikehearn commented Nov 22, 2012

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 Nov 22, 2012

@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.

@laanwj laanwj referenced this pull request May 7, 2013

Open

Update checker #2626

Member

jonasschnelli commented May 7, 2013

would this somehow also works for mac?

@ghost

ghost commented May 7, 2013

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

@TheBlueMatt TheBlueMatt referenced this pull request in bitcoin-dot-org/bitcoin.org Jun 16, 2012

Closed

Add latest version descriptor. #38

Member

gmaxwell commented May 7, 2013

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

@ghost

ghost commented May 7, 2013

@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,

Contributor

TheBlueMatt commented May 7, 2013

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

@TheBlueMatt TheBlueMatt closed this May 7, 2013

@ghost

ghost commented May 7, 2013

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

Diapolo commented May 7, 2013

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)?

@leofidus leofidus referenced this pull request in dogecoin/dogecoin Apr 24, 2014

Closed

Add preference to automatically check for updates #296

suprnurd pushed a commit to chaincoin/chaincoin that referenced this pull request Dec 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment