>
> that is must be absolutely secure. No compromises, no excuses, it MUST
> be secure: we can't just put a server address there that LMMS checks - it
> must be future proof (what if our server address changes? well, the users
> will get the new one in the next update... oh wait), so there must be
> some kind of foolproof authentication scheme, so that if someone manages
> to spoof our server or do a man-in-the-middle attack or something, LMMS
> will know "this isn't our real website, something is up, let's bail".
Well, to be fair, there's no such thing as absolutely secure.
I believe what you're referring to is using some form of certificate
verification (MD5, which is fairly secure gets ruled out for downloads
since we can't see into the future!)
Self-signed scenarios:
- The current software contains the public key in it's source code and
verifies the update is signed with the the private-public chain.
- Pros: No expensive trusted root certificate is needed, download is
verified against a known "trusted" source.
- Cons: Anyone can compile their own version with a different public
key. If the software were installed from an unofficial source to begin
with (and therefor a different public key), it would flag the
good software
as bad, or worse look elsewhere for updates and dangerously flag those
locations as good.
- Cons: The private key could not be part of the public domain.
Instead there would need to be a "trusted group" of people keep this
behind locked doors.
- Cons: Key expiration would eventually happen and if the private
key were accidentally stolen, no revocation information would be
available.
Trusted-signed scenario:
- Same as above, except revocation information *would be* available.
- Pros: The chain of trust comes from a centralized authority with
good revocation info.
- Cons: Expensive as well as the same issues mentioned above.
Public Certificates may eventually get "stacked" into the source code if
different CAs are used over time.
So a claim that "*it must be absolutely secure. No compromises, no excuses,
it MUST be secure*" is a noble but impossible requirement. There's no such
thing as security without compromises.
Furthermore, in one breath to say "*my word isn't the law on the subject*"
and then in another breath to use all caps with the word "*MUST be secure*"
is the very passive-aggressive wording that IMO discourages open ideas from
flowing. NO SHOUTING! :)
That said, I see very little harm in checking a mirror for a download link
and displaying that in the help area. Can someone spoof that DNS? Yes.
Can someone provide a virus at that address? Yes. Can someone ask
for Paypal login information? Yep. Can all of this happen when you click
on your normal web browser and type in lmms.sourceforge.net? Yep. The
risk is up to the community and so as long as there is no warranty and
we explicitly as the user to waive liability on install, I'd argue we are
no worse off than we would be if it were an email or a Facebook link that
offered a new version.
- tres.finocchi...@gmail.com
On Thu, Mar 6, 2014 at 11:36 PM, Vesa <dii....@nbl.fi> wrote:
> On 03/07/2014 02:44 AM, Tres Finocchiaro wrote:
> > I personally am spilt 50/50 in terms of a non-intrusive upgrade
> > indicator, but it would have to get coded and Vesa seems mostly
> > against it.
> >
> >
>
> Well, I'm not the only coder here (I'm not much of a coder anyway), and
> my word isn't the law on the subject. But I don't see much of a point in
> this feature. I don't like it when software does things I didn't ask it
> to do - particularly when it's things like connecting on networks.
>
> Maybe something like a button or menu option that says "check for
> updates" which would check for a new version, and then if one is found,
> suggest a download to the user - in the form of a link that will open in
> the browser (or torrent client, if that's the way we decide to go, which
> I personally think would be a great idea - it would save money on
> hosting, let the users help with the hosting of our binaries, it
> provides error-free download - automatic hash checking and no way for
> downloads to just cut off at 95%... buuuut, I'm digressing pretty far
> off topic here).
>
> That's the way I think it should be done, how smart programs do it: let
> the user decide when to check for updates. The user knows best, let's
> not try to start deciding things for the user - that's mostly just
> annoying, we can never know what the user wants as well as the user does.
>
> There's only one caveat for this kind of "check for updates" function...
> only one, but it's a big one: that is must be absolutely secure. No
> compromises, no excuses, it MUST be secure: we can't just put a server
> address there that LMMS checks - it must be future proof (what if our
> server address changes? well, the users will get the new one in the next
> update... oh wait), so there must be some kind of foolproof
> authentication scheme, so that if someone manages to spoof our server or
> do a man-in-the-middle attack or something, LMMS will know "this isn't
> our real website, something is up, let's bail".
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> LMMS-devel mailing list
> LMMS-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
