On 1/14/08, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote: > On Jan 13, 2008 8:50 PM, Jeffrey Ollie <jeff@xxxxxxxxxx> 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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
