From owner-cvs-all@FreeBSD.ORG Tue Feb 3 09:19:12 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B5F116A4CF; Tue, 3 Feb 2004 09:19:12 -0800 (PST) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C0B443D7D; Tue, 3 Feb 2004 09:19:08 -0800 (PST) (envelope-from trhodes@FreeBSD.org) Received: from localhost (acs-24-154-235-164.zoominternet.net [24.154.235.164]) by pittgoth.com (8.12.10/8.12.10) with SMTP id i13HJ5GI014673; Tue, 3 Feb 2004 12:19:05 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Tue, 3 Feb 2004 12:19:17 -0500 From: Tom Rhodes To: Andre Oppermann Message-Id: <20040203121917.17dd2e86@localhost> In-Reply-To: <401FD43E.174A6839@freebsd.org> References: <200402030932.i139WBpQ054113@repoman.freebsd.org> <20040203112824.01dfdc99@localhost> <20040203163214.GD17960@electra.cse.Buffalo.EDU> <401FD252.7F56765E@freebsd.org> <401FD43E.174A6839@freebsd.org> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: Ken Smith cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/kerberos5/lib/libroken Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 17:19:12 -0000 On Tue, 03 Feb 2004 18:02:54 +0100 Andre Oppermann wrote: > Andre Oppermann wrote: > > > > Ken Smith wrote: > > > > > > On Tue, Feb 03, 2004 at 11:28:24AM -0500, Tom Rhodes wrote: > > > > On Tue, 3 Feb 2004 01:32:11 -0800 (PST) > > > > Ruslan Ermilov wrote: > > > > > > > > > bland 2004/02/03 01:32:11 PST > > > > ^^^^^ > > > > > > > > You're bland... :) > > > > > > > > > > > > > > FreeBSD src repository > > > > > > > > > > Modified files: > > > > > kerberos5/lib/libroken Makefile > > > > > Log: > > > > > Take signal.c out of sources. > > > > > > > > > > Reviewed by: nectar > > > > > > > > Any idea what is causing this yet? Perhaps I missed/overlooked/ignored > > > > the discussion? > > > > > > > > -- > > > > Tom Rhodes > > > > > > We're actively trying to track it down now. No ETA on it being fixed > > > at this point, it is probably buried deep inside some perl scripts > > > but that's just a guess. We have caught the last couple of examples > > > to help try and track it down though (two or three have happened in > > > the last two or three days). > > > > All this magic happens in CVSROOT-src/cfg.pm where $PID for temporary > > files and $COMMITTER are set. $PID is probably not the problem but > > $COMMITTER seems to be. The text in this variable is put verbatim into > > the commit message in CVSROOT-src/log_accum.pl function build_header(). > > > > I'm not a perl hacker so I can't really comment on the code snipped > > below but it looks strange that the first $ENV{} has the environment > > variable name in "" and the second one in '' quotes. At least it seems > > to be inconsistent. I wonder if we ever can get into the case where > > LOGNAME and USER are not set in the users environment. It might be > > that for some SSH setups the environment is cleared or altered on > > freefall. Nontheless I don't think any of the others should return > > anything else than the current username. Unless there is a bug in > > the kernel wrt credential handling or some other bug in perl. > > > > # The username of the committer. > > $COMMITTER = $ENV{"LOGNAME"} || $ENV{'USER'} || getlogin > > || (getpwuid($<))[0] || sprintf("uid#%d",$<); > > Hmm... getlogin might be the problem (from perl man page): > > getlogin > > Implements the C library function of the same name, which on most systems > returns the current login from /etc/utmp, if any. If null, use getpwuid. > > Using LOGNAME and USER from the environment seems to be pretty unsave > as it can be changed by the user to any arbitrary string (or other > username). I think that, if you really believe this to be the problem, you should work with Ken on this. Thanks. :) -- Tom Rhodes