cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Date Wed, 26 Mar 2003 09:45:36 GMT
David Crossley wrote:
> Stefano Mazzocchi wrote:
> 
>>Pier Fumagalli wrote:
> 
> <snip/> 
> 
>>>Folks, do you know that there's the possibility to alias certain subparts of
>>>a particular CVS repository from another repository?
>>>
>>>Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
>>>
>>>Apache does it already with its httpd-docs repository, aliased to
>>>httpd-2.0/docs (or something like it)...
>>
>>Uh, that sounds *AWESOME*!
>>
>>Could it be possible, then, to restrict access of some committers only 
>>to the doc module but have commits coming thru the *main* module land in 
>>there as well?
>>
>>That would solve all issues at once, I guess.
>>
>>Stefano.
> 
> 
> Hold on. In another thread (not sure when/what) we decided that
> there would be no distinction about cocoon committers. They are
> committers for the whole of code and docs and would have access
> to the whole cvs.
> 
> Your proposal is going against your earlier valid point that
> we ensure there is no "perception that documents are maintained
> by somebody else".

Wait. What I'm thinking is the chance of being able to use a dummy CVS 
user for a potential CMS that uses CVS as its document repository (won't 
provide fast xpath queries (well, we could index it side-by-side with 
xindice anyway, but will provide metadata and versioning).

The infrastructure teams *does* *not* like service-attached accounts for 
icarus/daedalus and this is to prevent the introduction of weaker 
security points than SSH to the workflow.

at the same time, we have community oversight over all changes, so even 
if somebody routes around security restrictions of our CMS and commits 
straight to the CVS bypassing all SSH security (becasue the CMS holds 
the private key of that dummy CMS account), he/she will simply write 
something on our docs, we'll get a commit email and we'll fix it and 
since publishing is manually driven, this won't never end up on the web 
site.

this is, IMO, a very safe architecture even if our CMS is exploited and 
its security bypassed.

but if we allow the CMS to work on the *entire* CVS repository (thus 
being able to touch code), I can predict that infrastructure will feel 
much more uneasy.

So, the proposal is not about forcing docu-oriented people as 
second-class citizens, but potentially allowing people (or services) 
that *request* or *need* to be docu-oriented-only to be able to be given 
karma like that.

Stefano.




Mime
View raw message