rust-pcap / pcap

Rust language pcap library
Apache License 2.0
632 stars 144 forks source link

New maintainer-ship possibility / Future plans for `pcap` crate #96

Closed sekineh closed 2 years ago

sekineh commented 6 years ago

First, I like this crate very much and I'd like to say thank you to the author @ebfull .

Unfortunately, the development of the crate is rather inactive since the last Aug 2017. It's about one year. The interesting PRs seem exist but they were never merged nor explicitly rejected (closed). My experience is that I have encountered a trouble building on Windows 64 bit, so I must use the folked version instead of the crates.io version:

Possible organizational improvement I could think of is:

The features I'd like to see in near future includes.

Any ideas?

drrlvn commented 5 years ago

It's been another year and it would be great to see this project maintained again.

ebfull commented 4 years ago

I'd be happy to transfer ownership of this crate to someone else who is more interested in maintaining it.

sekineh commented 4 years ago

It looks things changed a bit since this issue was reported.

So, if rustcap and pcap-sys ecosystem would grow in a good direction, migrating to their crates might be a possible option in a near future.

Wojtek242 commented 4 years ago

I would be interested in taking over maintainership of this crate. Sharing the responsibility with others who are also willing to participate. I think it's pretty clear there is interest in this crate and it's still the first search engine hit for "rust pcap".

Over the last week I've been working on my own fork to bring this code base up to date: https://github.com/Wojtek242/pcap:

I've tried to avoid making any subjective/opinonated decisions so far. The changes above reflect issues that have been raised against this crate over the last few years and that I wanted fixed for myself. There are still some questions to answer going forward, such as what is the oldest version of libpcap that is to be supported. Issue #68 suggested to go from 0.8. When I tried to do that I realised much of the existing API depends on library calls introduced by version 1.0.0 so I decided to go from 1.0.0 instead. However, 1.0.0 is from 2008 and perhaps it would just be easier to not bother going back that far. For example, immediate mode support would be much easier if it went only from 1.5.0 (which was in 2013). Then again, WinPcap is based on 1.0.0.

I've had a look at rustcap and pcap-sys, but it appears that after that one PR six months ago it went quiet. It seems that the maintainers have little interest in having anything beyond the FFI bindings. The crates.io also has not been updated. Nothing wrong with that, but I do find the Rust API offered by this crate quite neat. Great work @ebfull!

I'm going to assume @ebfull has no interest in maintaining this crate (though do let me know if anything changed since last year) so I'd be happy to manage the crate on crates.io. Not sure what to do about repositories though. Should I just keep working on the fork? Should an GitHub org be created? Something else?

jmmk commented 4 years ago

I've had a look at rustcap and pcap-sys, but it appears that after that one PR six months ago it went quiet. It seems that the maintainers have little interest in having anything beyond the FFI bindings.

I'm not actively using it, and it's not really clear that anyone is (the person who made that PR never followed up on my suggestion to take over ownership). I'd be happy to update the README to point to a well-maintained solution

ilya-epifanov commented 4 years ago

@jmmk FYI, I'm still using it in production. I can passively maintain the crate no problem. You can add myself and @Wojtek242 as admins to reduce the bus factor.

jmmk commented 4 years ago

@ilya-epifanov Ok good to know. I have added @Wojtek242 as a contributor and I see you listed now as an owner on crates.io so hopefully you have the full ability to manage it.

Let me know if you would like to transfer the git repo.

Wojtek242 commented 4 years ago

Sorry for the confusion, but I meant that I'm not interested in rustcap and the related pcap-sys :) That crate seems to only provide the FFI bindings, whereas this crate pcap provides a safe Rust interface on top as well. I'm only interested in the pcap crate as I do want this safe interface.

jmmk commented 4 years ago

@Wojtek242 rustcap has limited usefulness. I wrapped a very small part of the API to accomplish what I was doing at the time. pcap-sys is maybe somewhat more useful in that it contains a (hopefully) repeatable way to generate complete libpcap bindings.

I agree that the pcap crate takes a nice approach and in general is more ergonomic and useful. I don't think they are necessarily exclusive however. pcap-sys for example could be used in place of the raw module here. Potentially there could be both a low-level API and a high-level API as part of the same crate instead of dividing efforts.

Anyway, I'll leave those decision up to people who actually plan to use/maintain these solutions, but I want you to have the option to change things as needed to suit your use case

kpcyrd commented 4 years ago

I think keeping the pcap-sys crate around is a good idea, I ran into bugs with the abstractions in the pcap crate and had to write my own, so I'm depending on it directly.

sekineh commented 4 years ago

@Wojtek242

I would be interested in taking over maintainership of this crate. Sharing the responsibility with others who are also willing to participate. I think it's pretty clear there is interest in this crate and it's still the first search engine hit for "rust pcap".

I think I can help the maintenance of this crate. I'm especially interested in windows support and CI. (I also have my own folk of pcap with Windows CI, but never sent PR.)

I'm going to assume @ebfull has no interest in maintaining this crate (though do let me know if anything changed since last year) so I'd be happy to manage the crate on crates.io. Not sure what to do about repositories though. Should I just keep working on the fork? Should an GitHub org be created? Something else?

I vote for a GitHub org like rust-packet, rust-capture, or alike. (Similar to rust-embedded. I first thought pcap-rs is the good org name, but it appeared to be taken by another crate name.)

sekineh commented 4 years ago

