forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Van Kets <>
Subject Re: forrestbot: security and trust
Date Fri, 12 Jul 2002 19:50:17 GMT
At 15:42 12/07/2002 +0200, you wrote:
>Warming up for the rehaul/update of our forrestbot which currently does 
>automated builds of the Forrest website on
>What is in place currently:
>- a Linux 'role' account that has a cron job configured which goes off 
>every hour and calls this shell script:
># needed by X
>export DISPLAY=:1
># sets the location of the jdk
>export JAVA_HOME=/usr/java/jdk1.3.1_02
># changes directory to where xml-forrest is
>cd /xxx/xxx/roleaccount/xml-forrest
># updates xml-forrest from cvs
>cvs -q update -dP
># calls the forrest target that generates and deploys the forrest site
># the output of the run goes to forrestbot.log
>./ clean updateforrestsite > forrestbot.log
>As you see, it is very simple (and the only thing not committed to CVS for 
>those who were worrying about that). Bad thing: it is a 'role' account, 
>which is considered to be bad practice on
>Inside our build.xml file, you can find back some targets which use scp 
>for transporting the build result to Krysalis and a ssh command that 
>unpacks it and overwrites the existing site.
>On the Krysalis side, there exists a role account user with the same name 
>as on our side, and there is key-based password-less authentication  (ssh) 
>between both. So basically our forrestbot can start an ssh/scp session 
>with Krysalis without being prompted for a password, since its 
>(passwordless) private key for Krysalis resides on our side.
>OK. This works as long as we can keep our host uncompromized.
>Next step.
>We are going to do remote project docs building, presumably for Apache and 
>non-Apache projects alike (Gump-style). The big difference however between 
>Gump and Forrest is that Gump only reports (on a central location) and 
>nags, whereas Forrest will distribute its results to other locations as 
>well for updating those websites. Hence 
> where 
>the configuration for a single project is described, but you can easily 
>imagine other projects being specified in that file as well.
>OK. Now for the 'trust' thing...
>I've been looking into the ssh/scp documentation already, which would be 
>the typical publishing protocol to be used, and it is possible to run 
>those from a role/real account, pretending they are somebody else however, 
>by specifying the location of the identity file (private key) and the 
>username. I was much relieved by this ;-)
>This however requires projects to trust Forrest, and to provide Forrest 
>with a username/key combination that is able to access and update the 
>remote website. And Forrest will need to safely manage those credentials, 
>i.e. if the box where the central Forrest service runs on is compromised, 
>a lot of websites potentially could be defaced :-s

I'm not THAT familiar with server stuff and security, but can't the server 
do a user/IP address combination check.  Then only a request from the 
forrest server would be allowed to access the CVS source of the other 
projects.  Would be be secure enough, or is an IP address very easy to fake?


>What do you think? Is it feasible to work in this direction? Point is that 
>this would offer our users with a true headless/handsfree environment, 
>which is my personal pet peeve. Other option would be that each group of 
>projects has its own box, a forrestbot installed with credentials to 
>access/update the entire collection of documentation sources and website. 
>This might be feasible in the context, but I wouldn't mind 
>hosting/building other projects as well, IMO. OTOH, having a federation of 
>forrestbots for specific software project groups sounds sensible, too.
>Steven Noels                  
>Outerthought - Open Source, Java & XML Competence Support Center

View raw message