Re: A Proposal to solve the non-US problem.
The system I am proposing has four components: the restrictions file, the
restrictions header, the global restrictions file, and the peer to peer
transport system. This system is based on ideas put forward by many
people. The only part I can really claim as my own is the usenet-like peer
to peer system.
The restrictions file is created by the maintainer and placed in
/usr/doc/<package>. It has three sections: a list of borders that the
package must not cross, a brief description of the restrictions, and a
longer explanation of them. The first two sections should follow a strict
format so that the packaging software can easily use them to generate a
restrictions header. The third section is explanatory text for users.
Sample restrictions file for gpg:
us-any any-us any-fr
Must not be exported from the US or imported into France.
gpg may not be exported from the US because of munitions export laws. It
may be imported into and used and distributed in the US but may not be
put up on ftp sites accessible to foreigners. Since Debian sites are
public it cannot be allowed on them in the US. French residents are
forbidden to use encryption.
The restrictions header is in the control file and has two sections: a list
of borders the package must not cross, and a brief description of the
restrictions. It is generated by the packaging software or by hand by the
maintainer.
Sample restrictions header for gpg:
Restrictions: us-any any-us any-fr
Must not be exported from the US or imported into France.
The global restrictions file is a list of all known restrictions. It
exists on every Debian peer and is updated by dinstall whenever a
restricted package is added or removed. It is the same on all peers.
Sample global restrictions file:
pgp-i: us-any any-us any-fr
pgp-us: us-any any-us any-fr
gpg: us-any any-us any-fr
doom: any-de
The peer to peer transport system uses a usenet-style flooding algorithm to
synchonize the peers. Before sending each package it checks the global
restrictions file and holds the package back if it must not be sent to the
destination peer. Packages received via the transport software go into
Incoming and get checked again by dinstall (redundancy is good). Whenever
a peer changes its copy of the global restrictions file it sends a control
message via the transport system informing the other peers of the change.
Package deletions are handled with cancel messages similar to usenet
cancels. Like usenet cancels, these should probably not be allowed to take
effect until a human reviews them.
The peers mentioned above are not ftp mirrors. They are masters under
direct control of Debian, and there is likely to be only a small number for
the forseeable future. Ordinary mirrors need not change anything.
Examples:
I upload foobar1.0-1 to master. When dinstall runs it checks the
restrictions (none), installs the package, updates the global restrictions
file, and feeds the package to the transport software. From here the
package propagate exactly like a usenet article (going through Incoming and
dinstall at each peer) and soon is available on every Debian site.
Lars attempts to upload mudmonsters1.1-1 to erlangen. It bounces when
dinstall sees 'any-de' in the restrictions header. He then uploads it to
chiark, which accepts it and it propagates just like foobar, but is stopped
from sending it to erlangen by the global restrictions file. If the
package does somehow get sent to erlangen, dinstall will drop it on the
floor.
This system solves the restrictions problem and eliminates the need for
non-us and the like while requiring no changes in the archive layout. It
also provides redundancy so that next time master has its traditional crash
just before a release we just keep on truckin. It does not require mirror
operators, CD makers, or users to change anything. Mirrors can continue
just as they are, switch to a Debian peer in a country with compatible
laws, upgrade to enhanced software that understands restrictions, or
install the Debian software and become passive leaf nodes. Users can
upgrade to an enhanced apt at their leisure. The enhanced apt could show
the user the description and restrictions headers before downloading, and
use a prioritized list of sites to download from.
The first method of handling dependecies I thought of was to make the
global restrictions file entry for a package be the union of the
restrictions on it and all of the packages it depends on. I think it would
be better, though, to make dinstall refuse to install any package whose
dependencies cannot be satisfied locally. This will prevent packages from
dangling for any reason, rather than just because they depend on a locally
illegal package. However, the system will work with either method of
handling dependencies or none.
To do (not an exhaustive list):
The 'language' for describing restrictions must be carefully designed. It
must be easy for maintainers to write correct restrictions in, easy for
software to parse, and general enough to accomodate future bizarre laws.
dinstall must be modified to understand restrictions and know about the
transport system.
The transport system must be designed and analyzed for stability.
At least one non-US peer must be created. The site must be under Debian
control.
Policy must be enacted to implement all this.
--
John Hasler This posting is in the public domain.
john@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
Reply to: