On Mon, Apr 28, 2014 at 06:48:07AM -0500, David Noel wrote:
>
> [snip a bunch of stuff]
Great. I'll start looking at stuff this week, then probably ping you
off-list to ask questions.
Now I just need to add a note about this to my todo-queue so I don't
make a liar of myself.
--
Chad Perrin [ o
On 4/25/14, Chad Perrin wrote:
> On Mon, Apr 14, 2014 at 12:36:28AM -0500, David Noel wrote:
>> Thanks. I'm happy to, and it's on my to-do list, the only problem is
>> that I'm swamped with other projects and it's been sitting on that
>> list for the past 2 years. It seems to be a similar problem
On Mon, Apr 14, 2014 at 12:36:28AM -0500, David Noel wrote:
> > Indeed it is not. David's solution - which seems to amount to removing
> > portsnap and herding the cats at home to DTRT about using svn securely -
> > relies on other cats being as smart and aware of the ramifications as he
> > is -
> Indeed it is not. David's solution - which seems to amount to removing
> portsnap and herding the cats at home to DTRT about using svn securely -
> relies on other cats being as smart and aware of the ramifications as he
> is - a highly questionable proposition especially for the numerous more
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 4/13/14, 10:04 PM, David Noel wrote:
> On 4/13/14, David Noel wrote:
>>> So by your definition, every single Apache server on the planet
>>> runs "a closed source fork of the open source Apache project"
>>> because they do not use the exact same
On Sun, 13 Apr 2014 10:33:53 -0400, Lowell Gilbert wrote:
> David Noel writes:
>
> > My main point was that if you don't trust Subversion it makes no sense
> > to say you trust portsnap. Portsnap pulls the ports tree from
> > Subversion. Using Subversion! The portsnap system relies on the tr
On 4/13/14, David Noel wrote:
>> So by your definition, every single Apache server on the planet runs "a
>> closed source fork of the open source Apache project" because they do
>> not use the exact same httpd.conf?
>
> Ah, you're right. That's from build.conf. My mistake.
Though if it's using sp
> So by your definition, every single Apache server on the planet runs "a
> closed source fork of the open source Apache project" because they do
> not use the exact same httpd.conf?
Ah, you're right. That's from build.conf. My mistake.
___
freebsd-secur
David Noel writes:
> The server-side code of the FreeBSD portsnap system -- a closed source
> fork of the open source portsnap project -- happens to use secured
> access for pulling data from svn.
So by your definition, every single Apache server on the planet runs "a
closed source fork of the op
> Portsnap uses secured access for getting updates out of Subversion
The portsnap open source project pulls data insecurely using the url
svn://svn.freebsd.org.
The server-side code of the FreeBSD portsnap system -- a closed source
fork of the open source portsnap project -- happens to use secure
David Noel writes:
> My main point was that if you don't trust Subversion it makes no sense
> to say you trust portsnap. Portsnap pulls the ports tree from
> Subversion. Using Subversion! The portsnap system relies on the trust
> of both svnadmin and svn. Just as it does when you run svn co and s
On 2014-04-11 15:23, David Noel wrote:
If you look at the portsnap build code you'll see that the first
thing portsnap does is pull the ports tree from Subversion. It uses
the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh
the entire ports archive is exposed to corruption right from
>> If you look at the portsnap build code you'll see that the first
>> thing portsnap does is pull the ports tree from Subversion. It uses
>> the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh
>> the entire ports archive is exposed to corruption right from the
>> start.
>
> Just to cl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/11/14 09:08, David Noel wrote:
>> Your report aside, I find portsnap to be far superior in security
>> for ports and users.
>
> If you look at the portsnap build code you'll see that the first
> thing portsnap does is pull the ports tree from
> Your report aside, I find portsnap to be far superior in security for
> ports and users.
If you look at the portsnap build code you'll see that the first thing
portsnap does is pull the ports tree from Subversion. It uses the URL
svn://svn.freebsd.org/ports. By not using ssl or svn+ssh the entir
On Thu, Apr 10, 2014 at 06:38:39PM -0500, Bryan Drewery wrote:
> On 4/10/2014 12:03 PM, David Noel wrote:
> > I found a few bugs in portsnap and freebsd-update that I'd like to
> > bring to the community's attention and hopefully recruit people to
> > help fix. I mentioned them to Colin (their auth
On 4/10/2014 12:03 PM, David Noel wrote:
> I found a few bugs in portsnap and freebsd-update that I'd like to
> bring to the community's attention and hopefully recruit people to
> help fix. I mentioned them to Colin (their author) a few years ago and
> he agreed that they're issues that need to be
On 4/10/14, David Noel wrote:
>> I'm not convinced that a rototil of the protocol and all the associated
>> storage duplication is worth the effort.
>
> As far as portsnap is concerned I'm not convinced that ANY amount of
> effort is worth it. That is why I was hoping to start a conversation
> on
> I'm not convinced that a rototil of the protocol and all the associated
> storage duplication is worth the effort.
As far as portsnap is concerned I'm not convinced that ANY amount of
effort is worth it. That is why I was hoping to start a conversation
on the possibility of phasing it out.
> It
[Trimming the list to -security plus Colin in hopes of reducing the
number of partial conversations. Sending to four lists and an alias is
a list etiquette violation.]
[Also dropping the discussion of replacing portsnap since that is
a mostly unrelated discussion.]
On Thu, Apr 10, 2014 at 12:03:
I found a few bugs in portsnap and freebsd-update that I'd like to
bring to the community's attention and hopefully recruit people to
help fix. I mentioned them to Colin (their author) a few years ago and
he agreed that they're issues that need to be addressed, but in the
time since neither he nor
21 matches
Mail list logo