Thread: How to coordinate web team for security releases?
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
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. > > 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? -packagers? /D
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. > > 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. 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
Stefan, > 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. 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
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. > > 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? //Magnus
Josh Berkus wrote: > Stefan, > >> 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. > > 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. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > 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 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 greg@turnstep.com PGP Key: 0x14964AC8 200702051500 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFx4z6vJuQZxSWSsgRA87yAKCjB1nUqegLjvxGoRChDWPZ9RwIjwCgnYrP 9WXDio7T+nT+/Q7ODXTMKMQ= =mKwW -----END PGP SIGNATURE-----
Greg Sabino Mullane 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. > > 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. the fact that new releases are coming up also got announced on IRC over three days ago and we have >300 people there ... Stefan
Stefan Kaltenbrunner wrote: > Greg Sabino Mullane 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. >> 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. > > the fact that new releases are coming up also got announced on IRC over > three days ago and we have >300 people there ... Where did that come from? Regards, Dave.
Greg Sabino Mullane 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. > > 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. 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
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> 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
Dave Page wrote: > Greg Sabino Mullane 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. >> 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. > > 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. 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
Dave Page wrote: > Stefan Kaltenbrunner wrote: >> Greg Sabino Mullane 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. >>> 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. >> the fact that new releases are coming up also got announced on IRC over >> three days ago and we have >300 people there ... > > 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
Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: >> 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. 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
Stefan Kaltenbrunner wrote: > Dave Page wrote: >> Greg Sabino Mullane 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. >>> 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. >> 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. > > 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. 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.
Stefan Kaltenbrunner wrote: > Dave Page wrote: >> Stefan Kaltenbrunner wrote: >>> Greg Sabino Mullane 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. >>>> 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. >>> the fact that new releases are coming up also got announced on IRC over >>> three days ago and we have >300 people there ... >> 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 ;-) 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
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 <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Dave Page wrote: >> 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. 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 greg@turnstep.com PGP Key: 0x14964AC8 200702051602 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFFx5ufvJuQZxSWSsgRA4SbAKCDm3AGz4+HNHxLGX/mViiLJ93XywCgxiSA U9pGW39bEZpfOZwVr4EQe0M= =G7T+ -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > > Dave Page wrote: >>> 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. > > 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. 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.
Dave Page wrote: > Greg Sabino Mullane wrote: >> Dave Page wrote: >>>> 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. >> 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. > > 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. 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
On Mon, 5 Feb 2007, Magnus Hagander wrote: > (We'd of course keep the ftp as well, given that things like freebsd > 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: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
David Fetter <david@fetter.org> writes:
> 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.
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
Hello, On Mon, 2007-02-05 at 16:38 -0500, Tom Lane wrote: > * 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. 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/
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? -- 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/
Devrim GUNDUZ <devrim@CommandPrompt.com> writes:
> On Mon, 2007-02-05 at 16:38 -0500, Tom Lane wrote:
>> * 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.
> 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.
> It should be sent to the slaves list I think, as JoshB said in his
> 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
On Mon, Feb 05, 2007 at 04:54:29PM -0500, Tom Lane wrote: > 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. 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 | ajs@crankycanuck.ca 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
Hi, On Mon, 2007-02-05 at 16:54 -0500, Tom Lane wrote: > > 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. Thanks for the info. > > 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. Ok. I can setup mailman so that when it sees such a line, it will hold that message for moderation. 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/
Tom Lane wrote: > > 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. 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: " ? > * 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. 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 (z-saito@guitar.ocn.ne.jp) is subscribed (he packages win32-ja) - if not, can we sort that at the same time please? Regards, Dave.
Tom Lane wrote: > 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. 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
Andrew, > 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. 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. 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. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Devrim GUNDUZ <devrim@CommandPrompt.com> writes:
> * 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.
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
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
Dave Page <dpage@postgresql.org> writes:
> Tom Lane wrote:
>> 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.
> 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.
Oh, OK. Maybe we do need a whole 'nother list? But probably -packagers
will do for the moment.
regards, tom lane
On Mon, 5 Feb 2007, Tom Lane wrote:
> Devrim GUNDUZ <devrim@CommandPrompt.com> writes:
>> * 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.
>
> 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.
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: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Monday, February 05, 2007 21:58:25 +0000 Dave Page <dpage@postgresql.org> wrote: > Can you hold messages to pgdmin-hackers with say: > "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 . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFx9vF4QvfyHIvDvMRAkZcAJ9p4TSSIhJ4Xc/ByWqRzelPmBVr5wCglSdR mK7UHOmKJ2m6V2mEpP7XyfE= =QIeX -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > > > --On Monday, February 05, 2007 21:58:25 +0000 Dave Page <dpage@postgresql.org> > wrote: > > >> Can you hold messages to pgdmin-hackers with say: >> "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? 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
Devrim GUNDUZ a ecrit le 05/02/2007 22:53: > 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? 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 'k, set ... you will want to test it though ... current 'taboo' strings are: /^Security: / /view=rev\n\nLog:\nSecurity: / 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 <dpage@postgresql.org> wrote: > Marc G. Fournier wrote: >> >> >> --On Monday, February 05, 2007 21:58:25 +0000 Dave Page >> <dpage@postgresql.org> wrote: >> >> >>> Can you hold messages to pgdmin-hackers with say: >>> "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? > > 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 - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyIga4QvfyHIvDvMRAtkuAKC/1DN7Z9dGPEVbY46mxZ0RzKZO/ACeLSb7 OvwvQlfACQgoaVoBQ0cCsQU= =HNqN -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > > 'k, set ... you will want to test it though ... > > current 'taboo' strings are: > > /^Security: / 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
Dave Page wrote: > Marc G. Fournier wrote: >> 'k, set ... you will want to test it though ... >> >> current 'taboo' strings are: >> >> /^Security: / > > 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. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, February 06, 2007 14:02:23 +0000 Dave Page <dpage@postgresql.org> wrote: > Marc G. Fournier wrote: >> >> 'k, set ... you will want to test it though ... >> >> current 'taboo' strings are: >> >> /^Security: / > > 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. 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 ... - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyI7o4QvfyHIvDvMRAt7ZAKCBUJbaJhBSJ6wRnVRF0/OS1F5XSACfeVU8 q8Yek8X09zrBsaAnKZVOutU= =YQxf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, February 06, 2007 14:08:49 +0000 Dave Page <dpage@postgresql.org> wrote: > Dave Page wrote: >> Marc G. Fournier wrote: >>> 'k, set ... you will want to test it though ... >>> >>> current 'taboo' strings are: >>> >>> /^Security: / >> >> 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. > > 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 ... > > 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 - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyI9G4QvfyHIvDvMRAhrmAKC+SO1/e408iKGVcfPoTvMJcEm9EwCfdvHY M/sG3rkC7CDPv97ecc97e4U= =wsWC -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > > > --On Tuesday, February 06, 2007 14:02:23 +0000 Dave Page > <dpage@postgresql.org> > wrote: > >> Marc G. Fournier wrote: >>> 'k, set ... you will want to test it though ... >>> >>> current 'taboo' strings are: >>> >>> /^Security: / >> 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. > > 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 ... No *you* missed something :-) The pgAdmin SVN commit messages go to pgadmin-hackers@postgresql.org - my request was that you add the long string to /that/ list. Regards, Dave.
Dave Page <dpage@postgresql.org> writes:
> Dave Page wrote:
>> Marc G. Fournier wrote:
>>> /view=rev\n\nLog:\nSecurity: /
>>
>> That should do the job.
> 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
Marc G. Fournier wrote: > >>>> /view=rev\n\nLog:\nSecurity: / >>>> >>> That should do the job. >> 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 ... 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, February 06, 2007 14:24:00 +0000 Dave Page <dpage@postgresql.org> wrote: > Marc G. Fournier wrote: >> >> >> --On Tuesday, February 06, 2007 14:02:23 +0000 Dave Page >> <dpage@postgresql.org> >> wrote: >> >>> Marc G. Fournier wrote: >>>> 'k, set ... you will want to test it though ... >>>> >>>> current 'taboo' strings are: >>>> >>>> /^Security: / >>> 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. >> >> 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 ... > > No *you* missed something :-) The pgAdmin SVN commit messages go to > pgadmin-hackers@postgresql.org - my request was that you add the long > string to /that/ list. Yup, I missed that, sorry ... okay, changed ... try that now, s hould work a wee bit better :) > > Regards, Dave. - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyJ0U4QvfyHIvDvMRAhQ/AJ4tL/En/EPKE3mpYXXgE5VHeHAx1gCfcqv8 VYj7OLobteyqMpa6tj8XQ/k= =Do7Y -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > >> No *you* missed something :-) The pgAdmin SVN commit messages go to >> pgadmin-hackers@postgresql.org - my request was that you add the long >> string to /that/ list. > > Yup, I missed that, sorry ... okay, changed ... try that now, s hould work a > wee bit better :) Nope, went straight through. Perhaps it's the fact it's multiline as Tom suggested. Wanna try the short string? Regards, Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 <dpage@postgresql.org> wrote: > Marc G. Fournier wrote: >> >>> No *you* missed something :-) The pgAdmin SVN commit messages go to >>> pgadmin-hackers@postgresql.org - my request was that you add the long >>> string to /that/ list. >> >> Yup, I missed that, sorry ... okay, changed ... try that now, s hould work a >> wee bit better :) > > Nope, went straight through. Perhaps it's the fact it's multiline as Tom > suggested. Wanna try the short string? > > Regards, Dave - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyKgY4QvfyHIvDvMRAieFAKCt60HbxghCJO9ebO74/hOMax7N+wCfVrUI VNxym55nOQEQz1NdZzE3Pxw= =unP2 -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > > 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, February 06, 2007 16:16:11 +0000 Dave Page <dpage@postgresql.org> wrote: > Marc G. Fournier wrote: >> >> 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 Ya, I used it about a week so far ... much more experience with it >:) - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFyL0M4QvfyHIvDvMRAgRcAKDNynrzejdNP6LPf/Kry0Hn2WMuUgCg1Hhq cnIWUe3jrOWHgjTo/uHXviA= =QgOW -----END PGP SIGNATURE-----