Having a Plugin doing the signature verification is one thing. The Plugin could even alert the user in case the signature is broken.
But right now there is no way to get that information into the OOo framework, which then makes sure that the status occurs in the status bar, and that the signature status can be used for the macro security level stuff.... Malte. Joachim Lingner wrote, On 03/04/08 17:08: > I learned that there are document load and document save events which > could be received by an extension. This could be some kind of entry > point for a signature service in an extension. But then again you need > to provide your own dialog. You could of cause use the low level > services (unpublished) but with the risk that the implementation breaks > later. > > Or you may also try to disentangle the code of the document signature > service > to have a clearly separated GUI packed into a UNO service. Then you > could use this GUI as well from your extension. > > -Joachim > > Joachim Lingner wrote: >> Giuseppe Castagno wrote: >>> Hi Joachim, >>> >>> Joachim Lingner wrote: >>>> Giuseppe Castagno wrote: >>>>> Hi all, >>>>> >>> ... >>>>> The idea was to write an extension to sign, but it seems that ATM >>>>> OOo lacks the needed stuff, e.g. it doesn't seem possible to sign a >>>>> document with a 3rd part signature method. >>>> Thats true. There is currently no way of plugin in a different >>>> mechanismn let alone something to switch between the them. >>>> >>>>> Actually I found a bunch of services in that area (an example [1]), >>>>> but almost all are tagged as 'unpublished'. >>>> True. >>> 'unpublished' because not supported or what? >> unpublished interfaces can be changed, removed at any time. So if you >> write an extension you should use always published ones. >>>>> Are there any plan to implement this in 3.x codeline? >>>> No, afaik. >>> I see, lack of resources or some other reason? >> Well, you are the first to ask for such a "pluggable signature >> framework" AFAIK. Given that it is a useful feature, and I think it is, >> there is still the question of who is going to do it. In that sense it >> is always a question of priority and resources. >> >>>> There is also the problem that the GUI code is mixed up "signing >>>> logic". This needs to be separated. >>>> One could also think of an options page where the user could select >>>> different signing methods. However, there is nothing planned yet. >>>> >>> I had a look to the code stuff. It seems all inside xmlsec module. >>> If I have specific questions to the current code, is there a dedicated >>> ML to ask for? >> Please ask on [EMAIL PROTECTED] >> >> -Joachim >>> Giuseppe. >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
