Subject: How to coordinate web team for security releases?

From: Josh Berkus <[email-masked]>
Date: Mon, 5 Feb 2007 11:28:13 -0800

WWW core team,

I need a way to coordinate with you around preparing postgresql.org for 
upcoming releases, especially for security releases where it's critical that 
the timing be tight.  Due to some issues with this last release, pgsql-www 
obviously isn't the right venue.

What I need is a non-public list for this, so that I can ask for web site 
changes 3-4 days ahead without it becoming a news item.

 I can think of two means:

1) I'm about to create a "contacts" ML for the regional contacts and 
regionalized website maintainers to give them advanced but non-public notice 
of upcoming releases in the future.  Magnus, Robert, Devrim, etc. could be 
subscribded to that; in fact, Magnus and Devrim will be as RCs.

2) I could sent it to slaves-to-the-www.  

3) Something else.

Thoughts?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 19:39:57 +0000

> 2) I could sent it to slaves-to-the-www.  

-packagers?

/D

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 20:46:59 +0100

> changes 3-4 days ahead without it becoming a news item.

well not that is closely related to the -www issue but the fix/patch
will end up on anoncvs/viewcvs days before the release too (and will get
published including the Security: tag and the commit message there and
distributed to the buildfarm boxes at least).
So to keep it really under the hood would probably be quite difficult to do.

Stefan

---

From: Josh Berkus <[email-masked]>
Date: Mon, 5 Feb 2007 11:51:30 -0800

Stefan,

> So to keep it really under the hood would probably be quite difficult to

Actually, we were discussing mechanisms to change that on -core.  Suggestions 
are welcome.  Mostly we just want to keep a tight lid on security expoloit 
information until the day of release.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 05 Feb 2007 20:52:32 +0100

> changes 3-4 days ahead without it becoming a news item.

Will that really help? In this case, the files were uploaded to the ftp
site long before you made your post to the -www list... Does it really
make a difference?

//Magnus

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 20:59:51 +0100

> information until the day of release.

yeah I understand the reasoning - but given the rather distributed
nature of the postgresql infrastructure I guess it might be very
difficult if not impossible to get down to less then 72 or 48 hours.
One needs that time to commit the patch and probably wait for at least
one round of buildfarm results, tag all the affected branches and build
the tarballs and finally all the packagers need to build at least the
most important binary packages.

Stefan

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Mon, 5 Feb 2007 20:04:38 -0000

> changes 3-4 days ahead without it becoming a news item.

I think Dave's idea of -packagers works fine, there should be enough overlap.

What we also need is a better way to update the mirrors in a timely manner.

- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200702051500
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 21:08:06 +0100

> What we also need is a better way to update the mirrors in a timely manner.

the fact that new releases are coming up also got announced on IRC over
three days ago and we have >300 people there ...

Stefan

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 20:09:48 +0000

> three days ago and we have >300 people there ...

Where did that come from?

Regards, Dave.

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 20:11:58 +0000

> What we also need is a better way to update the mirrors in a timely manner.

I don't see how we can do that unless we persuade all the mirrors to
update more than once per day, which I doubt the larger ones will do.

I guess we could consider reducing the max age of a mirror when we
generate the selection pages - but that will mean mirrors will be
enabled and disabled at different parts of the day for a few hours at a
time.

/D

---

From: Tom Lane <[email-masked]>
Date: Mon, 05 Feb 2007 15:12:28 -0500

> So to keep it really under the hood would probably be quite difficult to do.

Certainly.  We're not looking for something absolutely bulletproof, we
just don't want to read about it on pgsql-announce before the actual
release ;-).  Postgres isn't the sort of target that is likely to have
blackhats tracking our anoncvs watching for interesting commits.  We
think it's probably enough if we can keep the topic out of the public
mailing lists until the release announcement.  Or at least, let's try
to accomplish that before worrying about anything tighter.

(Speaking of which, somebody can go ahead and approve those Security:
pgsql-commit messages now ...)

			regards, tom lane

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 21:21:23 +0100

