I do like the idea of the LED, and I think that is a good way to go. I
think also we will need to then get in the habit if someone reports a bug
to have them try against the newest release to see if it still exists.
On Fri, Mar 7, 2014 at 8:20 PM, Bill Y. <b...@anzovin.com> wrote:
> 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
>
>
--
Jonathan Aquilina
------------------------------------------------------------------------------
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
