rdflib icon indicating copy to clipboard operation
rdflib copied to clipboard

Published 20 hours ago • verified publisher icon RDFLib

Fix/1369 custom resolver

Open alexdutton opened this issue 4 years ago • 5 comments

Fixes #1369

Proposed Changes

This adds a new Resolver framework, and updates the JSON-LD parser to use it.

As a result, implementors have much more control over which URLs referenced in JSON-LD documents will be resolved.

This PR implements a default-deny approach to URL resolution, which will need explaining in release notes and documentation. Implementors can revert to the old behaviour via environment variable if they are happy with the risks.

This also provides a base for future extensibility, e.g. caching or using locally-held copies of external resources.

No tests or documentation yet, but all existing tests pass when using the new PermissiveResolver.

alexdutton avatar Aug 04 '21 13:08 alexdutton

Hi @alexdutton I am watching this PR with interest - I think it's a great idea to have "everything" available to RDFlib users, and, if scary, off by default - so look forward to you bringing it out of draft.

Just a couple of questions:

  1. Has this work of yours been motivated by the JSON-LD parser & serializer now being in RDFlib core?
  2. Do you have your own code like this in action already, just not in RDFlib?
  3. Can you please add some notes to the top of the new file rdflib/resolver.py to explains what it's doing, perhaps something like rdflib/compare.py (though doesn't have to be as long!) This just helps with people and file browsing

nicholascar avatar Aug 28 '21 06:08 nicholascar

Hi @nicholascar

  1. I didn't realise the JSON-LD support had been moved into core when I first realised this was an issue, but still saw the fix as being in core as that's where the resolution behaviour was.
  2. No, I don't have similar code elsewhere. This was precipitated by needing to implement a Linked Data Notifications inbox for the COAR Notify initiative, which involves receiving JSON-LD documents to a publicly accessible HTTP endpoint.
  3. Yep, I'll do that now :-)

alexdutton avatar Sep 14 '21 11:09 alexdutton

@alexdutton this PR is still in draft. Are you planning on taking it out of draft soon so we can review it formally?

nicholascar avatar Nov 24 '21 13:11 nicholascar

This is a critical vulnerability. Will this be fixed in 6.3 release? Do we have a date for it?

ramcaat avatar Dec 07 '22 15:12 ramcaat

This is a critical vulnerability. Will this be fixed in 6.3 release? Do we have a date for it?

The plan is to fix in in 6.3, but sadly I have very little time to work on this. I will be having some days off work later this month and I hope to finish it then.

aucampia avatar Dec 11 '22 19:12 aucampia