Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 67
  1. #21
    Logitech Squeezebox Software Program Manager
    Join Date
    May 2007
    Location
    Silicon Valley
    Posts
    477

    Yum Repository?

    Quote Originally Posted by Fletch View Post
    For a while last year, I was involved in an effort (with Al Pacifico) to set up a slimserver yum repo. Unfortunately, both of of became busy and never completed the effort. (Side effect of the community model perhaps...) I think we both hope to re-engage at some point. Anyway...

    With Dan Sully's help, repos.slimdevices.com/yum was set up with a scripted sync (5 min?) from svn.slimdevices.com/vendor/yum. The main benefits to me were:
    1) It was sync'd from svn, so anyone with svn access could contribute.
    2) It was hosted by slimdevices which avoided any problems with distributing firmware and graphics.
    I hadn't heard about this effort -- Dan's not here anymore. I don't know much about yum repositories other than what I can google. What were the goals of this repository? Can a yum repository be useful for distributing SlimServer plugins?

    Mickey
    Transporter > ClassÚ Audio DR6 > Mark Levinson 23 > Wilson Watt 3/Puppy 1/Martin Logan Dynamo 700

  2. #22
    Perl Commando Dan Sully's Avatar
    Join Date
    Apr 2005
    Location
    Daly City, CA
    Posts
    2,865

    Updated SlimServer 7.0 Spec with Schedule

    * MickeyG shaped the electrons to say...

    >I hadn't heard about this effort -- Dan's not here anymore. I don't
    >know much about yum repositories other than what I can google. What
    >were the goals of this repository? Can a yum repository be useful for
    >distributing SlimServer plugins?


    No it's not.. yum is the mechanism used for distributing RPMs (RedHat,
    Fedora), similar to Debian's apt-get.

    The Slim Plugin Repo should be something similar to Winamp or Firefox's
    plugin pages.

    https://addons.mozilla.org/en-US/firefox/browse/type:7

    http://www.winamp.com/plugins/

    -D
    --
    <dsully> please describe web 2.0 to me in 2 sentences or less.
    <jwb> you make all the content. they keep all the revenue.

  3. #23
    formerly known as Fletch
    Join Date
    May 2005
    Posts
    2,260
    My point was that a script that automatically syncs from svn to an official plugin repo might be a good way to go. The yum repo was just an example.

  4. #24
    Senior Member hickinbottoms's Avatar
    Join Date
    Apr 2005
    Location
    Wokingham, UK
    Posts
    544

    Updated SlimServer 7.0 Spec with Schedule

    I'd support that (for the Lazy Search plugin).

    Far better to upload the plugin when I release it and people be notified
    of updates than of my having to keep boring people with announcements on
    the plugins list. Ideally the release could also include the changelog
    (which could be automatically done if a standard name of the changelog
    were used within the plugin's package), so the update manager might be
    able to point out what had changed (it what you'd normally write in the
    plugins list announcement).

    SlimServer could then also restrict itself to checking for updates from
    a single site (Logitech-hosted).

    Following the Firefox mozdev.org model there would be a standard format
    mini-website for each plugin that the author can use to briefly describe
    the plugin, and from where it can be downloaded, and perhaps with a
    mechanism for comment posting.

    In the short-term per-plugin pages could be provided as an extension of
    the wiki, but with updates locked to the authors. That would avoid
    having to create a custom portal until things become more established.

    Stuart

    MickeyG wrote:
    > JJZolx;214593 Wrote:
    >
    >> The choices are either a central repository or else each plugin author
    >> maintains the download on a publicly accessible HTTP server.
    >>
    >> ... An ideal solution would be to have a central repository (hosted by
    >> Logitech) where plugin authors log in and would have access only to
    >> their files. This would be fairly easy to do by giving plugin authors
    >> restricted FTP access to the server. But since it would involve
    >> someone at Logitech to maintain the server and FTP accounts, I'm
    >> assuming that's not currently an option.
    >>
    >> ... snip
    >>
    >>

    >
    > I could look into having Logitech host an FTP server solely for
    > SlimServer plugins. The www.slimdevices.com and SqueezeNetwork servers
    > will remain independent and managed by our little group, so it's a
    > possibility.
    >
    > However, I'll do this only if that's what the community wants. Let me
    > know what you guys think I should do.
    >
    > Mickey
    >
    >
    >
    > ------------------------------------------------------------------------
    >
    >

  5. #25

    plugin updates: XML model, CSRF issues

    Quote Originally Posted by kdf View Post
    On 13-Jul-07, at 4:48 PM, erland wrote:
    >>

    > Has there been any discussion about how to do it besides "that it
    > should use the same principle as Firefox extensions" ?
    >

    that's the model. the implementation wouldn't have to be a copy.
    After all, slimserver isn't firefox.

    However, in basic, it should be possible to enter a url in a field,
    click install and the installer will download and extract the tar.gz
    package to the Plugins folder. The user would then be informed that the
    plugin is installed and that it will be active after a restart
    Here's a thread with some discussion about XML for allowing Firefox-like plugin updates (as I understand it, the main goals for this plugin enhancement are first, simplifying plugin installation as KDF described; and, second, making it easier for users to install plugin updates):
    http://forums.slimdevices.com/showthread.php?t=31077

    Mickey, I think one thing that really ought to be on the list for 7.0 is restoring the CSRF protections in the web UI. Currently (in 6.5.x), they're virtually nonexistent. Currently this is mainly an annoyance -- CSRF could be used to force a rescan, change settings, make Slimserver "lose" music, send commands to players, etc. But with the envisioned web UI for installing and updating plugins, the lack of CSRF protections will allow attackers the ability to load malicious software onto customers' Slimserver hosts. More on CSRF protection in the current code base:
    http://forums.slimdevices.com/showthread.php?t=35317

    It would be nice to go beyond restoring CSRF protection and support encryption as a means of verifying plugins, especially updates to installed plugins. This could be either PGP-style signatures for the Plugin files (and the updates.xml metadata?), or, more simply, supporting https addresses as suggested in this report about a similar issue with Firefox plugins:
    http://paranoia.dubfire.net/2007/05/...n-firefox.html

    Personally, I'd prefer something like PGP (the RPM/JNLP signed content model), as it's easier & cheaper for me to digitally sign files and be able to host them anywhere than it would be for me to run an https server.

    I know, I know, "patches welcome". I wish I had time to spend writing patches, but lately it's been tough to find spare cycles for this stuff. :-/

    Thanks.

    -Peter
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  6. #26
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,039
    Quote Originally Posted by peterw View Post
    Mickey, I think one thing that really ought to be on the list for 7.0 is restoring the CSRF protections in the web UI. Currently (in 6.5.x), they're virtually nonexistent. Currently this is mainly an annoyance -- CSRF could be used to force a rescan, change settings, make Slimserver "lose" music, send commands to players, etc. But with the envisioned web UI for installing and updating plugins, the lack of CSRF protections will allow attackers the ability to load malicious software onto customers' Slimserver hosts. More on CSRF protection in the current code base:
    http://forums.slimdevices.com/showthread.php?t=35317
    This seems to solve what I was worried about in my previous post, the CSRF issues definitely has to be solved in some way regarding
    plugin installation. I guess there is number of solutions:
    1. Restore the CSRF protection, at least in the plugin installer UI, and allow download and installation from any web site on the internet.
    2. Only allow installations from local harddrive. Although this will make it more complicated for the users since they need to download the plugin separately before installing it.
    3. Only download and install from a known source, probably from a known Logitech server where the plugin authors can upload their new plugin releases.

    Solution 3 can of course be combined with solution 1.

    Quote Originally Posted by peterw View Post
    It would be nice to go beyond restoring CSRF protection and support encryption as a means of verifying plugins, especially updates to installed plugins. This could be either PGP-style signatures for the Plugin files (and the updates.xml metadata?), or, more simply, supporting https addresses as suggested in this report about a similar issue with Firefox plugins:
    http://paranoia.dubfire.net/2007/05/...n-firefox.html
    I'm not sure we need to go this far in the 7.0 release. After all SlimServer isn't as wide spread as Firefox and thus less interesting for attacks, so maybe some easier solution is good enough ?

    Quote Originally Posted by peterw View Post
    Personally, I'd prefer something like PGP (the RPM/JNLP signed content model), as it's easier & cheaper for me to digitally sign files and be able to host them anywhere than it would be for me to run an https server.
    I'm not sure I like to go this way. I've provided some Java JNLP distributions and getting a valid certificate to sign with cost money and I fear that this will limit the number of plugin authors. You can of course use self signed certificates, but that really doesn't result in any better security IMHO.

    I would really prefer a solution that:
    1. Is good enough regarding security, it doesn't have to be perfect
    2. Doesn't make it more complicated for a new plugin developer to write a plugin and make it available for download

    Anyway, having a plugin installer interface that would allow installation of perl code in the local comuputer from an unknown internet URL without also having some sort of CSRF protection seems unacceptable to me.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  7. #27
    Quote Originally Posted by erland View Post
    This seems to solve what I was worried about in my previous post, the CSRF issues definitely has to be solved in some way regarding
    plugin installation. I guess there is number of solutions:
    1. Restore the CSRF protection, at least in the plugin installer UI, and allow download and installation from any web site on the internet.
    2. Only allow installations from local harddrive. Although this will make it more complicated for the users since they need to download the plugin separately before installing it.
    3. Only download and install from a known source, probably from a known Logitech server where the plugin authors can upload their new plugin releases.

    Solution 3 can of course be combined with solution 1.
    And Solution 1 would be adequate. I would not like to see Logitech become a chokepoint for downloads -- let users install plugins from wherever they might find them. (And clearly there would need to be a way to tweak or bypass the 3rd option for legitimate developers.)

    I'm not sure I like to go this way. I've provided some Java JNLP distributions and getting a valid certificate to sign with cost money and I fear that this will limit the number of plugin authors. You can of course use self signed certificates, but that really doesn't result in any better security IMHO.
    As far as keypair management goes, I was mainly thinking of the RPM/PGP model. RPM packages can be signed or unsigned. Main Linux distributions like Red Hat sign everything they release, with a PGP that costs them nothing. Other vendors, like Slim/Logitech, release RPM packages that are not signed. There is an initial "leap of faith" when the user first gets a particular PGP key, which is a (security) downside compared to JNLP. But once the user has chosen to trust the public key, that developer's work is fairly safe from trojan horse attacks, even if the user is using insecure mechanisms like HTTP or FTP. I agree with you that
    1) developers should not be required to sign packages
    2) the signing mechanism should have no cost
    As concerned as I am about security matters, I wouldn't pay for a certificate for signing my Slimserver code, either.

    I do think it would be good to move towards some code signing option, but I agree that it's not critical. Addressing the CSRF problems is.

    -Peter
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  8. #28
    Logitech Squeezebox Software Program Manager
    Join Date
    May 2007
    Location
    Silicon Valley
    Posts
    477

    Updated SlimServer 7.0 Spec with Clarifying Beta Start Definition

    Quote Originally Posted by MickeyG View Post
    Thanks for the confirmation about how to handle beta start. I'll wait a little while longer for additional feedback before I modify the wiki to reflect that Beta Start = Coding Done = Feature Freeze = Branch from Trunk.

    Mickey
    I've made the change to the wiki per the above.

    Any other thoughts on SlimServer 7.0? What about plugin management and using a Logitech server to host plugins?

    Mickey
    Transporter > ClassÚ Audio DR6 > Mark Levinson 23 > Wilson Watt 3/Puppy 1/Martin Logan Dynamo 700

  9. #29
    Quote Originally Posted by MickeyG View Post
    Any other thoughts on SlimServer 7.0? What about plugin management and using a Logitech server to host plugins?
    What do you want to know about our opinions on plugin management? I think the web-based installation and update model is a very good idea.

    I don't like the idea of Logitech hosting plugins. It sounds like a bottleneck, and a potential procedural and legal mess. Having Logitech host the plugins would not solve the CSRF problem of users being tricked into configuration changes, plugin installation or removal, playing a sine wave pattern at full volume, etc. And having Logitech host plugins would make it more difficult to provide one-off releases and pre-release alpha- and beta- plugin versions to users, as I've done in the past when trying to fix newly reported bugs. Having Logitech host the plugins might solve the malware problem, but only if Logitech were to vet each plugin -- which would be an expensive proposition, and would open Logitech to liability if it missed some problem.

    I do think that having Slimserver request plugins *through* SLimserver, e.g. by requesting a URL like
    ht tp://slim.logitech.com/getplugin?par=ht tp://www.tux.org/~peterw/slim/MyPlugin-1.1.par
    would offer some advantages both to end users (their IP addresses hidden from plugin developers) and Logitech (it would facilitate analysis of plugin popularity). A straight passthrough mechanism with such URLs would also sidestep the logistics of plugins actually being hosted at Logitech, and I hope would also reduce liability concerns. But this proxy model also would not solve the CSRF problems that the current web UI has.

    -Peter
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  10. #30
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531
    Quote Originally Posted by peterw View Post
    I don't like the idea of Logitech hosting plugins. It sounds like a bottleneck, and a potential procedural and legal mess.
    Somehow I don't think the liability issues of hosting 3rd party plugins should be too daunting, but that's for Logitech to decide.

    As for bottlenecks, that will depend on the server resources and bandwidth that Logitech can devote for the purpose. There's no reason that it should be a bottleneck given sufficient resources. Taking the Firefox addon model, I like the way Firefox automatically checks for updated plugins, and wonder how well such a system would work if SlimServer is checking each plugin author's web site for updates. Many of those servers are going to be on inexpensive shared hosts, or even home connections, so I'd expect performance to be much worse.

    Having Logitech host the plugins would not solve the CSRF problem of users being tricked into configuration changes, plugin installation or removal, playing a sine wave pattern at full volume, etc.
    I don't think the idea was proposed as any kind of security measure. I'd really like to hear more about the CSRF threats, but in another thread.

    And having Logitech host plugins would make it more difficult to provide one-off releases and pre-release alpha- and beta- plugin versions to users, as I've done in the past when trying to fix newly reported bugs.
    I don't see that it makes any difference. The whole point of having a simple-to-use 'check for updates' plugin manager is that the user never leaves SlimServer in order to check for a newer plugin version, and never has to do a manual download. So once it's been installed, the users of your plugin would never have to visit your web page and won't see the alpha and beta downloads anyway. I would think the best you can hope for, no matter where the plugin package is hosted, is to provide a link on the prefs page to your web site.

    I do think that having Slimserver request plugins *through* SLimserver, e.g. by requesting a URL like
    ht tp://slim.logitech.com/getplugin?par=ht tp://www.tux.org/~peterw/slim/MyPlugin-1.1.par
    would offer some advantages both to end users (their IP addresses hidden from plugin developers)
    Wow. Do people really worry about such things?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •