Is there a reason this bug is private? The community is aware of it, the private nature, and the original reporter's content. Can we make the bug public now?

Greetings,

It appears that a bugzilla workflow rule is inadvertently marking all RHEL 7 bugs private and we will get this fixed as soon as possible.  In the interim, we have manually made this bug report public.

RHEL7 SRPMS are available in the Red Hat Customer Portal:
https://access.redhat.com/site/downloads/.  You can download them using
a web browser or using yum-utils on a rhel7 system.

Red Hat Enterprise Linux Product and Program Management.

Thank you for making the bug public.

One way to read this response is that Red Hat has made source code for RHEL 7 more difficult to access for all but paying customers.

I doubt this is the intended response, but if so, perhaps someone from Red Hat can release a statement to explain the change in policy/procedure.

There are bigger security concerns among this as well. SRPMs are usually signed and therefore cryptographically immune to tampering. Any modification of these packages would alter the signature and therefore cause the validation of the SRPM to fail.

With the initial import into git.centos.org, there is no steps available to validate if the source (patches and binary blobs) has been modified in transit.

Even more concerning is that nobody really knows who / what / how the initial checkin of code is done. The general thinking is that it is published to the git repository by RedHat - although there is no way to verify this. Checkins are made by a generic address, and none of it is signed.

In this day and age of computer security, the leap of faith that is required during this transition is 'Grand Canyon' sized - which is not something that should be asked of a major project such as RHEL / CentOS.

I have been in discussion with the CentOS team in #centos-devel on FreeNode - and while the concerns have been heard (by kbsingh and others), I am not sure they are in a position to change these processes.

The new git based access also has no *tags* tied to the specific software releases. There is no graceful way to determine the current release version number, or previous released versions, except to attempt to deduce it from the git history of the new .spec files. That's both awkward and not necessarily correct. There is also no way in place to tie the release numbers to a particuar point release of RHEL. I have to assume that the CentOS team has some canonical list they will use, in order to publish CentOS releases.

It's also awkward to extract the package names. Extracting the list from the front page for git.centos.org is awkward, and potentially unreliable as GUI changes in that site occur. The same list or listing mechanism usable for creating point releases might be usable for this.

It's clear that the initial code was brought into the git repository as an import operation, not a git clone. That's too bad in some ways: I'd have appreciated seeing the change history. But I can understand the desire to protect potentially proprietary or license violating source code that had to be later excised from a source tree, and I understand the need to protect employees from being contacted by new developers about code they no longer support. It's still a shame: I've really appreciated the git history when reviewing code myself.

What's making me very nervous, however, is that there are no GPG signed tags for this source code. I know it's extra work, but simply pulling the code from the git "master" provides no assurance against man-in-the-middle manipulation of the git repo and its contents, nor of the master containing unreleased and broken code.

I do appreciate Red Hat's commitment to open source and especially freeware, I use CentOS and Scientific Linux for testing, and RHEL for corporate work. I do hope that we can continue to have even more collaboration with the freeware and open source communities.

subscribe

I've just read through all the comments here, and fail to see any real reason why the git.centos.org route has issues. Getting srpms, if someone prefers to consume that format, is a 2 line script thats now been posted quite a few times ( atleast on the centos-devel list ).

The git.centos.org interface also offers a very comprehensive api layer for people looking to automate their process in a way that was never possible before. 

and finally, CentOS releases will have srpms, people still wanting to follow the srpm route can do so by tracking those in sync with centos binaries.

So, I think its worth spending a bit of time getting to know git, the git.centos.org interface and then working back from there to see what the real technical challenges are and work together to fix it.

just my thoughts.

I think partly its also the "CentOS isn't the only project in the world". There is a lot of mindshare of having this "we're being forced to suckle from the CentOS teet" attitude.

To be fair, a lot of people use the source that are not part of the CentOS project - and there is a lot of resentment of being forced to utilise the CentOS project as their only source of EL7 goodness.

