"Action Items" From FUDCon?

[Jeffrey Ollie]

On 1/14/08, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Jan 13, 2008 8:50 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
> > >From what I know of CVS, this isn't possible from inside CVS and
> > likely very difficult from outside CVS too.  Basically, you'd have to
> > set up a database outside CVS that would track the version (and maybe
> > the MD5/SHA signature) of every file that koji used to build the SRPM.
> >  With this setup you could at least know if CVS had been messed with
> > after Koji did the build.
>
> Are you aware of what are cvs is setup to do right now?  make srpm
> basically provides the needed functionality in a checked out cvs tree.
> For the purpose of recreating srpms for binaries we distribute
> on-demand we just have to have tags we can trust corresponding to a
> build we can trust. In discussion with infrastructure and release
> people before it was brought up that it would be a good idea to have
> koji re-tag back into cvs after a build to indicate it was a
> releasable build and that its a trivial change in how things are done.

The problem with your line of reasoning is that you can't trust the
tags in CVS.  Isn't that why we are having this discussion in the
first place?  If people can move the regular tags in CVS (and they
can) they'd be able to move the tags that Koji adds just as easily.

Why not extend the taginfo script already in use to prohibit tag
moving and deletion?  For extra points you could only prohibit moving
or deleting tags that had been submitted to Koji for a build (I think
that you'd want to preserve even unsuccessful build tags for
postmortems).  While the security/reliability of CVS's scripts isn't
stellar (re the syncmail control-c problems) this would get you closer
to the goal.  I think that this would also have a deleterious effect
on the speed of the tagging operation.

Personally, I'm tired of hacking around CVS's deficiencies and would
rather work on moving to a VCS that provided stronger guarantees about
the integrity of the data.

Jeff