aboutsummaryrefslogtreecommitdiff
path: root/utils
diff options
context:
space:
mode:
authorPaul Sokolovsky <paul.sokolovsky@linaro.org>2013-04-29 18:09:56 +0300
committerPaul Sokolovsky <paul.sokolovsky@linaro.org>2013-04-29 18:09:56 +0300
commit797bfa4729a128aee545bc4d3aedb686d16581ba (patch)
tree4972dadd8bca1b5d6a2a2e040d3b93c301db45c9 /utils
parent9555541f0d37a0169e9ce0e8146d4c8835c7f103 (diff)
Add Conclusions and Future Work for new-pub.
Diffstat (limited to 'utils')
-rw-r--r--utils/new-publish/README37
1 files changed, 37 insertions, 0 deletions
diff --git a/utils/new-publish/README b/utils/new-publish/README
index e63e000..b9be0c4 100644
--- a/utils/new-publish/README
+++ b/utils/new-publish/README
@@ -72,3 +72,40 @@ Publishing starts on build slave with SFTPing artifact files to master
processing by calling out (by SSH) sshd-config fixed script on master.
This script recursively applies same processing (chroot SFTP, fixed script)
to publish files to snapshots.
+
+Conclusions and Future Work
+---------------------------
+The biggest management and security issue with the implementation described
+above is authentication of publishing clients to publishing service.
+Implementation described above is cumbersome to setup and maintain and
+doesn't adhere to strictest security practices.
+
+To adress this problem, implementation of publishing as a web service may be
+suggested - this way, authentication handling on server side is confined to
+a single custom component, web application. It thus can be very flexible
+and featureful, for example, we can implement "publishing tockens", each
+associated with set of constraints, like "active not before 30min from
+time of issuance", "active not after 2hr from time of issuance", "can
+be used for publishing type 'android'", "publisher IP should be X.X.X.X",
+etc., etc. However, there still remains problems of issuing tockens for
+build hosts. Essentially, tockens should be "injected" into builds by
+a trusted party (a kind of build scheduling frontend). We already have
+frontend on android-build, but ci.linaro.org presents "raw" Jenkins. It
+might be possible to integrate needed functionality into Jenkins via plugin.
+
+But publishing few moderately-sized files is not the only usecase for
+Publishing Service. For OpenEmbedded builds, we need to publish used sources/
+cache files, which may be thousands of files totalling gigabytes. Except
+that any particular build would like likely change only reasonably small
+subset of these files, and only those need to bt actually published.
+This is clearly a usecase for rsync, but with rsync, we would need to deal
+with PAM for any custom authentication, and it's still unclear if it will
+possible to achieve flexibility simalar to tokens described.
+
+That's the dichotomy we have - we need efficient transfer protocol, as
+we potentially deal with many files and large amounts of data, and yet
+we need flexible token/ticket style authentication. It may be possible
+to choose a compromise between the two - implement a webservice with
+rudimentary "file freshness" protocol (which would work on the level of
+entire file, not sub-blocks). Existing system-level ticketing systems
+like Kerberos can be also considered.