In writing PUMA was never more than (dated 21 nov 2001):

Pike Universal Module Archive

1. 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.

2. Project Name Issues

Currently the PUMA project is called PUMA (erhm), but the real name should be

1. Pronouncable 2. Free for domain registration (preferably .org). 3. 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?)

3. 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.

4. 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.

5. 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.

6. 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)

Previous text:

2003-10-16 05:05: Subject: module repository ramblings

---

I've taken a few minutes to jot down some ramblings concerning a Pike module repository. I know that there was a proposal a while back called PUMA, though I can't find any trace of it when I went to look for it. I'm sure that it has some very good ideas that I will have neglected to include here. If that's the case, or if you have any thoughts, please feel free to send them my way.

• Initial tasks that need to be accomplished

1. The build/install system should be updated for the various varieties of

modules:

Modules with C component (ok) Modules with C and one Pike (ok, but see the problem below) Modules with C and multiple Pike Modules with Pike (see the problem below) Modules with multiple Pike

2. Skeleton modules should be prepared for the various varieties of

modules.

3. The documentation build tools should be modified to allow partial

merging of new documentation. The extracted documentation should be installed to facilitate the documentation process.

4. A local install option should be added so that a user may install a

module in their local module tree.

5. A method for passing arguments to the configure process should be

developed.

• A Practical Problem

When someone is granted a spot in the namespace, what are they getting? do they get the whole subtree below where they've been granted?

Example: if I get Protocols.NNTP, for the purposes of making a client, can anyone else get their module in that tree or do they have to look somewhere else? I worry that we'd end up with essentially a 2 level module tree.

Also, this problem manifests itself in the handling of the installed modules and how to make room for others. If a module is installed like this (example Protocols.NNTP):

lib/modules/Protocols.pmod/NNTP.pmod (single pike file)

how do we handle someone wanting to create Protocols.NNTP.Server?

would it be better to have all modules installed as module.pmod within ModName.pmod direcories? This would give the maximum amount of flexibility as far as making room for other modules to be slid in, but really seems inefficient, in that we'd most likely only have one module file per directory.

• Namespace Management

Coordination of the namespace will be handled by a namespace management board ("the Board"). The board should be made up of not less than 3 developers. The board should reflect the makeup of the Pike user community, with representatives from the IDA team, core developers and non-core developers.

Q: Should there be requirements for membership and/or rotating positions?

The Board is responsible for the smooth operation of the repository, and for keeping the namespace manageable. The Board is the final authority for handling namespace issues that may arise among developers. When practical, the Board should attempt to obtain consensus among its members when making decisions.

The Board may delegate responsibility for a given branch of the module naming tree to a non-Board member, though the Board will always retain the right to assert control over delegated branches.

Coordinators of delegated branches must remain active in thier role. If such a developer is no longer able to perform the duties of a branch coordinator, they must return control of the branch to the Board. All coordinators should be contacted on a regular basis (several times per year) to verify that they are accessible and able to carry out these duties.

• Duties of coordinators might include:

a) granting positions in the tree to other module developers b) assisting module developers in making wise decisions concerning module and class naming c) making sure that modules in their respective section of the repository comply with the requirements for inclusion (quality control)

• Adding modules to the repository

Before a module can be contributed to the repository, the module's author must request a place for that module within the module namespace. The request should include at least the following:

a) Developer Name b) Contact Information (at least email, but potentially other means) c) Proposed module location in the namespace d) Estimated scope of namespace usage (subclasses and possibility of other modules beneath) e) Request for coordination (if the tree is not already delegated)

Ideally, the process for making requests and having the requests approved would be streamlined and part of a semi-automated workflow.

• Requirements for modules in the repository

All modules must meet the following requirements (quality control):

a) Author name and contact information must be provided b) License must be clearly declared c) Version of the module must be included as a constant in the module d) API Documentation (should be provided), and must be in autodoc format e) Modules must use the standardized build and installation interfaces f) Modules must not cause interference with other modules in the tree

A directory of information about modules in the repository will be maintained by the Board. This directory should contain information about modules, their function, changes and versions, compatibility and dependency information. A distributed network of nodes will make the directory and the modules themselves available for access by users. The directory will also be used to provide a web service that will allow a user to locate, download and install modules automatically.

Well, that's about all I have for now. Please give me your thoughts, flames and other assorted musings.

Bill

/ Brevbäraren