compile error on cvs tip

Joe Conway <mail@joeconway.com> writes:

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

regards, tom lane

Tom Lane wrote:

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

I've already got --with-pam covered, but I don't have Kerberos4 to try
it with.

Joe

Joe Conway <mail@joeconway.com> writes:

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Patch applied for those mistakes.

I also get this new warning:
be-secure.c: In function `open_server_SSL':
be-secure.c:712: warning: assignment from incompatible pointer type

I can't see any reason for that --- the relevant code hasn't been
changed lately (at least not by me). Can you look to see what the
discrepancy in types is?

regards, tom lane

Tom Lane wrote:

I also get this new warning:
be-secure.c: In function `open_server_SSL':
be-secure.c:712: warning: assignment from incompatible pointer type

I can't see any reason for that --- the relevant code hasn't been
changed lately (at least not by me). Can you look to see what the
discrepancy in types is?

The definition in (at least my copy of) ssl.h for info_callback is:
void (*info_callback)(const SSL *ssl,int type,int val);
^^^^^

The following seems to take care of it. I just recently updated to Red
Hat 9, so this may be showing up now due to a newer gcc or openssl.

Joe

Index: src/backend/libpq/be-secure.c
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/backend/libpq/be-secure.c,v
retrieving revision 1.30
diff -c -r1.30 be-secure.c
*** src/backend/libpq/be-secure.c       19 Apr 2003 00:02:29 -0000      1.30
--- src/backend/libpq/be-secure.c       25 Apr 2003 04:23:53 -0000
***************
*** 115,121 ****
   static DH  *load_dh_buffer(const char *, size_t);
   static DH  *tmp_dh_cb(SSL *s, int is_export, int keylength);
   static int    verify_cb(int, X509_STORE_CTX *);
! static void info_cb(SSL *ssl, int type, int args);
   static int    initialize_SSL(void);
   static void destroy_SSL(void);
   static int    open_server_SSL(Port *);
--- 115,121 ----
   static DH  *load_dh_buffer(const char *, size_t);
   static DH  *tmp_dh_cb(SSL *s, int is_export, int keylength);
   static int    verify_cb(int, X509_STORE_CTX *);
! static void info_cb(const SSL *ssl, int type, int args);
   static int    initialize_SSL(void);
   static void destroy_SSL(void);
   static int    open_server_SSL(Port *);
***************
*** 547,553 ****
    *    into the PostgreSQL log.
    */
   static void
