From: Stephen G. Parry <sgparry@ma...> - 2014-01-26 17:57:11
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.
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.
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.
> 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.
> audacity-devel mailing list