From owner-cvs-all Sat Jan 19 9:16:32 2002 Delivered-To: cvs-all@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6B6DD37B402; Sat, 19 Jan 2002 09:16:22 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id C7CB95326; Sat, 19 Jan 2002 18:16:20 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Andrey A. Chernov" Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/libexec/ftpd ftpd.c References: <200201190901.g0J91H641020@freefall.freebsd.org> <20020119163648.GD10976@nagual.pp.ru> From: Dag-Erling Smorgrav Date: 19 Jan 2002 18:16:20 +0100 In-Reply-To: <20020119163648.GD10976@nagual.pp.ru> Message-ID: Lines: 60 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Andrey A. Chernov" writes: > 1) I agree that PAM_CRED_ERR may be not the perfect choice and hear for > better altenatives. Possibly PAM_CRED_UNAVAIL. It depends on what exactly you mean by it. > 2) Excepting that thing, you already see my patches in the tree. I may > produce diff, if it is needed. That's no good. You've spammed two PAM modules, two PAM applications and three PAM configuration file with unreviewed, unapproved and (mostly) incorrect changes, and you expect Mark and me to just accept that and clean up after you? That's not the way things work. Please back out all your commits, then submit a patch for review. As a side note, the sheer number of commits you made to the same files in a very short time span are (to me) a clear indication that your changes were poorly thought out and poorly tested, and that your understanding of how PAM works is insufficient. If you knew what you were doing, had thought things out, and had tested your patches thoroughly, a single commit to each affected file would have sufficed. > 3) I already post most detailed explanation considering all possible > variants. I can resend it to you, if you miss it in the thread. I haven't seen a "most detailed explanation"; I've only seen a series of confused, disjointed excuses. I want to see a single message that clearly explains, in order: 1) what the current behavior is 2) why it is incorrect 3) how you propose to fix it and I want it to be accompanied by a complete unified diff of the proposed changes. For what it's worth, I've read the log messages skimmed through the diffs, and from my point of view your changes fall into two broad categories: 1) Changes that attempt to work around a small amount of breakage in libopie by introducing moderate to large amounts of breakage in pam_opie(8), ftpd(8) and login(1). These have some merit in that they try to correct an error, but I believe the approach is wrong. 2) Changes to perfectly good code that simply enforce your opinion of how PAM should behave, with no regard for the opinion of the PAM maintainers or of the security officer. These have no merit whatsoever unless you manage to convince Kris that information leakage is not a security problem. As Kris already stated, PAM is a critical piece of security infra- structure, and you may not commit changes to it without discussing them first - at the very least with Mark and myself, and preferably also on -arch, -audit and / or -security. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message