[Savannah-hackers-public] Re: log_accum at Savannah

[Sylvain Beucler]

> log_accum.pl only runs at commit time.  You don't think it would be a
> reasonable assumption that anyone with commit access to the repository
> should have access to the tracker?

Not necessarily, because it depends on Savane's permissions. You could
be a member without access to any tracker.

Anyway, the real problem is that you could access another project's
tracker.


> Also, I wouldn't want the log_accum.pl script to try and close any
> issues.  I only imagined that it would annotate issues with
> information on related commits.  Since it seems to me that some
> issues might require multiple commits, it seems to me that closing
> the issues automatically on any commit would be bad, but I have
> thought that having that log message and list of URLs to diffs right
> in an issue would be handy in the past, and would almost certainly
> not be bad.

Ok. Usually people ask for interpreting '[closes #123123]' like the
Debian BTS, so I didn't thought about something more simple.


> > I have something in mind where the tracker service trusts the CVS
> > _machine_; then loginfo calls a setuid program that identify the user
> > using its system uid, and calls the tracker using credentials stored
> > in a private file.
> >   
> 
> This is about what I had in mind.  The users running log_accum.pl will
> have already authenticated to the CVS machine, so assuming that this
> authentication can be relayed to the tracker service securely, then this
> should be okay.

Yeah, the relaying part is what bothers me.


> > Meanwhile, using logging and mail notifications could ensure enough
> > after-the-fact security to start a quick hack, that we would hopefully
> > improve later on.
> >   
> 
> Yay!  :)
> 
> Do you know enough to write the SQL command (e.g. insert into
> bug-tracker values ($body) where id = $artifact_id)?  I can put it in
> the right place and fill in the variable contents in a few seconds.

Since there's the permissions to take into account, I suggest we do
something like in GForge: they call a URL to a new .php script. [I
should mention that GForge doesn't do any of the 'relaying
authentication' thing we discussed above...]

To authenticate this request, I think we need to pass via a setuid
program that will hold the necessary credentials - unless you have
another idea.

With that, we essentially need log_accum to exec that setuid script
and pass it:

- tracker type & number: you could accept the Savane notation: "you
  can add pointers to others items by typing artifact #nnn where
  artifact is one of support, bug, task, recipe, patch, file and nnn
  the item id number." - maybe not 'recipe' though.

- the comment body

-- 
Sylvain