Pack publish policies

Discussion
1

By installing from a publically accessible URL, you publish the package. Maybe that is not a great choice today, especially as there is

swipl pack publish ...

If you want to install privately, use this from the pack source directory

swipl pack install .

Or create a tar and do e.g.,

swipl pack install mypack-1.23.tar.gz
2

OK, this explains it.

BTW, does that mean that if someone clones a public github repo they can just re-publish the same pack? And does it mean that even if I don’t do it anyone else could use pack_install/1 and “publish” it for me?

I guess the answer is somewhere in the code but I looked at it and there is a lot of it…

3

Once a pack is registered, the URL can not be changed (except for the version number). So, nobody can clone a pack and publish it as the same pack. If for some reasons the pack need to be moved to a different location this (now) requires admin intervention.

But yes, anyone can publish a pack this way.

swipl pack publish ...
  • Downloads the pack from the location
  • Builds and installs it locally
  • On success, contacts the server with download URL and meta-data.
  • The server downloads the URL and validates that the meta-data in pack.pl matches. It also analyses the content to produce the package page. If all is fine it registers the pack.

If the pack is already known, it validates that the URL is the same and that the version is newer than the latest known version.

All this clearly requires some thought. Notably registering a new pack is probably too easy. Possibly just turn the default registration to false, so you must use swipl pack publish ...?

4

Yes, this is at least less surprising.

I like the idea of “anyone can publish anything” but it is just a matter of time until someone uses this maliciously. :frowning:

5

No pack system that I am aware of protects against this. I registered an account at PyPi and published janus-swi there. Yes, you need to register, they check your email and you need to setup two factor authentication, but I could have faked all that, leaving no trace behind and upload a malicious pack. This situation is similar to all pack systems I am aware of.

The pack system basically guarantees that, once a pack is claimed, it is controlled by some entity (person, team, …). This entity is, as long as it is careful with the credentials, the only entity that can push new versions of the pack.

This is precisely what the SWI-Prolog pack system does: once you claim a pack you claim a URL space. If you use a GIT repo, this is simply the HTTPS location of the repo. Otherwise if you upload from https:<host><dir>pack-version.zip it will create a pattern https:<host><dir>pack-.*\.zip and only accept an update from a URL that matches this pattern. Thus, as long as the entity makes sure it has exclusive control over https:<host><dir>, nobody else can upload. If I recall correctly, it has some additional rules for GitHub that allows switching between archives and the git URL itself. This route was chosen for two reasons:

  • No need to implement trustworthy registration and authentication as we relay the responsibility to the entity having exclusive control over a URL.
  • No risk for SWI-Prolog distributing illegal content as the SWI-Prolog pack system only acts as a directory.

Whether or not you should install a pack, considering security is up to the user. A security aware user shall analyse the pack, for example on the pack page, before installing. Note that version of the pack on the website is identified by a content hash. If you install the package it will download the package and first check the content hash. On a mismatch it will warn you.

As there are more users who installed the pack, it gains trust and it is probably safe to install (almost) blindly.

1 Like