Pike Extention Archive - PEA Pike Open Resource Keeper - PORK Pike Universal Resource Repository - PURR Pike Universal Plugin Archive - PUPA :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-10-16 05:22: Subject: module repository ramblings
In writing PUMA was never more than (dated 21 nov 2001):
Pike Universal Module Archive
- Goal
The goal of the PUMA project is to create a system for near to completely automatical storage, download, installation and management of 3rd party Pike modules. Both pure pike modules as well as C modules should be handled by the system. It should be possible to add more modules to the system without any contact with Roxen servers or any other Pike module provider. The system should ensure a fairly good authenticity over the origins of Pike modules.
- Project Name Issues
Currently the PUMA project is called PUMA (erhm), but the real name should be
- Pronouncable
- Free for domain registration (preferably .org).
- Free for use as a top module in Pike.
Possible name permutations might include
Pike Universal Module Archive Open Plugin Library Global Extension Decentralized Secure
(Pike Universal Decentralized Extension Library, anyone?)
- Module hierarchy
To ensure that there are no name clashes, all PUMA modules are stored in a (directory) tree under PUMA.pmod. Roxens only involvment is administration the PUMA top level, e.g. handing out identifiers directly below PUMA, e.g. PUMA.PExt. Everything below PUMA.PExt is then handled by whoever got responsibility for PUMA.PExt. A corresponding direcotry structure _PUMA.pmod exists for C modules.
- Security
Every module in the module hierarchy has got its own authentification key. When a new module is installed, e.g. PUMA.CPAN then the signature of the CPAN package is verified against the PUMA authentification key. When the package PUMA.PExt.PDF is installed the PDF package is verified with the PUMA.PExt key. If that verification failed, the package is verified against the PUMA key.
Note that no authentification is made after the a module has been installed, so unsigned packages may be installed manually.
A file signature is a MD5 checksum encrypted with a private RSA key. A module key is a the public RSA key that can decrypt the MD5 checksum. The module key is stored encrypted with any of the private keys of the parent module. The top module, PUMA, has only its unencrypted public keys.
- Finding packages
Every module may provide a URL where its modules are located. If no URL is provided, the parents URL is assumed. E.g. if the module PUMA.PExt is to be installed, the installation program queries PUMA for the location of its modules and gets a URL in return. The installation program downloads the package (hopefully) found at URL+"PExt" and installs it. Note that the PUMA administrator (Roxen) might send a HTTP referrer to another server.
A URL may use the protocols HTTP and HTTPS. A server may request a user/password response.
Requesting only URL will return a list of all available modules in a human readable list.
5.1. Multilevel download
Let's say that our Pike installation has no PUMA.PExt module and we want to install PUMA.PExt.PCRE. First the installer will download and install PUMA.PExt as described in section 5, and then it will check if PUMA.PExt.PCRE exists. If not, it will repeat the download, but quering PUMA.PExt for URL root and requesting URL+"PCRE".
5.2. Refresh module tree
It should be possible to refresh the module tree, e.g. starting from the PUMA module and search for all modules as if Pike had no prior knowledge of where to find them. This will update all moved URLs that might otherwise cause Pike to fail to install a requested module. If a package download fails, a refresh operations should be executed, at least on the failing branch.
5.3. Repair/Update module tree
It should also be possible to make a more extensive tree refresh, where all modules are downloaded and installed. This will repair/revert all modified files and bring the module tree up the latest versions. There is no real need to add any version system to the actual PUMA system. Installing CVS directories with the aproriate anon-CVS-root ought to be enough.
- Package format.
The package could be a tar.gz-file. It contains, apart from the actual files needed, a signature file, an information file and a Makefile file. The signature file obviously includes the signatures of all files in the package, the information file includes some formalized information about the package as well as the modules URL root.
/ Martin Nilsson (saturator)