svn - but smaller?

[Jeremy Chadwick]

(Please keep me CC'd as I'm not subscribed to the list)

> Great idea;
> 
> http://www.bayofrum.net/~crees/patches/svn-static.diff
> 
> Lev, do you mind if I commit this?  I haven't touched the subversion
> port, but it'll have you as maintainer :)
> 
> If you prefer, I don't mind maintaining this.

As I understand it this patch would induce the build cluster to build
subversion-static.tbz (eventually) and put it on the package servers.

So what happens when one of the underlying dependencies that you've
included statically (those would possibly be: Oracle/SleepyCat DB, APR,
expat, sqlite3, neon, gettext, and iconv) have security holes or major
bugs found/addressed in them?

As I understand it -- based on history -- the packages on the FTP
servers get updated "whenever".  My other post shows some haven't been
updated in months (and yes I'm aware of the security incident).

So how long would a key piece of software containing insecure
statically-linked libraries be on the FTP servers?

How would the port maintainer(s) even know the libraries/software which
subversion is dependent upon had been updated, thus requiring a new
subversion package to be pushed out to the package servers ASAP (i.e.
immediately, not days, weeks, or months)?

My point: ports have always been "best-effort".  They are advertised
vehemently throughout "everything FreeBSD" as being third-party software
and therefore <infinite list of caveats>.  Yet now critical pieces to
FreeBSD development (and now end-users too, as a result of using the
security incident to push SVN) rely upon something in ports.  That's
quite a conundrum the Project has created for itself, an ouroboros of
sorts.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |