Thread: compile error on cvs tip
I just updated to cvs tip, did `make clean`, `configure`, and `make all`
and got this:
i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -I/usr/kerberos/include
-c -o auth.o auth.c -MMD
auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'
auth.c:294: structure has no member named `user'
auth.c:294: structure has no member named `user'
. . .
auth.c:297: structure has no member named `user'
auth.c: In function `ClientAuthentication':
auth.c:491: structure has no member named `user'
make[3]: *** [auth.o] Error 1
make[3]: Leaving directory `/opt/src/pgsql/src/backend/libpq'
I also get this new warning:
i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -I/usr/kerberos/include
-c -o be-secure.o be-secure.c -MMD
be-secure.c: In function `open_server_SSL':
be-secure.c:712: warning: assignment from incompatible pointer type
Joe
p.s. Here is a patch for the error:
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.100
diff -c -r1.100 auth.c
*** src/backend/libpq/auth.c 22 Apr 2003 00:08:06 -0000 1.100
--- src/backend/libpq/auth.c 25 Apr 2003 02:58:21 -0000
***************
*** 291,300 **** }
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user, kusername, SM_DATABASE_USER)) { elog(LOG, "pg_krb5_recvauth: user
name\"%s\" != krb5
name \"%s\"",
! port->user, kusername); ret = STATUS_ERROR; } else
--- 291,300 ---- }
kusername = pg_an_to_ln(kusername);
! if (strncmp(port->user_name, kusername, SM_DATABASE_USER)) { elog(LOG, "pg_krb5_recvauth:
username \"%s\" != krb5
name \"%s\"",
! port->user_name, kusername); ret = STATUS_ERROR; } else
***************
*** 488,494 **** #ifdef USE_PAM case uaPAM: pam_port_cludge = port;
! status = CheckPAMAuth(port, port->user, ""); break; #endif /* USE_PAM
*/
--- 488,494 ---- #ifdef USE_PAM case uaPAM: pam_port_cludge = port;
! status = CheckPAMAuth(port, port->user_name, ""); break; #endif /*
USE_PAM*/
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, Pennsylvania19073
> > > > 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, Pennsylvania19073
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, Pennsylvania19073
> > > > 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, Pennsylvania19073
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