Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Reply to message

2020-04-07: This site is going to be decommissioned and shut down on 2020-07-01. Please copy and archive any data you wish to keep before that date.

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Alex Kramarov <alex@incredimail.com>
Full name Alex Kramarov <alex@incredimail.com>
Date 2003-02-02 15:28:06 PST
Message Actually, i have been working with up2date in http only mode since the last
2.7.x client, and continuing to work like this, so this works just fine -
the client doesn't care about the certificate as long as you don't make him
use https.

----- Original Message -----
From: "Hunter Matthews" <thm at duke dot edu>
To: "Current Server Mailing List" <current-server@l​ists.dulug.duke.edu​>
Sent: Sunday, February 02, 2003 11:45 PM
Subject: Re: [Current-server] Installing Current breaks RH7.3 SSL


Its tough to reply to this. In my own enviroment, its pretty silly right
now that anything is SSL'd, because all the machines that can see the
current server are trusted (I'm root - if I can't trust myself, we're

But there are other considerations here. The database code is developing
(on current.tigris.org) at a good pace, and soon more important
information will be transmitted back and forth between the clients and
servers. Just having everything that could potentially be sensitive
encrypted is the easiest way to prevent trouble.

More importantly that that is the current projects stance on client
compatibility - we just don't patch the client. While I haven't paid
much attention to that layer of the networking code since mid-2.7
clients, they at least ALWAYS checked the servers SSL certificate
against the RHNS-CA-CERT. I have no reason to beleive that that code has

So if you just set the normal url to 'http', thats why you're getting an
error. Yes, in early devel series, encyrption just added too much to
deal with, and I commented out that one line. But I would never
recommend that to a user/admin - just a fellow developer.

On Sat, 2003-02-01 at 14:17, Alex K wrote:
> as one of the NRH guys that imply otherwise, i must disagree. the SSL is
> an absolute requirement, especially for testing, if we take into account
> amount of trouble people have with this issue. Farthermore, an
> may decide, that since his deployment takes place inside his internal LAN,
> he doesn't need to secure the information exchanged between the client and
> the server, to avoid dealing with all the SSL related issues.
> Of course, i must agree that since the login information can potentially
> contain confidential user data, an administrator should have the choice if
> to make some of the clients address the server using https, and he does -
> NRH has an entire paragraph in it's documentation devoted to explanation
> about configuring secure data transfer.
> Alex.
> -------Original Message-------
> From: current-server@lists​.dulug.duke.edu
> Date: ùáú 01 ôáøåàø 2003 19:22:37
> To: current-server@lists​.dulug.duke.edu
> Subject: [Current-server] Installing Current breaks RH7.3 SSL
> On Sat, 2003-02-01 at 10:47, John Berninger wrote:
> > SSL is an absolute requirement, even for testing. The client
> > has the ability to transfer package headers and packages via HTTP, but
> > the login information is always transferred using HTTPS. This is
> > because the login information can potentially contain confidential user
> > data, which should never be transmitted in the clear.
> This REALLY needs to be made clear in the instructions, because the
> NRH-current guys imply otherwise.

We don't speak for them, and they don't speak for us. The best place to
resolve a conflict like that is to make sure the current docs match the
behavior of the current server, or report it as a bug in issuezilla or
on this list.

Similarly for nrh-update - if their docs don't match what their server
actually does, report it to them.

> In fact, I initially set up my server URL as http: rather than https:,
> and the initial configure *worked* and my initial attempt to update
> *worked*. It was only on subsequent invocations of client side up2date
> --configure that I got a traceback.

Uh, I just looked at the code itself for 2.8 something, and there's
actually a test now (maybe that was there before?) for "if this
connection is ssl'd, confirm that the certificate matches up with our
CA-CERT", so http maybe should work.

I'm not at all surprised --configure doesn't like that - its a config
Red Hat would never recommend nor support in any way.

> At that point, I switched to https: and got a certificate validation
> failure.
> So the point is that this is an obscure bug that occurs several steps
> along the road, and should be documented up front.

Which? That http isn't a supported protocol for some requests in the
client? If you report that to RH, I gaurantee they'll mark that NOTABUG
and close it.

That current's docs can be improved for generation/compatibility of its
SSL certificate? I'm not an expert, and John isn't either - make
suggestions, and we'll make changes.

Hunter Matthews Unix / Network Administrator
Office: BioScience 145/244 Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.

Current-server mailing list

To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org