On Tue, Nov 25, 2014 at 06:43:03PM +0100, Michal Sekletar wrote:
I got a response from a member of Red Hat's SRT stating that since the
issue was already reported publicly they can not assign CVE number. If
we want to request CVE number we should either write to oss-security
list or ask MITRE
On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote:
I didn't request one, but probably. RH or Debian folks can likely just
assign one from their pools.
I can ask the Debian security team to assign one, or we can ask
cve-assign@mitre directly. Or perhaps the other Michal can get one
On Tue, Nov 25, 2014 at 09:52:59AM +0100, Romain Francoise wrote:
On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote:
I didn't request one, but probably. RH or Debian folks can likely just
assign one from their pools.
I can ask the Debian security team to assign one, or we can
Hi All,
I need to capture traffic over dynamically created UDP port, I am unable to
capture some RTP traffic flowing through some dynamic udp port.I am using
latest TCPDUMP version 4.6.2
Please help me in sorting this issue
Thanks,
Kishore
On Tue, Nov 25, 2014 at 8:13 PM, Michal Sekletar
On Tue, Nov 25, 2014 at 03:43:21PM +0100, Michal Sekletar wrote:
On Tue, Nov 25, 2014 at 09:52:59AM +0100, Romain Francoise wrote:
On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote:
I didn't request one, but probably. RH or Debian folks can likely just
assign one from their
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.
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,
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
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
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
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
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
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
On Fri, Nov 21, 2014 at 11:01:15PM +0100, Romain Francoise wrote:
On Fri, Nov 21, 2014 at 03:47:06PM -0500, Michael Richardson wrote:
It's supposed to happen, but I'm checking.
Should be there now. Is cron failing to do it's thing?
Ok, the fixes still aren't on master, but now there's a
On Nov 23, 2014, at 11:16 PM, Michal Sekletar msekl...@redhat.com wrote:
Yes, I spent good couple hours backporting those to older versions we have in
Fedora 19 and 20.
So did I. :-)
(See branches tcpdump_4.1 through tcpdump_4.6.)
I started to work on the patches ASAP and after submitting
On Nov 21, 2014, at 2:01 PM, Romain Francoise rfranco...@debian.org wrote:
Ok, the fixes still aren't on master, but now there's a tcpdump-4.7
branch with the commits I need.
So I apparently need all of these?
3f5693a 10 days ago Guy Harris Report a too-long unreachable destination list.
Romain Francoise rfranco...@debian.org wrote:
That's a lot bigger than typical security patches. :(
It's in the tcpdump.org/beta/ directory, but I didn't want to release
until the distros had a chance to patch.
But did you notify the distros? Because I didn't get advance
Hi,
I'm looking for the official patches for CVE-2014-8767, CVE-2014-8768
and CVE-2014-8769 but they don't seem to be in the Github repository.
The advisories also mention a 4.7.0 version with the fixes, but it's not
there either.
More info:
http://seclists.org/bugtraq/2014/Nov/88
On Nov 21, 2014, at 1:00 AM, Romain Francoise rfranco...@debian.org wrote:
I'm looking for the official patches for CVE-2014-8767, CVE-2014-8768
and CVE-2014-8769 but they don't seem to be in the Github repository.
Michael, are changes made to the bpf.tcpdump.org repository still getting
Guy Harris g...@alum.mit.edu wrote:
I'm looking for the official patches for CVE-2014-8767, CVE-2014-8768
and CVE-2014-8769 but they don't seem to be in the Github repository.
Michael, are changes made to the bpf.tcpdump.org repository still
getting pushed to the Github
On Fri, Nov 21, 2014 at 03:47:06PM -0500, Michael Richardson wrote:
It's supposed to happen, but I'm checking.
Should be there now. Is cron failing to do it's thing?
Ok, the fixes still aren't on master, but now there's a tcpdump-4.7
branch with the commits I need.
So I apparently need all of
On Fri, Nov 21, 2014 at 11:01:15PM +0100, Romain Francoise wrote:
But did you notify the distros? Because I didn't get advance notice, and
the others haven't released security updates yet either.
Oh, actually I'm wrong: Fedora has updated packages.
--
Romain Francoise rfranco...@debian.org
22 matches
Mail list logo
