* CVS, Documentation, TODO Lists, New Maintainer, and Stuff @ 2004-06-10 21:20 Chad C. Walstrom 2004-06-10 21:44 ` Chad C. Walstrom ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Chad C. Walstrom @ 2004-06-10 21:20 UTC (permalink / raw) To: help-gnats On Thu, Jun 10, 2004 at 12:57:06PM +0200, Yngve Svendsen wrote: > These features look useful indeed, and I would strongly recommend that > Mel gets CVS access. I sent him email about getting an account on savannah.gnu.org. In order to get CVS access, you need to import your ssh public key into your account settings on savannah. Then ask for membership to the group from one of the administrators listed (which I need to ask you or Andrew to appoint me to, BTW). > One more thing, though. We should have a strict policy of keeping the > docs up to date in synch with code checkins Absolutely. The only way to keep documentation current is to stay on top of it. I tried using the newer cvs2cl last night to update the ChangeLogs, but the formatting is off. It would probably make sense to have a changelog target in the root Makefile.in so that we won't have to remember how to reinvoke it every time. Additionally, the cvs2cl doesn't pick out details that weren't placed in the cvs log entry, such as the enclosed function name in some entries. I'm not sure such detail is THAT important, but it's also possible to update the log entries to contain that information too. Perhaps it's time to add in log templates and a user list to the CVSROOT for username-to-emailaddress resolution; perhaps an AUTHORS file should be created. On to the TODO file... I use this very nice console tool called devtodo, executed as "todo". It creates an outlined TODO list saved in XML format as ".todo". Each subdirectory can have it's own .todo file, and it's fairly simple to remap your shell "cd" command to display the TODO list for that directory when you change into it. In any case, I'm working on rewriting the current TODO file in the root source directory using this devtodo tool. We can start organizing some of the feature requests and prominent bug fixes to a release schedule. For example (off the top of my head, not referencing the current TODO list): GNATS General TODO List 1. Release 4.1 1. Prepend $(DESTDIR) varibles to each install target (Chad) 2. Clean up send-pr (Chad) 3. Add missing manpages 4. Update Documentation 2. Release 4.2 1. Mail handling enhancements (Mel) 1. Mail-based manipulation of GNATS DB (Mel) 2. Trigger-based mail format replies 3. Enable To: PR#[DATABASE]@host.domain.tld syntax to queue-pr 2. MIME Handling 1. Convert HTML to TEXT 2. Detach Files Appropriately for GNATS DB format 3. Add RDBMS Backend Support (Mel) 1. Oracle Support 2. DB Abstraction layer 3. Release 4.3 1. Mail handling enhancements 1. Maintain mbox archive of all emails 2. Fake Audit trail entries as emails and append to mbox archive 3. Continue to use existing PR datafile for logging events, keywords, and metadata 2. Account Enhancement 1. PAM authentication So on, and so forth. ;-P -- Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom @ 2004-06-10 21:44 ` Chad C. Walstrom 2004-06-13 8:51 ` Mel Hatzis 2004-06-13 23:01 ` Andrew Gray 2004-06-11 22:28 ` Yngve Svendsen 2004-06-14 17:07 ` Pankaj K Garg 2 siblings, 2 replies; 22+ messages in thread From: Chad C. Walstrom @ 2004-06-10 21:44 UTC (permalink / raw) To: help-gnats OH, about the New Maintainer portion of the subject... I am officially appointed as the New Maintainer of GNATS! I will be putting in at least 2 hours per week on the project, but realistically it'll probably be more. So, I suppose it's time to start thinking about what we would like for our next release and plan accordingly. Mel, I look forward to merging in your enhancements! -- Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-10 21:44 ` Chad C. Walstrom @ 2004-06-13 8:51 ` Mel Hatzis 2004-06-13 23:01 ` Andrew Gray 1 sibling, 0 replies; 22+ messages in thread From: Mel Hatzis @ 2004-06-13 8:51 UTC (permalink / raw) To: help-gnats On Jun 10, 2004, at 2:02 PM, Chad C. Walstrom wrote: > OH, about the New Maintainer portion of the subject... I am officially > appointed as the New Maintainer of GNATS! I will be putting in at > least > 2 hours per week on the project, but realistically it'll probably be > more. > > So, I suppose it's time to start thinking about what we would like for > our next release and plan accordingly. Mel, I look forward to merging > in your enhancements! Excellent! I've started work on the PostgreSQL backend to supplement the Oracle & Flat-File backends which are currently supported by the gnats-dbi enhancement. I plan on setting up a savannah account sometime next week...I have too much going on at work this week. Thanks for the pointers. -- Mel Hatzis _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-10 21:44 ` Chad C. Walstrom 2004-06-13 8:51 ` Mel Hatzis @ 2004-06-13 23:01 ` Andrew Gray 1 sibling, 0 replies; 22+ messages in thread From: Andrew Gray @ 2004-06-13 23:01 UTC (permalink / raw) To: help-gnats > OH, about the New Maintainer portion of the subject... I am officially > appointed as the New Maintainer of GNATS! I will be putting in at least Congratulations on your appointment as the New Maintainer of GNATS! Also, thank you for being prepared to take on this role. I am sure you will do a much better job as maintainer than I have been recently. -- Andrew Gray _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom 2004-06-10 21:44 ` Chad C. Walstrom @ 2004-06-11 22:28 ` Yngve Svendsen 2004-06-14 17:07 ` Pankaj K Garg 2 siblings, 0 replies; 22+ messages in thread From: Yngve Svendsen @ 2004-06-11 22:28 UTC (permalink / raw) To: Chad C. Walstrom; +Cc: help-gnats Chad C. Walstrom wrote: >On Thu, Jun 10, 2004 at 12:57:06PM +0200, Yngve Svendsen wrote: > > >>These features look useful indeed, and I would strongly recommend that >>Mel gets CVS access. >> >> > >I sent him email about getting an account on savannah.gnu.org. In order >to get CVS access, you need to import your ssh public key into your >account settings on savannah. Then ask for membership to the group from >one of the administrators listed (which I need to ask you or Andrew to >appoint me to, BTW). > > Congratulations on your appointment as maintainer! I have given you Project Admin permissions for GNATS on Savannah. The TODO section looks good and very useful. I think you have captured well the different themes and suggestions that have come up lately, and the prioritization and separation into releases looks about right (I think 4.2, with RDBMS backend support, would be better named 5.0, but that we can argue about later). I hope to be able to do some doc work beginning late summer, but please don't stick my name on the TODO doc items yet -- I am not yet sure how much time I will have for that. - Yngve _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom 2004-06-10 21:44 ` Chad C. Walstrom 2004-06-11 22:28 ` Yngve Svendsen @ 2004-06-14 17:07 ` Pankaj K Garg 2004-06-14 17:16 ` Chad C. Walstrom 2 siblings, 1 reply; 22+ messages in thread From: Pankaj K Garg @ 2004-06-14 17:07 UTC (permalink / raw) To: Chad C. Walstrom; +Cc: help-gnats Chad C. Walstrom wrote: > 2. Account Enhancement > 1. PAM authentication Chad, Is anyone signed up for adding PAM authentication support yet? If not, I can sign up for it. Pankaj -- Pankaj K Garg garg@zeesource.net 1684 Nightingale Avenue 408-373-4027 Suite 201 408-733-2737(fax) Sunnyvale, CA 94087 http://www.zeesource.net http://home.earthlink.net/~gargp _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff 2004-06-14 17:07 ` Pankaj K Garg @ 2004-06-14 17:16 ` Chad C. Walstrom 2004-06-20 17:39 ` PAM Authentication Patch Pankaj K Garg 0 siblings, 1 reply; 22+ messages in thread From: Chad C. Walstrom @ 2004-06-14 17:16 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 554 bytes --] Pankaj K Garg wrote: > Is anyone signed up for adding PAM authentication support yet? If not, > I can sign up for it. No, no one has signed up for this yet. I placed your name in the TODO list and updated it in CVS. I don't plan on making ChangeLog entries for these files (.todo and TODO), though I will note the changes made in the cvs log entry. Welcome aboard! I look forward to getting your patches! -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* PAM Authentication Patch 2004-06-14 17:16 ` Chad C. Walstrom @ 2004-06-20 17:39 ` Pankaj K Garg [not found] ` <gargp@earthlink.net> 2004-06-21 16:13 ` PAM Authentication Patch Chad Walstrom 0 siblings, 2 replies; 22+ messages in thread From: Pankaj K Garg @ 2004-06-20 17:39 UTC (permalink / raw) To: help-gnats [-- Attachment #1: Type: text/plain, Size: 1722 bytes --] I'm attaching a patch for enabling PAM authentication support. To keep the patch file small, I've not included the diffs to the files 'configure' and 'gnats/configure'. Use autoconf to generate these two files. If you need the generated files, let me know and I'll create another patch. PAM support can now be enabled by using '--enable-pam' switch to configure. With PAM support enabled, you can put an entry in the gantsd.user_access file as: <user>:$p$:<access-level> and the authentication for the user will be done against the configured PAM modules. The name of the PAM service is taken from the DEFAULT_GANTS_SERVICE define, so by default it should be 'support'. Hence, you can configure PAM by creating the file /etc/pam.d/support on RH Linux. I've tried to make appropriate changes to the documentation. Let me know if any other document requires update. I've done some preliminary testing on my RH 9.0 Linux. Please let me know if there's any problem with it. Pankaj Chad C. Walstrom wrote: > Pankaj K Garg wrote: > >>Is anyone signed up for adding PAM authentication support yet? If not, >>I can sign up for it. > > > No, no one has signed up for this yet. I placed your name in the TODO > list and updated it in CVS. I don't plan on making ChangeLog entries > for these files (.todo and TODO), though I will note the changes made in > the cvs log entry. Welcome aboard! I look forward to getting your > patches! -- Pankaj K Garg garg@zeesource.net 1684 Nightingale Avenue 408-373-4027 Suite 201 408-733-2737(fax) Sunnyvale, CA 94087 http://www.zeesource.net http://home.earthlink.net/~gargp [-- Attachment #2: pam_patch.out --] [-- Type: text/plain, Size: 17955 bytes --] ? autom4te.cache ? pamdiffs.out ? gnats/autom4te.cache ? libiberty/xhost-mkfrag Index: doc/gnats.texi =================================================================== RCS file: /cvsroot/gnats/gnats/doc/gnats.texi,v retrieving revision 1.44 diff -u -p -r1.44 gnats.texi --- doc/gnats.texi 30 Aug 2003 07:55:06 -0000 1.44 +++ doc/gnats.texi 20 Jun 2004 16:34:24 -0000 @@ -1670,8 +1670,9 @@ string @samp{$1$}.@footnote{Some systems methods. In FreeBSD, for instance, a prefix of @samp{$2$} implies Blowfish encoding. @sc{gnats} will happily accept any encryption that the OS supports.} Passwords encrypted by @code{crypt()} should have no -prefix. If no password is given then users can login with an empty -password string. +prefix. If you want to authenticate users with PAM authentication +module, then supply a @samp{$p$} for the password entry. If no +password is given then users can login with an empty password string. A @code{gnats-passwd} tool to manage @file{gnatsd.user_access} files is planned. In the meantime, @code{crypt()} passwords can be generated by Index: gnats/acconfig.h =================================================================== RCS file: /cvsroot/gnats/gnats/gnats/acconfig.h,v retrieving revision 1.3 diff -u -p -r1.3 acconfig.h --- gnats/acconfig.h 26 May 2001 20:42:30 -0000 1.3 +++ gnats/acconfig.h 20 Jun 2004 16:34:24 -0000 @@ -26,3 +26,8 @@ Software Foundation, 59 Temple Place - S /* Define if strftime supports %z. */ #undef HAVE_STRFTIME_WITH_Z + +/* Define to enable system authentication with PAM instead of using the simple + getpwnam interface. This allows authentication (in theory) with any PAM + module, e.g. on systems with shadow passwords or via LDAP */ +#undef HAVE_PAM Index: gnats/autoconf.h.in =================================================================== RCS file: /cvsroot/gnats/gnats/gnats/autoconf.h.in,v retrieving revision 1.11 diff -u -p -r1.11 autoconf.h.in --- gnats/autoconf.h.in 6 Jan 2002 16:16:45 -0000 1.11 +++ gnats/autoconf.h.in 20 Jun 2004 16:34:24 -0000 @@ -1,143 +1,212 @@ -/* autoconf.h.in. Generated automatically from configure.in by autoheader 2.13. */ +/* autoconf.h.in. Generated from configure.in by autoheader. */ +/* GNATS specific autoconf symbols. + Copyright (C) 2001 Milan Zamazal + Copyright (C) 1995, 1996 ??? (FIXME, see ChangeLog.v3) + +This file is part of GNU GNATS. + +GNU GNATS is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU GNATS is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU GNATS; see the file COPYING. If not, write to the Free +Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111, USA. */ -/* Define if on AIX 3. - System headers sometimes define this. - We just want to avoid a redefinition error message. */ -#ifndef _ALL_SOURCE -#undef _ALL_SOURCE -#endif +/* Define if you have MIT Kerberos version 4 available. */ +#undef HAVE_KERBEROS -/* Define if using alloca.c. */ -#undef C_ALLOCA +/* Define if your system has socklen_t (glibc?) */ +#undef HAVE_SOCKLEN_T -/* Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems. - This function is required for alloca.c support on those systems. */ +/* Define if strftime supports %z. */ +#undef HAVE_STRFTIME_WITH_Z + +/* Define to enable system authentication with PAM instead of using the simple + getpwnam interface. This allows authentication (in theory) with any PAM + module, e.g. on systems with shadow passwords or via LDAP */ +#undef HAVE_PAM + +/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP + systems. This function is required for `alloca.c' support on those systems. + */ #undef CRAY_STACKSEG_END -/* Define if you have alloca, as a function or macro. */ +/* Define to 1 if using `alloca.c'. */ +#undef C_ALLOCA + +/* Define to 1 if you have `alloca', as a function or macro. */ #undef HAVE_ALLOCA -/* Define if you have <alloca.h> and it should be used (not on Ultrix). */ +/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix). + */ #undef HAVE_ALLOCA_H -/* Define if on MINIX. */ -#undef _MINIX - -/* Define if the system does not provide POSIX.1 features except - with this defined. */ -#undef _POSIX_1_SOURCE - -/* Define if you need to in order for stat and other things to work. */ -#undef _POSIX_SOURCE - -/* Define to `unsigned' if <sys/types.h> doesn't define. */ -#undef size_t - -/* If using the C implementation of alloca, define if you know the - direction of stack growth for your system; otherwise it will be - automatically deduced at run-time. - STACK_DIRECTION > 0 => grows toward higher addresses - STACK_DIRECTION < 0 => grows toward lower addresses - STACK_DIRECTION = 0 => direction of growth unknown - */ -#undef STACK_DIRECTION +/* Define to 1 if you have the <crypt.h> header file. */ +#undef HAVE_CRYPT_H -/* Define if you have the ANSI C header files. */ -#undef STDC_HEADERS +/* Whether unsetenv is present in headers. */ +#undef HAVE_DECL_UNSETENV -/* Define if you have MIT Kerberos version 4 available. */ -#undef HAVE_KERBEROS +/* Define to 1 if you have the <dirent.h> header file, and it defines `DIR'. + */ +#undef HAVE_DIRENT_H -/* Define if your system has socklen_t (glibc?) */ -#undef HAVE_SOCKLEN_T +/* Define to 1 if you have the <fcntl.h> header file. */ +#undef HAVE_FCNTL_H -/* Define if you have the ftime function. */ +/* Define to 1 if you have the `ftime' function. */ #undef HAVE_FTIME -/* Define if you have the krb_get_err_text function. */ +/* Define to 1 if you have the <inttypes.h> header file. */ +#undef HAVE_INTTYPES_H + +/* Define to 1 if you have the `krb_get_err_text' function. */ #undef HAVE_KRB_GET_ERR_TEXT -/* Define if you have the mkdir function. */ -#undef HAVE_MKDIR +/* Define to 1 if you have the `crypt' library (-lcrypt). */ +#undef HAVE_LIBCRYPT -/* Define if you have the mkstemp function. */ -#undef HAVE_MKSTEMP +/* Define to 1 if you have the `gen' library (-lgen). */ +#undef HAVE_LIBGEN -/* Define if you have the mktemp function. */ -#undef HAVE_MKTEMP +/* Define to 1 if you have the <libgen.h> header file. */ +#undef HAVE_LIBGEN_H -/* Define if you have the unsetenv function. */ -#undef HAVE_UNSETENV +/* Define to 1 if you have the `inet' library (-linet). */ +#undef HAVE_LIBINET -/* Define if you have the <crypt.h> header file. */ -#undef HAVE_CRYPT_H +/* Define to 1 if you have the `intl' library (-lintl). */ +#undef HAVE_LIBINTL -/* Define if you have the <dirent.h> header file. */ -#undef HAVE_DIRENT_H +/* Define to 1 if you have the `malloc' library (-lmalloc). */ +#undef HAVE_LIBMALLOC -/* Define if you have the <fcntl.h> header file. */ -#undef HAVE_FCNTL_H +/* Define to 1 if you have the `nsl' library (-lnsl). */ +#undef HAVE_LIBNSL -/* Define if you have the <libgen.h> header file. */ -#undef HAVE_LIBGEN_H +/* Define to 1 if you have the `socket' library (-lsocket). */ +#undef HAVE_LIBSOCKET -/* Define if you have the <limits.h> header file. */ +/* Define to 1 if you have the <limits.h> header file. */ #undef HAVE_LIMITS_H -/* Define if you have the <machine/endian.h> header file. */ +/* Define to 1 if you have the <machine/endian.h> header file. */ #undef HAVE_MACHINE_ENDIAN_H -/* Define if you have the <memory.h> header file. */ +/* Define to 1 if you have the <memory.h> header file. */ #undef HAVE_MEMORY_H -/* Define if you have the <ndir.h> header file. */ +/* Define to 1 if you have the `mkdir' function. */ +#undef HAVE_MKDIR + +/* Define to 1 if you have the `mkstemp' function. */ +#undef HAVE_MKSTEMP + +/* Define to 1 if you have the `mktemp' function. */ +#undef HAVE_MKTEMP + +/* Define to 1 if you have the <ndir.h> header file, and it defines `DIR'. */ #undef HAVE_NDIR_H -/* Define if you have the <netdb.h> header file. */ +/* Define to 1 if you have the <netdb.h> header file. */ #undef HAVE_NETDB_H -/* Define if you have the <string.h> header file. */ +/* Define to enable system authentication with PAM instead of using the simple + getpwnam interface. This allows authentication (in theory) with any PAM + module, e.g. on systems with shadow passwords or via LDAP */ +#undef HAVE_PAM + +/* Define to 1 if you have the <stdint.h> header file. */ +#undef HAVE_STDINT_H + +/* Define to 1 if you have the <stdlib.h> header file. */ +#undef HAVE_STDLIB_H + +/* Define to 1 if you have the <strings.h> header file. */ +#undef HAVE_STRINGS_H + +/* Define to 1 if you have the <string.h> header file. */ #undef HAVE_STRING_H -/* Define if you have the <sys/dir.h> header file. */ +/* Define to 1 if you have the <syslog.h> header file. */ +#undef HAVE_SYSLOG_H + +/* Define to 1 if you have the <sys/dir.h> header file, and it defines `DIR'. + */ #undef HAVE_SYS_DIR_H -/* Define if you have the <sys/ndir.h> header file. */ +/* Define to 1 if you have the <sys/ndir.h> header file, and it defines `DIR'. + */ #undef HAVE_SYS_NDIR_H -/* Define if you have the <sys/select.h> header file. */ +/* Define to 1 if you have the <sys/select.h> header file. */ #undef HAVE_SYS_SELECT_H -/* Define if you have the <syslog.h> header file. */ -#undef HAVE_SYSLOG_H +/* Define to 1 if you have the <sys/stat.h> header file. */ +#undef HAVE_SYS_STAT_H + +/* Define to 1 if you have the <sys/types.h> header file. */ +#undef HAVE_SYS_TYPES_H -/* Define if you have the <unistd.h> header file. */ +/* Define to 1 if you have the <unistd.h> header file. */ #undef HAVE_UNISTD_H -/* Define if you have the crypt library (-lcrypt). */ -#undef HAVE_LIBCRYPT +/* Define to 1 if you have the `unsetenv' function. */ +#undef HAVE_UNSETENV -/* Define if you have the gen library (-lgen). */ -#undef HAVE_LIBGEN +/* Define to the address where bug reports for this package should be sent. */ +#undef PACKAGE_BUGREPORT -/* Define if you have the inet library (-linet). */ -#undef HAVE_LIBINET +/* Define to the full name of this package. */ +#undef PACKAGE_NAME -/* Define if you have the intl library (-lintl). */ -#undef HAVE_LIBINTL +/* Define to the full name and version of this package. */ +#undef PACKAGE_STRING -/* Define if you have the malloc library (-lmalloc). */ -#undef HAVE_LIBMALLOC +/* Define to the one symbol short name of this package. */ +#undef PACKAGE_TARNAME -/* Define if you have the nsl library (-lnsl). */ -#undef HAVE_LIBNSL +/* Define to the version of this package. */ +#undef PACKAGE_VERSION -/* Define if you have the socket library (-lsocket). */ -#undef HAVE_LIBSOCKET +/* If using the C implementation of alloca, define if you know the + direction of stack growth for your system; otherwise it will be + automatically deduced at run-time. + STACK_DIRECTION > 0 => grows toward higher addresses + STACK_DIRECTION < 0 => grows toward lower addresses + STACK_DIRECTION = 0 => direction of growth unknown */ +#undef STACK_DIRECTION -/* Whether unsetenv is present in headers. */ -#undef HAVE_DECL_UNSETENV +/* Define to 1 if you have the ANSI C header files. */ +#undef STDC_HEADERS -/* Whether unsetenv is present in headers. */ -#undef HAVE_DECL_UNSETENV +/* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a + `char[]'. */ +#undef YYTEXT_POINTER +/* Define to 1 if on AIX 3. + System headers sometimes define this. + We just want to avoid a redefinition error message. */ +#ifndef _ALL_SOURCE +# undef _ALL_SOURCE +#endif + +/* Define to 1 if on MINIX. */ +#undef _MINIX + +/* Define to 2 if the system does not provide POSIX.1 features except with + this defined. */ +#undef _POSIX_1_SOURCE + +/* Define to 1 if you need to in order for `stat' and other things to work. */ +#undef _POSIX_SOURCE + +/* Define to `unsigned' if <sys/types.h> does not define. */ +#undef size_t Index: gnats/configure.in =================================================================== RCS file: /cvsroot/gnats/gnats/gnats/configure.in,v retrieving revision 1.31 diff -u -p -r1.31 configure.in --- gnats/configure.in 20 Sep 2003 22:36:43 -0000 1.31 +++ gnats/configure.in 20 Jun 2004 16:34:24 -0000 @@ -291,6 +291,42 @@ if test -z "${GNATS_DEFAULT_DB_DIR}"; th GNATS_DEFAULT_DB_DIR=${sharedstatedir}/gnatsdb fi +dnl +dnl begin --enable-pam +dnl + +dnl +dnl Check if PAM authentication is enabled +dnl +AC_ARG_ENABLE( + [pam], + AC_HELP_STRING( + [--enable-pam], + [Use to enable system authentication with PAM instead of using the + simple file based passwords. This allows authentication (in theory) + with any PAM module, e.g. on systems with shadow passwords or via LDAP]), , + [enable_pam=no] + ) + +if test yes = $enable_pam; then + AC_CHECK_HEADER(security/pam_appl.h, + AC_DEFINE(HAVE_PAM, 1, + [Define to enable system authentication with PAM instead of using the + simple getpwnam interface. This allows authentication (in theory) + with any PAM module, e.g. on systems with shadow passwords or via LDAP]) + AC_CHECK_LIB(pam, pam_start, [LIBS="${LIBS} -lpam"], + AC_MSG_ERROR([Could not find PAM libraries but the headers exist. + Give the --disable-pam option to compile without PAM support (or fix + your broken configuration)]) + ), + AC_MSG_ERROR([Could not find PAM headers]) + ) +fi + +dnl +dnl end --enable-pam +dnl + # Set up default values to be overridden _h=`(hostname || uname -n) 2>/dev/null | sed 1q` Index: gnats/gnatsd.c =================================================================== RCS file: /cvsroot/gnats/gnats/gnats/gnatsd.c,v retrieving revision 1.48 diff -u -p -r1.48 gnatsd.c --- gnats/gnatsd.c 14 Oct 2002 11:42:25 -0000 1.48 +++ gnats/gnatsd.c 20 Jun 2004 16:34:25 -0000 @@ -248,18 +248,133 @@ match (const char *line, const char *pat } } -/* Return true iff `password' matches `hash'. - `hash' is a possibly encrypted password, according to the $?$ convention. */ +#ifdef HAVE_PAM +/** + * + * Support for PAM authentication. Code borrowed from CVS server code + * with similar capability (gargp@acm.org) + * + **/ +#include <security/pam_appl.h> + +struct gnats_pam_userinfo { + const char *username; + const char *password; +}; + static int -password_match (const char *password, const char *hash) +gnats_pam_conv(int num_msg, const struct pam_message **msg, + struct pam_response **resp, void *appdata_ptr ) { - if (strlen(password) && strlen(hash)) + int i; + struct pam_response *response; + struct gnats_pam_userinfo *ui = (struct gnats_pam_userinfo *)appdata_ptr; + + response = xmalloc(num_msg * sizeof(struct pam_response)); + memset(response, 0, num_msg * sizeof(struct pam_response)); + + for (i = 0; i < num_msg; i++) + { + switch(msg[i]->msg_style) + { + /* PAM wants a username */ + case PAM_PROMPT_ECHO_ON: + response[i].resp = xstrdup(ui->username); + break; + /* PAM wants a password */ + case PAM_PROMPT_ECHO_OFF: + response[i].resp = xstrdup(ui->password); + break; + case PAM_ERROR_MSG: + case PAM_TEXT_INFO: + printf("%s\n",msg[i]->msg); + break; + /* PAM wants something we don't understand - bail out */ + default: + goto cleanup; + } + } + + *resp = response; + return PAM_SUCCESS; + + cleanup: + for (i = 0; i < num_msg; i++) + { + if (response[i].resp) + { + free(response[i].resp); + response[i].resp = 0; + } + } + free(response); + return PAM_CONV_ERR; +} + +static bool +pam_password_match( const char *username, const char *password ) +{ + pam_handle_t *pamh = NULL; + int retval, err; + struct gnats_pam_userinfo ui; + struct pam_conv conv; + const char *pam_stage = "start"; + + ui.username = username; + ui.password = password; + + conv.conv = gnats_pam_conv; + conv.appdata_ptr = (void *)&ui; + + retval = pam_start(DEFAULT_GNATS_SERVICE, username, &conv, &pamh); + + if (retval == PAM_SUCCESS) { + pam_stage = "authenticate"; + retval = pam_authenticate(pamh, 0); + } + + if (retval == PAM_SUCCESS) { + pam_stage = "account"; + retval = pam_acct_mgmt(pamh, 0); + } + + if (retval != PAM_SUCCESS) + syslog(LOG_ERR, "PAM %s error: %s\n", pam_stage, pam_strerror(pamh, retval)); + + if ((err = pam_end(pamh, retval)) != PAM_SUCCESS) + { + syslog(LOG_ERR, "PAM error %s\n", pam_strerror(NULL, err)); + exit (EXIT_FAILURE); + } + + return retval == PAM_SUCCESS ? TRUE : FALSE; /* indicate success */ +} +#endif + +/** + * + * Return TRUE iff `password' matches, as specified by `hash'. + * `hash' is a possibly encrypted password, according to the $?$ convention. + * If hash == '$p$', then use the PAM service for authentication. + * + **/ +static int +password_match (const char *user, const char *password, const char *hash) +{ + if (strlen(user) && strlen(password) && strlen(hash)) { if (! strncmp (hash, "$0$", 3)) { /* explicit plain-text password */ return match (password, hash+3, TRUE); } +#ifdef HAVE_PAM + else if (! strncmp (hash, "$p$", 3)) + { + /* check with PAM module */ + return pam_password_match (user, password); + } +#endif else { #ifdef HAVE_LIBCRYPT @@ -461,7 +576,7 @@ findUserAccessLevel (const char *file, c if ((ent->fieldcount == 3 || ent->fieldcount == 4) && match (user, ent->admFields[0], TRUE)) { - if (! password_match (passwd, ent->admFields[1])) + if (! password_match (user, passwd, ent->admFields[1])) { /* Username matched but password didn't. */ if (strlen(ent->admFields[1]) && strlen(passwd)) [-- Attachment #3: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <gargp@earthlink.net>]
* Re: PAM Authentication Patch [not found] ` <gargp@earthlink.net> @ 2004-06-20 17:59 ` Mark D. Baushke 2004-06-21 7:25 ` Chad Walstrom 0 siblings, 1 reply; 22+ messages in thread From: Mark D. Baushke @ 2004-06-20 17:59 UTC (permalink / raw) To: gargp; +Cc: help-gnats Pankaj K Garg <gargp@earthlink.net> writes: > I'm attaching a patch for enabling PAM > authentication support. > > To keep the patch file small, I've not included > the diffs to the files 'configure' and > 'gnats/configure'. Use autoconf to generate > these two files. If you need the generated > files, let me know and I'll create another > patch. > > PAM support can now be enabled by using > '--enable-pam' switch to configure. > > With PAM support enabled, you can put an entry > in the gantsd.user_access file as: > > <user>:$p$:<access-level> > > and the authentication for the user will be done > against the configured PAM modules. > > The name of the PAM service is taken from the > DEFAULT_GANTS_SERVICE define, so by default it > should be 'support'. Hence, you can configure > PAM by creating the file /etc/pam.d/support on > RH Linux. > > I've tried to make appropriate changes to the > documentation. Let me know if any other document > requires update. > > I've done some preliminary testing on my RH 9.0 > Linux. Please let me know if there's any problem > with it. > > Pankaj The biggest problem I have with PAM support for gnatsd is that you will now be sending a credential across the network in the clear which is presumably able to be used as a credential outside of gnats. This could lead to a simple password replay attack to gain access to systems by unauthorized individuals or their agents. I strongly urge you to first include and enable SSL (or TLS) support in gantsd before you allow PAM to be used to authorize connections. -- Mark > Chad C. Walstrom wrote: > > Pankaj K Garg wrote: > > > >>Is anyone signed up for adding PAM > >>authentication support yet? If not, I can sign > >>up for it. > > No, no one has signed up for this yet. I > > placed your name in the > > TODO > > list and updated it in CVS. I don't plan on > > making ChangeLog entries for these files > > (.todo and TODO), though I will note the > > changes made in the cvs log entry. Welcome > > aboard! I look forward to getting your > > patches! > > -- > Pankaj K Garg garg@zeesource.net > 1684 Nightingale Avenue 408-373-4027 > Suite 201 408-733-2737(fax) > Sunnyvale, CA 94087 > > http://www.zeesource.net http://home.earthlink.net/~gargp _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PAM Authentication Patch 2004-06-20 17:59 ` Mark D. Baushke @ 2004-06-21 7:25 ` Chad Walstrom 2004-06-21 15:26 ` Chad Walstrom 0 siblings, 1 reply; 22+ messages in thread From: Chad Walstrom @ 2004-06-21 7:25 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --] Mark D. Baushke wrote: > The biggest problem I have with PAM support for gnatsd is that you > will now be sending a credential across the network in the clear which > is presumably able to be used as a credential outside of gnats. This > could lead to a simple password replay attack to gain access to > systems by unauthorized individuals or their agents. > > I strongly urge you to first include and enable SSL (or TLS) support > in gantsd before you allow PAM to be used to authorize connections. Agreed. This is definitely something that should get on the TODO list for gnatsd. Alternatively, there are ways of tunneling TCP connections over secure channels, so I don't think the lack of gnutls integration should exclude the PAM patch. We should make it abundantly clear in the documentation that use of PAM authentication should be thoroughly protected. If such measures cannot be taken, don't enable PAM. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PAM Authentication Patch 2004-06-21 7:25 ` Chad Walstrom @ 2004-06-21 15:26 ` Chad Walstrom [not found] ` <chewie@wookimus.net> 0 siblings, 1 reply; 22+ messages in thread From: Chad Walstrom @ 2004-06-21 15:26 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 543 bytes --] Chad Walstrom wrote: > We should make it abundantly clear in the documentation that use of > PAM authentication should be thoroughly protected. If such measures > cannot be taken, don't enable PAM. Additionally, we can't always assume that because something uses PAM, it'll authentication against system accounts. There are dbm modules, ldap modules, etc. that can be used for account management. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <chewie@wookimus.net>]
* Re: PAM Authentication Patch [not found] ` <chewie@wookimus.net> @ 2004-06-21 15:34 ` Mark D. Baushke 2004-11-04 1:27 ` Preparing 4.1 Mark D. Baushke 1 sibling, 0 replies; 22+ messages in thread From: Mark D. Baushke @ 2004-06-21 15:34 UTC (permalink / raw) To: help-gnats Chad Walstrom <chewie@wookimus.net> writes: > Chad Walstrom wrote: > > We should make it abundantly clear in the > > documentation that use of PAM authentication > > should be thoroughly protected. If such > > measures cannot be taken, don't enable PAM. > > Additionally, we can't always assume that > because something uses PAM, it'll authentication > against system accounts. There are dbm modules, > ldap modules, etc. that can be used for account > management. While I do understand that it is *possible* to enable PAM and not endanger other applications or systems. I also understand that very few people or organizations will consider keeping such things separate in such a safe configuration unless the documentation clearly states that there are security implications to be considered. Yes, I am being paranoid. right now it seems fairly clear that gnatsd authentication is not very strongly protected. Folks are more likely to believe something is 'secure' if it can talk to PAM even though there may be explicit basis for that belief. -- Mark _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... [not found] ` <chewie@wookimus.net> 2004-06-21 15:34 ` Mark D. Baushke @ 2004-11-04 1:27 ` Mark D. Baushke 2004-11-04 3:15 ` Chad Walstrom 1 sibling, 1 reply; 22+ messages in thread From: Mark D. Baushke @ 2004-11-04 1:27 UTC (permalink / raw) To: help-gnats, info-gnats Chad C. Walstrom <chewie@wookimus.net> writes: > OK, I think we're about ready to make the 4.1 release. > send-pr/install-sid has been updated, the debian directory has been > synchronized, configure.in has been updated in the gnats/ and send-pr/ > directories. There are a few remaining issues to consider: > > * Compilation issues on Mac OS X 10.3.x > > * Core dump issues for Fedora Core 2 (remove optimization in the > compile) > > * libiberty autoconf requires version 2.13 rather than 2.50. > We either need to update the configure.in file to work with > 2.50 or update libiberty to the most recent version (wherever > that might be available) I recommend moving to autoconf 2.59 and consider a transition to automake 1.9.3. > * Should we replace texinfo/texinfo.tex file with a more recent > version? (Version 4.2?) Well, you may do well to consider making sure that the documentation still looks correct when using something like the makeinfo that comes with texinfo-4.7 (released 2004-04-10) which is hte latest release of the texinfo software. -- Mark _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-11-04 1:27 ` Preparing 4.1 Mark D. Baushke @ 2004-11-04 3:15 ` Chad Walstrom 2004-11-04 19:15 ` Chad Walstrom 0 siblings, 1 reply; 22+ messages in thread From: Chad Walstrom @ 2004-11-04 3:15 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 969 bytes --] Mark D. Baushke wrote: > I recommend moving to autoconf 2.59 and consider a transition to > automake 1.9.3. Certainly, but let's consider 4.1 security/bugfix release. We'll migrate to a cleaner autoconf/automake setup in 4.2. It's on the top of my list of things to do. I recommended 2.50 based on an incorrect assumption that Debian ships with 2.50 by default. In fact, I had been using 2.59 where the binary was named autoconf2.50. So, I agree to requiring 2.59. The only library that we need to concentrate on is libiberty, which appears to be supplementary for non-GNU platforms. > > * Should we replace texinfo/texinfo.tex file with a more recent > > version? (Version 4.2?) To clarify, I meant to imply that updates to texinfo.tex would occur in GNATS version 4.2. It will happen, just not yet. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-11-04 3:15 ` Chad Walstrom @ 2004-11-04 19:15 ` Chad Walstrom 2004-11-17 23:26 ` Chad Walstrom 0 siblings, 1 reply; 22+ messages in thread From: Chad Walstrom @ 2004-11-04 19:15 UTC (permalink / raw) To: help-gnats, bug-gnats [-- Attachment #1.1: Type: text/plain, Size: 857 bytes --] OK. An update is in order. It looks like gnats will not build on my system with the existing libiberty/ (and subsequently include/) directories and the changes I made to configure.in. I've tested dumping the old libiberty and replacing it with the one found in the gcc 3.4 sources. I was able to get a successful build and test installation. This is a larger change than I had hoped for, but probably one that needs to be done. The alternative is to step back from requiring autoconf 2.59, and instead stick with autoconf 2.13 for now. Anyway, I'll keep testing and let you know what I find. As an aside, should we be using bug-gnats for development discussions and leave help-gnats for end-user help? -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-11-04 19:15 ` Chad Walstrom @ 2004-11-17 23:26 ` Chad Walstrom 0 siblings, 0 replies; 22+ messages in thread From: Chad Walstrom @ 2004-11-17 23:26 UTC (permalink / raw) To: bug-gnats [-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --] Chad Walstrom wrote: > This is a larger change than I had hoped for, but probably one that > needs to be done. Update number two. I've tagged the HEAD branch of CVS before adding the libiberty updates. I intended on branching off HEAD to test this addition, but messed up my commits, so the libiberty updates are on HEAD instead of of the libiberty update branch. In any case, I have a few more cleanup changes to commit tonight. Note, I'm not getting the coredump issues with the update libiberty files. When I ran a backtrace on the offending gnatsd executable, it traced back to the memcpy function in the /lib/tls/libc-2.3.2.so library. I haven't tracked down the exact updates in libiberty yet to pinpoint the problem, but because I'm not getting these coredumps, I think might be able to assume they were fixed. So, wait for my commits later today, and then please test on your respective platforms. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Bug-gnats mailing list Bug-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnats [-- Attachment #3: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PAM Authentication Patch 2004-06-20 17:39 ` PAM Authentication Patch Pankaj K Garg [not found] ` <gargp@earthlink.net> @ 2004-06-21 16:13 ` Chad Walstrom 1 sibling, 0 replies; 22+ messages in thread From: Chad Walstrom @ 2004-06-21 16:13 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 889 bytes --] Pankaj K Garg wrote: > I'm attaching a patch for enabling PAM authentication support. ... > I've done some preliminary testing on my RH 9.0 Linux. Please let me > know if there's any problem with it. Thanks for the patch! I'll try to test this out later this week. If anyone else would like to do some testing, it would be appreciated. We can continue this discussion about security and gnatsd. I'll add a Security Enhancement in the TODO list for 5.x releases. We can decide whether or not we want to hold off on the PAM addition until TLS and/or SASL is introduced with TLS being of higher priority than SASL. I vote to allow it, but document the warnings and possible solutions regarding security. Feedback, ideas, rebuttals? -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Preparing 4.1... @ 2004-10-29 21:33 Chad C. Walstrom 2004-10-31 14:03 ` Pankaj Garg ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Chad C. Walstrom @ 2004-10-29 21:33 UTC (permalink / raw) To: help-gnats Hello, folks. Well, now that my training as a parent have been initiated, I think it's time to put my shoulder to the grindstone. Hans-Albert submitted a change to CVS to fix a couple buffer overflow problems on September 6th, and we should roll these out into a new release of gnats sooner than later. An optimistic goal is to have a release ready to roll out by Monday. If you have patches or fixes you would like incorporated, please let me know ASAP. Things I still plan on rolling in for the 4.1 release: * NEWS: Summarize changes and important security fixes * A note in the compilation documentation that bison version 1.35 or earlier is required to rebuild getdate.c. (Is there anyone versed in using bison to update the getdate.y file to use bison 1.875?) * install-sid: Either remove or update so that a separate configuration (sh) file is generated rather than editing send-pr. * send-pr: - Source a configuration (sh) file (i.e. /etc/gnats/send-pr.conf) and $HOME/.send-pr.conf to override default environment variables - Remove or update references/error messages regarding install-sid * debian/...: Roll in changes from current debian package I'm going to hold off on the PAM patch for just a while longer. Pankaj, do you think it would be possible to add a cautionary note in gnats.texi regarding the security problems in exposing the PAM to GNATS authentictation (i.e. plain-text network protocol sniffing)? For example, we should suggest that administrators not authenticate system accounts through GNATS. Rather, give suggestions for using other PAM modules to authenticate against alternate passwd or db format files. (Is it possible to blacklist pam modules for use w/gnats?) Once we get a gnutls layer incorporated into the gnats daemon and libraries, we could update our suggestions to be more permissive. Note: I do have to purchase and install a new power supply for my workstation at home, but I hope to have it up and running later tonight. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/~chewie _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom @ 2004-10-31 14:03 ` Pankaj Garg 2004-11-01 19:09 ` Pankaj Garg 2004-11-03 22:46 ` Chad C. Walstrom 2 siblings, 0 replies; 22+ messages in thread From: Pankaj Garg @ 2004-10-31 14:03 UTC (permalink / raw) To: Chad C. Walstrom; +Cc: help-gnats Yes, I'll put a cautionary note in gnats.texi. I don't think we can block modules selectively. Anyhow, people using PAM modules should know what they are doing, and will be careful of security issues, specially if we warn them. I'm under the impression that if you use a client and server on the same machine, then there is no security problem. Is this correct? Pankaj On Oct 29, 2004, at 2:33 PM, Chad C. Walstrom wrote: > I'm going to hold off on the PAM patch for just a while longer. > Pankaj, > do you think it would be possible to add a cautionary note in > gnats.texi > regarding the security problems in exposing the PAM to GNATS > authentictation (i.e. plain-text network protocol sniffing)? For > example, we should suggest that administrators not authenticate system > accounts through GNATS. Rather, give suggestions for using other PAM > modules to authenticate against alternate passwd or db format files. > > (Is it possible to blacklist pam modules for use w/gnats?) > -- Pankaj K Garg garg@zeesource.net 1684 Nightingale Avenue 408-373-4027 Suite 201 408-733-2737(fax) Sunnyvale, CA 94087 http://www.zeesource.net _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom 2004-10-31 14:03 ` Pankaj Garg @ 2004-11-01 19:09 ` Pankaj Garg 2004-11-03 22:39 ` Chad C. Walstrom 2004-11-03 22:46 ` Chad C. Walstrom 2 siblings, 1 reply; 22+ messages in thread From: Pankaj Garg @ 2004-11-01 19:09 UTC (permalink / raw) To: Chad C. Walstrom; +Cc: help-gnats One more thing, when I compiled Gnats 4.0 on my Mac OS X.3 (Panther) I had to take out the '-ansi' switch from GCC_CFLAGS in gnats/configure. I got this tip by searching this mailing list. Can we make this somehow permanent in 4.1? On Oct 29, 2004, at 2:33 PM, Chad C. Walstrom wrote: > Hans-Albert submitted a change to CVS to fix a couple buffer overflow > problems on September 6th, and we should roll these out into a new > release of gnats sooner than later. An optimistic goal is to have a > release ready to roll out by Monday. If you have patches or fixes you > would like incorporated, please let me know ASAP. _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-11-01 19:09 ` Pankaj Garg @ 2004-11-03 22:39 ` Chad C. Walstrom 0 siblings, 0 replies; 22+ messages in thread From: Chad C. Walstrom @ 2004-11-03 22:39 UTC (permalink / raw) To: help-gnats [-- Attachment #1.1: Type: text/plain, Size: 661 bytes --] Pankaj Garg wrote: > One more thing, when I compiled Gnats 4.0 on my Mac OS X.3 > (Panther) I had to take out the '-ansi' switch from GCC_CFLAGS > in gnats/configure. I got this tip by searching this mailing list. > > Can we make this somehow permanent in 4.1? I'm not sure exactly how to do this, but I suspect that it might involve adding a file to the config/ subdirectory for the Mac OS X platform. We have a few Mac's at work. I'll see what I can dig up. If someone knows the answer off-hand, let us know. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Preparing 4.1... 2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom 2004-10-31 14:03 ` Pankaj Garg 2004-11-01 19:09 ` Pankaj Garg @ 2004-11-03 22:46 ` Chad C. Walstrom 2 siblings, 0 replies; 22+ messages in thread From: Chad C. Walstrom @ 2004-11-03 22:46 UTC (permalink / raw) To: help-gnats, info-gnats [-- Attachment #1.1: Type: text/plain, Size: 1007 bytes --] OK, I think we're about ready to make the 4.1 release. send-pr/install-sid has been updated, the debian directory has been synchronized, configure.in has been updated in the gnats/ and send-pr/ directories. There are a few remaining issues to consider: * Compilation issues on Mac OS X 10.3.x * Core dump issues for Fedora Core 2 (remove optimization in the compile) * libiberty autoconf requires version 2.13 rather than 2.50. We either need to update the configure.in file to work with 2.50 or update libiberty to the most recent version (wherever that might be available) * Should we replace texinfo/texinfo.tex file with a more recent version? (Version 4.2?) If you're interested in testing the current development version of GNATS, please check out the recent CVS repository. https://savannah.gnu.org/cvs/?group=gnats -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-11-17 23:26 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom 2004-06-10 21:44 ` Chad C. Walstrom 2004-06-13 8:51 ` Mel Hatzis 2004-06-13 23:01 ` Andrew Gray 2004-06-11 22:28 ` Yngve Svendsen 2004-06-14 17:07 ` Pankaj K Garg 2004-06-14 17:16 ` Chad C. Walstrom 2004-06-20 17:39 ` PAM Authentication Patch Pankaj K Garg [not found] ` <gargp@earthlink.net> 2004-06-20 17:59 ` Mark D. Baushke 2004-06-21 7:25 ` Chad Walstrom 2004-06-21 15:26 ` Chad Walstrom [not found] ` <chewie@wookimus.net> 2004-06-21 15:34 ` Mark D. Baushke 2004-11-04 1:27 ` Preparing 4.1 Mark D. Baushke 2004-11-04 3:15 ` Chad Walstrom 2004-11-04 19:15 ` Chad Walstrom 2004-11-17 23:26 ` Chad Walstrom 2004-06-21 16:13 ` PAM Authentication Patch Chad Walstrom 2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom 2004-10-31 14:03 ` Pankaj Garg 2004-11-01 19:09 ` Pankaj Garg 2004-11-03 22:39 ` Chad C. Walstrom 2004-11-03 22:46 ` Chad C. Walstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).