> enabled and disabled at different parts of the day for a few hours at a

how much traffic are the mirrors handling on average btw ? maybe we do
not actually need 70+ or so offical mirrors and reducing that number
significantly to the ones that can get updated more often might help a bit.

Stefan

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 21:36:33 +0100

> Where did that come from?

david fetter according to my irc-client  - but I suppose he just guessed
that from the fact that you did 3 commits(to pginstaller which is also
on the commiters list) on that day mentioning the new versions in the
commit message ;-)

Stefan

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 05 Feb 2007 21:40:09 +0100

> to accomplish that before worrying about anything tighter.

That is probably a reasonable approach to the whole issue - and for the
anoncvs/buildfarm testing thing(if we want/need that even for such
patches) we could maybe look into the recent discussion on allowing
certain patches to be pulled from trusted people.
Maybe one could use that infrastructure to get basic buildfarm testing
without the need to commit to to the main public tree immediatly.
However the time gained from that might not be worth the pain ...

Stefan

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 20:53:34 +0000

> significantly to the ones that can get updated more often might help a bit.

I have no idea. You could probably work out an average by correlating
file sizes with downloads logged by the tracker, but that'd take a bit
of patience.

Regards, Dave.

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 20:59:38 +0000

> on the commiters list) on that day mentioning the new versions in the

Yeah, I realised that after I'd done it. They also hit the pgAdmin SVN
repo because thats where the CHM docs are built from.

:-(

/D

---

From: David Fetter <[email-masked]>
Date: Mon, 5 Feb 2007 13:03:15 -0800

On Mon, Feb 05, 2007 at 11:28:13AM -0800, Josh Berkus wrote:
> WWW core team,
> 
> I need a way to coordinate with you around preparing postgresql.org
> for upcoming releases, especially for security releases where it's
> critical that the timing be tight.  Due to some issues with this
> last release, pgsql-www obviously isn't the right venue.

I think we need to separate this into two issues:

1. Publishing vulnerabilities only after we've distributed the fix, and

2. Publishing the fact that a minor point release is on its way in
order that organizations be able to schedule upgrades.

I see these as separable announcements, with what appear to be
opposing motivations.

For getting upgrades in the pipeline, sooner is better than later.
Quite a few outfits have processes that take two weeks or more before
the upgrade actually goes through.  Giving them a heads-up on this is
a good thing, and serious users know that we don't do minor point
releases for the sheer thrills of it, i.e. just knowing that something
is coming is enough reason for them to schedule the aforementioned
upgrade.

For vulns, it's really a Good Idea to let as little about them as
possible get out in advance of the fix.  It's this part that is
sensitive information.

So here's my proposal.  As soon as we have a pretty good idea of when
we are going to do a minor point release, we should let the public
know with a generic, "Point releases coming.  Get ready to upgrade"
kind of message.

When we find and characterize vulns, we put out at least the severity
on some specific private list--which one is TBD--when known so
mirrors, packagers, etc. can make it a priority to make those updates
available ASAP.

As far as the details of vulns, those should only get published as
part of the post-distribution announcement.

Cheers,
D
-- 
David Fetter <[email-masked]> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Mon, 5 Feb 2007 21:07:24 -0000

> update more than once per day, which I doubt the larger ones will do.

Well, I was thinking more in terms of something in addition to the daily update,
such as an hourly (or less) check that would pull in any high-priority changes[1].
Seems that most of the time-sensitive changes we've needed affect a very small
subset of the pages and should not be a traffic concern. The good thing about
such a system is that we would not even need 100% buy-in right away - the ones
not implementing it would still get the daily update. Eventually we'd want to
strongly encourage everyone to use it, of course.

[1] Indication of a need to pull in changes could be as simple as an atomic
number stored in a text file somewhere, or by a list of files and timeststamps,
or something else simple yet low traffic.

- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200702051602
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 21:12:58 +0000

> strongly encourage everyone to use it, of course.

A nice idea, but a good number of our mirrors are big mirrors sites who
likely won't want to muck around with special configs for each site they
mirror.

Perhaps we could group the mirrors into 'preferred' and 'normal'
sections, where the preferred ones are all on a 2 or 4 hour update.

Regards, Dave.

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 05 Feb 2007 22:22:05 +0100

> sections, where the preferred ones are all on a 2 or 4 hour update.

I think we've discussed this before at some point, and yeah, i think
that's a good idea. At least if we can get a couple of the "big boys" in
on that update schedule - when we should have enough bw to deal with
almost everything, and keep the "smaller local mirrors" for those that
have really bad international bandwidth.

If we're going to be changing the deal around that, I think we should at
the same time require that the "preferred mirrors" also support http
downloads. We're seeing a regular trickle of people who can't download
because their firewall won't let ftp through. And frankly, most other
projects provide *only* http downloads these days ;-) Ftp doesn't really
buy you anything when you do single file downloads, and we just link to
that anyway.

(We'd of course keep the ftp as well, given that things like freebsd
ports uses them, if I'm not mistaken)

//Magnus

---

From: Larry Rosenman <[email-masked]>
Date: Mon, 5 Feb 2007 15:35:52 -0600 (CST)

> ports uses them, if I'm not mistaken)
FreeBSD ports can use either......
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: [email-masked]
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

---

From: Tom Lane <[email-masked]>
Date: Mon, 05 Feb 2007 16:38:37 -0500

> order that organizations be able to schedule upgrades.

We already have a solution to #2, which is to say the private
pgsql-packagers mail list.

Usually, we also let pgsql-hackers know of a planned release cycle, but
since this one was so soon after the last one, it would've been pretty
obvious that a security issue was driving it.

I see the leakage points in this case as being

* Dave (and Devrim too) making commits that made it obvious something
was afoot.  They could and should have used the Security: filter that
Marc set up to cause those messages to be held for moderator approval.

* Josh using pgsql-www to notify the web team.  I had had the idea that
pgsql-www was supposed to be closed-subscription, so I didn't think
anything of it at the time, but that's evidently wrong.  Fixing that
leak is the point of this discussion.

Note that we did all right in terms of not leaking the details of the
problems; it was just the fact of a pending release that got out.
So for a first try in this direction it wasn't bad.  But let's try to
improve matters for next time...

			regards, tom lane

---

From: Devrim GUNDUZ <[email-masked]>
Date: Mon, 05 Feb 2007 23:46:42 +0200

Hello,

> Marc set up to cause those messages to be held for moderator approval.

How? By adding a 

Security:

line before the commit message? Does it also work for pgfoundry commits?

> * Josh using pgsql-www to notify the web team.  I had had the idea
> that pgsql-www was supposed to be closed-subscription, so I didn't
> think anything of it at the time, but that's evidently wrong.  Fixing
> that leak is the point of this discussion. 

It should be sent to the slaves list I think, as JoshB said in his
e-mail. It is closed subscription.

Regards,
-- 
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

---

From: Devrim GUNDUZ <[email-masked]>
Date: Mon, 05 Feb 2007 23:53:35 +0200

Hello,

On Mon, 2007-02-05 at 20:52 +0100, Magnus Hagander wrote:
> > What I need is a non-public list for this, so that I can ask for web
> > site changes 3-4 days ahead without it becoming a news item.
> 
> Will that really help? In this case, the files were uploaded to the
> ftp site long before you made your post to the -www list... Does it
> really make a difference? 

Here is what I have been thinking about this for a while:

* As now, an announce to -packagers about the new release.

* Upload the new tarballs to a private area (instead of public FTP site)
so that only packagers and other related people can download them to
build the packages, etc.

* Win32 binaries, source tarballs and RPMs will be uploaded to another
directory (not to FTP site in developer.postgresql.org) before the
release.

* After we are done with all of them, (that takes 2 days only), we'll
move this directory to FTP site and wait for propagation.

Does it look good?

---

From: Tom Lane <[email-masked]>
Date: Mon, 05 Feb 2007 16:54:29 -0500

> How?

If there's a line beginning 'Security: ' (note the space, and I think
it's case sensitive) in a pgsql-committers message then it'll get held
for moderator approval.  You'll see some examples as soon as Marc gets
around to releasing my commits from last week.  I thought Marc was going
to notify all the committers about the existence of this mechanism, but
I guess it didn't happen.

> Does it also work for pgfoundry commits?

AFAIK any traffic to pgsql-committers will be handled this way.  If
you've got other outlets for your commit messages then you need to take
it up with them.

> e-mail. It is closed subscription.

I could go with using either slaves or -packagers, though I'd lean to
the former as helping to avoid useless cross-chatter.  I think the
packagers have different concerns as a rule than the webfolk.

			regards, tom lane

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Feb 2007 16:56:33 -0500

> packagers have different concerns as a rule than the webfolk.

OTOH, reducing the number of addresses to include in these
co-ordinations (since packagers presumably need to be alerted too)
mightn't be a bad idea.

A

-- 
Andrew Sullivan  | [email-masked]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
		--Alexander Hamilton

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 21:58:25 +0000

> Marc set up to cause those messages to be held for moderator approval.

The pgInstaller CVS for sure - but that wouldn't have worked for the SVN
repo the docs are in. The messages from there go to pgadmin-hackers, so
I'm not quite so keen to keyword filter there unless the regexp is a
little more precise.

Marc; a commit message there might look like (without the lines):

=================================================================
Author: dpage

Date: 2007-02-05 20:28:43 +0000 (Mon, 05 Feb 2007)

New Revision: 5906

Revision summary:
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5906&view=rev

Log:
Add a guru hint to warn the user of the consequences of storing
passwords, per Tony Caduto.
=================================================================

Can you hold messages to pgdmin-hackers with say:
"view=rev\n\nLog:\nSecurity: " ?

> leak is the point of this discussion.

No, we got lots of flack over it being closed so eventually gave up and
made it 'by approval' and then completely open.

-packagers will work though - can we get David Fetter subscribed, and my
own address approved if it still hasn't been. On a related I'm also not
sure if Hiroshi Saito ([email-masked]) is subscribed (he
packages win32-ja) - if not, can we sort that at the same time please?

Regards, Dave.

---

From: Devrim GUNDUZ <[email-masked]>
Date: Mon, 05 Feb 2007 23:58:41 +0200

Hi,

On Mon, 2007-02-05 at 16:54 -0500, Tom Lane wrote:
> for moderator approval.

Thanks for the info.

> you've got other outlets for your commit messages then you need to
> take it up with them.

Ok. I can setup mailman so that when it sees such a line, it will hold
that message for moderation.

Regards,

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 22:02:09 +0000

> packagers have different concerns as a rule than the webfolk.

The slaves list is used entirely for cron output and moderation
messages. It's not a list to try to discuss things on as I, and I'm sure
some of the other members have unusual recipes on stuff going there.

Regards, Dave

---

From: Tom Lane <[email-masked]>
Date: Mon, 05 Feb 2007 17:04:46 -0500

> so that only packagers and other related people can download them to

We're not going to be able to make things really water-tight unless we
are willing to close off CVS somehow; which is not an idea I favor.
So I'm not particularly concerned about hiding tarballs --- especially
since that's not something we'd do in a normal, non-security release
cycle.  As I said before, keeping it off the mailing lists is probably
sufficient, and in any case has to be our first goal before we start
worrying about any more-invasive procedural changes.

			regards, tom lane

---

From: Dave Page <[email-masked]>
Date: Mon, 05 Feb 2007 22:05:22 +0000

Josh Berkus wrote:

> The question is which is more appropriate for the web folks?  I'm thinking 
> -packagers, because the web folks need to know when the actual packages 
> will be ready and any delays.

And a good percentage of us are already on it.

/D

---

From: Josh Berkus <[email-masked]>
Date: Mon, 5 Feb 2007 14:06:28 -0800

Andrew,

> co-ordinations (since packagers presumably need to be alerted too)

yeah, I'm thinking two (and only two) lists:
pgsql-packagers: for actual release building
press-contacts: for release FAQ.

I know the second adds more people, but I'm realizing that it's important 
that our Regional Contacts know about the releases before they go out.  
Otherwise we risk a press person actually calling, say, Nick about a 
release and having him say "what security issue?"  Also, the RCs are a 
good way to dissemenate important update information to our 
non-English-language communities.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---

From: Tom Lane <[email-masked]>
Date: Mon, 05 Feb 2007 17:12:45 -0500

> some of the other members have unusual recipes on stuff going there.

Oh, OK.  Maybe we do need a whole 'nother list?  But probably -packagers
will do for the moment.

			regards, tom lane

---

From: Oleg Bartunov <[email-masked]>
Date: Tue, 6 Feb 2007 01:14:44 +0300 (MSK)

> worrying about any more-invasive procedural changes.

I hope we will not go beyond this.

btw, how other OSS projects manage releases ?

Inkscape, for example, just didn't announce it's 0.45 release, but 
all tarballs were available from sourceforge site.

 	Regards,
 		Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [email-masked], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 05 Feb 2007 21:37:08 -0400

> "view=rev\n\nLog:\nSecurity: " ?

If you give me a proper regex for there, I can put it in and you can test it ...

Or is it just:

/view=rev\n\nLog:\nSecurity: /

that you want me to add?

- ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . [email-masked]                              MSN . [email-masked]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 08:32:53 +0000

Marc G. Fournier wrote:
> 
> 
> --On Monday, February 05, 2007 21:58:25 +0000 Dave Page <[email-masked]> 
> wrote:
> 
> 

If that'll hold the messages then sure, please do.

Oh, and please subscribe to the list - I'm getting fed up with approving
all your messages.

/D

---

From: Guillaume Lelarge <[email-masked]>
Date: Tue, 06 Feb 2007 10:49:21 +0100

> move this directory to FTP site and wait for propagation.

It looks good to me if these are the steps to follow for security 
release only. I update the french manual for each release (even minor 
ones). Last week, I had some hints that a minor release was going to 
happen and I kept an eye on the ftp source server (as I do every time a 
minor release is on its way). Saturday, 7.4, 8.0 and 8.1's french 
manuals were updated on the SVN repository (see 
http://svn.postgresqlfr.org/timeline?from=02%2F03%2F07&daysback=0&changeset=on&update=Update).
And Sunday, 8.2's french manual was updated (see 
http://svn.postgresqlfr.org/timeline?from=02%2F04%2F07&daysback=0&changeset=on&update=Update).
Sunday evening or Monday morning (I don't quite remember), I uploaded them.

I completely understand why you want a private area for security 
updates. French manual will be available a few days later. But I don't 
think other releases should take the same steps. I translate beta and RC 
because it gives me much more time to do it. Actually, I have a full 
translation available the same day the release is out. And if it was 
possible that I have access to this private area, it would be great :)

-- 
Guillaume.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 09:52:25 -0400

'k, set ... you will want to test it though ...

current 'taboo' strings are:

/^Security: /

For those unaware, these will cause the commit message to be queued for 
moderator approval, so, for instance, when Tom does 'security commits' before a 
security release, the messages don't go out before the announcement itself ...

- --On Tuesday, February 06, 2007 08:32:53 +0000 Dave Page
<[email-masked]> 
wrote:

> Marc G. Fournier wrote:
>>
>>
>> --On Monday, February 05, 2007 21:58:25 +0000 Dave Page
>> <[email-masked]>  wrote:
>>
>>

- ----

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 14:02:23 +0000

> current 'taboo' strings are:

Please lose that one - the pgAdmin list is used for general discussion
and that string doesn't seem unreasonable to be included in an email.

> /view=rev\n\nLog:\nSecurity: /

That should do the job.

Thanks, Dave

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 14:08:49 +0000

>> /view=rev\n\nLog:\nSecurity: /

Or not - this went straight through:

Author: dpage

Date: 2007-02-06 13:40:30 +0000 (Tue, 06 Feb 2007)

New Revision: 5907

Revision summary:
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5907&view=rev

Log:
Security: Test commit

Modified:
   trunk/pgadmin3/CHANGELOG

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 10:21:28 -0400

- --On Tuesday, February 06, 2007 14:02:23 +0000 Dave Page
<[email-masked]> 

> and that string doesn't seem unreasonable to be included in an email.

Discuss it with Tom ... he's the one that requested that one ...

Wait, you missed something in the thread here (or, I didn't emphasize it 
enough) .. this is *only* on the committers list, none of the other ones ... 
its only meant to trap commit messages pertaining to a security release, not 
security related discussions ... is that why you did that 'long string' below? 
Cause you thought it was on all lists? :)

Sorry, I should have been more clear ...

- ----

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 10:23:02 -0400

- --On Tuesday, February 06, 2007 14:08:49 +0000 Dave Page
<[email-masked]> 

> Or not - this went straight through:

Of course it would ... the message comes through as something like:

view=rev</a>\n\nLog:\nSecurity:

the HTTP is a clickable URL ...

But, not sure why /^Security: / isn't picking it up like it should ...

- ----

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 14:24:00 +0000

Marc G. Fournier wrote:
> 
> 
> --On Tuesday, February 06, 2007 14:02:23 +0000 Dave Page
> <[email-masked]> 
> wrote:
> 
>> Marc G. Fournier wrote:

No *you* missed something :-) The pgAdmin SVN commit messages go to
[email-masked] - my request was that you add the long
string to /that/ list.

