I would say that unless you're having problems with Sparkle, you probably
wouldn't want to move away from it. We did not build Update Engine to steal
Sparkle userswe really like Sparkle! We built Update Engine to do a few
things that Sparkle doesn't do (or at least didn't do at the time we
designed Update Engine). We needed something that could update
non-bundle-based apps in addition to regular Cocoa apps. We needed something
that could update root-owned products and things with, for example, kernel
extensions. And we needed something that could update multiple products all
at once. We also needed something that was flexible and could be extended in
a number of different ways to support future products.
Our intent was not to build competition for Sparkle. We focused on different
problems than those that Sparkle solves. Update Engine is a lower-level
solution than Sparkle. For updating an ordinary Cocoa application, I don't
see anything wrong with using Sparkle.
From what I've seen, the Update Engine is *way* better engineered
(both in class structure, overall structure, and in actually having
unit tests) and is a *lot* more flexible, but is probably a bit
trickier to get up and running for The Common Case. I'm still looking
through the code, but it looks like there's no cryptographic
verification, which is kinda really scary. Is there standardized GUI
for .apps? I understand if not: what's cool about the update engine is
that it lacks all the logic about "should I do the update thing now",
which is a nice way of setting up the architecture.
Good work, guys! I'm looking forward to seeing with this turns
into. :)
On Sep 29, 8:56 pm, Andy Matuschak <lemnis...@gmail.com> wrote:
> Thanks for the friendly answer, Greg! :)
> From what I've seen, the Update Engine is *way* better engineered
> (both in class structure, overall structure, and in actually having
> unit tests) and is a *lot* more flexible, but is probably a bit
> trickier to get up and running for The Common Case. I'm still looking
> through the code, but it looks like there's no cryptographic
> verification, which is kinda really scary.
Update Engine requires the server response to contain a size and SHA-1
hash of the binary that gets downloaded. These are used to ensure the
downloaded file was not compromised. If either of these do not match,
the download is ignored.
> Update Engine requires the server response to contain a size and SHA-1
> hash of the binary that gets downloaded. These are used to ensure the
> downloaded file was not compromised. If either of these do not match,
> the download is ignored.
Using only SHA-1 and no signature only provides a better CRC and no
security.
Does the engine requires connection to the server to use SSL? Even if
it does,
it looks like Sparkle's solution is much stronger.
From memory (I looked at it a while ago):
- Get the developer to generate a self-signed certificate
- Bundle the certificate in the application
- Check that updates are signed by this certificate
Simple and efficient!
If the initial download of the application can be performed over SSL,
the
systems is pretty robust.
Hi Greg, Update Engine is really a good ideas and solve many problems
reducing scripts part when you are using Sparkle, but why another
project
maybe it could be a good thing to add the Low Engine to Sparkle
I do open-source stuff since (more than ~) 14 years now, and I'm
always disturbed by the
proliferation of projects in the same field, I would like to see more
"concentration",
even if open-source lands commit to diversity, I think it's always
more efficient to focus,
and I think google could try to show "good attitudes" regarding how to
manage projects,
it could also be cool that's the released Obj-c code has more code
beautifier and code conformance
example
@interface KSSpotlightExistenceChecker : KSExistenceChecker {
@private
NSString *query_; // this the c++ rcf of Google, unreadable,
(my mind, sorry, I'm reading from the left to the right, English.
latin) and doesn't solve any possible collision problem
maybe it has been created by someone is used to read from the right to
the left ... but it's not how we read the English
}
#pragma mark KSSEC stands for KSSpotlightExistenceChecker
> > Update Engine requires the server response to contain a size and SHA-1
> > hash of the binary that gets downloaded. These are used to ensure the
> > downloaded file was not compromised. If either of these do not match,
> > the download is ignored.
> Using only SHA-1 and no signature only provides a better CRC and no
> security.
> Does the engine requires connection to the server to use SSL? Even if
> it does,
> it looks like Sparkle's solution is much stronger.
> From memory (I looked at it a while ago):
> - Get the developer to generate a self-signed certificate
> - Bundle the certificate in the application
> - Check that updates are signed by this certificate
> Simple and efficient!
> If the initial download of the application can be performed over SSL,
> the
> systems is pretty robust.
I'm getting the impression that the other difference, specially
regarding The Common Case like Andy mentions, is the actual install
process. So far I've gleaned this is handled by the .engine_install
script which is entirely up to the developer. One of the benefits of
Sparkle was not worrying about that. I assume a common use
engine_install could be built for various common update processes.
I'm wondering since I'm unsure what's involved with updating a
running .app for example. I haven't looked how sparkle does it, but I
assume you can't just copy the new one over the running one, that is
if you're running the update code from within your application.
Will there be more information coming on some more common uses to help
people get started?
-- jeremy
On Sep 29, 11:56 pm, Andy Matuschak <lemnis...@gmail.com> wrote:
> From what I've seen, the Update Engine is *way* better engineered
> (both in class structure, overall structure, and in actually having
> unit tests) and is a *lot* more flexible, but is probably a bit
> trickier to get up and running for The Common Case. I'm still looking
> through the code, but it looks like there's no cryptographic
> verification, which is kinda really scary. Is there standardized GUI
> for .apps? I understand if not: what's cool about the update engine is
> that it lacks all the logic about "should I do the update thing now",
> which is a nice way of setting up the architecture.
> Good work, guys! I'm looking forward to seeing with this turns
> into. :)
From what I understand, update-engine can update more or less
everything. Although I fail to understand how it can do so as a
framework (I'm thinking of "regular files"). Will it contain a
centralized executable component? From what I understand an autoupdate
framework resides inside a program and can only be called when that
program is run. Could you explain the paradigm for stuff like internet
plugins, QT plugins, file-systems, kernel extensions and such, which
are not "run" by the user?
Cheers,
Guillaume
On Sep 30, 2:40 am, Torsten Curdt <tcu...@vafer.org> wrote:
> > Update Engine requires the server response to contain a size and SHA-1
> > hash of the binary that gets downloaded. These are used to ensure the
> > downloaded file was not compromised. If either of these do not match,
> > the download is ignored.
> Using only SHA-1 and no signature only provides a better CRC and no
> security.
> Does the engine requires connection to the server to use SSL? Even if
> it does,
> it looks like Sparkle's solution is much stronger.
> From memory (I looked at it a while ago):
> - Get the developer to generate a self-signed certificate
> - Bundle the certificate in the application
> - Check that updates are signed by this certificate
> Simple and efficient!
> If the initial download of the application can be performed over SSL,
> the
> systems is pretty robust.
> My 2c. anyway.
We just added a small doc that explains Update Engine's security
model(s). Please take a look at http://code.google.com/p/update-engine/wiki/UpdateEngineAndSecurity But in a nutshell, simply fetch the server plist using https: and you
can trust the server response, and more specifically, the SHA-1 hash.
I realize that the demo I made may have caused some confusion because
my sample tickets said "http://...". The intent was to save space and
merely show some url. I added a comment to clarify that and direct
folks to the new security wiki... but there's no way in hell I'm going
to re-record the demo ;-)
|
