Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
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 Michal's patches for 4.4.0 from the fc19 srpm, but if you have "official" backports, even better. The branch also has fixes for print-udp.c and print-ppp.c. Are these security-sensitive? Should I pick them up as well? If so, do they have CVE identifiers? Thanks, -- 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 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. Yes, please. -- 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?
Guy Harris 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, with the aid of some time spent > with a porcelain kiln, so I can probably spend a little more time > firing the clay and glaze, if necessary, if libpcap/tcpdump switches to > using GitHub. :-)) What I'm hearing is that using git is confusing, because it allows tcpdump to exist on more than one person's laptop at a time. So I guess we should remove it from git, and go back to CVS? -- ] 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 Mon, Nov 24, 2014 at 09:22:23AM -0500, Michael Richardson wrote: > > Guy Harris 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, with the aid of some time spent > > with a porcelain kiln, so I can probably spend a little more time > > firing the clay and glaze, if necessary, if libpcap/tcpdump switches to > > using GitHub. :-)) > > What I'm hearing is that using git is confusing, because it allows tcpdump > to exist on more than one person's laptop at a time. 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. There are two options, make bpf.tcpdump.org sync with GitHub after every commit or do development on GitHub only. Or the other way around, I don't care. But given questionable reliability of bpf.tcpdump.org (IIRC there were numerous outages for longer time periods in the past) I'd prefer GitHub. I don't care what people do in their private repos, but having two "main" repos for tcpdump/libpcap is confusing and doesn't bring any benefit whatsoever. Or am I missing some obvious benefit of current solution. Michal > > So I guess we should remove it from git, and go back to CVS? > > -- > ] 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?
Michal Sekletar wrote: >> Guy Harris 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, with the aid of some time spent > with a porcelain kiln, >> so I can probably spend a little more time > firing the clay and >> glaze, if necessary, if libpcap/tcpdump switches to > using >> GitHub. :-)) >> >> What I'm hearing is that using git is confusing, because it allows >> tcpdump to exist on more than one person's laptop at a time. > 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 developers' forget to push, and it stays on their laptop. How is this any different? > There are two options, make bpf.tcpdump.org sync with GitHub after > every commit or do development on GitHub only. Or the other way around, It pushes every single night: it seems that it failed to push a new branch. bpf.tcpdump.org has issues on occasion --- many people, including some distros, are hesistant about relying on github. I think you are exagerating how often bpf.tcpdump.org has been unavailable. I don't really want to put *all* my eggs on github. > I don't care. But given questionable reliability of bpf.tcpdump.org > (IIRC there were numerous outages for longer time periods in the past) There were a few outages from Sunday night to Monday morning. > I don't care what people do in their private repos, but having two > "main" repos for tcpdump/libpcap is confusing and doesn't bring any > benefit whatsoever. Or am I missing some obvious benefit of current > solution. Yeah, when github gets p0wned again, or goes offline again, or their database gets confused about which fork is the lead and which fork is the "child"... [for a few months, the "master" repo you speak of, was listed as a child of some random other user] -- ] 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 Nov 24, 2014, at 1:04 AM, Romain Francoise 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 Michal's patches for 4.4.0 from the fc19 srpm, but if > you have "official" backports, even better. > > The branch also has fixes for print-udp.c and print-ppp.c. Are these > security-sensitive? print-udp.c just makes the UDP dissector take the length field in the UDP header into account; I don't think it fixes security issues, but it does handle the "arguably this should never happen" case where the length is shorter than the IP payload. (So was RFC 768 written before they'd decided to put a total length field into the IP header, or something such as that? The length field doesn't serve any obvious purpose I can see, unless the intent was to run UDP atop something other than IPv4 as defined in RFC 791.) print-ppp.c fixes a case where the un-escaping code could overrun a buffer and crash, so I'd call that one security-sensitive. > Should I pick them up as well? The print-ppp.c one, yes. The print-udp.c one is your choice. > If so, do they have CVE identifiers? No. Michal (Zalewski), that's a fix to the issue you reported; should it get a CVE? ___ 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 Nov 24, 2014, at 10:25 AM, Michael Richardson wrote: > Michal Sekletar 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 developers' forget to push, and it stays on > their laptop. How is this any different? What I have on my laptop isn't official - and isn't available to anybody else. Think of it as a collection of temporary personal forks, each of which will be eliminated when I either abandon it by deleting the tree or push it to bpf.tcpdump.org. It has nothing to do with official libpcap/tcpdump. For bpf.tcpdump.org and GitHub, however, they're both publicly available; if somebody wants to know what's in the official repository, where should they look? >> There are two options, make bpf.tcpdump.org sync with GitHub after >> every commit or do development on GitHub only. Or the other way around, > > It pushes every single night: it seems that it failed to push a new branch. New branch? The trunk on GitHub doesn't, for example, show my checkins for the CVEs in question, unless I'm missing something. That wasn't on a new branch. And changes made on GitHub - such as the changes that result from merging pull requests on GitHub - require manual pulling to get them onto bpf.tcpdump.org. ___ 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?
>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 project is hosted does not matter as much as if it has working backups (in this scope git provides a very convenient means to backup its own repositories). Hosting hardware and software just fail from time to time, whether the infrastructure is your own or sponsored by somebody else. 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 use both GitHub and bpf.tcpdump.org, but with one important change. The changes should normally be committed to GitHub instance only, as that's currently the environment that is most convenient for contributors of varying levels of experience. Then bpf.tcpdump.org would not experience auto-merging difficulties any more and with the two repositories being 100% identical the read-only choice between the two will become again purely theoretical and a matter of taste. A weekly backup of bpf.tcpdump.org on top of that will bring a complete peace of mind. Does that sound reasonable? -- 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 Nov 24, 2014, at 1:24 PM, Denis Ovsienko 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 use > both GitHub and bpf.tcpdump.org, but with one important change. The changes > should normally be committed to GitHub instance only, as that's currently the > environment that is most convenient for contributors of varying levels of > experience. Then bpf.tcpdump.org would not experience auto-merging > difficulties any more and with the two repositories being 100% identical What mechanism would be used to ensure that any change committed to GitHub will be pushed/pulled to bpf.tcpdump.org in a timely fashion when possible (with catchup pushes/pulls if it becomes impossible for a while due to some problem)? > the read-only choice between the two will become again purely theoretical and > a matter of taste. But doesn't "The changes should normally be committed to GitHub instance only" mean that the bpf.tcpdump.org repository should be treated as read-only for contributors - presumably including core contributors? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] bpf.tcpdump.org vs github
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) this CVE process has been botched (I said this, and I take responsability for this) before I propose some solution/policy/adjustment, I want to make sure that I've heard all the issues. -- ] 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 Nov 24, 2014, at 7:01 PM, 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? > b) bpf is unreliable. > c) there is some issue (please explain more) with bpf.tcpdump.org > experiencing auto-merging difficulties. > d) this CVE process has been botched (I said this, and I take > responsability for this) e) for whatever reason, changes being checked into bpf.tcpdump.org haven't recently been getting pushed to/pulled by GitHub. If that were fixed, that might help with issue a). There's also f) fixes checked into GitHub (including pull requests) have to be manually pulled to bpf.tcpdump.org, and the people checking them in aren't always doing that at the time they check fixes in and fixing that might also help with issue a). I don't know what the issues are in c), so I don't know whether that'd help there. I'll let others address b). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
