“Modifying Expectations”

Talk about being slow… As a person with lots of hand problems (thanks grandma, thanks mom!), typing has become increasingly laborious over the years, yet this is one more story where the responsibility of the problem lies more in my head than anywhere else. But, hey, as long as my hands don’t hurt, can’t complain!!

The original goal of the project, to “Add Git protocol support to Wireshark” by improving the existing Git protocol dissector for requests tunneled through raw TCP, originally had 2 main tasks; to add HTTPS and SSH dissection support.

Upon starting the program in December it became evident that some fundamental parsing needed to be done first, not only for ease of reading and filtering, but also to help me get familiar with existing work, to help me define (and understand!) a road-map to follow, and of course, to get a sense of my speed (or lack of XD).

This part definitely took a lot longer than expected.

Building on existing work to complete the first MR (!1313, credits on previous post!) took me most of the 1st month itself! And although there were other things to contend with (Xmas, lots of reading and documentation to absorb, understanding said documentation and relating it to the actual code, find examples to focus on as opposed to falling down endless rabbit holes…), it was “the joy of discovery” (wink jrnieder!) and the persistence of moving forward towards a plan that kept me motivated.

This 2nd month, although still slower than I would’ve preferred, things feel like they’re falling faster into place.

Just today, and through careful and patient guidance from my mentor Emily, managed to finally do a cherry-pick/squash and actually understand the steps around it. Tears of joy!

Also, another MR with more output parsing is on the way, and that HTTPS support work that I’ve been so looking forward to (credits also on a previous post), is finally starting to happen in another commit. Not bad for my arthritic hands, huh? ^^

For the next half of the program, I’ll continue with pending items from issue #17093 relating to testing and documentation of current changes and then, hopefully, will get to work on adding SSH support.

Can’t wait!

“Think about your audience”

When I first saw Git’s and Wireshark’s joint project description for Outreachy, I immediately knew I wanted to get involved. As a junior developer, I’ve been using Git since the 1st year of my studies, and as a DNS privacy advocate, I’m familiar with research and articles that used Wireshark in their packet inspection, yet had never had the chance to work with Wireshark itself myself, other than the rare class exercises in my 2nd or 3rd year of Bachelor’s…

So What exactly are Git and Wireshark? And what am I trying to accomplish for this project?

Git goes beyond distributed version control; it’s one of the main open source projects you start working with as a developer. In my case, it gave me first contact with open source communities, and the most tangible proof, that “sharing” indeed “is caring”; that having access to other people’s work is good for me, for them (in the long run!), and, oh yes indeed, for the glorious soul of the internets!
Then, of course, you start running across things like squashing commits and cherry-picking changes, and your eyes might bleed a little… but when you start to overcome that, it really is worth it not only for becoming more experienced in maintaining your own (and your team’s) code but also for that great feeling of certainty that those changes that took you hours to write are safe and accessible somewhere. Even if you have no clear idea where, you know that they are!

And Wireshark goes well beyond packet dissection as well; a tool that creative and curious folks can modify to their liking to analyze and inspect Any type of packet transmitted over the network that they can think of, gaining lots of information as they do. As long as those curious folks can follow loads of examples of cool ways to parse and inspect information, and can picture how and what to dissect, they can write a dissector file for the protocol, send it upstream, and rejoice when the option for analyzing that protocol or type of packet becomes available for everyone.

And the intersection of both projects? We want to have fun with dissecting Git packets! And we want loads more information when we do!!

Starting with base functionality building on top of other member’s work shared in my previous post, we added parsing of the multiplexing (sideband) version in use (if any). Then we started work on parsing the specific version of the git protocol being used following up on MR 805, and, my favorite so far probably because of my privacy advocacy background, we started working on adding git protocol support for HTTPS by following up on a patch started (and shared) by Richard Sharpe (thanks Richard!).

  • Can we use Wireshark to differentiate traffic sent over HTTPS through port 443, be it Git packets, or encrypted DNS-over-HTTPS packets?
  • Can this be useful to Git?

These and other questions are what I’m hoping to contribute some answers to, but there’s for sure endless others; as tools used by developers, researchers, advocates, and students alike, the opportunities are endless as is your imagination. Alas I’m not a creative type!

So then, what are Your suggestions?

“Everybody struggles”

…and everybody overlooks things some times!

I had been intensely staring a dissector implementation of over a year ago, trying so hard to figure out why any of the changes I was writing were not showing up in any of the captured dumps and txts I was reviewing.

Thought I was missing something important in the data transfer, probably wasn’t sending my data to the right buffer defined in this file and it needed to be sent to a different file first, right?

Well, as my mentor (thanks Emily!) pointed out; “I was running the version that I didn’t rebuild”.

facepalm

So why was it confusing? When my second mentor (thanks jrnieder!) reassured me I was writing changes on the right file, it became evident I was missing something. I could blame it on the fact that after building Wireshark from source, 2 different versions of the software were installed; the regular version and the development version. I was running the regular version even though my changes were in the development version.

Can I blame my oversight on the documentation? Probably. Would I learn anything if I did? Not really. In hindsight, after the first few changes I wrote were not being reflected in the software, I should’ve asked my mentors to check on my work and why it wasn’t changing anything in the output, I should’ve gone back quicker to the documentation and made sure I wasn’t missing something. Hour’s would’ve been saved. Facepalms would’ve gone un-palmed… or, uhm, un-faced.

Will it happen again? Likely. But I’ll be faster next time, and the “I was running the version that I didn’t rebuild” money jar will be that much closer to have enough for a nice rewarding coffee. Or a full trip to Thailand if I keep getting the same thing messed up!!

Hello there!

I’m Joey from Costa Rica, Outreachy 2020 intern happily joining the Git team for the “Add Git protocol support to Wireshark” project.

As a self-learner in a constant search for improvement, Balance is one of my core values, where autonomy and guidance go hand in hand into Growth and Contribution, which are 2 of my other core values.

Being in IT since 2008, I look for opportunities that help me grow as a an engineer and that enable me to provide meaningful contributions to the open source community.

Outreachy is an exciting program through which I hope to do just that; become a better programmer and give back through upstream contributions.

Very happy to start this journey today!

Create your website at WordPress.com
Get started