I think keeping the pcap-sys crate around is a good idea, I ran into bugs with the abstractions in the pcap crate and had to write my own, so I'm depending on it directly.

Another option might be to add pcap-raw feature which exposes raw module of this crate. Separate repo for -sys is cleaner setup, but it might duplicate work on both repos.

Wojtek242 commented 4 years ago

I agree that the pcap crate takes a nice approach and in general is more ergonomic and useful. I don't think they are necessarily exclusive however. pcap-sys for example could be used in place of the raw module here. Potentially there could be both a low-level API and a high-level API as part of the same crate instead of dividing efforts.

I agree they are not exclusive. Both crates might be useful and they could probably at some point in the future interact in the way you describe.

Anyway, I'll leave those decision up to people who actually plan to use/maintain these solutions, but I want you to have the option to change things as needed to suit your use case

That's a good point

Wojtek242 commented 4 years ago

I think I can help the maintenance of this crate. I'm especially interested in windows support and CI. (I also have my own folk of pcap with Windows CI, but never sent PR.)

That would be great. Whilst I made an attempt to get the Windows builds and tests working, I don't actually do dev on Windows. This would be a very complementary setup.

So now, we just need to wait for @ebfull and see what he thinks. If he wants to pass maintainership it would be best if we could also keep this repository with all the issues and PRs, but moved to a github org.

I vote for a GitHub org like rust-packet, rust-capture, or alike. (Similar to rust-embedded. I first thought pcap-rs is the good org name, but it appeared to be taken by another crate name.)

rust-pcap?

sekineh commented 4 years ago

The feasible steps I see are:

  1. Give commit right of ebfull/pcap to @Wojtek242 and @sekineh if @ebfull would like :-) 1-1. @Wojtek242 and @sekineh will submit code change as a PR, one by one. 1-2. @Wojtek242 and @sekineh will review PRs each other. 1-3. Eventually, other contributors will come. 1-4. Release new version of the crate by @ebfull or team.
  2. Working on ebfull/pcap repository may limit bandwidth (ex. relying on @ebfull for crate release and CI setting changes).
    2-1. In that case, move to organization, like rust-pcap/pcap.

What do you whink? @ebfull and @Wojtek242

Wojtek242 commented 4 years ago

I'm happy with either. I like the idea of splitting ownership and reviewing each other. Solution 2 would be better if @ebfull doesn't want to maintain the project anymore though, but I'm fine with solution 1 as well.

Wojtek242 commented 4 years ago

@sekineh, I got in touch with @ebfull and now we've been added as contributors to the project so we should decide what our next steps should be before we close this issue.

There are two things we should do:

  1. Work through existing PRs and respond/address/close them as appropriate. The code on my fork will address a few of the issues (tokio update, travis fix, etc) so I will submit a few PRs from that fork. Then we can go through the remaining issues.
  2. Decide where this repository should live. Short-term it can remain where it is. I guess there may be some reasons to move it to an org though like rust-pcap so that we have full access to settings (CI might require a move). If so, we should just set up the org and have the repo moved.

I'll start by preparing the PRs and let @sekineh review them. In the mean-time we can think about where this repo should live.

Following these changes we might as well go straight away and release 0.8.0 before figuring out what next.

srikwit commented 4 years ago

Looking forward to your release.

sekineh commented 4 years ago

@Wojtek242 your plan looks good to me. Let's start reviewing existing PRs and yours. @ebfull Thanks for the invitation!

lambdaiv commented 2 years ago

Since this issue was last update a while ago, has there been any momentum in the future plans for this crate or maintainer-ship?

Stargateur commented 2 years ago

@0b00001101 so far Wojtek242 have done a lot of work for the crate, I also want to help but I know little on tokio internal needed so I'm a little limited to the help I can give, but it's on my todo list since I use this in production. But I have not a lot of time left for this currently.

Wojtek242 commented 2 years ago

@0b00001101 yes, I'm maintaining the crate right now. I check in roughly once a month to go through PRs and issues as that seems to match the average level of activity. If you have ideas/want to contribute that's more than welcome. I maintain this crate in my spare time so it always takes a back seat to my day job which does keep me busy.

Wojtek242 commented 2 years ago

So, I finally hit a snag with ownership in that I cannot modify the settings for GitHub pages to publish code coverage reports :-). Therefore, I guess it's time to follow up with a suggestion that has been thrown some time ago in this thread

I vote for a GitHub org like rust-packet, rust-capture, or alike. (Similar to rust-embedded. I first thought pcap-rs is the good org name, but it appeared to be taken by another crate name.)

@ebfull, could you transfer ownership to the new GitHub organization I created rust-pcap? Also let me know if you would like to added as member/owner of that organization.

For everybody else in this thread. I'm happy to add any contributors so far as a member so just let me know. @sekineh, in particular, let me know if you would like to be added as owner.

Edit: for anybody that's curious I have the current code coverage report on my fork at https://wojtek242.github.io/pcap/. Coverage is pretty poor so I was going for publishing the code coverage and then work on testing.

sekineh commented 2 years ago

@Wojtek242 thanks for the work you’ve done. I’d be happy to be included as an owner in the new org though I’m not confident that I can use my time enough for the oss work.

Wojtek242 commented 2 years ago

Repo is now in new org closing issue.

@sekineh - in that case, I'll leave the owners as is for now. If you would like to be added to the owners at any point just send me a message saying that you explicitly would like to be added when you feel like it.