From glen at delfi.ee Tue Mar 1 11:00:24 2005 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 1 Mar 2005 13:00:24 +0200 Subject: [cvsspam-devel] mail threading Message-ID: <200503011300.24465.glen@delfi.ee> hi i've been using (seeing, whatever) some other cvs diff program, which created message-id and references header so the threading would work in mail client any chance to have this behaviour also in cvsspam? [...] Message-ID: References: In-Reply-To: [...] -- glen From dave at badgers-in-foil.co.uk Tue Mar 1 11:32:10 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 1 Mar 2005 11:32:10 +0000 Subject: [cvsspam-devel] record_lastdir.rb Insecure operation In-Reply-To: <1109632232.22534.34.camel@localhost.localdomain> References: <1109632232.22534.34.camel@localhost.localdomain> Message-ID: <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> On Mon, Feb 28, 2005 at 05:10:32PM -0600, Steve Fox wrote: > I'm trying to set up CVSSPam in a SourceForge-like environment with one > CVSSpam installation shared between multiple CVS repositories. Sometimes > it works fine, but other times I see the below error. > > -------------------------------------------------------------------- > Nothing in CVS/Entries > for ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., . Odd; I wonder why it believes there are so many '.' arguments being passed. Does that text always appear? Maybe you could add this line at the top of record_lastdir.rb to dump the full argument list, $stderr.puts "record_lastdir.rb: ARGV=<#{ARGV.join('>, <')}>" I don't think that this is necessarily related to what follows, though. > /usr/local/cvsspam/record_lastdir.rb:16:in `stat': Insecure operation - > stat (SecurityError) > from /usr/local/cvsspam/record_lastdir.rb:16:in `find_data_dir' > from /usr/local/cvsspam/record_lastdir.rb:15:in `each' > from /usr/local/cvsspam/record_lastdir.rb:15:in `find_data_dir' > from /usr/local/cvsspam/record_lastdir.rb:22 > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > > Error, CVS operation failed > -------------------------------------------------------------------- > > I did some Googling last week and found a suggestion to call an untaint > function right before the stat() call, but it sounded kind of hackish. I actually had no idea that Ruby would do this. I *guess* that the given invocation of the script is seeing the temp dir created by a another (failed? concurrent?) invocation by a different user. Since the stat() which fails is simply attempting to exclude dirs not owned by the committing user, I'd say the fix for your problem is simply to catch and ignore this exception. I must admit to not knowing Ruby's exception handling syntax off the top of my head :) I'll have a deeper look into this later. > We're using CVS 1.11.18 and Ruby 1.6.7 on the server. The #cvsspam* > directories created in /tmp have user ownership of the user performing > the commit and group ownership of the project's unix group and > permissions set 0700. Perhaps that is the problem? Is out umask too > strict? CVSspam doesn't clean up tmp dirs from failed invocations, so you may want to do that by hand (unless you have a scheduled cleantmp anyway). dave -- http://david.holroyd.me.uk/ From dave at badgers-in-foil.co.uk Tue Mar 1 11:49:45 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 1 Mar 2005 11:49:45 +0000 Subject: [cvsspam-devel] mail threading In-Reply-To: <200503011300.24465.glen@delfi.ee> References: <200503011300.24465.glen@delfi.ee> Message-ID: <20050301114945.GB11306@vhost.badgers-in-foil.co.uk> On Tue, Mar 01, 2005 at 01:00:24PM +0200, Elan Ruusam?e wrote: > i've been using (seeing, whatever) some other cvs diff program, which created > message-id and references header so the threading would work in mail client > > any chance to have this behaviour also in cvsspam? > > [...] > Message-ID: > References: > In-Reply-To: > [...] Here, the local MTA to which messages are submitted adds a Message-Id automatically. Are you using CVSspam's SMTP support, rather than $sendmail? While, without looking at the RFCs, I'd imagine that the MUA is expected to generate the Message-Id, I always thought that $sendmail is sort-of acting as the MUA on CVSspam's behalf. If that's an incorrect assumption, I can certainly look into having CVSspam generate that header. As for References and In-Reply-To, what values do you actually expect to see in these headers? Are you just referring to the values as they would appear in a *reply* to a CVSspam message? dave -- http://david.holroyd.me.uk/ From glen at delfi.ee Tue Mar 1 13:22:18 2005 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 1 Mar 2005 15:22:18 +0200 Subject: [cvsspam-devel] mail threading In-Reply-To: <20050301114945.GB11306@vhost.badgers-in-foil.co.uk> References: <200503011300.24465.glen@delfi.ee> <20050301114945.GB11306@vhost.badgers-in-foil.co.uk> Message-ID: <200503011522.18308.glen@delfi.ee> On Tuesday 01 March 2005 13:49, David Holroyd wrote: > On Tue, Mar 01, 2005 at 01:00:24PM +0200, Elan Ruusam?e wrote: > > i've been using (seeing, whatever) some other cvs diff program, which > > created message-id and references header so the threading would work in > > mail client > > > > any chance to have this behaviour also in cvsspam? > > > > [...] > > Message-ID: > > References: > > In-Reply-To: > > [...] > > Here, the local MTA to which messages are submitted adds a Message-Id > automatically. Are you using CVSspam's SMTP support, rather than > $sendmail? it may add these if they're missing, but not obligatory for example bernstein created separate daemon (ofmipd) for such purpose :) (do you want your smtp server generate message-id's with your server name, which just pass thru?) http://cr.yp.to/mess822.html and i'm using local sendmail-compatible /usr/sbin/sendmail. > While, without looking at the RFCs, I'd imagine that the MUA is expected > to generate the Message-Id, I always thought that $sendmail is sort-of > acting as the MUA on CVSspam's behalf. If that's an incorrect > assumption, I can certainly look into having CVSspam generate that > header. > > > As for References and In-Reply-To, what values do you actually expect to > see in these headers? Are you just referring to the values as they would > appear in a *reply* to a CVSspam message? no, these should be in cvsspam generated messages. if the values are created with known algorithm, then the references create up thread in that sample the message-id and references are cvsrepository+revision@domain so eventually, it will create thread of messages, for changes to same file(s) you could have look at that program which produced those headers: http://cvs.pld-linux.org/cgi-bin/cvsweb/CVSROOT/logdiff.pl > dave -- glen From dave at badgers-in-foil.co.uk Tue Mar 1 14:58:33 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 1 Mar 2005 14:58:33 +0000 Subject: [cvsspam-devel] mail threading In-Reply-To: <200503011522.18308.glen@delfi.ee> References: <200503011300.24465.glen@delfi.ee> <20050301114945.GB11306@vhost.badgers-in-foil.co.uk> <200503011522.18308.glen@delfi.ee> Message-ID: <20050301145833.GA12702@vhost.badgers-in-foil.co.uk> On Tue, Mar 01, 2005 at 03:22:18PM +0200, Elan Ruusam?e wrote: > On Tuesday 01 March 2005 13:49, David Holroyd wrote: > > As for References and In-Reply-To, what values do you actually expect to > > see in these headers? Are you just referring to the values as they would > > appear in a *reply* to a CVSspam message? > no, these should be in cvsspam generated messages. > if the values are created with known algorithm, then the references create up > thread > > in that sample the message-id and references are cvsrepository+revision@domain > so eventually, it will create thread of messages, for changes to same file(s) > > you could have look at that program which produced those headers: > http://cvs.pld-linux.org/cgi-bin/cvsweb/CVSROOT/logdiff.pl I didn't understand what you were suggesting originally, but now I get it: That's a very cool idea! It seems that this will only work if most commits change just a single file, but I expect that will fit with many people's way of working. So the feature should work like this: - A message should contain an entry in References for each modified or deleted file - Each ref will identify to the file's *old* revision - If the commit only effects a single file, add a Message-Id that refers to the *new* revision of the file - If the commits effects more than one file, come up with some resonable timestamp()+random() value to put before the @hostname sounds good? dave -- http://david.holroyd.me.uk/ From glen at delfi.ee Tue Mar 1 21:21:16 2005 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 1 Mar 2005 23:21:16 +0200 Subject: [cvsspam-devel] mail threading In-Reply-To: <20050301145833.GA12702@vhost.badgers-in-foil.co.uk> References: <200503011300.24465.glen@delfi.ee> <200503011522.18308.glen@delfi.ee> <20050301145833.GA12702@vhost.badgers-in-foil.co.uk> Message-ID: <200503012321.16615.glen@delfi.ee> On Tuesday 01 March 2005 16:58, David Holroyd wrote: > I didn't understand what you were suggesting originally, but now I get > it: That's a very cool idea! > > It seems that this will only work if most commits change just a single > file, but I expect that will fit with many people's way of working. > > So the feature should work like this: > > - A message should contain an entry in References for each modified or > deleted file > - Each ref will identify to the file's *old* revision > - If the commit only effects a single file, add a Message-Id that > refers to the *new* revision of the file > - If the commits effects more than one file, come up with some > resonable timestamp()+random() value to put before the @hostname > > sounds good? yes, but i'm not sure about the random(). it's no way possible to continue that thread. but having message-id one of the commited files (doesn't matter probably which one of them), it's possible that the thread continues. altho, question remains, is it wanted that such mass commit thread continues? i have no opinion here. and not to be forgotten, in-reply-to header will contain list of old-revision of all commited files. > dave -- glen From drfickle at us.ibm.com Wed Mar 2 22:23:06 2005 From: drfickle at us.ibm.com (Steve Fox) Date: Wed, 02 Mar 2005 16:23:06 -0600 Subject: [cvsspam-devel] record_lastdir.rb Insecure operation In-Reply-To: <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> References: <1109632232.22534.34.camel@localhost.localdomain> <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> Message-ID: <1109802186.5916.39.camel@localhost.localdomain> On Tue, 2005-03-01 at 11:32 +0000, David Holroyd wrote: > Odd; I wonder why it believes there are so many '.' arguments being > passed. Does that text always appear? Maybe you could add this line > at > the top of record_lastdir.rb to dump the full argument list, > > $stderr.puts "record_lastdir.rb: ARGV=<#{ARGV.join('>, <')}>" Unfortunately the person who reported this to me can't recreate the problem any more. If they hit it again I'll try to get this debug output. > I actually had no idea that Ruby would do this. I *guess* that the > given invocation of the script is seeing the temp dir created by a > another (failed? concurrent?) invocation by a different user. > > Since the stat() which fails is simply attempting to exclude dirs not > owned by the committing user, I'd say the fix for your problem is > simply to catch and ignore this exception. Ok, maybe I'll give that a shot if we hit this again. > CVSspam doesn't clean up tmp dirs from failed invocations, so you may > want to do that by hand (unless you have a scheduled cleantmp anyway). Good to know. I'll create a script to handle these. Thanks for your time and help. -- Steve Fox IBM Linux Technology Center http://www.ibm.com/linux/ltc http://k-lug.org From dave at badgers-in-foil.co.uk Wed Mar 2 23:22:12 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Wed, 2 Mar 2005 23:22:12 +0000 Subject: [cvsspam-devel] record_lastdir.rb Insecure operation In-Reply-To: <1109802186.5916.39.camel@localhost.localdomain> References: <1109632232.22534.34.camel@localhost.localdomain> <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> <1109802186.5916.39.camel@localhost.localdomain> Message-ID: <20050302232212.GA7444@vhost.badgers-in-foil.co.uk> On Wed, Mar 02, 2005 at 04:23:06PM -0600, Steve Fox wrote: > On Tue, 2005-03-01 at 11:32 +0000, David Holroyd wrote: > > I actually had no idea that Ruby would do this. I *guess* that the > > given invocation of the script is seeing the temp dir created by a > > another (failed? concurrent?) invocation by a different user. > > > > Since the stat() which fails is simply attempting to exclude dirs not > > owned by the committing user, I'd say the fix for your problem is > > simply to catch and ignore this exception. > > Ok, maybe I'll give that a shot if we hit this again. I've just-this-minute Googled it myself. Looks like I was completely wrong about the problem here (I'd never looked at Ruby's tainting security model[1] before). It appears that this error happens when, - Ruby's $SAFE is >=1 - File.stat() is called on a tainted String Ruby automaticaly sets $SAFE=1 when running setuid or setgid. Would this ever be the case in your envionment? I'll need to investigate what changes would be reqired to have CVSspam work with taint-checks enabled, and if this even makes sense. dave ---- [1] http://rubycentral.com/book/taint.html -- http://david.holroyd.me.uk/ From drfickle at us.ibm.com Fri Mar 4 21:22:51 2005 From: drfickle at us.ibm.com (Steve Fox) Date: Fri, 04 Mar 2005 15:22:51 -0600 Subject: [cvsspam-devel] record_lastdir.rb Insecure operation In-Reply-To: <20050302232212.GA7444@vhost.badgers-in-foil.co.uk> References: <1109632232.22534.34.camel@localhost.localdomain> <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> <1109802186.5916.39.camel@localhost.localdomain> <20050302232212.GA7444@vhost.badgers-in-foil.co.uk> Message-ID: <1109971371.7518.5.camel@localhost.localdomain> On Wed, 2005-03-02 at 23:22 +0000, David Holroyd wrote: > Ruby automaticaly sets $SAFE=1 when running setuid or setgid. Would > this ever be the case in your envionment? Sure enough, I took the suid bit off the CVS binary and the error did not occur. Unfortunately that breaks other things in SourceForge EE so I'll still have to work around it. -- Steve Fox IBM Linux Technology Center http://www.ibm.com/linux/ltc http://k-lug.org From dave at badgers-in-foil.co.uk Sat Mar 5 18:26:45 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Sat, 5 Mar 2005 18:26:45 +0000 Subject: [cvsspam-devel] record_lastdir.rb Insecure operation In-Reply-To: <1109971371.7518.5.camel@localhost.localdomain> References: <1109632232.22534.34.camel@localhost.localdomain> <20050301113210.GA11306@vhost.badgers-in-foil.co.uk> <1109802186.5916.39.camel@localhost.localdomain> <20050302232212.GA7444@vhost.badgers-in-foil.co.uk> <1109971371.7518.5.camel@localhost.localdomain> Message-ID: <20050305182645.GA32723@vhost.badgers-in-foil.co.uk> On Fri, Mar 04, 2005 at 03:22:51PM -0600, Steve Fox wrote: > On Wed, 2005-03-02 at 23:22 +0000, David Holroyd wrote: > > Ruby automaticaly sets $SAFE=1 when running setuid or setgid. Would > > this ever be the case in your envionment? > > Sure enough, I took the suid bit off the CVS binary and the error did > not occur. Unfortunately that breaks other things in SourceForge EE so > I'll still have to work around it. Try changing the shebang line at the top of the Ruby files to explicitly set the tainting level to 'none', #!/usr/bin/ruby -wT0 I don't know if this will override the value due to setuid/setgid, but it's worth a try. I am also seeing what changes would be required to run the scripts normally with $SAFE at 1. I think you are correct that it would be naive to simply untaint all the tainted strings without a basic audit of the code used to derive them. dave -- http://david.holroyd.me.uk/ From bkelly at fppartners.com Wed Mar 23 19:14:44 2005 From: bkelly at fppartners.com (Kelly, Brendan) Date: Wed, 23 Mar 2005 14:14:44 -0500 Subject: [cvsspam-devel] cvsnt support Message-ID: <93037AC02C65324EAB5014015C6E6D0502BCA9FD@frontpt7.fppartners.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C52FDC.927E6010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The archives reference a patch file to allow cvsspam to run under cvsnt with cygwin-ruby on a windows box. Unfortunately, the link is dead and the site maintainer has lost the file. =20 Any suggestions on where I might get a modified version of cvsspam to run on windows (or how I might do this myself)? =20 Many thanks,=20 best regards ********************************************************************** CONFIDENTIALITY: This e-mail is confidential and/or legally privileged and = is intended only for the use of the individual or entity named herein. If y= ou are not the intended recipient, you are hereby notified that any disclos= ure, copying, distribution, or the taking of any action in reliance on the = contents of this e-mail is strictly prohibited. In this regard, if you have= received this e-mail in error, please notify us by reply e-mail immediatel= y and then delete this message from your system. =20 Thank you for your cooperation. ********************************************************************** ------_=_NextPart_001_01C52FDC.927E6010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The archives reference a patch file to allow cvsspam to = run under cvsnt with cygwin-ruby on a windows box. Unfortunately, the link is d= ead and the site maintainer has lost the file.

 

Any suggestions on where I might get a modified version = of cvsspam to run on windows (or how I might do this myself)?

 

Many thanks,

best regards



**********************************************************************
CONFIDENTIALITY: This e-mail is confidential and/or legally privileged and = is intended only for the use of the individual or entity named herein. If y= ou are not the intended recipient, you are hereby notified that any disclos= ure, copying, distribution, or the taking of any action in reliance on the = contents of this e-mail is strictly prohibited. In this regard, if you have= received this e-mail in error, please notify us by reply e-mail immediatel= y and then delete this message from your system.

Thank you for your cooperation.

**********************************************************************
 =00 ------_=_NextPart_001_01C52FDC.927E6010--