Re: [Audacity-devel] Plugin Warning on Load

[Stephen G. P. <sg...@ma...>]

I will apply my best brain on this over the next few days. I'm already
looking at the suggestions you made regarding the menu and scripting
command directories - I think the ability to easily extend the command
set without editing the core source is a very good thing - and essential
if we are going to have commands implemented by 3rd party modules.
Intended plan of action:
1. Possibly unify the two directories (Scripting Commands and Menu Commands)
2. add the features to easily extend the directories into other modules
- that is some macros, and some DLLAPI adds
3. Move one or two areas out of menus.cpp as a trial.
4. Generate one monster patch to move the other areas.
I've automated this kind of messy thing before - I'm hopeful to make it
a clean switch.

The idea of the MD5 thing was not for us to maintain a list as such, but
that when a user authorises a module, for audacity to maybe store the
MD5 in such a way the module can't tamper with it. Then if the module is
replaced with anything malicious or updated without user consent, they
get a warning. Probably a lot of work for not much benefit though.

On 29/01/2014 01:19, aud...@li... wrote:
> Message: 8
> Date: Wed, 29 Jan 2014 01:19:01 +0000
> From: Martyn Shaw <mar...@gm...>
> Subject: Re: [Audacity-devel] Plugin Warning on Load
> To: aud...@li...
> Message-ID: <52E...@gm...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi
>
> There have been a number of stages with 'modules', and we have not 
> settled on a solution as yet.
>
> Modules could (I believe) be written to open up security problems with 
> a machine via Audacity, hence our closing down the 'modules' thing a 
> little, and giving warnings each time.  The warnings are better than 
> the immediately previous version of rejecting all modules, I think. 
> FWIR I opened it up a little.
>
> We currently ask users to 'authorize' modules each time, since we have 
> no control over what they do.  And why should we?  'Modules' should be 
> able to do 'stuff'.
>
> md5 is no use to us, if we want users to be able to load modules that 
> a.n.devel has produced and not run by us.  Why should we take that 
> workload?  Why should they need to run it by us anyway?  I think we 
> should allow users to try anybody else's module whenever they want. 
> And reject it.
>
> If a user 'authorized' a module for ever (presumably stored in prefs) 
> and that module turned out to be a problem, what would they do about 
> it?  Remember that most users don't have the ability to find/edit a 
> text file ;-).
>
> This is quite a complex problem, that we have discussed a number of 
> times.  I would like to see a solution to it.
>
> There was a solution implemented that insisted that modules were 
> compiled with the exact same date/time (I think, maybe version) as the 
> main Audacity program.  That was proved to be flawed by a work-around 
> where the module interrogates the prefs and reports back what it sees 
> there.  Modules need to be able to read prefs, so there is nothing we 
> can do about that.
>
> Audacity and non-Audacity devels need to be able to ship new modules 
> for Audacity, and have them work for users.  Users need to be able to 
> try new modules, and reject ones that cause problems.  Users don't 
> want click 'ok' many times when loading (like they have to now).  We 
> don't want to code each module into the prefs (as that would reduce 
> the functionality for third-party devels).  So what do we do?
>
> Any good ideas welcome!  Like I said, an open problem and I have 
> probably missed some points here.
>
> TTFN
> Martyn
>
> On 26/01/2014 17:57, Stephen G. Parry wrote:
>> Hi All,
>> At some point in the past a warning on load was introduced for modules
>> (plug-ins) loaded into Audacity. Can someone please tell me what the
>> intention if any was for 'authorizing' new modules so the warning no
>> longer appears? I was considering implementing it - perhaps using an md5
>> or such like to verify that authorized plug-ins had not been tampered with.
>> Thanks
>> Stephen
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable 
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> End of audacity-devel Digest, Vol 93, Issue 37
> **********************************************