[Catalog-sig] Moving forward

[Martin v. Loewis]

>   1. How can the server identify the uploader? You can include an
> optional signature file, however if you don't include this file there is
> no way to associate an identity with the uploaded file.

Sure there is: there should be an author= argument to setup. If the
package is not signed, the server could assume that the package is
submitted by the author of the package. Of course, that would require
manual verification of some kind by the server operator at some later
point. The Author: is also available in the PKG-INFO.

> In my prototype even if you don't include a signature file the
> server requires an account and keeps track of who uploaded
> what. Perhaps there could be optional support for HTTP
> authentication during the upload. This would allow the distutils to
> supply optional authentication credentials.

IMO, many security protocols suffer from there being to many options.
We have a authentication procedure which involves verification that
the package was really produced by someone with a certain identity, I
don't think there is need for another authentication mechanism.

As for "HTTP authentication", I assume you mean the Basic
authentication. As you surely know, this has major problems from a
security point of view; it is almost as good or bad as plain
identification. As I said, identification is already possible through
the distutils author= argument, although there might be need for an
additional packager= identity - as supported by the bdist_rpm command.

>   3. PKG-INFO conflicts. The PEP allows both extraction of the PKG-INFO
> file from the package and an optional upload of the PKG-INFO file. What
> happens if these files are not the same. I propose that the PKG-INFO
> file in the package be used if there is a conflict.

I'd think that should be an error - although it is probably a
quality-of-implementation issue to detect that error automatically.

> > * The prototypes need to begin evolving toward being
> >   production-usable.
> 
> What are the criteria for production usability? I'd say we need to have
> a basic level of usability and stability.

I think the most important aspect is that somebody needs to start to
operate a server as if it was in production use. That means they need
to have an out-of-band procedure to accept public keys, and a download
facility. The packages being uploaded must be persistent (and ideally
available for immediate download), and an administrative contact
address must be set-up. Of course, the servers should follow the
protocol to the letter of the spec.

I understand that there are some basic parameters to the protocol
(e.g. the URL of server); I think we need to minimize these parameters
(to, say, just the host name, fixing the relative path on the host).

Regards,
Martin