There are however other technical issues (some I've outlined above).

Revisiting this - and hopefully inviting more comments - I think the big problem is authenticity of code via a proven and verifiable method - or the lack thereof!

Is there any method to verify that no code has been tampered with while on the git.centos.org system? In the initial import?

Maybe something as simple as doing an initial checkout, checksumming each file, then publishing these to the RH FTP (ie somewhere trusted) could satisfy this?

I'm happy with the possibility of changes being tracked via the git moving forwards, but the initial step still has me concerned...

Security is one issue.  But there are broader issues as well, as described in the initial comment.

SRPMs are the standard method for making sources available for RPM content. This has been the case since the beginning, and is still the case for all other Red Hat software, and for all other software providers in the industry.

Many tools exist for working with SRPMs (the project I work on happens to be one of those). These tools now have to be rewritten to deal with sources in a new and non-standard way (at least I have seen no announcements from Red Hat indicating that git.centos.org is a model for distributing all sources going forward). 

Tools that work across multiple operating system versions, as well as operating system and non-operating system software, must now write and maintain special case code for dealing with rhel7 sources. There is no guarantee that the current way of accessing code from git.centos.org will remain constant or supported over time.

This change is occurring without notice, and it causes additional (and seemingly unnecessary) work for the community at the same time as they are working hard to update their applications to work with RHEL7. 

Mixing RHEL sources with CentOS sources is confusing. CentOS is a different project and should, in theory, have the same level of access to Red Hat sources as any other RHEL-based distribution. Otherwise, questions come up about whether (and why?) Red Hat is trying to make it more difficult for 3rd parties to create RHEL-based distributions. 

A very reasonable solution, it would seem, would be for Red Hat to continue releasing srpms on ftp.redhat.com. This addresses all of the concerns. It also eliminates the feeling that Red Hat is (for some unknown reason) making it harder for the public to access RHEL7 sources.

Users who wish to access sources from git.centos.org can continue to do so. Perhaps this approach will become the standard in the future. But until then, forcing the public to use this method, with no explanation and no advance notice, creates a great deal of dissatisfaction, as evidenced by the comments on the centos-devel mailing list, and by the number of people subscribing to this bug.

Hi folks - I've created a google group at https://groups.google.com/d/forum/rhel7-sources for discussion of this topic. Perhaps we can make some plans to raise further awareness.

The repository at https://git.centos.org/project/rpms is populated by Red Hat. We disclosed our plan to switch to git for sharing sources publicly back in January: http://red.ht/1hCCvta.

CentOS community members have been working to sort out gaps in tools and processes around the new source mechanism. To connect with these community members, check out the centos-devel mailing list: http://lists.centos.org/mailman/listinfo/centos-devel.

You win. You've addressed the questions.

You lose. You've bullied the community into an experimental source distribution method for RHEL7 without providing a standard alternative.

Is there a reliable, automated procedure to obtain a git checkout of the exact source code for a particular complete RHEL release, and also for each subsequent update?

I am not concerned about anybody tampering with the git repo. I am concerned about how hard it is for third parties to create derivatives of Red Hat. (Note "derivatives of Red Hat", not "derivatives of CentOS".)

For what its worth, there are a lot of people that do derivatives of RedHat that don't want to do a derivative of CentOS - ie wanting the 'unmolested' source.

So, here is an easy way people can continue expressing their thoughts on this issue. Take a simple, yes/no survey:

Take the survey:
https://www.surveymonkey.com/s/TNXZP9H

View the results:
https://www.surveymonkey.com/results/SM-HZ8KLSD8/

Feel free to share these links. Perhaps if enough people weigh in, Red Hat will reconsider. :-)

(In reply to Karanbir Singh from comment #8)
> Getting srpms, if someone
> prefers to consume that format, is a 2 line script thats now been posted
> quite a few times ( atleast on the centos-devel list ).

Could you please post the URL to that message, or even better, please post the two line script.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days