Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Romain Francoise
On Mon, Nov 24, 2014 at 08:16:56AM +0100, Michal Sekletar wrote: Also it would be nice if we agree on single place where development happens and stick to that. Because bpf.tcpdump.org has a bad track-record (IIRC multiple power, network failures in the past) I am for sticking with GitHub.

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Michael Richardson
Guy Harris g...@alum.mit.edu wrote: (I'm fine with making it the Official Home if Michael chooses to do so. I've managed to cope with the workflow changes required when libpcap/tcpdump switched to Git, when Wireshark switched to Git, and when Wireshark switched to Git+Gerrit,

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Michal Sekletar
On Mon, Nov 24, 2014 at 09:22:23AM -0500, Michael Richardson wrote: Guy Harris g...@alum.mit.edu wrote: (I'm fine with making it the Official Home if Michael chooses to do so. I've managed to cope with the workflow changes required when libpcap/tcpdump switched to Git, when

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Michael Richardson
Michal Sekletar msekl...@redhat.com wrote: Guy Harris g...@alum.mit.edu wrote: (I'm fine with making it the Official Home if Michael chooses to do so. I've managed to cope with the workflow changes required when libpcap/tcpdump switched to Git, when Wireshark switched to

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Guy Harris
On Nov 24, 2014, at 1:04 AM, Romain Francoise rfranco...@debian.org wrote: On Sun, Nov 23, 2014 at 11:35:21PM -0800, Guy Harris wrote: So did I. :-) (See branches tcpdump_4.1 through tcpdump_4.6.) Ah, great, I need patches for Debian stable, which ships tcpdump 4.3.0. I was about to use

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Guy Harris
On Nov 24, 2014, at 10:25 AM, Michael Richardson m...@sandelman.ca wrote: Michal Sekletar msekl...@redhat.com wrote: I don't agree. Rather what are you hearing is a request that code should appear in master branch on GitHub with reasonable time delay. So, it happens occasionally that

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Denis Ovsienko
I don't really want to put *all* my eggs on github. I agree that GitHub is a business and businesses are not always in a good shape and are not forever in the best case. Specifically, many projects have had a lesson from SourceForge developments in the recent few years. Besides that, where a

Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Guy Harris
On Nov 24, 2014, at 1:24 PM, Denis Ovsienko de...@ovsienko.info wrote: So the problem is to let GitHub do its good things to tcpdump yet to protect from the bad ones. To me it seems that for the next few years the best balance between survivability and convenience would be in continuing to

[tcpdump-workers] bpf.tcpdump.org vs github

2014-11-24 Thread Michael Richardson
okay, can we start again. I would appreciate some clear data and clear complaints. This is what I heard: a) which is master, bpf or github? b) bpf is unreliable. c) there is some issue (please explain more) with bpf.tcpdump.org experiencing auto-merging difficulties. d)

Re: [tcpdump-workers] bpf.tcpdump.org vs github

2014-11-24 Thread Guy Harris
On Nov 24, 2014, at 7:01 PM, Michael Richardson m...@sandelman.ca wrote: okay, can we start again. I would appreciate some clear data and clear complaints. This is what I heard: a) which is master, bpf or github? b) bpf is unreliable. c) there is some issue (please explain