It has just come to my notice that Redhat is planning to ship a forked version of OpenSSH. The change goes beyond the usual patches applied to RPMs in the build process: Redhat have built their own OpenSSH tarball and are using that in their source RPM instead of the official release distribution. If you are interested, have a look at the openssh-3.9p1-7.src.rpm from the Fedora development/ directory. This source tarball is modified from the official portable OpenSSH distribution. It does not have a digital signature, an independent download site or even a basic list of changes. From diffing this source against the official release, it appears that the only change is deletion of files related to the experimental ACSS cipher. It is unclear why Redhat has chosen to do this: the cipher is disabled by default and their own Cygwin product has shipped these same files for many months, as have many other Linux distributions. Nobody disputes Redhat's right to fork OpenSSH, but why does Redhat not make their desired changes through the standard RPM patching mechanism? By distributing their own OpenSSH tarballs instead of patching pristine sources, Redhat breaks the link of transparency, accountability and trust that their own RPM build model is supposed to provide. We are also curious as to the extent that the community was involved in this decision; OpenSSH is developed by volunteers and Fedora is at least ostensibly a community effort. The OpenSSH developers were not contacted and there does not appear to have been any discussion of the change on any public mailing list. Even the RPM Changelog entry "disable ACSS support" greatly understates the nature of the change. It appears that the community was not consulted at all and that this change was made unilaterally by Redhat, with no explanation. The OpenSSH developers have neither the time nor the desire to investigate the changes Redhat makes to OpenSSH under the cover of their modified source tarball. As such, we will be forced to disregard support requests from users of Redhat or Fedora systems. Security conscious users are advised to audit the Redhat changes themselves (for each RPM release) or build OpenSSH from the original sources. We consider it very disappointing that Redhat has decided to effectively fork OpenSSH without consulting the OpenSSH developers or their own community. It is not too late for Redhat to reconsider, or for the community to urge them to do so. Regards, Damien Miller
On Mon, 2004-11-08 at 15:23, Damien Miller wrote:> It has just come to my notice that Redhat is planning to ship a > forked version of OpenSSH. The change goes beyond the usual > patches applied to RPMs in the build process: Redhat have built > their own OpenSSH tarball and are using that in their source RPM > instead of the official release distribution. If you are > interested, have a look at the openssh-3.9p1-7.src.rpm from the > Fedora development/ directory. >Do you find that a cross-posted missive to a set of lists like this is: 1. less or more inflammatory than a post to the openssh maintainer @redhat.com? 2. less or more productive than an entry in bugzilla about the details? Thanks -sv
On Tue, 9 Nov 2004, Damien Miller wrote:> It has just come to my notice that Redhat is planning to ship a > forked version of OpenSSH. The change goes beyond the usual > patches applied to RPMs in the build process: Redhat have built > their own OpenSSH tarball and are using that in their source RPM > instead of the official release distribution. If you are > interested, have a look at the openssh-3.9p1-7.src.rpm from the > Fedora development/ directory.> This source tarball is modified from the official portable > OpenSSH distribution. It does not have a digital signature, an > independent download site or even a basic list of changes. From > diffing this source against the official release, it appears that > the only change is deletion of files related to the experimental > ACSS cipher. It is unclear why Redhat has chosen to do this: the > cipher is disabled by default and their own Cygwin product has > shipped these same files for many months, as have many other > Linux distributions.> Nobody disputes Redhat's right to fork OpenSSH, but why does > Redhat not make their desired changes through the standard RPM > patching mechanism? By distributing their own OpenSSH tarballs > instead of patching pristine sources, Redhat breaks the link of > transparency, accountability and trust that their own RPM build > model is supposed to provide.> We are also curious as to the extent that the community was > involved in this decision; OpenSSH is developed by volunteers and > Fedora is at least ostensibly a community effort. The OpenSSH > developers were not contacted and there does not appear to have > been any discussion of the change on any public mailing list. > Even the RPM Changelog entry "disable ACSS support" greatly > understates the nature of the change. It appears that the > community was not consulted at all and that this change was made > unilaterally by Redhat, with no explanation.> The OpenSSH developers have neither the time nor the desire to > investigate the changes Redhat makes to OpenSSH under the cover > of their modified source tarball. As such, we will be forced to > disregard support requests from users of Redhat or Fedora > systems. Security conscious users are advised to audit the Redhat > changes themselves (for each RPM release) or build OpenSSH from > the original sources.> We consider it very disappointing that Redhat has decided to > effectively fork OpenSSH without consulting the OpenSSH > developers or their own community. It is not too late for Redhat > to reconsider, or for the community to urge them to do so.> Regards, > Damien MillerWelcome to the world of "Open Source", as defined by RedHat. XFree86 has already suffered the same fate. Marc. +----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: tsi at ualberta.ca | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 developer and VP. ATI driver and X server internals.
On Tue, Nov 09, 2004 at 07:23:44AM +1100, Damien Miller wrote:> the only change is deletion of files related to the experimental > ACSS cipher. It is unclear why Redhat has chosen to do this: the > cipher is disabled by default and their own Cygwin product has > shipped these same files for many months, as have many other > Linux distributions.Of course, the readership might be more enlightened to know what ACSS is. "This library implements the Alleged Content Scrambling System. It is believed to be interoperable with CSS of the DVD Copy Control Association. ACSS is a stream cipher with a fixed key length of 40 bit (5 byte). ACSS consists of a key setup phase and the actual encryption or decryption phase." Apart from the potential legal issues (even if are just some litigious bastards suing people for fun/profit instead of real ones) surrounding said algorithms, isn't it OpenBSD policy (dunno about openssh) to not ship known broken crypto algorithms at all? -- Pekka Pietikainen
> On Tue, Nov 09, 2004 at 07:23:44AM +1100, Damien Miller wrote: > > the only change is deletion of files related to the experimental > > ACSS cipher. It is unclear why Redhat has chosen to do this: the > > cipher is disabled by default and their own Cygwin product has > > shipped these same files for many months, as have many other > > Linux distributions. > > Of course, the readership might be more enlightened to know what ACSS > is. > > "This library implements the Alleged Content Scrambling System. It is > believed > to be interoperable with CSS of the DVD Copy Control Association. > ACSS is a stream cipher with a fixed key length of 40 bit (5 byte).I quote from the openssl RC4 manual page: This library implements the Alleged RC4 cipher, which is described for example in Applied Cryptography. It is believed to be compatible with RC4[TM], a proprietary cipher of RSA Security Inc.> ACSS consists of a key setup phase and the actual encryption or decryption > phase." > > Apart from the potential legal issues (even if are just some litigious > bastards suing people for fun/profit instead of real ones) surrounding > said algorithms,Precisely what legal issues would that be? What we have here in ACSS is a multi-purpose cipher that can be used for many things, including but not limited to encrypting ssh sessions. And it is fast.> isn't it OpenBSD policy (dunno about openssh) to not ship > known broken crypto algorithms at all?It is our policy to provide a secure replacement for telnet and rlogin, so that people stop using telnet and rlogin. It is our policy to release that software in a free fashion so that vendors can supply their customers with a high quality implimention. If you don't like what we write, you can run something else.. .
On Tue, 09 Nov 2004 00:38:06 -0700, Theo de Raadt <deraadt at cvs.openbsd.org> wrote:> > > > The OpenSSH web site history page says: > > > > Therefore, the version of OpenSSH was based on these older versions > > of ssh 1.2.12, but with many bugs removed and newer features > > re-added: > > > > * has all components of a restrictive nature (i.e. patents, > > see ssl) directly removed from the source code > > > > The CSS algorithm is claimed as a trade secret and there have been > > several court cases fought over it. Is that not code "of a restrictive > > nature"? Why is such code in OpenSSH? > > I claim that the colour red is a trade secret of me. > > Are you afraid?Do you know enough about Trade Secret law in the United States and Europe to really make such a claim? In most cases you could not consider the colour red a trade secret.. how you make a specific colour red specifically for your dye manufacturing would be.> > Why is Redhat such a pushover? >Maybe its because the value of the algorithm is not considered enough to fight over. The other issues could be that ArcFour was desiminated before DMCA and other US and European laws.. and ACSS was done so afterwords.> Is it because they are an American company? >More than likely. They also have a lot of stockholders and lawsuits filed anytime the stock drops more than 20cents because someone filed a frivolous item.> Come on! Someone tell me what law prohibits the ACSS cipher from > being used to protect an SSH communication! >I do not think there are any lawyers on this list so any answer people gave you would be worthless. Most lawyers do not post legal opinions to electronic lists because they open themselves to various criminal and civil lawsuits.> Why does noone want to answer this question? > >Because it is so much more fun to bait you and watch your responses. I think that most of this argument has been to see if someone can get you to have Touriets Syndrome. In the end, Red Hat did not say to OpenSSH that they were going to do this, but really under the BSD license they do not have to. Heck they do not have to give the code if they want. In their .src.rpm, Red Hat does put in a script that was used to take out the code, AND they did label the tar-ball as openssh-noaccs.tar.gz versus calling it openssh.tar.gz. All of these things were things that the original email Damien mentioned that he was worried about not being there. On the other side, OpenSSH does not have to answer support/problem reports from Red Hat, SuSE, Debian or any other group that decides the ACCS is not to be shipped. On the other hand, they do not have to answer questions if the code was there either. The fact that people do answer questions is a nicety that too few people recognize with words or dollars. -- Stephen J Smoogen. CSIRT/Linux System Administrator
On Tue, 9 Nov 2004, Stephen J. Smoogen wrote:> On Tue, 09 Nov 2004 00:38:06 -0700, Theo de Raadt > <deraadt at cvs.openbsd.org> wrote: > > > > > > > The OpenSSH web site history page says: > > > > > > Therefore, the version of OpenSSH was based on these older versions > > > of ssh 1.2.12, but with many bugs removed and newer features > > > re-added: > > > > > > * has all components of a restrictive nature (i.e. patents, > > > see ssl) directly removed from the source code > > > > > > The CSS algorithm is claimed as a trade secret and there have been > > > several court cases fought over it. Is that not code "of a restrictive > > > nature"? Why is such code in OpenSSH? > > > > I claim that the colour red is a trade secret of me. > > > > Are you afraid? > > Do you know enough about Trade Secret law in the United States and > Europe to really make such a claim? In most cases you could not > consider the colour red a trade secret.. how you make a specific > colour red specifically for your dye manufacturing would be. >Even at that.. You may *ONLY* sue the person that leaked the trade secret. Anyone how figures it out on their own (either via reverse engineering or mistake) are not bound to keep your secret. People seem to forget this, and MPAA and others keep wanting to link "Trade Secret" with "Patented Works".. which is confuses things even more. =) - Ben
Ben Lindstrom wrote:>Even at that.. You may *ONLY* sue the person that leaked the trade secret. >Anyone how figures it out on their own (either via reverse engineering or >mistake) are not bound to keep your secret. > >Then why was Bunner sued? He neither leaked the trade secret, nor did he perform the reverse engineering. Regards, Sten
On Tue, 9 Nov 2004, Sten Drescher wrote:> Ben Lindstrom wrote: > > >Even at that.. You may *ONLY* sue the person that leaked the trade secret. > >Anyone how figures it out on their own (either via reverse engineering or > >mistake) are not bound to keep your secret. > > > > > Then why was Bunner sued? He neither leaked the trade secret, nor did > he perform the reverse engineering. >Why was DC and AutoZone sued? <shrug> Same reasons. Just instead of SCO coming out on top (as the MPAA seems to have) it just caused them more pain. Civil law is screwy. For as much as I hate trying to remember Criminal Speedy Trial rules. It is more consistant in the procedure. Rarely in Criminal law do you have an attorney trying to "redefine" an existing congressal law. Which happens alot in Civil. - Ben IAMAL.. I just work around them.
Has anyone actually _asked_ Red Hat why they patch the code out? Mailing list posts are not going to get answers, and I see nothing open in bugzilla.redhat.com. Someone said the reason may be trade secret (and I carried on the idea as well as others), but it is more likely that they're doing it because of the DMCA. IIRC all the CSS lawsuits based on trade secrets have been dropped or lost, while DMCA based suits are apparently succeeding. Yes, I realize how stupid the DMCA is, but the fact is that it is being applied to CSS, but Red Hat has other legal battles to fight (like SCO). I do have a question that it would be nice if someone could answer: why would I want to use CSS as a cipher in SSH? As I understand it, CSS is a fairly weak algorithm; why would I want to use a weak encryption method? A different question: why are any of the ciphers being included in OpenSSH? I thought that's why OpenSSL was used (if not, why not just put all the ciphers in OpenSSH and not require OpenSSL?). -- Chris Adams <cmadams at hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Sten Drescher wrote:> So now any Red Hat user, even if they build their own OpenSSH binaries > from your tarballs, is persona non grata on your (apparently) personal > lists? Wonderful attitude, just wonderful.Nobody has ever been kicked off this list, so please spare us the non sequiturs.
Damien Miller wrote:>Sten Drescher wrote: > > > >>So now any Red Hat user, even if they build their own OpenSSH binaries >>from your tarballs, is persona non grata on your (apparently) personal >>lists? Wonderful attitude, just wonderful. >> >> > >Nobody has ever been kicked off this list, so please spare us the non >sequiturs. > >It was hardly a non sequitur. Mr de Raadt repeatedly made comments about how Red Hat users apparently (or "obviously") felt, but as soon as one spoke up and expressed his feelings, making a point to note that they built their own binaries, Mr de Raadt suggested that he was posting to the wrong list. Care to explain why that should not be expected to make that Red Hat user (and, by extension, all Red Hat users) feel unwelcome? Regards, Sten
Sten Drescher wrote:> It was hardly a non sequitur. Mr de Raadt repeatedly made comments > about how Red Hat users apparently (or "obviously") felt, but as soon as > one spoke up and expressed his feelings, making a point to note that > they built their own binaries, Mr de Raadt suggested that he was posting > to the wrong list. Care to explain why that should not be expected to > make that Red Hat user (and, by extension, all Red Hat users) feel > unwelcome?I was referring to you erroneous assertion that the lists are the "personal" playthings of anyone.
I work for lawyers, have for 5 years now. I consulted several on this issue, some educated enough on this area of law, others not. A lot of what's said here is true on both accounts. What Theo De Raadt says about "trade secret" law appears to be true, he's not blowing steam up your asses. They all agree it's somewhat questionable as to wether or not what OpenSSH is doing with aacs is "illegal". Discussing this issue over some scotch with one attorney, one I consider a good friend, after hearing the basic flow of this argument he posed this question: "Why do the OpenSSH folks care? If Red Hat took their code and is distributing in a state they don't like, refuse to support it. Being that a simple civil law suit from one of these hardball prick organizations like the MPAA/RIAA hell bent on protecting their property or whatever the hell can destroy a publicly held company once the media gets wind of the lawsuit being filed". If Red Hat removed this code in question from a legal standpoint, it's probably just a safegaurd and perhaps not needed. Red Hat wouldn't care to have the media saying bogus things like "Red Hat, provider of Linux, is using some super encryption code and distributing it illegally". Untrue as that is, it would affect stock price. This is a possible motivation. This is obviously not an issue OpenSSH should bother caring about. Red Hat is distributing OpenSSH's project and work in a state they deem as being hard for OpenSSH to support. Red Hat can either fix it, or have their tarball recognized as something OpenSSH neither condones nor will support. OpenSSH seems firm in their stance, so that is that. Red Hat probably should properly contact the OpenSSH people and explain why this was done. Perhaps they feel they have fixed something here. It is possible that this code hack has nothing at all to do with US law. Anytime you change a person's code you should provide a reason why, it may be beneficial to the original code's maintainer. Don't get confused, the first half of this mail is just me trying to explain a reason as to why this list debating the legality of aacs is probably moot. I don't use Red Hat, never have. I don't agree with how they've handled their source changes to OpenSSH. Richard Holland Holland Transportation