Implement auto-update feature

[anonimal]

And auto-update feature that would (at the very least) notify the user of their out-of-date version.

[anonimal]

Discussed today in IRC re: cpp-netlib, as also discussed in the recent past with @fluffypony, the idea is to implement an auto-update feature that is side-channeled along with java I2P's newfeed. An HTTP auto-update is one of the reasons why we are researching a better URI parsing implementation as discussed in #121 and here:

2016-02-07 19:22:48     +zzz    compliant url parsing is actually quite difficult. java code got a lot better when we moved to a library implementation instead of roll-your-own. You may wish to do the same.
2016-02-07 19:23:04     +EinMByte       zzz: Indeed. boost might have something
2016-02-07 19:23:46     &anonimal       EinMByte: Re: boost, read comments in HTTP.h, I threw in an alternative somewhere in there
2016-02-07 19:23:56     +zzz    especially over in the http proxy, parsing bugs could turn into vulnerabilities
2016-02-07 19:24:42     +EinMByte       zzz: not "could", they probably are already
2016-02-07 19:26:43     +EinMByte       anonimal: cpp-netlib, yes. Well the only problem might be is that it uses boost.spirit
2016-02-07 19:27:00     +EinMByte       Which is really overkill for URI parsing?
2016-02-07 19:27:39     +EinMByte       I've used it once, and it's a powerful library. A bit too powerful, paybe
2016-02-07 19:27:43     +EinMByte       s/paybe/maybe
2016-02-07 19:28:14     +EinMByte       It might have improved since then, though
2016-02-07 19:28:22     +EinMByte       (compilation took ages)
2016-02-07 19:28:54     &anonimal       I think it's worth looking into
2016-02-07 19:29:03     &anonimal       Especially since we will be doing auto-updating over http
2016-02-07 19:29:15     &anonimal       Well, in theory so far.
2016-02-07 19:29:55     +EinMByte       Sure, we're using HTTP in quite a few places so it might be worth it

[anonimal]

Referencing #162. In terms of distribution, we should (at the very least could) use SU3. Class SU3 will handle the brunt of the work: signature verification (we simply include our own certificate with other su3 certs) and extraction (currently only zip but we could implement other types of compression if needed).

Within the realm of SU3, after content type is determined (now of which has now been made readily available in #162), all we would need to do is point to a filesystem-related replace-kovri-with-new-updated-lib implementation; but that portion of works depends on a completed #98 and, IMHO, a well-defined auto-update specification.

[EinMByte]

@anonimal Is it the intend to provide auto-updating for the library as well? Auto-updating the application (possibly including the library) is relatively straightforward, but I'm not convinced that updating the library itself (when used in another application) is a desirable feature. It's also much more difficult to implement.

You could replace the binaries (.so files), but not any includes (since that would require the application be recompiled). That imposes a pretty strong backwards-compatibility restriction on the interface. It seems more logical to me that the applications using libkovri would deal with updating themselves, which is how things are usually done.

Of course I'm not talking about minor updates such as certificates, hosts etc.

[anonimal]

Sorry, I wasn't clear. I meant in terms of binary signature verification and processing; something of which @fluffypony and I touched on a while ago and I wanted to bring that back up again.

I completely agree with you @EinMByte about the difficulty. If we are going to side-channel with java i2p's newsfeed, and AFAICT they treat their newsfeed as an su3 (but that doesn't mean that we need to send our updates as an su3), and if the application wants to update over i2p, the application could (after API work) use our classes instead of their own implementation. But maybe that isn't necessary? Maybe we can tackle the specifics of this issue in-depth at our next meeting?

[EinMByte]

@anonimal Discussing this in the next meeting seems like a good idea. We could provide classes to update software over I2P, but in my opinion that kind of high-level stuff is not our primary concern. We should just ofter people a (ideally simple) library to send data over the I2P network using various protocols.

[anonimal]

Sounds good, added to #163.

[anonimal]

NOTICE: THIS ISSUE HAS BEEN MOVED TO GitLab. Please continue the discussion there. See #1013 for details.