Access2Base - New release

[Noel Power]

On 12/06/14 16:16, Lionel Elie Mamane wrote:
> On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote:
>> On 28/05/14 12:11, Lionel Elie Mamane wrote:
>>
[...]
>> you are just stating how you want it to work, it's not a
>> justification
> No, that was my prediction from reading the code that implements
> that. I now *tested*, in plain 4.2.4.2 (Debian amd64 package), that it
> indeed behaves in that way, by:
>
> 1) Installing "Foo" as a user extension
> 2) Observe result: Libraries Quux And Frobotz (from Foo) are enabled
>    and available.
> 3) Install "Bar" as a user extension
> 4) Observe result:
>    * Library Frobotz is still there and available (from Foo)
>    * Library Quux from Foo is nowhere to be found in the Library
>      browser.
>    * Library Quux from Bar is enabled and present, and can be used.
I took it (or thought that I read it) that the description above was how
you wish it to behave when installing a user extension against an
existing share Basic Library.
[...]
>> Security, I mentioned it in a previous mail, what you are suggesting is
>> basically allowing the user to rootkit the libreoffice api.
> I'm surprised you consider LibreOffice a security barrier /
> enforcer. I don't. As I see it, factually, it is an application that
> runs with the user's identity and privileges, that is under the
> control of the user and of anybody that subverts the user's
> environment. If you are thinking in terms of security, well LD_PRELOAD
> / LD_LIBRARY_PATH allows overriding any binary part of LibreOffice
> anyway. As does LD_PRELOAD'ing a library that redefines open() to
> override any part of LibreOffice (Python code, Basic, dialog .ui,
> ...).
sure you can do anything you want, but I am not talking about a
convoluted and technically complicated scenario like wrapping various
libreoffice libraries. It's clear you are comfortable with the idea that
a user extension can override the core, a hypothetical example being say
of a user installing a user extension that overrides the allows a user
XProtectable so they can easily unlock any spreadsheet to unhide their
bosses salary. But... the issue here isn't the silly example it's the
fact that libreoffice itself uses the api, it expects the code it calls
via the api to be the code it shipped with and to behave exactly how it
expects, this is one of the boundaries (or at least how I read it)  that
Michael mentioned previously and one of the invariants the core expects.
The key is in the name, extensions extend, not override
>
>> In the binary case the possibilities should be clear. But even if
>> Libreoffice didn't ship any basic libraries as part of the core it
>> wouldn't change the fact that enterprises normally deploy all of
>> their macros in share, I doubt they would wish that a user could
>> 'override' any libraries (including Access2Base that possibly some
>> of their macros have a dependency on)
> Enterprises are free, if they so wish, to forbid their employees to
> install an extension that overrides a part of core, or otherwise
> override a part of LibreOffice core.
first they need to know that they need to tell their users not to do
that, then they got to believe that users will obey them or understand,
but I suppose they could always customise libreoffice so that the
extension functionality is not available or go through a hundred other
hoops they never had to know about or consider before...
>
> I think that a (semi-)structured / (semi-)controlled (that is,
> extensions) way of overriding more-or-less arbitrary parts of a
> program is much better than having to resort to LD_PRELOAD /
> LD_LIBRARY_PATH, but that's not my fight, and (obviously) not a change
> we'd introduce in a stable branch.
>
see above, and I fail to see how lowering the barrier to for people to
do bad (intentionally or not) things is a good idea,

Anyway, since binary overriding isn't on the table yet my main concern
was with basic where you have can have Libraries deployed in share by
the enterprise, and with the previous proposal the possibility that a
user could with an extension override say the corporate authorisation
macros or whatnot.
Above you concede that allowing this in Basic generally is probably not
a good idea. But... still you propose to special case this overriding
for Access2Base, I can't see how it is any different, the same argument
holds and users can easily break deployed macros depending on the
'installed' version of Access2Base.
> FWIIW, an enterprise could also wish to deploy a newer Access2Base
> version without upgrading to LibreOffice Fresh (because they are
> enterprise, they want Stable), because it suits their newly developed
> macros better... And then doing it by a system-wide extension is much
> better than having to recompile the whole of LibreOffic
in that case the Enterprise has made the decision for themselves that
part of the libreoffice installation has been updated, you want to take
the decision out of the Adminstrators hands and into the users, that is
bad policy. If the updating of basic libraries was limited to shared
(for-all) extenions e.g. normally only able to be done by the
administrator then this whole thing would be a hell of a lot less evil
(but still wrong imho)

But, as I see this morning this discussion is a waste of my time, seems
that this change was already in, why even bother asking for an opinion
in the first place, unfortunately I find I am not surprised


good bye!