My feeling is that having a direct download link inside of LMMS is a bad
idea because it forces all the issue Vesa mentioned on us, several of which
are near impossible to guarantee at this point. My thought was in the paths
there can be a user definable url that points to a simple version number.
If the number at the URL differs from the number on your version, then the
update LED glows. Then the user can go through what ever means they want to
to get the update. If the URL field is empty, then the LED stays off. If
the URL is a dead link the light will glow, the user will check, and if
they see that they have the latest version then they will investigate why
their update LED url is no longer functioning, and can either update it, or
remove it. The dimmer aspect I mentioned previously is because some people
might want the LED to light but not glow as bright as some one else. It
makes it user definable. This takes the burden of a static link away while
keeping a user informed in a simple interface friendly manor.
On Fri, Mar 7, 2014 at 10:42 AM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
