Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-04 Thread Dave Page
On Tue, Apr 3, 2012 at 11:12 PM, Greg Stark st...@mit.edu wrote:
 On Wed, Apr 4, 2012 at 1:19 AM, Dave Page dp...@pgadmin.org wrote:
 then, we're talking about making parts of the filesystem
 world-writeable so it doesn't even matter if the user is running as an
 admin for a trojan or some other nasty to attack the system.

 The argument is that a trojan or other nasty doesn't *need* to be
 admin to attack the system since it can just attack the user's account
 since that's where all the interesting data is anyways.

Isn't that what I said?

 But again, this is all beside the point. It's a judgement for Apple
 and Microsoft and individual administrators to make. We can't really
 start reconfiguring people's systems to use a different security model
 than they expect just because they've installed a database software --
 even if we think our security model makes more sense than the one
 their used to.

Exactly - which is why I was objecting to recommending a distribution
of PostgreSQL that came in a packaging system that we were told
changed /usr/local to be world writeable to avoid the use/annoyance of
the standard security measures on the platform.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-04 Thread Jay Levitt

Dave Page wrote:

Exactly - which is why I was objecting to recommending a distribution
of PostgreSQL that came in a packaging system that we were told
changed /usr/local to be world writeable to avoid the use/annoyance of
the standard security measures on the platform.


We... that's not exactly what happened:

I originally wrote:

POSSIBLE OBJECTIONS/PREREQUISITES

1. homebrew installs everything under /usr/local and makes that user-writeable.


So. :)

Jay

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Robert Haas
On Mon, Apr 2, 2012 at 5:23 AM, Dave Page dp...@pgadmin.org wrote:
 If homebrew intentionally creates a hole like that, then for as long
 as I'm one of the PostgreSQL webmasters it will *never* be listed on
 our download pages.

I think that's a bit harsh.  It's not as if the PostgreSQL package
creates the security hole; it's something that the packaging system
does itself, independent of whether or not you try to install
PostgreSQL with it.  So it seems to me that refusing to list it is
making life difficult for people who have already made the decision to
use brew, without any compensating advantage.

That doesn't mean that I approve of brew's approach to this problem,
though.  Even if you think that it's unimportant to keep the desktop
user from usurping root privileges, having some things installed in
/usr/local as root and others as the desktop user (multiple different
desktop users?) seems like a recipe for chaos.  I've made those types
of mistakes, but I got them out of my system in the nineties.  I can't
help but wonder if this isn't just the natural way a packaging system
evolves - you start with something very simple (like what brew is now)
and then gradually you realize that there are some annoyances, so you
file those down by adding some more complexity, and eventually you end
up with a system that's just as complex as the ones that you
originally thought were too complex.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Christopher Browne
On Tue, Apr 3, 2012 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
 On Mon, Apr 2, 2012 at 5:23 AM, Dave Page dp...@pgadmin.org wrote:
 If homebrew intentionally creates a hole like that, then for as long
 as I'm one of the PostgreSQL webmasters it will *never* be listed on
 our download pages.

 I think that's a bit harsh.  It's not as if the PostgreSQL package
 creates the security hole; it's something that the packaging system
 does itself, independent of whether or not you try to install
 PostgreSQL with it.  So it seems to me that refusing to list it is
 making life difficult for people who have already made the decision to
 use brew, without any compensating advantage.

+1.

If someone has decided that they want to use homebrew on their Mac,
then they have accepted the whole class of issues of this sort for a
bunch of *other* software.  I don't think Postgres is that much more
special.

And note that if they're using Ruby to access the Postgres instance,
and there are (perceived) security holes with the Ruby toolchain's
installation, it doesn't much matter if the Postgres installation is
'more secure', it's being accessed via a layer that is already Plenty
Holey.

 That doesn't mean that I approve of brew's approach to this problem,
 though.  Even if you think that it's unimportant to keep the desktop
 user from usurping root privileges, having some things installed in
 /usr/local as root and others as the desktop user (multiple different
 desktop users?) seems like a recipe for chaos.  I've made those types
 of mistakes, but I got them out of my system in the nineties.  I can't
 help but wonder if this isn't just the natural way a packaging system
 evolves - you start with something very simple (like what brew is now)
 and then gradually you realize that there are some annoyances, so you
 file those down by adding some more complexity, and eventually you end
 up with a system that's just as complex as the ones that you
 originally thought were too complex.

I suspect that this is Yet Another Case of people using a mostly
desktop/single user system building something that's perfectly
convenient for that case.

It's pretty typical for MacOS applications to require enter your
password; I need to su to root to install this! in plenty of places
where the UI does not actually tell you what is being done as root.
After enough iterations of enter your password so my process can do
undisclosed admin stuff, I'm not sure that you've got anything more
secure than you'd have if /usr/local was writable by the desktop user.

I'm not sure you can successfully wrench people in that environment
into a proper multi-user setup.  It took Microsoft *years* to get it
to a semblance of working, and people still have a flurry of oh,
click this to give administrative permissions activities that are
*begging* to be an exploit.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, How would the Lone Ranger handle this?

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Robert Haas
On Tue, Apr 3, 2012 at 11:56 AM, Christopher Browne cbbro...@gmail.com wrote:
 It's pretty typical for MacOS applications to require enter your
 password; I need to su to root to install this! in plenty of places
 where the UI does not actually tell you what is being done as root.
 After enough iterations of enter your password so my process can do
 undisclosed admin stuff, I'm not sure that you've got anything more
 secure than you'd have if /usr/local was writable by the desktop user.

I think that's somewhat true.  Part of the reason why Windows is so
crufty is because of lousy privilege separation -- MacOS and even
Ubuntu are now busy copying that design, but realistically people do
need to install software, so short of educating users better or
creating a walled garden it's not clear how much better you can do.
However, Windows has another problem, too: there are so many ways that
you can hook into the system and get control that it's basically
impossible to remove spyware and crapware without its cooperation.  I
mean, you can get rid of some of it, but finding all the little fiddly
pieces that have to be ripped out is basically not doable.  You just
reinstall the machine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Jay Levitt

