From 797bfa4729a128aee545bc4d3aedb686d16581ba Mon Sep 17 00:00:00 2001 From: Paul Sokolovsky Date: Mon, 29 Apr 2013 18:09:56 +0300 Subject: Add Conclusions and Future Work for new-pub. --- utils/new-publish/README | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'utils') 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. -- cgit v1.2.3