Hi, has anyone tried to serve a PCM repo from a local folder or network share?
Or must the URL strings to the repo and inside the json meta files always point to http(s) ressources? If not, could it work with “file:///” links? I tried to add a locally referenced repository.json but received the error “unsupported protocol”. It seems the PCM uses curl but that should support file urls!? Is it blocked by the PCM module?
I’m on Win10 @ latest KiCad stable.
According to the curl documentation a particular implementation might be compiled without support for some schemes.
Also note that the scheme in a local file URL is actually file:// (two slashes). You often see the third slash for Unix/Linux because that indicates the root of the filesystem. On Windows it might be something like file://C:\Users\blahblah… Or maybe it has to be a UNC path. Whether those actually work, well, it depends…
Local paths used to be supported but it was limited to http(s) in
@imcinerney to weigh in on if it’s prudent to add file:// there.
Update: actually it’s not very useful anyway because repository has packages link which is required to be http(s) by the schema validation. So you would only be able to host repository.json locally, packages.json still has to be on a web resource.
It’s easy enough to host a local directory on a web server using
python -m http.server --directory <path>
@imcinerney to weigh in on if it’s prudent to add file:// there.
Update: actually it’s not very useful anyway because repository has packages link which is required to be http(s) by the schema validation. So you would only be able to host repository.json locally, packages.json still has to be on a web resource.
It would depend on if we want to support pure-local repositories and made sure there was protection against malicious file:\\ links. Limiting the CURL protocols helps to lower the library code that could possibly be used (since CURL has multiple protocols in it, we would be affected by CVEs in any of them without that change), but additionally removing the file:\\ protocol prevents any filesystem access by CURL.
Looking through the schema, I guess technically the URLs are supposed to only have https: and file: (no http: though?) in the URL definition. However, how safe is it to allow file links? I could see that being a possible route for malicious file exfiltration, where someone serves a repository.json with one of the packages being a local URL (such as file:\\\etc\passwd), and then if the user tries to install it (or update the packages cache if they put that as the packages file for the repo), we end up copying the file into a temp/cache directory making it more vulnerable.
Feel free to open an issue over on GitLab though, we can discuss it more there and dive into the security aspects of it with the rest of the dev team.
Looks like we both misread the regex. I missed the file:// part and you missed the ? in the https part.
I filed PCM: local filesystem repository support (#13060) · Issues · KiCad / KiCad Source Code / kicad · GitLab to discuss further.
Wow. Thanks for the discussion and further reactions at GitLab. The original purpose was to deliver a small preconfigured set of some plugins to some colleagues.
I’d prefer to leave possible security risks low and can understand the reduction to only-http(s) links of curl. In my use case the manual pcm file install would be the quickest to achieve this even if this means some clicks more…
This topic is solved for me because I have my answer why file links (currently) doesn’t work. Is here a tradition to mark this as [SOLVED]?
Yes, just edit the title of this post and write [SOLVED] before the title. 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.