How important is this bug ? eg security ?

It's a local filesystem racecondition, which may cause an overflow on the heap. It's likely to be hard to trigger the race, and creating successful exploit code that doesn't just crash the server is probably very hard, since it's a heap overflow.

Because if this can allow remote access to webservers like Roxen, Chilimoon or Caudium we should be prepared to work fast.

By the way, is this bug can push a new pike 7.6 version ?

Yes.

Good to hear that :) Estimated time of release ? :p

This weekend I suppose.

On Sun, 9 Oct 2005 10:55:06 +0000 (UTC) "Peter Bortas @ Pike developers forum" 10353@lyskom.lysator.liu.se wrote:

Time to do something about this today. Are the bugs against the last beta resolved?

I sent in patches to fix gettext and pdflib configure checks on at least openbsd, back in august. Both problems still exist in the latest 7.6 CVS, although I think they were both fixed in 7.7.

Adam

On Sun, 9 Oct 2005 14:25:06 +0000 (UTC) "Peter Bortas @ Pike developers forum" 10353@lyskom.lysator.liu.se wrote:

Neither are regressions, right? Since it's a security related release I'm only going to be concerned about regressions.

I thought it was a new stable release? A new release was already planned before the security issue came up right? It seems dumb that the "latest stable release" doesn't work properly and needs patching. Or is there going to be a stable release of 7.7? I've been attempting to get pike into the openbsd ports tree, but it seems like a waste of time. I get the impression that the pike developers don't want people using pike.

Adam

On Sun, 9 Oct 2005 16:25:06 +0000 (UTC) "Peter Bortas @ Pike developers forum" 10353@lyskom.lysator.liu.se wrote:

It should hopefully be stable, but I'm not going to put the energy in to it that a regular stable release gets. Especially not with 80% of Xenofarm incapacitated at the moment.

For what its worth, the reason my openbsd/i386 xenoclient updates haven't been happening is because sometimes my xenoclient runs seem to like sitting idle for days at a time until I notice and login to kill pike. One pike process is sleeping waiting on poll, 4 makes are in idle wait, and there's a bunch of sh's in idle pause, and that's it. Killing the sleeping pike starts things moving again.

Stable pike releases seem to be few and far between. I just don't want to see another release come out that still has the same problems that I've already reported (especially simple ones like these), and then when I try to bug for a "real" stable release later getting an apathetic "we just did a release last month" in response. It appears as though convincing someone to make a stable release is quite a difficult task already, so I don't imagine it will be even worth trying when the reason will just be some minor configure fixes.

Adam

It has been longer since the last one, I estimate.

Yep. It goes something like this:

1. The current release manager thinks it's been to long since the last release.

2. The release manager asks for outstanding issues¹ including an up to date CHANGES.

3. Outstanding issues are fixed and someone will check in new features in panic² to get them in the new release. Repeat 2.

4. If the release manager did not time out in the above loop a beta is done. Repeat 2.

5. If the release manager did not time out in the above loop a release is done.

¹ Room for optimizations: Someone could take it upon him or her to keep an updated list of issues, separated in classes like "securty", "regressions" and "bugs". Preferably in Crunch.

² Room for optimizations: Getting releases out more often always makes this step less troublesome.

Typically, the source code package is what embodies the "release". Binary packages are then provided as they become available. Often this can take a couple of days. But what happens in step 5 is that the source package is built (make export) and posted on the site.

You need to have the bundles in the bundle directory when you do make export. I've added an ugly check for those in 7.6.

The bundles are just library distributions. Patches against them are applied during the client make process, if the destination host has no suitable library. I don't know if it is possible to force the bundles to be used, which might be desired.

Note that the libs put into the dist bundle should be the same as in the Xenofarm dists, otherwise we'll probably have a problem. More importantly, we don't know if we have a problem or not :)

If we assume that the loop outlined by Peter Bortas is done, (all "musts" have been backported, Unicode is updated etc. and the CHANGELOG is done) then the following should occur.

The source should of course build with Xenofarm and active measures should be take to have it green on as many systems as possible. Often problems are with the machines, so this usually involves quite a bit of sysadm work.

I always make a few manual tests with the source such as make verify on a dmalloc build and a make verify within valgrind.

Checks for some previous mistakes has been added to the tools/release_checks.pike, and should be run.

Bundles should be added to the bundles directory.

make doc make export

The exported build must then be tested on another computer so that it build and then a binary dist should be made (make bin_export).

The exported binary build must then be tested on yet another computer so that it installs. I guess that the external module build system with monger should be tested here as well.

Weehee! The build is good! You rarely get down all the way here without cheating and forgetting a test or two :) Now release the source and make proper binary builds on various platforms.

Start working on windows binary....

why am i only seeing mails from bill on this thread? and not any of the mails he replies to?

greetings, martin.

On Tue, Oct 11, 2005 at 01:15:11PM +0000, Hedda (No ads at the moment) @ Pike (-) developers forum wrote:

So I think that you have a SPAM-filter or something that filters out "Martin Nilsson (lvl 60)" for some reason.

you are right, i am sorry, i should have checked that possibility. it turns out that in fact the whole thread except for bills mails were tagged as spam.

seems that our university spam filter is tuned against numbers at the end of a subject: pts rule name description 10 VIRUS_SPAM_2 Virus sending spam: ID/number in subject

Or maybe you can't even read this?

for some reason this mail is not tagged as spam either, just like bills mails. and i can't figure out why...

anyways, it's a local problem. sorry for the noise...

greetings, martin.

I wrote about the bug Marcus reported earlier this week. Noone bothered to answer that. My suggestion for 7.6 though is to let the line iterator throw an exception if called with no arguments.