optionally enforce strict TLS handling

[jonassmedegaard]

By default LWP::UserAgent is relatively forgiving about TLS problems. This is a problem when caring about the trust chain, in particular for use with Web::ID.

This issue is documented e.g. in the POD description of Net::SSLGlue and concerns is raised e.g. at the W3C WebID list.

Simplest seems to be to use Net::SSLGlue::LWP - but Toby Inkster points out that this has a global affect, i.e. may hurt LWP operations independent from RDF::Trine as well.

It seems to me that same tightening offered by Net::SSLGlue::LWP can be had by setting ssl_opts option of LWP::UserAgent to '{ verify_hostname => 1 }'.

There might be further improvements possible, but seems the ability for RDF::Trine to support setting that flag is at least a start.

[kasei]

Would you want this as a single flag like:

RDF::Trine::Parser->parse_url_into_model( $url, $model, verify_hostname => 1 )

or do you think the user should be giving the verbose form to pass explicitly to LWP, e.g.:

RDF::Trine::Parser->parse_url_into_model( $url, $model, lwp_options => { ssl_opts => { verify_hostname => 1 } } )

[jonassmedegaard]

the verbose form is better, I think - or the opposite: I don't know which options might be useful so some, and cannot see how providing access to all could be harmful :-)

[kasei]

OK. I'll work something up and let you know when I push it.

[kasei]

The LWP::UserAgent documentation seems to suggest that { verify_hostname => 1 } is the default. Have I misunderstood something about what you want here? I'm still planning on making it possible to pass in options to LWP, but it seems what you're asking for is already happening...?

[jonassmedegaard]

Oh.

More likely I have not done my homework properly. I will take a closer look and get back to you...

[kasei]

Commit 44728d4 has now added:

RDF::Trine->default_useragent( $ua )

that allows setting a custom user agent object for use in network requests. Additionally, if you want to use a custom user agent just for the one operation, you can now do:

RDF::Trine::Parser->parse_url_into_model( $url, $model, useragent => $ua );

which I think is a cleaner interface than having users pass in the LWP::UserAgent constructor arguments. The only thing I'm not sure about is whether this should forcibly set the Accept header on $ua before the request, or assume that the user knows what they're doing and has set custom headers appropriately. If we make that assumption, there should probably be a way for RDF::Trine::Parser to expose the Accept header string that it would ordinarily use for the request so that people can access it themselves when constructing a custom user agent.

Thoughts?

[kasei]

I just went ahead and added RDF::Trine::Parser->default_accept_header to return the accept header value.

[jonassmedegaard]

sounds like an elegant approach. That seems to even leave room for my not really being certain what exactly it is that I want to tighten...

...and for others to do their other crazy distortions :-D