Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Thu, 19 Jun 2014, Lamar Owen wrote: On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote: I do not care what any lawyer has to say on this topic, because this is not a legal question. Sure it is. It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Thu, Jun 19, 2014 at 9:47 AM, Lamar Owen lo...@pari.edu wrote: On 06/19/2014 09:16 AM, Nico Kadel-Garcia wrote: Take a look at even a simple SPEC file, such as ntp.spec to see how much interpretation it's doing. Oh, I'm well aware of that. Relying on the upstream authors to always do the .spec files *last* with new builds is not necessarily fair, and precludes certain type of code merges. While I have no knowledge of the actual workflow at Red Hat, I would think that the population into git.centos.org would happen as an automated part of the upstream build process, and that what is going in to git.centos.org is what rpmbuild is seeing as it builds the 'canonical' upstream package (or it's being generated by depackaging the built SRPM). This would just about have to be true in order for the git.centos.org source to be the actual upstream source. Anyone with a valid subscription should be able to verify this for themselves by comparing the git committed source bundle with the subscription access SRPM. There are a stack of ways to do this, some less reliable than others. They're not clearly making git clones of the upstream RHEL git repository. there is some kind of import of the files happening. If they're simply unpacking the SRPM's and importing those, cool. But import/export procedures with git are prone to fascinating discrepancies, some from user error, It creates fascinating risks, and without a carefully comparison toolkit that compares either RHEL SRPM's to git.centos.org's unstated and thus unpredictable layout, or someone with git access to both running git diff between the repos, it's a small but very real risk of fascinating discrepancies. I'm afraid that the only way to get a valid, reliable, and *signed* set of source code is going to be to buy subscriptions. This allows excellent change tracking with git (which many many people have asked for from CentOS in the past) while still getting the upstream source. See above. The careful tracking of upstream is happening out of view. Of course, it is a bit of a leap of faith to trust Red Hat to do it this way; but, then again, unless you have (or had) a valid subscription you couldn't verify that the source RPMs going into ftp.redhat.com were the same as what subscribers were getting (in terms of package metadata, and even perhaps a different signing key.etc). IMHO, if you don't trust Red Hat But at least they had a GPG signature, from Red Hat, saying we published this. That signature is still present when I hand you a copy of the SRPM or put it in a local mirror or get it from Scientific Linux's vendor mirror. git.centos.org has no GPG tags, not even on their initial imports. I'm fairly shocked: it puts all git clones of git.centos.org material at risk of unauthorized modification and pollution of the source code for people trying to build from them. to put the correct source into git.centos.org then why trust their source at all? The git commit ID's will take care of detecting side-channel modifications after Red Hat's populating of the source. (Side note: Linus' choice of the way commit ID's were to work is absolutely brilliant. IMHO). But I'm curious as to what kind of merge would work with a depackaged source RPM but not with the files available through git.centos.org. There's no way, as things stand, to tell which is the vendor version nor which is the centos build version of the code in git.centos.org. There's not even a tag or branch to indicate it, just a master on which changes are accumulating. And it's already gotten polluted. Is the new centos-git-common repository part of the official RHEL releases? I think not, but it's in the same environment that formerly contained purely RHEL code. How can we tell future such packages apart? SL did this very well, with the separate sl6 and vendors directories for SRPM's from Scientific Linux, and tools from upstream vendors like Red Hat. A similar separation would have been very welcome at www.centos.org, but somehow, I don't see them resetting the URL's in all their working git clones.
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
[A very well-reasoned reply, and I thank you. Comments in-line.] On 06/20/2014 08:20 AM, Nico Kadel-Garcia wrote: There are a stack of ways to do this, some less reliable than others. They're not clearly making git clones of the upstream RHEL git repository. there is some kind of import of the files happening. If they're simply unpacking the SRPM's and importing those, cool. I too would like a bit more info from Red Hat on this mechanism. They don't actually have to provide that info, but it certainly would be nice to have. It would seem easiest to automate either a depackaging of each SRPM and import, or a direct importing from the to-be-packaged contents of the SRPM prior to writing it out (and signing). But that is an assumption that may or may not be accurate. But import/export procedures with git are prone to fascinating discrepancies, some from user error, It creates fascinating risks, and without a carefully comparison toolkit that compares either RHEL SRPM's to git.centos.org's unstated and thus unpredictable layout, or someone with git access to both running git diff between the repos, it's a small but very real risk of fascinating discrepancies. I'm afraid that the only way to get a valid, reliable, and *signed* set of source code is going to be to buy subscriptions. GPL doesn't require distributed source to be signed, but your final line is probably a correct statement. Although with your fascinating use of fascinating in that paragraph, I have to wonder if you've recently watched a Star Trek marathon or something. :-) And I'm curious as to those cases, specifically some documentation of some of the issues involved. Lots of large projects, including the linux kernel, use git, and those artifacts should be (and probably are) well documented. I am not a git guru, by any stretch, but I am curious. I'm fairly shocked: it puts all git clones of git.centos.org material at risk of unauthorized modification and pollution of the source code for people trying to build from them. This is where the git design should help; no modification can go unnoticed, thanks to the manner in which the commit ID's are calculated. The gap is between Red Hat's build process and the import of the sources for that process into git. Once in git, all changes will be tracked. There's no way, as things stand, to tell which is the vendor version nor which is the centos build version of the code in git.centos.org. While I may be misunderstanding the script, SL devs are contributing scripts that look to be able to do this discernment. There's not even a tag or branch to indicate it, just a master on which changes are accumulating. There is no content in master. The EL7 content is in the c7 branch. And it's already gotten polluted. Is the new centos-git-common repository part of the official RHEL releases? I think not, but it's in the same environment that formerly contained purely RHEL code. How can we tell future such packages apart? Commit IDs and the committer name seem to be the only way at present. SL did this very well, with the separate sl6 and vendors directories for SRPM's from Scientific Linux, and tools from upstream vendors like Red Hat. A similar separation would have been very welcome at www.centos.org, but somehow, I don't see them resetting the URL's in all their working git clones. Yes, it would be welcome to have more traditional separation, but it appears that will not happen. I do reserve the right to be wrong, of course. And I again thank you for a well-reasoned and level response.
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. GPL does not require sources to be released to the public; the requirement is to release sources to the same people to whom you distributed the binaries (and of the same version). The GPL FAQ covers this pretty well. I'm well aware of both sides to this issue, and I sympathize both with the enterprise linux distributors wanting to stay in business in a competitive climate as well as the larger community wanting to have open rebuilds of those enterprise distributions. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.)
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014 09:16:14 -0400 Lamar Owen lo...@pari.edu wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. GPL does not require sources to be released to the public; the requirement is to release sources to the same people to whom you distributed the binaries (and of the same version). The GPL FAQ covers this pretty well. I'm well aware of both sides to this issue, and I sympathize both with the enterprise linux distributors wanting to stay in business in a competitive climate as well as the larger community wanting to have open rebuilds of those enterprise distributions. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) Simply I cannot see the point you're making here. Excuse me but as I see, you're not coming up with any solution but only saying that this is more than alright. But without pointing out its advantage over the former method. You yourself is saying too that there is a gap between RH's release of the sources and their import to the git tree. Regarding the license: I am more than certain that if I happen to buy supscription to RHEL then I am allowed to do with the GPL'd sources whatever I want while it is between the boundaries of the GPL. It may easily be because I'm not an expert in licence matter, but I cannot come up with an idea how the license could be changed by any lawyers, for example, forbidding the redistribution of the sources. Is that really possible? If so, then could you provide background info or facts on the matter how that is done? Thank you.
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Lamar Owen wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On 06/20/2014 08:55 AM, Dag Wieers wrote: On Fri, 20 Jun 2014, Lamar Owen wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) Although this discussion seems interesting, I see the same points being reiterated. I don't see how any of this is going to change anything though. RedHat and CentOS are moving forward whether we like it or not and the SL development team are doing what they can within those constraints. If one needs all that integrity and vetting of the source, go fork over the money for a license.
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On 06/20/2014 09:45 AM, Andras Horvath wrote: Regarding the license: I am more than certain that if I happen to buy supscription to RHEL then I am allowed to do with the GPL'd sources whatever I want while it is between the boundaries of the GPL. And Red Hat has reserved the right to not distribute updates to you if you breach the terms of their subscription agreement (it's in their agreement; if you don't like it, don't agree to it or take them to court over it). It's a matter of interpretation and opinion as to whether the act of cutting off updates constitutes 'restrictions on source code redistribution,' since that has not been tested in court as yet.
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Mark Stodola wrote: On 06/20/2014 08:55 AM, Dag Wieers wrote: On Fri, 20 Jun 2014, Lamar Owen wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) Although this discussion seems interesting, I see the same points being reiterated. I don't see how any of this is going to change anything though. RedHat and CentOS are moving forward whether we like it or not and the SL development team are doing what they can within those constraints. If one needs all that integrity and vetting of the source, go fork over the money for a license. I have a license, don't worry. I am a Red Hat customer. But of course, one license will not do. You need a bunch of entitlements to get access to all channels. And on a yearly basis too. HA, RHSCL, ... For only accessing the SRPMs and rebuilding it adds up quickly. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
I'm not worried at all if you have a license or not. I'm not your sales rep. :) The way the comment read didn't sit with me well. It sounded dismissive to a lot of work that Red Hatters do for upstream communities all over that allow RHEL, RHEL derivitaves and all other forms of Linux to happen. Not just the kernel, but the un-sexy bits in the middle that make an OS usable. I also can't agree with the the thought that Red Hatters won't dissent against company decisions that they don't agree with. I'm not going to dig through the world archives this late on a Friday but I just don't accept that assumption. Of course I'm a fanboy and an employee. But I'm those things because I believe in how we try to do things. We don't always get it right (see RHEV 1.0 and other debacles). But we try to. Have a good weekend. -jduncan On Fri, Jun 20, 2014 at 3:07 PM, Dag Wieers d...@wieers.com wrote: On Fri, 20 Jun 2014, Mark Stodola wrote: On 06/20/2014 08:55 AM, Dag Wieers wrote: On Fri, 20 Jun 2014, Lamar Owen wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) Although this discussion seems interesting, I see the same points being reiterated. I don't see how any of this is going to change anything though. RedHat and CentOS are moving forward whether we like it or not and the SL development team are doing what they can within those constraints. If one needs all that integrity and vetting of the source, go fork over the money for a license. I have a license, don't worry. I am a Red Hat customer. But of course, one license will not do. You need a bunch of entitlements to get access to all channels. And on a yearly basis too. HA, RHSCL, ... For only accessing the SRPMs and rebuilding it adds up quickly. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] -- Thanks, Jamie Duncan @jamieeduncan
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Jamie Duncan wrote: I'm not worried at all if you have a license or not. I'm not your sales rep. :) The way the comment read didn't sit with me well. It sounded dismissive to a lot of work that Red Hatters do for upstream communities all over that allow RHEL, RHEL derivitaves and all other forms of Linux to happen. Not just the kernel, but the un-sexy bits in the middle that make an OS usable. So if I don't agree, or am critical about something Red Hat did, I am dismissive to Red Hat's contributions ? Sorry, but that is not true at all. In this complex world, I think one is allowed to criticize one action without implying everything else... Self-criticism (and yes, I feel part of Red Hat's community) is essential. And a decision that makes Red Hat weaker, weakens my case as well. I also can't agree with the the thought that Red Hatters won't dissent against company decisions that they don't agree with. I'm not going to dig through the world archives this late on a Friday but I just don't accept that assumption. Of course I'm a fanboy and an employee. But I'm those things because I believe in how we try to do things. We don't always get it right (see RHEV 1.0 and other debacles). But we try to. With al due respect, but your response to one point of criticism is probably why someone at Red Hat (unless maybe high up in the organization) may not speak up. It clearly is a management/legal decision and yes, I do believe if you are on the payroll, that is exactly what you are not supposed to question. Red Hat becoming less Open Source may harm the company's public image. And since the CentOS board is on Red Hat's payroll as well, I think they are in the same boat, unfortunately. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
xterm and clipboard
Hi All, Anyone know if there is a way to get copy shiftCtrlC, past shiftCtrlV, and cut shiftCtrlX keystrokes into an xterm? Many thanks, -T
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
Hi, Dag!! Haven't seen you since that London Linux conference, I'm back in the USA now. On Fri, Jun 20, 2014 at 5:14 PM, Dag Wieers d...@wieers.com wrote: Self-criticism (and yes, I feel part of Red Hat's community) is essential. And a decision that makes Red Hat weaker, weakens my case as well. It's also contributing to skepticism from companies and users looking at RHEL 7 or the clone rebuilds. If we're all stuck rebuilding from CentOS, not from RHEL signed packages that are verifiably consistent with what our favorite upstream vendor actually packages and tests, that's a logical source of security and support concern. What makes it worse is that HTTPS is not sufficiently secure to verify the authenticity of original source code, and the git repo itself could be hijacked by any subtle attacker using any of the unrevoked, stolen SSL wildcard keys in the wild. That could be a fascinating security hole for 3rd party vendors who rely on RHEL or CentOS SRPM's for their source code for or open source based projects. These include Centrify, that rebundles OpenSSH with various features, and apparently Cisco for their ASA firewall products. With al due respect, but your response to one point of criticism is probably why someone at Red Hat (unless maybe high up in the organization) may not speak up. It clearly is a management/legal decision and yes, I do believe if you are on the payroll, that is exactly what you are not supposed to question. Red Hat becoming less Open Source may harm the company's public image. Dag, I beg to differ with you here. My experience with Red Hat technical personnel on an individual basis is that they will *question* policies, but that they are quite aware that their voice is not authoritative and are cautious about saying this is the way it is, because I work for Red Hat and that's the policy. They're leave it to the legal and management personnel, who may also be aware of things they're not privy to (such as software licensing agreeements with Sun, back in the day.) And since the CentOS board is on Red Hat's payroll as well, I think they are in the same boat, unfortunately. Yeah, I've been urging my clients to switch to Scientific Linux where possible for a stack of reasons. If we, or our friends on the SL build team, can work around this, it'll be another reason to switch. The decision to switch to pure git based distribution is, currently, rife with security and implementation issues. That it was done effectively unannounced, without testing it with the RHEL 7 beta components is a sign of a problem.
