Debian Smart Upload Server
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
After talking with Joerg on IRC, based off a comment of his that
Debian should have a smart upload mechanism instead of FTP, I came up
with the following. Please review, inspect, and maybe command on it.
Debian Smart Upload Server Protocol
RFC - Drafted Tuesday 23 December 2008
===
Rational:
Currently, Debian employs an FTP based upload solution known as the
Incoming Queue to handle uploads and a queue daemon, debianqueued to
manage these uploads, and copy to the dak queue/unchecked folder
should they pass a basic tests such as successfully passing a GPG key
check. This protocol and proposal will change the queue import
function from a pull (debianqueued pulls files from the UploadQueue
directory), to a push (the upload from the client automatically
triggers basic checks, and either immediately triggers dak
process-unchecked, or some similar action) that isn't cron based,
allowing for instantaneous acceptance or rejection of a package.
Protocol Specification:
Contray to its name, the Debian Smart Upload Server Protocol (DSUSP)
is actually a fairly dumb protocol, designed to do two jobs, and do
them quickly and effectively.
1). Accept files from a client,
2). Validate them for near-instantaneous rejection or acceptance.
All protocol commands are ASCII based.
Command Protocol
====
Example command:
1234\0RECV\0ArgumentOne\0*payload*
All client commands start with an integer to state how long (in bits)
the incoming data is, followed by a null, followed by the command key
word, followed by any arguments, each ended with a null, and then the
payload of the command, such as a file. The payload has no ending
demented, the server will receive up to the length given by the
client.
RECV Command
Client -> Server
====
Arguments:
IncomingFileName - Name of the file the remote server is sending.
Description:
This command is to tell the remote server to receive a file. The
client must send a signed changes file as the first file uploaded. As
a security precaution, no file greater then 16 kilobytes shall be
accepted until a signed changes is received and its signature has been
verified to prevent a denial of service attack. Should a larger file
be sent, an automatic REJECT shall be sent, and the server shall
immediately close the connection.
Responses:
ACCEPT - The file received was accepted. The client should send the
next file in the series. No further informational shall be given in
the ACCEPT command
REJECT - The file was rejected. The reason shall be given as the
argument The connection should be closed from the server side
ACCEPT Command
Server -> Client
====
Arguments:
Information - Further instructions to be displayed to the user by the
client. Only used at the end of the transfer. May be blank.
Description:
This command tells the client that the server has accepted the last
upload, and is ready for the next file.
Responses:
The client may send any valid command
REJECT Command
Server -> Client
====
Arguments:
Reason - Reason the last upload was rejected.
Description:
This command tells the client that the server has rejected, with the
reason why. Once sent, the server shall disconnect.
Responses:
None. The connection is closed.
DEFER Command
Server -> Client
====
Arguments:
Reason - Reason the last upload was deferred.
Description:
This command tells the client that the server has deffered, with the
reason why. Once sent, the server shall disconnect. Defered uploads,
once processed, will send a normal ACCEPT/REJECT email once it has
been processed.
Responses:
None. The connection is closed.
DONE Command
Client -> Server
====
No Arguments
Description:
This command tells the server that all files are done uploading, and
is submitted them for processing.
Responses:
Same as RECV expect ACCEPT should include a reason behind it. Once
accepted, the server should close the connection. Can also send a
DEFFER command.
ERROR Command
Client Server
====
Arguments:
MD5 Hash - Hash of the last accepted file. If responding to a DONE
command, this shall be blank
Reason - Reason for the Error
Description:
Something went wrong on either end. The error message shall be sent,
and then the connection closed by the side that issued the ERROR
command.
Responses:
None.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org
iEYEARECAAYFAklRBXgACgkQpblTBJ2i2psdNgCfdopg/MWM5Z5YkvawpMzQuON4
V+wAnRJ9ljvvskoSLFCegFE0xlZf/ukf
=pg4U
-----END PGP SIGNATURE-----
Reply to: