Re: [tcpdump-workers] bpf.tcpdump.org vs github
> c) there is some issue (please explain more) with bpf.tcpdump.org > experiencing auto-merging difficulties. When a repository exists in two copies and each copy has the same branch (i.e. master) and some new commits go to that branch in one copy but not the other, and also the other way around, the branches will look like this (this is how GitHub and bpf.tcpdump.org look right now): a-b-c-d-e-m-n-t a-b-c-d-e-x-y-z Then git-merge in any of the directions will not be fast-forward and will require explicit merge commits and sometimes conflict resolution. That is additional work for no gain. If instead the copies get converged first and then new commits go to one copy only, the other copy will always enjoy fast-forward pulls, making it possible to run git-pull every 15 minutes from crontab. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
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 via internal Red Hat channels? -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
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 ask > cve-assign@mitre directly. Or perhaps the other Michal can get one via > internal Red Hat channels? I will contact Red Hat SRT to look into that. Michal > > -- > Romain Francoise > http://people.debian.org/~rfrancoise/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
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 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 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 via > > internal Red Hat channels? > > I will contact Red Hat SRT to look into that. > > Michal > > > > > -- > > Romain Francoise > > http://people.debian.org/~rfrancoise/ > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] bpf.tcpdump.org vs github
On Mon, Nov 24, 2014 at 10:01:11PM -0500, Michael Richardson 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? There are commits on github/master which are not on bpf. We already have maintenance branch for 4.7 but there was no release yet. No commit on master has tcpdump-4.7 tag. This is very confusing. > b) bpf is unreliable. I mean an outage for hour or two and regular maintaince windows are fine but if site is unreachable for days without prior notice then it is unreliable in my book. > c) there is some issue (please explain more) with bpf.tcpdump.org > experiencing auto-merging difficulties. In my opinion you are putting this mildly. I am sorry, but current situation with tcpdump/libpcap git is very unfortunate. Why auto-merging doesn't work I can't tell. I have no idea who is an admin of bpf and what cron job doing the merge actually does. > d) this CVE process has been botched (I said this, and I take > responsability for this) It could have been much less painful if all of the above was not the case. > > before I propose some solution/policy/adjustment, I want to make sure that > I've heard all the issues. I don't follow, you don't like the idea to use GitHub then why we encourage people to use it as tool for contributing to the project. Michal > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works| network architect > [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
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 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 via > > internal Red Hat channels? > > I will contact Red Hat SRT to look into that. 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 directly. Michal > > Michal > > > > > -- > > Romain Francoise > > http://people.debian.org/~rfrancoise/ > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] bpf.tcpdump.org vs github
Michal Sekletar 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? > There are commits on github/master which are not on bpf. We already > have maintenance branch for 4.7 but there was no release yet. No commit > on master has tcpdump-4.7 tag. This is very confusing. Right, but the idea was supposed to be that we DO NOT PUBLISH the fault until after you guys (the distros) actually have a package.So, this is ENTIRELY ON PURPOSE. Are you saying that you'd prefer to have a zero-day exploit? >> b) bpf is unreliable. > I mean an outage for hour or two and regular maintaince windows are > fine but if site is unreachable for days without prior notice then it > is unreliable in my book. I am unaware of it being unreachable for more than a Sunday afternoon to Monday morning; and that instability with power was solved. >> before I propose some solution/policy/adjustment, I want to make sure >> that I've heard all the issues. > I don't follow, you don't like the idea to use GitHub then why we > encourage people to use it as tool for contributing to the project. github has lots of nice features. Maybe we should only use github --- certainly when I first proposed github, many people were uncertain about it --- it was too new, and we were too experienced with sourceforge coming and going to want to sign up for another disaster. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] bpf.tcpdump.org vs github
On Tue, Nov 25, 2014 at 01:12:18PM -0500, Michael Richardson wrote: > > Michal Sekletar 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? > > > There are commits on github/master which are not on bpf. We already > > have maintenance branch for 4.7 but there was no release yet. No commit > > on master has tcpdump-4.7 tag. This is very confusing. > > Right, but the idea was supposed to be that we DO NOT PUBLISH the fault until > after you guys (the distros) actually have a package.So, this is ENTIRELY > ON PURPOSE. Are you saying that you'd prefer to have a zero-day exploit? Disregarding security patches, those two git trees are out-of-sync anyway. If I understand current state correctly, then whatever is pushed to GH must be pull to bpf manually. Other way around somewhat works. > > >> b) bpf is unreliable. > > > I mean an outage for hour or two and regular maintaince windows are > > fine but if site is unreachable for days without prior notice then it > > is unreliable in my book. > > I am unaware of it being unreachable for more than a Sunday afternoon to > Monday morning; and that instability with power was solved. I was also referring to other occurrences in the past. IIRC buildbot was sending emails to workers multiple times that build is failing and reason at the time was bpf server unreachability. > > >> before I propose some solution/policy/adjustment, I want to make sure > >> that I've heard all the issues. > > > I don't follow, you don't like the idea to use GitHub then why we > > encourage people to use it as tool for contributing to the project. > > github has lots of nice features. > > Maybe we should only use github --- certainly when I first proposed github, > many people were uncertain about it --- it was too new, and we were too > experienced with sourceforge coming and going to want to sign up for another > disaster. GitHub or something else, I will let this decision to you, core developers. All I am saying is that having to "master" trees is sub-optimal, confusing and adds needless work to people. Michal > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works| network architect > [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
