1. 28 Mar, 2008 1 commit
  2. 27 Mar, 2008 2 commits
  3. 23 Mar, 2008 1 commit
  4. 22 Mar, 2008 1 commit
  5. 18 Mar, 2008 1 commit
    • Rémi Denis-Courmont's avatar
      Remove the short-lived security-policy parameter. · 6ee1e74f
      Rémi Denis-Courmont authored
      In by far the overwhelming majority of cases, the user would not know
      how to determine the correct answer to the security prompt (did you
      ever compare SSL error handling in IE6 and IE7?). Since the trust value
      is now determined programatically, this would seem to mostly help users
      shoot themselves in the foot.
      
      --security-policy is also broken when using --playlist-enqueue: imagine
      you are running VLC with no security, and then your browser enqueues an
      M3U from some nasty webserver... fireworks.
      
      Wrappers around VLC really should NOT use M3U files if they need to
      tweak certain options (e.g. --sout). Global options can simply be set
      the normal way from the command line (e.g.: vlc --sout '#std{...}').
      Per-item options can be set using the colon notation. Multiple items
      should be expanded on the command line in the right order, rather than
      written to a M3U file. Alternative, IPC interfaces could be used
      (single instance + playlist enqueue, RC interface, DBus interface...)
      or language bindings.
      
      *** Important note ***
      Web browser plugins are still in need of fixing. I suppose
      libvlc-control should be extented to support playlist item trust.
      
      Feel free to revert and do something else if you have a _better_ idea.
      6ee1e74f
  6. 08 Mar, 2008 1 commit
  7. 04 Mar, 2008 1 commit
  8. 29 Feb, 2008 1 commit
  9. 21 Feb, 2008 1 commit
  10. 20 Feb, 2008 1 commit
  11. 27 Jan, 2008 1 commit
  12. 23 Jan, 2008 1 commit
  13. 16 Jan, 2008 3 commits
    • Damien Fouilleul's avatar
      vlc security: As i've seen very little improvement on that front, i've decided... · 658b4f83
      Damien Fouilleul authored
      vlc security: As i've seen very little improvement on that front, i've decided to check in my take on handling the problem of managing harmful options. I'm pretty sure this is going to be very controversial, but I think my approach is quite simple and yet very effective Anyway, my approach makes the following assumptions:
      
      - most vlc options are considered safe, only a handful are particularily unsafe and need be declared as such in their definition (they mostly deal with writing to an output file or URL)
      - unsafe options are only considered potentially harmful when used as an input option, ie. the ':option' format. Configuration options are always considered safe 'i.e --option' 
      - unsafe options are associated with a global security policy, which dictates how these are handled. At the moment, The policy can be either block, allow or prompt, and is set using the '--security-policy' option (which itself is considered unsafe ;)
      
      the policy can be set by the user at the command line or in the preferences, it curently defaults to prompt, which is the desirable state for deskop use. However, it can be overriden depending on context, for example, the activex and mozilla will force the security-policy to block regardless of preference settins.
      
      the code is a bit rough at the moment, but i will optimize/clean it up if the dev community this approach is worth keeping.
      
      try the following example, and you'll see quickly what i mean:
      
      ./vlc -vvv <a mrl> :sout=#transcode{vcodec=mp1v,vb=1024,acodec=mpga,ab=192}:standard{mux=ts,dst=vlc-output.ts,access=file}"
      
      Enjoy,
         Damien
      
      
      658b4f83
    • Rémi Denis-Courmont's avatar
    • Rafaël Carré's avatar
      input options whitelisting: 1st step · 9e5ebb07
      Rafaël Carré authored
      9e5ebb07
  14. 18 Dec, 2007 4 commits
  15. 15 Dec, 2007 2 commits
  16. 03 Dec, 2007 1 commit
  17. 28 Nov, 2007 1 commit
  18. 24 Nov, 2007 1 commit
  19. 08 Nov, 2007 1 commit
  20. 07 Nov, 2007 1 commit
  21. 30 Oct, 2007 1 commit
  22. 26 Oct, 2007 1 commit
  23. 20 Oct, 2007 1 commit
  24. 15 Oct, 2007 1 commit
  25. 12 Oct, 2007 1 commit
  26. 23 Sep, 2007 2 commits
  27. 18 Sep, 2007 1 commit
  28. 10 Sep, 2007 3 commits
  29. 31 Aug, 2007 1 commit
  30. 04 Aug, 2007 1 commit