Is there any "try catch" functionality in VCL? If not, how to handle runtime errors in vcl_init?
Dridi Boukelmoune
dridi at varni.sh
Wed Apr 19 16:29:08 UTC 2023
On Wed, Apr 19, 2023 at 4:25 PM Batanun B <batanun at hotmail.com> wrote:
>
> Hi,
>
> We use the vmod crypto to verify cryptographic signatures for some of our traffic. When testing, the public key was hard coded in the VCL, but before we start using this feature in production we will switch to reading the public key from a file on disk. This file is generated on server startup, by fetching it from an Azure keyvault.
>
> Now, the problem I'm picturing here is that this fetching of the public key can fail, or the key can be corrupt or empty, maybe by user error. Or the key could be valid, but the format of the key happens to be unsupported by the vmod crypto. So, even if we do our best to validate the key, in theory it could pass all our tests but still fail when we give it to the vmod crypto. And if that happens, Varnish won't start because the vmod crypto is initiated with the public key in vcl_init, like this:
>
> sub vcl_init {
> new cryptoVerifier = crypto.verifier(sha256, std.fileread("/path/to/public.key"));
> }
>
> What I would prefer to happen if the key is rejected, is that vcl_init goes through without failure, and then the requests that use the cryptoVerifier will fail, but all other traffic (like 99%) still works. Can we achieve this somehow? Like some try-catch functionallity? If not, is there some other way to handle this that doesn't cause Varnish to die on startup?
It's the VMOD author you should ask to have an option to ignore public
key errors.
This is a constructor, and even if we had a try-catch kind of
construct in the language, I don't think we would make this one
recoverable.
Dridi
More information about the varnish-misc
mailing list