From owner-cvs-all Sat Jan 19 9:50:23 2002 Delivered-To: cvs-all@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 4907537B445; Sat, 19 Jan 2002 09:49:43 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0JHnXd27475; Sat, 19 Jan 2002 17:49:33 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id g0JHo9t22888; Sat, 19 Jan 2002 17:50:09 GMT (envelope-from mark@grondar.za) Message-Id: <200201191750.g0JHo9t22888@grimreaper.grondar.org> To: Dag-Erling Smorgrav Cc: "Andrey A. Chernov" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/libexec/ftpd ftpd.c References: In-Reply-To: ; from Dag-Erling Smorgrav "19 Jan 2002 18:16:20 +0100." Date: Sat, 19 Jan 2002 17:50:09 +0000 From: Mark Murray 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 I agree strongly with this. M > "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 -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message