Regards, Dave.

---

From: Tom Lane <[email-masked]>
Date: Tue, 06 Feb 2007 09:25:41 -0500

> Or not - this went straight through:

I was wondering whether the pattern matcher would match across lines.

You might have to settle for the same '^Security: ' pattern.  I'm not
convinced it'd catch as much traffic as all that, and even if it does,
it just goes to the moderation queue ... not the end of the world ...

			regards, tom lane

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 14:27:37 +0000

Marc G. Fournier wrote:

> the HTTP is a clickable URL ...

Only 'cos your MUA renders it as a clickable link - the code that
generates the email reads:

my @body;
push(@body, "Author: $author\n\n");
push(@body, "Date: $date\n\n");
push(@body, "New Revision: $rev\n\n");
push(@body, "Revision summary:
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=$rev&view=rev\n\n");
push(@body, "Log:\n");
push(@body, @log);
push(@body, "\n");
push(@body, "\n");

Regards, Dave

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 11:21:56 -0400

- --On Tuesday, February 06, 2007 14:24:00 +0000 Dave Page
<[email-masked]> 
wrote:

>> security related discussions ... is that why you did that 'long string'
>> below?  Cause you thought it was on all lists? :)
>>

Yup, I missed that, sorry ... okay, changed ... try that now, s hould work a 
wee bit better :)

- ----

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 15:40:43 +0000

> Yup, I missed that, sorry ... okay, changed ... try that now, s hould work a 

Nope, went straight through. Perhaps it's the fact it's multiline as Tom
suggested. Wanna try the short string?

Regards, Dave

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 12:08:56 -0400

Done, try that ... but, you can edit taboo_body yourself for the list, no? :)

- --On Tuesday, February 06, 2007 15:40:43 +0000 Dave Page
<[email-masked]> 

- ----

---

From: Dave Page <[email-masked]>
Date: Tue, 06 Feb 2007 16:16:11 +0000

> Done, try that ... but, you can edit taboo_body yourself for the list, no? :)

I could, but you know it better than I do :-p

/D

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 06 Feb 2007 13:38:20 -0400

- --On Tuesday, February 06, 2007 16:16:11 +0000 Dave Page
<[email-masked]> 

> I could, but you know it better than I do :-p

Ya, I used it about a week so far ... much more experience with it >:)

- ----