Robert Haas wrote:

On Mon, Apr 2, 2012 at 5:23 AM, Dave Pagedp...@pgadmin.org  wrote:

If homebrew intentionally creates a hole like that, then for as long
as I'm one of the PostgreSQL webmasters it will *never* be listed on
our download pages.


I think that's a bit harsh.  It's not as if the PostgreSQL package
creates the security hole; it's something that the packaging system
does itself, independent of whether or not you try to install
PostgreSQL with it.  So it seems to me that refusing to list it is
making life difficult for people who have already made the decision to
use brew, without any compensating advantage.


In fairness to Dave, I think he was still reacting to my initial proposal 
that homebrew be the *recommended* install. In that case, people might 
install homebrew specifically because postgresql.org recommended it.


If the consensus is that /usr/local/* user-writable is insecure, I certainly 
wouldn't object to a little note that said If you're using homebrew, do 
'brew install postgresql', but we don't recommend homebrew for security 
reasons; a little pressure might provide the impetus for homebrew to allow a 
better way.


That said, about 8 months ago Homebrew's defaults changed. It no longer 
requires /usr/local to be directly writable; it will sudo if necessary 
during the initial installation to create its subdirectories.  Those 
directories are mostly user-writable, though:


% ls -l /usr/local
total 8
drwxr-xr-x   37 jay   admin   1.2K Mar 31 16:39 Cellar/
drwxr-xr-x7 jay   admin   238B Feb 29 10:51 Library/
-rw-r--r--1 jay   admin   789B Feb 29 10:57 README.md
drwxr-xr-x  499 jay   admin17K Apr  1 15:29 bin/
drwxr-xr-x9 jay   admin   306B Mar  7 16:23 etc/
drwxr-xr-x   69 jay   admin   2.3K Mar 16 16:48 include/
drwxr-xr-x  178 jay   admin   5.9K Mar 16 16:48 lib/
drwxr-xr-x3 root  admin   102B Mar 14 13:20 man/
drwxr-xr-x   20 jay   admin   680B Mar 31 16:40 share/
drwx--3 jay   admin   102B Feb 29 11:43 var/

At no point was anything in /usr/local *world*-writable, FWIW.


That doesn't mean that I approve of brew's approach to this problem,
though.  Even if you think that it's unimportant to keep the desktop
user from usurping root privileges, having some things installed in
/usr/local as root and others as the desktop user (multiple different
desktop users?) seems like a recipe for chaos.


I think the brew designers expect most folks to either not have anything in 
/usr/local from outside homebrew, to not install anything there as root, to 
understand the security consequences, or to use homebrew as root even though 
it's unsupported, and deal with their own bugs.



I can't help but wonder if this isn't just the natural way a packaging system
evolves - you start with something very simple (like what brew is now)
and then gradually you realize that there are some annoyances, so you
file those down by adding some more complexity, and eventually you end
up with a system that's just as complex as the ones that you
originally thought were too complex.


Packaging systems? I thought that's called all software ever!

brew's lucky in that the Mac by definition is not a heterogeneous 
environment, and so Mac users don't expect it to be. (Last I checked, it's 
either difficult, impossible or unsupported to boot from a volume other than 
your filesystem root.) By being mostly source-fetch-only, sitting on top of 
git, and not packaging either system-provided features (many of which would 
require root) or repackaging gems/eggs/nodes, they've avoided a lot of the 
hard problems.  But sure, it's only two years old and it will get more 
complex over time.


Jay

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Greg Smith

On 04/01/2012 04:19 PM, Jay Levitt wrote:

POSSIBLE OBJECTIONS/PREREQUISITES


10. There is no homebrew support for multiple versions, and no current
plans to add it (though it's on the wishlist). This means homebrew is
only useful if I want to install a PostgreSQL thingie is the common
Mac use case. If people often need to use specific older versions, to
mirror their server configs, it's a problem. It *might* be possible to
hack this into our formula, but I'm not sure it's either doable or
acceptable.


To be a credible alternative to EDB's packages, Homebrew would need to 
match having installers for all of the supported versions at 
http://www.postgresql.org/support/versioning/ , which right now means 
back to 8.3.  While I'm often annoyed at checkbox compliance 
exercises, that's unlikely to be a negotiable one.  Your optimism that 
it's just switch the version number to build another version will make 
everyone who currently builds packages roll their eyes too.  Wandering 
this road will end up with a formula for each version, because they will 
be different sometimes, and there's going to be packaging bug 
backporting coming out of that.  Just be glad you don't have to worry 
about anything before 8.3 now.


I just started playing in this area recently.  I have a shell utility 
whose purpose in life is to make it easier to install multiple 
PostgreSQL builds from source:  https://github.com/gregs1104/peg


I confirmed recently that it works fine on OS X using brew.  Was even 
toying with renaming the project ('peg' is already squatted on in 
Homebrew) and packaging it up.  There are enough people who hack on 
PostgreSQL on Macs using Homebrew that I think I'd find a few users. 
I'm not sure if someone would be willing to get stuck with maintaining 
that if it got merged into an official package though.


That's wavering off topic though, so back to more officialish 
installers.  You've asked one question and discussion has implied a few 
others.  Let me try to iterate over them with my opinions:


-Will PostgreSQL switch to Homebrew as the recommended Mac install soon?

No.  You've already hit a few nerves suggesting why, as well as 
suggesting some of the issues in your first e-mail.  There's a larger 
problem challenging Homebrew too.  This sort of Mac packaging has never 
escaped having a flavor of the week feel to it, and as a group the 
people working on PostgreSQL are not fans of switching things regularly 
like that.  Don't take that personally:  this is a project that stayed 
on CVS until late 2010, partly because the alternatives didn't seem 
stable enough.  And when we did switch, it was only after finding 
problems that had to be fixed in the tools used.  You just got a first 
round of such griping here.


I do believe Homebrew is the lead dog in the build from source race 
right now, but the history here says the right bet is on none of 
them--that the simplest feasible binary install is the right choice for 
the recommended package.  That's what EDB is trying to do, and some of 
the important associated details like make it easy to use pgAdmin are 
not really negotiable.


-Should there be better documentation on using Homebrew to satisfy 
people who don't like the assumptions made by the EDB Mac packages?


Yes.  We've had a link from 
http://wiki.postgresql.org/wiki/Detailed_installation_guides to one of 
the early guides for a while. I've been wanting to see a whole page 
hosted directly on the wiki covering this subject; I just created 
https://wiki.postgresql.org/wiki/Homebrew for that purpose.  I'll link 
it into the main install guide section once it's more interesting.


-Should Homebrew add [automatic initdb|service script 
integration|compatibility with using a postgres user]?


Yes to all of these.  If you're going to argue from a perspective like 
make it easy for Ruby developers, it really should be easy in the end, 
to make for a compelling change from the status quo.


I think you've set your sights beyond their needs.  If the Homebrew 
recipe becomes better, and some rough edges are removed, those are the 
important parts.  I don't think Homebrew shouldn't aim to satisfy 
everyone; it should do a really good job satisfying its intended 
audience.  It is not necessary to make it the recommended installer 
for that to happen.  I'd suggest dumping that whole idea as too 
ambitious and focus just how to make things better for the intended 
targets.  Homebrew is never going to be an enterprise satisfying 
installer, since most businesses will not tolerate building from source 
themselves unless pressed extremely hard.


-What needs to change in Homebrew before it would be considered more 
seriously by the PostgreSQL community?


You framed your discussion points as a technical argument.  Good 
execution there is a necessary component, but not the only one.  I 
mentioned pgAdmin (and Formulas are simple if building is simple will 
surely be of no help there) and multiple 

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Josh Berkus
On 4/3/12 5:22 AM, Robert Haas wrote:
 On Mon, Apr 2, 2012 at 5:23 AM, Dave Page dp...@pgadmin.org wrote:
 If homebrew intentionally creates a hole like that, then for as long
 as I'm one of the PostgreSQL webmasters it will *never* be listed on
 our download pages.

I don't agree. Listed with a warning, sure.  But it should be listed.

Consider that OSX is pretty much purely a desktop platform (if you're
using OSX on the server, security is the least of your problems).  As
such, it doesn't have the same security concerns which server platforms
have.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Dave Page
On Tue, Apr 3, 2012 at 7:48 PM, Josh Berkus j...@agliodbs.com wrote:
 On 4/3/12 5:22 AM, Robert Haas wrote:
 On Mon, Apr 2, 2012 at 5:23 AM, Dave Page dp...@pgadmin.org wrote:
 If homebrew intentionally creates a hole like that, then for as long
 as I'm one of the PostgreSQL webmasters it will *never* be listed on
 our download pages.

 I don't agree. Listed with a warning, sure.  But it should be listed.

That's fine - you don't have to agree with me :-).

 Consider that OSX is pretty much purely a desktop platform (if you're
 using OSX on the server, security is the least of your problems).  As
 such, it doesn't have the same security concerns which server platforms
 have.

Can I interest you in a move to Windows XP, pre security shake-up?
It'll be pretty darn snappy on modern hardware!

Having the ability for users to write files to system locations was
one of the major reasons why Windows got into such problems. The only
difference with this situation is that instead of users running with
admin privileges as often (but not always) happened on Windows back
then, we're talking about making parts of the filesystem
world-writeable so it doesn't even matter if the user is running as an
admin for a trojan or some other nasty to attack the system.

That said, Jay has told me he was wrong about the world-writeable
thing anyway. Apparently Homebrew fixed that last year.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Dave Page
On Tue, Apr 3, 2012 at 6:58 PM, Greg Smith g...@2ndquadrant.com wrote:

 --Documentation

 Homebrew will have to become more complicated if it's going to try and
 wander down this path.  With complexity and backward compatibility come
 increased needs for documentation.

One more to add:

--QA

When PostgreSQL updates are prepared, not only do they have to be
built but they also get tested in installation and upgrade mode on all
supported versions of OS X, including some of the server versions.
That obviously takes time and hardware, and is done over a brief
Friday - Sunday period to fit in with the release procedure.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-03 Thread Greg Stark
On Wed, Apr 4, 2012 at 1:19 AM, Dave Page dp...@pgadmin.org wrote:
 then, we're talking about making parts of the filesystem
 world-writeable so it doesn't even matter if the user is running as an
 admin for a trojan or some other nasty to attack the system.

The argument is that a trojan or other nasty doesn't *need* to be
admin to attack the system since it can just attack the user's account
since that's where all the interesting data is anyways.

But again, this is all beside the point. It's a judgement for Apple
and Microsoft and individual administrators to make. We can't really
start reconfiguring people's systems to use a different security model
than they expect just because they've installed a database software --
even if we think our security model makes more sense than the one
their used to.



-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-02 Thread Dave Page
On Mon, Apr 2, 2012 at 12:29 AM, Jay Levitt jay.lev...@gmail.com wrote:

 At this point I agree with you, but I'm still going to go into detail,
 because I think there are two markets for Postgres, and the database
 community has been so focused around enterprise for so long that you're
 missing opportunities with web startups. I'd love to help bridge the gap,
 having jumped straight from big-iron PL/I to ooh-Ruby-is-shiny. And web
 startups develop on Mac laptops. They just do. So if it helps you to imagine
 me as a 20something I'm a Mac hipster, working on some hot Facebook/mobile
 app with funding from Spark Capital, do that. Lord knows it helps me.

Just as an FYI, a large percentage of the PostgreSQL developers are
Mac users, including myself. They're also the company standard at
EnterpriseDB - so we're not entirely unfamiliar with software
development on them.

 - We have few Mac experts hanging out in #postgresql.
 Not sure how this is relevant to the proposal.

 The impetus for the idea was that there seems to be a steady stream of
 novice PG users on Mac who come into #postgresql with installation problems,
 which is bad enough as an out-of-box experience - but worse is that there
 are rarely folks around who can help. (Of course, I'm extrapolating; every
 time *I'm* in IRC and see this, there's someone who can help. But you know
 what I mean.)

If you see someone report a bug with the installers, please have them
report it on the EnterpriseDB forums:
http://forums.enterprisedb.com/forums/show/9.page

 I didn't realize that you were actively maintaining the EDB installer (see
 below for the 8.4 doc explanation); obviously, if you can improve that, it's
 the best solution and we should, if anything, recommend it MORE vigorously.
 Still, there's a growing community of developers who expect brew install
 to work, and I do want to fix it for them.  The EDB installer will always be
 a one-off experience; most of the other servers you install will be through
 a package manager, and homebrew's popularity (despite its youth) is
 impressive.

I would disagree with that. Most users I know do not use things like
homebrew (particularly those coming from Windows who have no
familiarity with such package managers at all).

  Both of my n=2 data points had run across PG a while back,
 installed it with the one-click to try it out, forgotten about it, done
 brew install postgresql today, and naturally ran into problems.

As I said, that will happen with any distro. The installers are smart
enough to detect it and avoid trying to reuse the same port. They
won't ever try to touch an existing installation though (except of
their own, which if detected will cause a switch to upgrade mode).


 - The EDB docs are written against 8.4.
 Only if you install 8.4. If you install 8.3 you get the 8.3 docs, 9.0
 the 9.0 docs and so on.

 No, I meant on the web:

 http://www.enterprisedb.com/resources-community/pginst-guide

 That's what made me assume that the installer wasn't maintained (except as
 to repackaging new PG versions, obviously). It's obviously not hard to
 replace 8.3 with 9.1 when you read it, but it still leaves an impression
 akin to This web site works best with IE7 and above. Allow me to now
 replace most of this thread with hey, you might wanna update that page.

That hasn't been updated because the installation steps haven't
changed and I'd rather spend time writing software than updating
screenshots. A couple of points of note:

- The introduction says: This document is based on the 8.4.x
one-click installers but applies equally to later versions.

- The doc also explains where to find the uninstaller.

 - There are eight ways to install Postgres on a Mac

 That isn't any more of a reason to discount the EDB installer than any
 other.

 Nope, just an argument that the recommended installer should handle that
 nicely.

It does. It'll detect that the port is in use and suggest a different
one. I don't know of any other of those installation methods that'll
do that.


 1. Rubyists in general are sick of sudo'ing on their laptops, because It
 Doesn't Matter (as I'll fail to argue later).  Homebrew puts itself into a
 directory that is user-writable so it does not require sudo for basic
 installation.

Nice. You just turned me off ever wanting anything related to Ruby on
my Mac either!

 2. Because shell's $PATH is hard to change programmatically due to
 shell-config individualism (MacPorts was notorious for failing at this), and
 yet many Mac programmers know nothing of shells at all (so they don't know
 how to edit it manually), Homebrew puts itself into a directory that is
 already in $PATH by default, but which is conveniently nonexistent by
 default.

Are you honestly trying to tell me that a developer (using any
language, other than maybe vbscript in Excel) doesn't know about
$PATH?

 Thus, Homebrew chowns /usr/local to (desktop user):admin.


 In any case, the fact that Homebrew does that to /usr/local 

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-02 Thread Andrew Dunstan



On 04/02/2012 05:23 AM, Dave Page wrote:

There are hundreds of thousands of pieces of malware for Windows that
relied on the ability to write to system directories like this to do
their misdeeds. Anywhere they can write (or modify existing) software
that may get executed at boot time or by an unsuspecting users (or
potentially, root). Microsoft spent millions, probably tens or
hundreds of millions enhancing the security of Windows precisely
because of this type of security issue.

If homebrew intentionally creates a hole like that, then for as long
as I'm one of the PostgreSQL webmasters it will *never* be listed on
our download pages.




+10

I'm one of the people who doesn't have a horse in this race. (Recently I 
was teaching my daughter about some development stuff and so I got her 
to install Fedora under VirtualBox on her Mac :-) ). But as soon as I 
saw this stuff about the intentional security hole it raised a great big 
red flag with me too.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-02 Thread Jay Levitt

Dave Page wrote:

On Mon, Apr 2, 2012 at 12:29 AM, Jay Levittjay.lev...@gmail.com  wrote:
Just as an FYI, a large percentage of the PostgreSQL developers are
Mac users, including myself. They're also the company standard at
EnterpriseDB - so we're not entirely unfamiliar with software
development on them.


Good to know; now I realize that even on Macs there are two worlds. I think 
it's important to understand the new world, because although very little 
infrastructure spans two generations, I believe that PostgreSQL is uniquely 
positioned to do exactly that, just as POSIX has. It's a performant ACID 
relational data store for the old guard, but it's also a web-scale 
cloud-friendly polyglot-extensible preinstalled 
XML/JSON/hstore/tree/graph/schemaless store for the new, and like Java 
HotSpot, it gets smarter and faster every day. It is an operating system for 
your data, it's free, and Oracle hasn't bought it (except yesterday).


This goes back to the marketing challenge, not technical challenge threads.


- We have few Mac experts hanging out in #postgresql.

Not sure how this is relevant to the proposal.

The impetus for the idea was that there seems to be a steady stream of
novice PG users on Mac who come into #postgresql with installation problems,

If you see someone report a bug with the installers, please have them
report it on the EnterpriseDB forums:
http://forums.enterprisedb.com/forums/show/9.page


It's not a bug with the EDB installer, except insofar as the bug is the EDB 
installer is not prominent and widely recommended enough and so they used 
homebrew or macports. The EDB installer is what they used once upon a time; 
today they are following a blog post that walked them through homebrew 
(probably as one line of a longer process involving memcached, sphinx, 
nginx, node.js, and seven other things).



The EDB installer will always be
a one-off experience; most of the other servers you install will be through
a package manager, and homebrew's popularity (despite its youth) is
impressive.


I would disagree with that. Most users I know do not use things like
homebrew (particularly those coming from Windows who have no
familiarity with such package managers at all).


Yep; two worlds.

 [docs reference 8.4]

That hasn't been updated because the installation steps haven't
changed and I'd rather spend time writing software than updating
screenshots.


Fair. I wonder if there's an easy way to automate the generation and 
insertion of those screen shots. You could always write an 
AppleScript/Automator/Keyboard Maestro script, but I feel like I've seen a 
better way specifically for tech docs; I'll keep an eye out.



A couple of points of note:

- The introduction says: This document is based on the 8.4.x
one-click installers but applies equally to later versions.

- The doc also explains where to find the uninstaller.


Sure, and if humans read docs, instead of just glancing at them, that'd be 
all you needed. In any case, I could counter myself that nobody reads the 
doc period, so it doesn't matter what version is listed; that's just the 
source of my own misunderstanding about maintenance.



- There are eight ways to install Postgres on a Mac

That isn't any more of a reason to discount the EDB installer than any
other.

Nope, just an argument that the recommended installer should handle that
nicely.


It does. It'll detect that the port is in use and suggest a different
one. I don't know of any other of those installation methods that'll
do that.


That's terrific, and you're right - it's the only one.

 2. The current formula installs Postgres as the desktop user, not as the
 _postgres role account.
 That's not very helpful on shared machines - and whilst it may be fine
 for developers etc, it's not the recommended way to setup PostgreSQL
 for any kind of production use.
 Oh, of course. Homebrew does not target the three remaining people who run
 production XServes.  It's purely for Mac developer workstations.  At
 startups. Which are MacBooks! :)
 Production doesn't necessarily mean server. All those thousands of
 Poker Tracker users that run with PostgreSQL on Windows on their home
 machines are production users for example.

Excellent point, and one I hadn't thought of.


1. Rubyists in general are sick of sudo'ing on their laptops, because It
Doesn't Matter (as I'll fail to argue later).  Homebrew puts itself into a
directory that is user-writable so it does not require sudo for basic
installation.


Nice. You just turned me off ever wanting anything related to Ruby on
my Mac either!


Well, for Rubyists, I should properly substitute younger developers, aka 
all developers eventually.


As more toolchains work without sudo (Ruby, Python, JavaScript), using sudo 
actually breaks stuff, because now you've written some files as root and 
you'll later fail to overwrite them as user. Heck, I've had that happen with 
ccache; if you do sudo make install without make, you're 

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-02 Thread Dave Page
On Mon, Apr 2, 2012 at 8:17 AM, Jay Levitt jay.lev...@gmail.com wrote:

 Sure, and if humans read docs, instead of just glancing at them, that'd be
 all you needed. In any case, I could counter myself that nobody reads the
 doc period, so it doesn't matter what version is listed; that's just the
 source of my own misunderstanding about maintenance.

Seems odd that you claim the docs are out of date in one breathe, then
in the next counter with an argument that users never read docs so
they're basically irrelevant.

 Well, for Rubyists, I should properly substitute younger developers, aka
 all developers eventually.

 As more toolchains work without sudo (Ruby, Python, JavaScript), using sudo
 actually breaks stuff, because now you've written some files as root and
 you'll later fail to overwrite them as user. Heck, I've had that happen with
 ccache; if you do sudo make install without make, you're compiling and
 caching as root, and three years later you'll recompile as user and get a
 permissions error (or a broken ccache IIRC).

I'm not aware that either Python or JavaScript require that you remove
sensible and long established security measures from your machine.
Come to think of it, neither did the MacPorts installation of Ruby
that I used to have to run a couple of utilities, nor does the version
that Apple ship with OS X.

I would suggest that it's not modern languages that require bypassing
of security measures, but a poorly designed packaging system.

 I'm not only telling you that *a* developer doesn't know; I'm telling you
 that soon, *most* won't.  (Or, if they do, they know it's a magic
 incantation that when something breaks, a blog tells them what to type to
 fix it.) I work with a smart 2005 CS graduate who, when I said look in
 /usr/lib, would try cd'ing to /Users/Library. He wrote his first shell
 script last week.

 I'm not saying it's good. I'm just saying it is - and you're younger than
 me, so you're not going to get to retire before it happens either!

I run multiple teams of engineers at EnterpriseDB, and many of them
are basically fresh out of university (or were when they joined EDB).
Every single one of them knows what the path is and how to change it,
and I can say with confidence that every one of them could explain to
you what's wrong with making /usr/local/ world writeable. They may not
be able to code in a particular language, but they all have the
ability to learn and the basic skills on which to build. If the
students of the future have as little knowledge of computer systems as
you suggest, we might as well throw away our machines now and go live
in caves or huts!

And on that note, I suggest we take this off pgsql-hackers now as it's
drifting (drifted) way off topic for the list.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install? / apology

2012-04-02 Thread Jay Levitt

David Johnston wrote:
 Just trying to bridge an apparent gap since the original e-mail seems to
 have come across as too adversarial that the underlying thoughts have
 been overlooked.  Trying to contribute in my own way with my current
 resources.

Thanks, but it's my own fault for basing a half-baked let's rewrite 
everything idea on a few wrong assumptions without asking some simple 
questions first. (Sorry, David.) And you guys don't know me very well yet, 
so you don't how to interpret my tone, or that I spend the *first* half of 
each day making the exact opposite arguments to all the young turks in the 
hopes we'll all meet in the middle.  I plan to hang around, so by way of 
belated introduction, and you can imagine this in the style of Beetlejuice:


Hi. I wrote AOL's OLTP-style mail server in 1994 and scaled it (with an 
eventual team of 25) from 27 to 4000 TPS on minicomputers as powerful as an 
iPhone. It had multi-site replication, zero-downtime installs (without 
blocking writes), and served 1.5 million simultaneous users. I had to write 
nearly a whole SVM-based OS in the app, because nothing at the time - from 
the message bus to the disk cache to poll() itself - could handle our load, 
and our growth outpaced the hardware manufacturers' ability to build it. I 
did this with no CS background beyond public school (I started as a 6502 
hacker), no search engine, and no access to research papers or computer 
scientists. I have no idea how.


The architecture survived five underlying infrastructure transitions 
(Stratus filesystem, Sybase, Informix, Tandem, and the move from four- to 
eight-byte IDs that PG has successfully staved off) while migrating live. It 
never lost or misrouted a message, and never had a security breach in the 
nine years I led it (or, AFAIK, since), despite the fact that we were a big 
enough target for hackers to respond to our changed defenses within hours. I 
do actually know this stuff, or did.


I spent 10 years taking a break, studying music, successfully sleeping 
through Java; now I'm back in technology, leading development in a 
Rails/web/JS startup, and luxuriating in the ability to actually store data 
in a database this time - because you guys have spent the past 20 years 
studying and improving the hard parts of abstracting performant, reliable, 
scalable data storage.


I have a tendency to see the possible endgame and insist on starting now, 
and if I get too idealistic, ambitious, and MongoDB is webscale, please 
just drag me into a conversation about lock contention and distributed 2PC 
and I'll forget the whole thing. But I really do think PG can be the 
makes-everything-possible, does-most-things-well data store - really, data 
platform - for the next decade or two, and I want to contribute.


I'm provocative, playful and grandiose, I apologize except not really, and 
it's because in my n=1 experience, the way life works is (a) you decide to 
change the world and then (b) you do.


 You do not need permission to contribute to the community
 in the way you seek so what is it that you are really asking for?

Nothing at this point. I was thinking out loud, and at the time was 
temporarily insa^h^h^hconvinced that the homebrew formula should be the 
community standard, and thus that I'd have to bring it up to some level of 
acceptability/review.  I've contributed to the formula in the past, and will 
continue to do so based on the thoughts everyone's shared here. It doesn't 
need to be official to be useful, and as David Page said, it's not gonna be 
listed in the docs no matter what, given the one decision that homebrew 
makes (/usr/local) that I can't override.



When brew is replaced by something more popular do you
think you will continue to maintain the recipe or is it going to end
up stuck showing us how to install version 9.3 or earlier.


Like anything, I'll maintain it until it becomes useless to me or vice 
versa, and someone will pick it up or they won't.  But just to be clear, 
Homebrew's a source-based repo (so there's no cross-compiler issues), 
pulling from the upstream source repository, using only the stock compiler 
toolchain, Intel-only, on a platform where the only hardware manufacturer 
has themselves severely constrained the number of possible configurations. 
For the most part, updating the formula to package new versions is a 
matter of changing the following two lines:


  url 'http://ftp.postgresql.org/pub/source/v9.1.3/postgresql-9.1.3.tar.bz2'
  md5 '641e1915f7ebfdc9f138e4c55b6aec0e'

Unless the instructions for How to build postgres from source change, 
nothing else in the formula *needs* to.  The current formula is fairly 
simple; aside from user instructions, the code is 75 lines and mostly 
consists of default arguments to ./configure.  (Formula attached for the 
curious.)  Pull requests are freely and quickly accepted after a quick 
review; the homebrew repo is operated more in the fail early and often 
spirit than in 

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-02 Thread Greg Stark
On Mon, Apr 2, 2012 at 5:29 AM, Jay Levitt jay.lev...@gmail.com wrote:
 So this is pointless to the discussion now, but if you want to engage
 off-list, I'd frankly love to be reconvinced:

It may not be an unreasonable thing for an individual user to do to
their own machine. But it's not really Postgres's place to be
re-engineering the whole security model of the user's machine based on
our beliefs of what's important.



-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread Jay Levitt

Jay Levitt wrote:

POSSIBLE OBJECTIONS/PREREQUISITES


10. There is no homebrew support for multiple versions, and no current plans 
to add it (though it's on the wishlist). This means homebrew is only useful 
if I want to install a PostgreSQL thingie is the common Mac use case. If 
people often need to use specific older versions, to mirror their server 
configs, it's a problem.  It *might* be possible to hack this into our 
formula, but I'm not sure it's either doable or acceptable.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread Tom Lane
Jay Levitt jay.lev...@gmail.com writes:
 So with all respect and thanks to EDB for maintaining those installers, I'd 
 like to propose that homebrew become the recommended install method on Mac, 
 and I will update the Mac formula to overcome any current objections.

This proposal doesn't seem to me to have any chance at all of getting
accepted.  While you might not like the EDB installer, at least those
folks are active in the lists and accountable for whatever problems
their code has.  Who in heck is responsible for the homebrew
packaging, and do they answer questions in the PG lists?

ISTM a more useful response to the problems you've mentioned is to
suggest to the EDB folk that they'd better install somewhere else
than where the built-in Lion installation is.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread Dave Page
Hi

On Sun, Apr 1, 2012 at 4:14 PM, Jay Levitt jay.lev...@gmail.com wrote:
 The Mac installation docs currently recommend the EDB one-click installer as
 the first choice. While this does install pgadmin and some other
 refinements, it also is fairly confusing to troubleshoot:

 - By default, it installs to /Library/PostgreSQL, which is also (I think)
 where the Apple-supplied Lion install is

No, Apple's version is installed in /usr on mine.

 - The uninstaller is hidden in /Library/PostgreSQL, which (since Finder
 hides /Library by default) you're likely to go to via Terminal. But the
 uninstaller is a Mac app, so even if you find it you have to know to use
 open to run it, because Mac apps are really directories that the Finder
 abstracts away from you.

Yes.

 - The EDB docs are written against 8.4.

Only if you install 8.4. If you install 8.3 you get the 8.3 docs, 9.0
the 9.0 docs and so on.

 - There are, as @lluad points out, no fewer than eight ways to install
 Postgres on a Mac (fink, macports, homebrew, Lion default, build from
 source, EDB, and two other binary installers)

That isn't any more of a reason to discount the EDB installer than any other.

 - We have few Mac experts hanging out in #postgresql.

Not sure how this is relevant to the proposal.

 - We just had two folks within an hour, BOTH with conflicting installs of
 Postgres.

Not sure how that is relevant either. You can have conflicting
installation using any of the installation methods, including a
home-built source tree.

 1. homebrew installs everything under /usr/local and makes that
 user-writeable.  Sorry.  It does because most Mac users don't know how to
 edit PATH for GUI apps (it's in a .plist in a hidden directory in your home
 dir), and /usr/local is already in PATH by default.

Your reasoning doesn't make sense. Why does putting something in the
path require a directory to be world writeable.

In any case, the fact that Homebrew does that to /usr/local should be
enough to make any user run away screaming in terror. If it opens up a
security hole like that, what else does it do to break your system?

 2. The current formula installs Postgres as the desktop user, not as the
 _postgres role account.

That's not very helpful on shared machines - and whilst it may be fine
for developers etc, it's not the recommended way to setup PostgreSQL
for any kind of production use.

 I'm personally of the strong opinion that user-to-user privilege escalation
 attacks are NOT an issue on desktops; all important files are already owned
 by the desktop user. The attack vector is *maybe* root escalation attacks,
 but if you want root, it's so common for installers to ask permission that
 your malware could just ask.  The real attack vector is I'm in your
 browser, and that has nothing to do with root, permissions, or users at
 all.

I, and I suspect many others, would disagree that user to user
security is not important.

 Meanwhile, the EDB installer by default installs both app and data to a
 directory that requires root - so I assume it runs as root too - and
 nobody's complained.

No it doesn't. It installs the app to a root owned directory for
security, and the data goes in a postgres owned directory so it can
only be modified by the account the service runs under.

 4. TCF also spits out instructions for adding Postgres to launchctl (Mac's
 version of /etc/init.d or Windows Services), rather than doing it for you,
 but again, I'd happily add the option.  (I'm checking with Homebrew folks to
 see if there's some dictum against that; it's a common pattern to put
 launchctl in the instructions, but IME the usability is poor.)

 5. TCF doesn't update your shared memory settings. Again, happy to add that.

 6. TCF doesn't look for existing installs. This is especially a problem on
 Lion, since Apple bundles PG 8.4, either client or server IIUC, and although
 /usr/local/bin is in your PATH, it comes *after* /usr/bin (grumble), so
 you'll either have the homebrew server fail to launch (since port 5432 is in
 use), or you'll have an outdated client version.

They seem like a number of reasons not to use Homebrew too (at least
as it is now).

 In IRC, both users had actually installed the EDB version months ago and
 forgotten about it, but over time, Lion users will grow, since all new Macs
 come with only Lion.  There are several ways to address this; my preference
 is to have homebrew warn about existing installs but take care of any magic
 to make them go away, a la
 http://nextmarvel.net/blog/2011/09/brew-install-postgresql-on-os-x-lion/.

So you propose to make it silently disable existing servers? I know
various people whose machines would be broken by that, including mine.
We went to great lengths to allow side by side installations of
different versions, precisely because developers (and occasionally
users) need to use multiple versions to support current and future
versions of their applications, and to experiment with new features.

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread Jay Levitt

Dave Page wrote:
 It seems to me that most of your arguments against the installers are
 based on incorrect understanding or information, and most of your
 arguments for Homebrew actually come across as arguments against!

You're right about the former - and as to the latter, they *were* arguments 
against (potential objections).  I try to pre-argue against my own 
proposals to save everyone time; if I can still prevail, I must have a damn 
good idea :)


At this point I agree with you, but I'm still going to go into detail, 
because I think there are two markets for Postgres, and the database 
community has been so focused around enterprise for so long that you're 
missing opportunities with web startups. I'd love to help bridge the gap, 
having jumped straight from big-iron PL/I to ooh-Ruby-is-shiny. And web 
startups develop on Mac laptops. They just do. So if it helps you to imagine 
me as a 20something I'm a Mac hipster, working on some hot Facebook/mobile 
app with funding from Spark Capital, do that. Lord knows it helps me.


 - We have few Mac experts hanging out in #postgresql.
 Not sure how this is relevant to the proposal.

The impetus for the idea was that there seems to be a steady stream of 
novice PG users on Mac who come into #postgresql with installation problems, 
which is bad enough as an out-of-box experience - but worse is that there 
are rarely folks around who can help. (Of course, I'm extrapolating; every 
time *I'm* in IRC and see this, there's someone who can help. But you know 
what I mean.)


And (although my proposal started with documentation) I'm of the firm 
opinion that there's no such thing as a documentation error; a user 
problem is a software problem.  Humans will click buttons before they'll 
read, developers are humans, and no amount of RTFM will ever fix that. If we 
can make installers smarter, that's way better than troubleshooting guides, 
IRC, mailing lists, etc. So that's where I was coming from.


I didn't realize that you were actively maintaining the EDB installer (see 
below for the 8.4 doc explanation); obviously, if you can improve that, it's 
the best solution and we should, if anything, recommend it MORE vigorously. 
Still, there's a growing community of developers who expect brew install 
to work, and I do want to fix it for them.  The EDB installer will always be 
a one-off experience; most of the other servers you install will be through 
a package manager, and homebrew's popularity (despite its youth) is 
impressive.  Both of my n=2 data points had run across PG a while back, 
installed it with the one-click to try it out, forgotten about it, done 
brew install postgresql today, and naturally ran into problems.


 - By default, it installs to /Library/PostgreSQL, which is also (I think)
 where the Apple-supplied Lion install is
 No, Apple's version is installed in /usr on mine.

Ah hah. I suppose only the Apple .plist is stored under /Library, then. Let 
me amend that to this made everyone in IRC, and probably many other 
non-Mac-expert troubleshooters, assume that this is an Apple-installed 
package. It'd be great for this to go somewhere that feels like Oh, this 
was installed by you; /Library feels kinda weird for a server, though I can 
understand your reasoning. Maybe even /Library/EnterpriseDB/PostgreSQL to 
make it obvious?


 - The uninstaller is hidden in /Library/PostgreSQL, which (since Finder
 hides /Library by default) you're likely to go to via Terminal. But the
 uninstaller is a Mac app, so even if you find it you have to know to use
 open to run it, because Mac apps are really directories that the Finder
 abstracts away from you.
 Yes.

How about a one-liner bash script uninstall-postgresql that does nothing 
but open uninstall-postgresql.app?


 - The EDB docs are written against 8.4.
 Only if you install 8.4. If you install 8.3 you get the 8.3 docs, 9.0
 the 9.0 docs and so on.

No, I meant on the web:

http://www.enterprisedb.com/resources-community/pginst-guide

That's what made me assume that the installer wasn't maintained (except as 
to repackaging new PG versions, obviously). It's obviously not hard to 
replace 8.3 with 9.1 when you read it, but it still leaves an impression 
akin to This web site works best with IE7 and above. Allow me to now 
replace most of this thread with hey, you might wanna update that page.


 - There are eight ways to install Postgres on a Mac
 That isn't any more of a reason to discount the EDB installer than any other.

Nope, just an argument that the recommended installer should handle that nicely.

 - We just had two folks within an hour, BOTH with conflicting installs of
 Postgres.
 Not sure how that is relevant either. You can have conflicting
 installation using any of the installation methods, including a
 home-built source tree.

Right, but I suspect this is a common problem - not only have I seen it in 
IRC but 3 or 4 times in my 12-person startup, which is kinda amazing given 
that we've 

Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread Jay Levitt

Tom Lane wrote:

While you might not like the EDB installer, at least those
folks are active in the lists and accountable for whatever problems
their code has.  Who in heck is responsible for the homebrew
packaging, and do they answer questions in the PG lists?


Just for general knowledge... Who's responsible is whoever wants to be; 
homebrew is open source, and with a github-based workflow, it's trivial for 
them to accept pull requests.  On the 1967 formulas (packages) in the repo, 
there have been 1759 contributors.  I was volunteering to be the maintainer 
and liaison if we did this; I'm pretty good at email and IRC.


It's actually pretty clever and elegant - homebrew itself uses git and 
github for formula updates and distribution, and is written in ruby1.8 which 
ships with all Macs. /usr/local is a git repo, brew update is mostly git 
pull, and brew search checks for new pull requests if it doesn't find a 
matching formula. The whole thing's all of 1500 lines of code, and you saw 
what formulas look like.


Jay

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread David Johnston
On Apr 1, 2012, at 21:50, Jay Levitt jay.lev...@gmail.com wrote:

 Tom Lane wrote:
 While you might not like the EDB installer, at least those
 folks are active in the lists and accountable for whatever problems
 their code has.  Who in heck is responsible for the homebrew
 packaging, and do they answer questions in the PG lists?

 
 Just for general knowledge... Who's responsible is whoever wants to be; 
 homebrew is open source, and with a github-based workflow, it's trivial for 
 them to accept pull requests.  On the 1967 formulas (packages) in the repo, 
 there have been 1759 contributors.  I was volunteering to be the maintainer 
 and liaison if we did this; I'm pretty good at email and IRC.
 
 It's actually pretty clever and elegant - homebrew itself uses git and github 
 for formula updates and distribution, and is written in ruby1.8 which ships 
 with all Macs. /usr/local is a git repo, brew update is mostly git pull, 
 and brew search checks for new pull requests if it doesn't find a matching 
 formula. The whole thing's all of 1500 lines of code, and you saw what 
 formulas look like.
 
 Jay
 
 

You seem highly approving of homebrew and seem willing to develop and support 
it.  I guess the question to be asked is what requirements you would expect to 
have to meet before the Mac Downloads section would list your installer routine 
along with the three already present?  Aside from that unless you are really 
intent on trying to prove yourself to be the best if you are trying to overcome 
shortcomings of the existing installers it would still be nice to let them know 
how you feel things could be improved for the community/user sub-set you belong 
to.  

As a Windows developer (though production is on Linux) I get where you are 
coming from with respect to user permissions and the like - what is desirable 
in a development and in production do differ and so having different 
installation routines for them makes some sense.  Until your developers go to 
install on the production server and do not realize that they should be doing 
something different in order to make the server more secure than their 
development environment.

From what I follow I think you have really good ideas and sound reasoning.  
You do not need permission to contribute to the community in the way you seek 
so what is it that you are really asking for?  From the sound of things your 
primary focus is not in supporting the PostgreSQL community via providing 
services to others or developing new tools.  When brew is replaced by 
something more popular do you think you will continue to maintain the recipie 
or is it going to end up stuck showing us how to install version 9.3 or 
earlier.  I'm beyond my element here but the current installer maintainers are 
doing so in addition to their other, more regular, contributions.  That said, 
the contribution, even if it did stall in the future, would still be welcomed 
and if it is found to be very useful someone would likely pickup the torch as 
long as it is released under the same terms as PostgreSQL itself.

Just trying to bridge an apparent gap since the original e-mail seems to have 
come across as too adversarial that the underlying thoughts have been 
overlooked.  Trying to contribute in my own way with my current resources.

David J.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Switching to Homebrew as recommended Mac install?

2012-04-01 Thread David Johnston
On Apr 1, 2012, at 13:14, Jay Levitt jay.lev...@gmail.com wrote:

 The Mac installation docs currently recommend the EDB one-click installer as 
 the first choice. While this does install pgadmin and some other refinements, 
 it also is fairly confusing to troubleshoot:
 

The items are not numbered and it is impossible to avoid special ordering.  
There are three options - and yes EDD is listed at the top of the page - but 
nothing else implies any kind of order and given that they are dealing with 
different ways to package if someone prefers MacPorts or Fink the fact they are 
listed lower shouldn't induce them to pick the unfamiliar one first.

David J.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers