1. 16 Apr, 2009 1 commit
  2. 04 Apr, 2009 1 commit
  3. 29 Aug, 2008 1 commit
    • Laurent Aimar's avatar
      Improved config_chain parsing by using escape for \ " and ' (close #1952) · ce1a1d96
      Laurent Aimar authored
      It also add checks against failed malloc.
      The option value should be escaped by \ for the mentionned characters and
      only for them (and only one time).
      For example
       dst="test \"ok\".mp3"
      will assign the value
       test "ok".mp3
      to the option dst.
      The following one
      will assign the value
      You can use the functions
      - config_StringEscape (allocates memory)
      - config_StringUnescape (does not allocate memory).
  4. 27 Jul, 2008 1 commit
  5. 31 May, 2008 1 commit
  6. 14 Apr, 2008 1 commit
  7. 02 Mar, 2008 1 commit
    • Rémi Denis-Courmont's avatar
      Remove security-policy from config_ChainParse() · cc1f013d
      Rémi Denis-Courmont authored
      but NOT from var_OptionParse().
      Rationale: At a shallow level, this breaks the command line use badly.
      At a deeper level: We still do security enforcement in
      var_OptionParse(). In practice, the config chain strings are always
      coming from (part of) the value of string configuration variable,
      which is parsed by var_OptionParse(). Hence, as long as these variables
      are all tagged as "unsafe", only trusted input can ever reach
      There are other (intractable?) issues with checking configuration chain
      strings: First, we would also need to check the module name in front of
      the {var1=val1,...} stuff. Second, some modules parse their
      configuration chain manually, i.e. they don't call config_ChainParse()
      and sometimes do not register their variables as configuration items
      (e.g. the sout duplicate module).
      If you have a super-duper idea on how to improve this, you're welcome,
      but in the mean time...
      Signed-off-by: Rémi Denis-Courmont's avatarRémi Denis-Courmont <rem@videolan.org>
      Vaguely-acked-by: Pierre's avatarPierre d'Herbemont <pdherbemont@free.fr>
  8. 24 Jan, 2008 2 commits
  9. 23 Jan, 2008 1 commit
  10. 16 Jan, 2008 1 commit
    • damienf's avatar
      vlc security: As i've seen very little improvement on that front, i've decided... · 658b4f83
      damienf 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}"
  11. 17 Dec, 2007 1 commit
  12. 09 Dec, 2007 2 commits
  13. 10 Sep, 2007 1 commit
  14. 08 Sep, 2007 1 commit
  15. 21 Aug, 2007 1 commit
  16. 20 Aug, 2007 1 commit
  17. 04 Aug, 2007 2 commits
  18. 14 Apr, 2007 1 commit
  19. 25 Mar, 2007 1 commit
  20. 12 Nov, 2006 1 commit
  21. 01 Oct, 2006 1 commit