hi,
CentOS-7 has been a massive sprint, but we got there in the end with a
few blips - nothing that cant be fixed retrospectively.
I just wanted to drop a note here and say thanks to everyone who
participated in the lead up, the builds, the testin and the delivery.
This is, ofcourse, where things begin - we have a great platform with
lots of potential to do some really cool stuff.
Lets get started,
- KB
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
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(a)gmail.com>
hi,
given that srpms contain upstream tarballs, in most cases directly
linked from upsream; I wonder if its worth while setting up a service
that can track git commits, extract the urls for our lookaside tarballs
and compare them with the upstream projects's release tarballs.
this would be a great addition to the ci.dev.centos.org infra, and could
add another data point to the 'can-we-trust-this' mindset.
- KB
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
[PATCH] add in a starter specfile
- This spec was used to build v0.1 RPMS
RPMS are here;
http://copr.fedoraproject.org/coprs/bstinson/Centpkg/
This is still very much alpha software, and the copr is subject to removal at any time, so be sure you're not using those repos for anything important.
On Sat, Jul 5, 2014 at 1:30 PM, Christoph Galuschka <tigalch(a)tigalch.org> wrote:
> Am 05.07.2014 18:43, schrieb Nico Kadel-Garcia:
>> I'd mentioned this in a previous note, on a thread that got long:
>>
>>> 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.
>>
>> I tried to submit this at bugs.centos.org, but there's not a category
>> there for 'centos-git-common' that I could easily find. The patch is
>> below:
>
> try changing the project to Buildsys - there git.centos.org is available.
Thanks. The interface at git.centos.org also has some serious issues:
the "Search" function, for example, does not find "centos-git-common",
and does not allow an anonymous user to select specific repositories
on the "Search" page.
[PATCH 1/3] Catch exceptions when running commands for a nicer experience when things go wrong
- Top-level exception handling was turned off in earlier versions to make debugging easier
[PATCH 2/3] update the readme to make the epel installation step more clear
- As requested: http://lists.centos.org/pipermail/centos-devel/2014-July/011321.html
[PATCH 3/3] bump the version number to 0.1 for the first RPM
- Since local builds work, this is probably a good place to build the first RPM
hi,
http://buildlogs.centos.org/centos/7/os/x86_64-20140625/ is now online,
livemedia to match this tree is in the isos/ dir at
http://buildlogs.centos.org/centos/7/isos/x86_64/
Cloud images, docker images, coming shortly.
Note: this tree now has a centos-release that implements the scope of
change we were talking about in the numbering thread. I went through
quite a few permutations and what we have here seems like the best
middle ground to be on. I am also going to try and circle back to some
of the RH folks to make sure they are ok with how we message around
where the CentOS Linux release is built from.
Please also test scope and breath,
The builds included address all closed bug reports so far, so please
keep the reports coming as we start staging for final builds.
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc