QuantLibXL.xla digital signature

[Ferdinando M. Ametrano-3]

On 5/3/07, Luigi Ballabio <[hidden email]> wrote:
> > Log Message:
> > -----------
> > digital signature added back
>
> I see a lot of these messages lately. How manual is the generation of
> the signature? It seems like something that could be added as a
> post-build action...

there's not that much we could do as far as I know. I summarize my
best understanding below, hoping somebody here has some clever
suggestion

QuantLib.xla is not built in any way, so a post-build action is not
appropriate. Besides the xla can only be signed on my workstation
(more on this later).

Let's look at Excel:
1) Excel has different macro security levels (Tools | Macro |
Security). "Low" is not recommended as it means no protection at all.
"Medium" allows the user to choose whether or not to run "potentially
unsafe" macros: when loading macros it pops up a message box asking
the user if he trust the macros. "High" only trusts signed macros
2) as most developers/beta_users select "medium" security level it's
annoying that every time they load QuantLib.xla Excel asks them if
they trust the macros. here is where digital signature comes into
play: if QuantLib.xla is signed and they trust its (public key)
certificate the question is asked only once and no more
3) if developers/beta_users select "high" security level having a
signed xla is simply mandatory

We have signed QuantLib.xla with a self-certificate, that is a
certificate whose private key cannot be exported and shared, but it
just lives on the workstation where it has been created. If any
developer modifies the xla the signature is lost, and can only be
added back from the original workstation, i.e. currently by me.
Even if in this way we haven't solved any security issue at all, at
least developers/beta_users who trust the (public key) certificate
have a way to avoid the annoying pop up in "medium" security level or
to use QuantLib.xla in "high" security level. Should I lose access to
my current workstation any developer could just issue another
self-certificate, sign the xla, and developers/beta_users will have to
trust this new (public key) certificate

Buying a true digital certificate would not make things really better
for developers/beta_users, as we would face similar problems: whenever
a developer without the private key alters the xla the signature is
lost. Sharing the private key between all developers would actually
invalidate the level of protection provided by a private key, so we
would get back to the situation we have now with the self-certificate,
but we would also have to pay yearly fees.
A true digital certificate would helps in signing QuantLib.xla for
official releases, providing final end users with a real security
protection.

So manually adding back the digital signature using the (private key)
self-certificate on my workstation is the only solution we have found
so far that allows developers/beta_users who trust the distributed
(public key) certificate to avoid pop ups when using QuantLib.xla with
"medium" Excel security level or to use QuantLib.xla in "high"
security level.

If anyone has suggestions to improve the current situation it would be
more than welcome

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev