[CentOS-devel] Back on CentOS-devel to get some git.centos.org improvements

Fri Jul 4 13:46:30 UTC 2014
Nico Kadel-Garcia <nkadel at gmail.com>

Morning, folks. Happy July 4th.

I'm hopping back onto centos-devel to raise some concerns about
git.centos.org components. Overall it's working. There are things I
don't like, but as things stand that's *my* problem.  These issues,
however, affect others, and I don't see a good bugzilla mentioned at
git.centos.org itself.

1) Many repositories are being listed with excessive "/" in their
names. It messes up alphabetization and can get quite confusing.

              rpms/docker, for example, is listed as
"https://git.centos.org/summary/?r=////rpms/docker.git"

2) The "show_possible_srpms.sh" script relies on checking for the word
"import" in the git logs to determine SRPM versions, embedded in the
git logs themselves. This raises the risk of *any* commit that uses
that word for other reasons to report an invalid  SRPM version number.
As much as I dislike relying on a git log rather than a signed tag to
do a build, please, refine this script to at least grep more carefully
for 'import' as the leading word, and ideally sanity check the rest of
the import line for the SRPM number.

              Obligatory XKCD comic about sanitizing inputs:
http://xkcd.com/327/

3) Anyone who attempts to replicate any of the git repositories for
improved local access is at risk of corruption or the embedding of
trojans in the local repository, due to the lack of GPG signed tags or
similar verification of the contents. I realize that the use of the
"package.medata" information provides git commit hash tags, which help
verification, but that data *itself* can be reset in a trojaned local
git repository.

               Please consider the use of signed GPG tags for actual
SRPM updates, rather than merely relying on '[package].metadata, to
help assure provenance for people who may test or rebuild security
components.

Thanks for the attention: I'll stick around for a while, to try and
pay back the support for others working with this.

                    Nico Kadel-Garcia <nkadel at gmail.com>