! info_cb(SSL *ssl, int type, int args)
   {
         switch (type)
         {
--- 547,553 ----
    *    into the PostgreSQL log.
    */
   static void
! info_cb(const SSL *ssl, int type, int args)
   {
         switch (type)
         {

Joe Conway <mail@joeconway.com> writes:

The definition in (at least my copy of) ssl.h for info_callback is:
void (*info_callback)(const SSL *ssl,int type,int val);
^^^^^

Ah so. Patch applied. I guess I need to update my copy of openssl,
too --- here it just says

/**/ void (*info_callback)();

What openssl release do you have?

regards, tom lane

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

The definition in (at least my copy of) ssl.h for info_callback is:
void (*info_callback)(const SSL *ssl,int type,int val);

Ah so. Patch applied. I guess I need to update my copy of openssl,
too --- here it just says

/**/ void (*info_callback)();

What openssl release do you have?

Red Hat 9, latest update:
openssl-0.9.7a-5

Joe

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

--
Sean Chittenden

Sean Chittenden wrote:

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

Did we decide we _didn't_ want to remove krb4? Removal seems like a
good idea to me, but I am just checking if the consensus was to keep it.
I think someone said it was OK in a closed environment or something.
Maybe we need to document that it is not recommended.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

Did we decide we _didn't_ want to remove krb4? Removal seems like a
good idea to me, but I am just checking if the consensus was to keep
it. I think someone said it was OK in a closed environment or
something. Maybe we need to document that it is not recommended.

Keep krb4 in the tree for 7.4, but before 7.4 gets released, the
documentation and release notes need to state that krb4 has been
depreciated and that it will be removed before 7.5. I'll add submit a
patch for the updated verbiage in a bit. -sc

--
Sean Chittenden

Sean Chittenden writes:

Keep krb4 in the tree for 7.4, but before 7.4 gets released, the
documentation and release notes need to state that krb4 has been
depreciated and that it will be removed before 7.5. I'll add submit a
patch for the updated verbiage in a bit. -sc

I object to treating foreign software packages like that. Those who are
interested in Kerberos 4 or even managed to obtain software for it are
intelligent enough to be able to make judgements about it. Kerberos 4 is
nowhere near the likely-to-be-chosen path in PostgreSQL, so there's
nothing we need to be scared about.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Sean Chittenden writes:

Keep krb4 in the tree for 7.4, but before 7.4 gets released, the
documentation and release notes need to state that krb4 has been
depreciated and that it will be removed before 7.5. I'll add submit a
patch for the updated verbiage in a bit. -sc

I object to treating foreign software packages like that. Those who are
interested in Kerberos 4 or even managed to obtain software for it are
intelligent enough to be able to make judgements about it. Kerberos 4 is
nowhere near the likely-to-be-chosen path in PostgreSQL, so there's
nothing we need to be scared about.

True, but it does bloat our distribution. I had to work around its
need for gethostname() while I was coding the Win32 port, so it doesn't
stay around with zero maintance.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sean Chittenden wrote:

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

I have added the following to our documentation in the Kerberos section:

<para>
While <productname>PostgreSQL</> supports both Kerberos 4 and
Kerberos 5, only Kerberos 5 is recommended. Kerberos 4 is
considered insecure and no longer recommended for general
use.
</para>

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

I have added the following to our documentation in the Kerberos section:

<para>
While <productname>PostgreSQL</> supports both Kerberos 4 and
Kerberos 5, only Kerberos 5 is recommended. Kerberos 4 is
considered insecure and no longer recommended for general
use.
</para>

iirc, we were going to depreciate kerberos 4 in the 7.4 release notes
and remove support for it for 7.5, giving users one full release cycle
to move to krb5.

There any plans to include the appropriate verbiage to allow for krb4's
future deorbit?

-sc

--
Sean Chittenden

Sean Chittenden wrote:

auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'

Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.

Now that I think about it, there might be similar omissions in the
PAM or Kerberos4 support --- can anyone try those?

krb4 code should be removed from PostgreSQL ASAP for various
insecurities in the protocol. It's been removed from FreeBSD, MIT,
and Heimdal's code base and is officially unsupported as of June this
year. -sc

I have added the following to our documentation in the Kerberos section:

<para>
While <productname>PostgreSQL</> supports both Kerberos 4 and
Kerberos 5, only Kerberos 5 is recommended. Kerberos 4 is
considered insecure and no longer recommended for general
use.
</para>

iirc, we were going to depreciate kerberos 4 in the 7.4 release notes
and remove support for it for 7.5, giving users one full release cycle
to move to krb5.

There any plans to include the appropriate verbiage to allow for krb4's
future deorbit?

I don't remember any agreement to remove krb4 in 7.5. Am I wrong?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

I don't remember any agreement to remove krb4 in 7.5. Am I wrong?

It needs to go. I thought the question was when, not if.

In that case there seem to be 2 choices - deprecate in 7.4 and remove in
7.5, or deprecate in 7.5 and remove in following release.

I favor the former - supporting insecure and unsupported protocols for
any length of time is a bad idea - put users on notice and give them 1
release cycle to switch.

andrew

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I don't remember any agreement to remove krb4 in 7.5. Am I wrong?

My recollection is we had at least one person still using it, who was
apparently unworried by the security issues.

While I think deprecating krb4 is a good idea, I don't see any need
to remove it. It's not costing us any maintenance effort to leave it
there, is it?

regards, tom lane

I don't remember any agreement to remove krb4 in 7.5. Am I wrong?

My recollection is we had at least one person still using it, who
was apparently unworried by the security issues.

Peter Eisentraut <Pine.LNX.4.44.0305161542510.2224-100000@peter.localdomain>:
As long as people are still using it, I see no reason. Just the other
day someone reported that he was trying to get it to work in his
environment.

Tom Lane <27165.1053097081@sss.pgh.pa.us>:
I wouldn't mind pulling it from 7.5, if the 7.4 docs say we are going
to and no one complains.

While I think deprecating krb4 is a good idea, I don't see any need
to remove it. It's not costing us any maintenance effort to leave
it there, is it?

Bruce Momjian <200306010352.h513qsS05070@candle.pha.pa.us>:
Did we decide we _didn't_ want to remove krb4? Removal seems like a
good idea to me, but I am just checking if the consensus was to keep
it. I think someone said it was OK in a closed environment or
something. Maybe we need to document that it is not recommended.

Bruce Momjian <200306020235.h522Zs320377@candle.pha.pa.us>:
True, but it does bloat our distribution. I had to work around its
need for gethostname() while I was coding the Win32 port, so it
doesn't stay around with zero maintance.

*shrug* It's not possible to upgrade from krb4 to krb5 by running a
simple conversion program, but there is a krb425d daemon that
exchanges krb4 tickets for krb5 tickets which makes upgrading more
less painful. It's not like users of krb4 are left without any
recourse or documentation for getting krb4 to work with PgSQL. MIT
has documented how to do this quite well and has been pushing for this
to happen for at least 3-4 years now.

http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb425.html#Introduction

When the BSDs dumped support for krb4 from the base, I don't recall a
single email from someone complaining as almost everyone who uses krb
uses hiemdal or MIT krb5. -sc

--
Sean Chittenden