summaryrefslogtreecommitdiff
path: root/tupkg
diff options
context:
space:
mode:
Diffstat (limited to 'tupkg')
-rw-r--r--tupkg/README.txt99
-rwxr-xr-xtupkg/client/tupkg19
-rwxr-xr-xtupkg/server/tupkgs22
3 files changed, 140 insertions, 0 deletions
diff --git a/tupkg/README.txt b/tupkg/README.txt
new file mode 100644
index 0000000..47facc4
--- /dev/null
+++ b/tupkg/README.txt
@@ -0,0 +1,99 @@
+TU Packaging Tools (tupkg)
+--------------------------
+- client side (python for proof of concept, later re-write to C?)
+ The main purpose of this tool is to upload the compiled
+ pkg.tar.gz to the server. It can (should?) do some verification
+ on the package prior to uploading to the server. It will have
+ a config file to store run-time information such as username
+ (email), password, and server name.
+
+- server side (python for proof of concept, later re-write to C?)
+ The server side will handle incoming connections from its client
+ side counterpart. The server should bind to port 80 (maybe a
+ vhost such as tupkg.archlinux.org?) so that firewalls won't be
+ an issue. The server verifies the client authentication data,
+ and then accepts the package(s). If port 80 is not available,
+ perhaps 443, or are there other 'standard' ports that usually
+ do not get filtered?
+
+ I think the server should be multithreaded to handle simultaneous
+ uploads rather than queue up requests. The download should be
+ stored in a temp directory based on the username to prevent
+ directory, filename clashes.
+
+ Once the package(s) is uploaded, the server can either kick off
+ a gensync, or we can write a separate script to call gensync once
+ or twice a day. My preference would be a separate script to call
+ gensync (like the *NIX philosophy of one tool per task).
+
+- protocol (c: => client, s: => server)
+ Whenever the client/server exchange a message, it is always
+ preceeded by two-bytes representing the following message's
+ length. For example, when the client connects, it will send:
+
+ 0x0028username=bfinch@example.net&password=B0b
+
+ 0x0028 is the 40 byte strlen of the message in two-bytes. The
+ client and server always read two-bytes from the socket, and
+ then know how much data is coming and can read that amount of
+ bytes from the socket.
+
+ ==> authentication
+ c: username=emailaddy&password=mypassword
+ s: result=PASS|FAIL
+
+ NOTE: We can add encryption easily enough with the python
+ version using the socket.ssl method.
+
+ ==> uploading package data
+ if PASS:
+
+ c: numpkgs=2&name1=p1.pkg.tar.gz&size1=123&md5sum1=abcd\
+ name2=p2.pkg.tar.gz&size2=3&md5sum2=def1
+ s: numpkgs=2&name1=p1.pkg.tar.gz&size1=119&\
+ name2=p2.pkg.tar.gz&size2=0 (*)
+
+ (*) NOTE: The server will reply back to the client how many
+ packages it has already received and its local file size.
+ This way, the client can resume an upload. In the example
+ above, the server still needs the last four (123-119) bytes
+ for the first package, and that it has no part of the
+ second package. The client would then begin sending the
+ last four bytes from the first package (p1.pkg.tar.gz) and
+ then follow it with the full second package (p2.pkg.tar.gz).
+ The data would be sent as a continuous chunk of data. The
+ server will then need to track which bytes belong to which
+ package.
+
+ else FAIL:
+ c: -spits out error message on stderr to user-
+
+
+ ==> after upload completes
+ The server should verify the integrity of the uploaded packages
+ by doing an md5sum on each and sending the info back to the client
+ for comparison. After sending the message, the server waits for
+ the 'ack' message from the client and then closes the connection.
+
+ s: np=2&m1=PASS&m2=FAIL
+ c: ack
+
+ The client replies with the 'ack' and then closes its connection
+ to the server. It then reports the PASS/FAIL status of each
+ package's upload attempt.
+
+ NOTE: If the upload fails (client connection dies), the server
+ keeps any data it has received in order to support resuming an
+ upload. However, if the client uploads all data, and the server
+ successully reads all data and the final MD5 fails, the server
+ deletes the failed package.
+
+
+Terms/definitions:
+======================
+TU - No change (trusted by the community, if anyone asks what trust
+ means)
+TUR - renamed to Arch User-community Repo (AUR) (so we can use -u for
+ versions)
+Incoming - renamed to "Unsupported"
+
diff --git a/tupkg/client/tupkg b/tupkg/client/tupkg
new file mode 100755
index 0000000..ab42b43
--- /dev/null
+++ b/tupkg/client/tupkg
@@ -0,0 +1,19 @@
+#!/usr/bin/python -O
+#
+# Description:
+# ------------
+# This is the client-side portion of the Trusted User package
+# manager. The TUs will use this program to upload packages into
+# the AUR. For more information, see the ../README.txt file.
+#
+# Python Indentation:
+# -------------------
+# Use tabs not spaces. If you use vim, the following comment will
+# configure it to use tabs.
+# vim: ts=2 sw=2 noet ft=python
+#
+
+
+
+# TODO write the code
+#
diff --git a/tupkg/server/tupkgs b/tupkg/server/tupkgs
new file mode 100755
index 0000000..2c410a5
--- /dev/null
+++ b/tupkg/server/tupkgs
@@ -0,0 +1,22 @@
+#!/usr/bin/python -O
+#
+# Description:
+# ------------
+# This is the server-side portion of the Trusted User package
+# manager. This program will receive uploads from its client-side
+# couterpart, tupkg. Once a package is received and verified, it
+# is placed in a specified temporary incoming directory where
+# a separate script will handle migrating it to the AUR. For
+# more information, see the ../README.txt file.
+#
+# Python Indentation:
+# -------------------
+# Use tabs not spaces. If you use vim, the following comment will
+# configure it to use tabs.
+# vim: ts=2 sw=2 noet ft=python
+#
+
+
+
+# TODO write the code
+#