Closed bcook-r7 closed 9 years ago
Is it worth considering using subrepos for the libpcap stuff?
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/150/ Test PASSED.
If we're storing the tarballs in the subrepo, sure! I hesitated for this because this tarball is actually smaller than other blobs we already have checked in, e.g. the static windows openssl libs.
Automake/conf projects do not fare well being built straight from a git checkout (libpcap especially since they check in generated files) due to timestamp being semi-unpredictable. This will cause random failures in continuous integration systems when the git repo checkout crosses a second threshold at just the wrong moment. Can you tell I've debugged this problem before :) ?
But, a meterpreter-deps submodule would be a good idea! We could move the checked-in Windows .libs and random support executables there as well. Then when we're ready to do the final squash of the sources, it won't have to have any old binaries in it at all in the history.
This sounds relatively sane! I approve :)
I'm still in the process of getting that new repo up, had to learn the right people to poke to get the privileges right. Should hopefully have it tomorrow.
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/151/ Test PASSED.
Hopefully its still relatively sane :) The initial 'dependency' repo is at https://github.com/rapid7/meterpreter-deps.
There is a sneaky openssl update here just to unbreak the build temporarily, since the openssl mirrors seem to have rearranged themselves over the weekend. My plan is to send a separate SSL library update tomorrow, maybe this can go in after?
Closing this for a more general 'update libs' PR. Its currently not possible to test libpcap update in isolation with a libssl update.
I am working on automating POSIX meterpreter builds, and one step is removing the requirement to download files from external sites during the build process. So, this incorporates the latest stable libpcap source and updates the patches as needed.
The Makefile also moves (@wvu-r7 was amused that Makefile.pcap wasn't actually a pcap file :) and simplifies a little build foo.
I updated and got the 64-bit kernel + 32-bit userspace TPACKET v1 patch merged upstream, but its not in a release yet, so the patch is still needed. See https://github.com/the-tcpdump-group/libpcap/pull/421
Verification steps
Here is a session that I tested with: