Time to wrap up!

As week 12 of this learning journey comes to a close, I couldn’t be happier with the areas I got to practice and improve on.

From fears when using git rebase to learning how impatience can be a positive thing, my Git mentors helped me work on both tech and soft skills, while the Wireshark team was a reliable source of technical knowledge and feedback.

Thanks to jrnieder‘s and nasamuffin‘s consistent encouragement and support, all the guidance from Pascal and the Wireshark team (thanks Richard and Peter!), and all the practice I got (from reinforcing fundamentals in C to writing test cases in Python), I am now more confident in finding ways to sustain my contributions in the open source community, contributions that have now also strengthened in usefulness and depth.

After improving the base functionality of the Git protocol support in Wireshark, as well as adding the basis for HTTPS support, starting the testing suite in Wireshark for the Git protocol, and improving a few documentation items in both Wireshark and Git, there’s still lots that need to be done. The upcoming Outreachy intern that joins this project will hopefully have a clearer roadmap, and lots of fun in tackling any of these:

  • Adding SSH-connection support
  • Adding session-id tracking for stateful connections
  • Following up on #17093 and improving everything!!

I hope they take a look at my blog and realize what a treat is coming their way!! And although there’s always stressful and/or difficult moments, determination and patience will get them through everything. Specially with such dedicated guidance and attention from the Git team!

And hopefully, the core values they identify in their 1st blog post will serve them as beacon to keep going, similarly to how it was for me;
Looking back to my 1st post 3 months ago, striving for Balance between patience and impatience, and between autonomy and guidance, played a major role in the achieved Growth for the type and quality of Contribution that stands as my ultimate goal. I’m sure determination and persistence will likely assist the next intern too, and under the patient guidance of the Git mentors, I can’t wait to see what else will improve and change in this project, I’ll be sure to take a look!

And, likewise, visit my about.me page and keep in touch!

Career Goals

… or for coffee

How to remain an active community member after Outreachy? This is the question I find myself asking in my head more and more often these days. Open Source contributions can be as flexible or as time-consuming as you let them be, but once you’ve established initial rapport and set a pace, how best to keep that up or modify it when your availability changes?

Although contributing as a volunteer is at the core of what Open Source represents, I’ve come to the idea that more formal relationships tend to give that extra bit of solidity a newcomer might need; more advanced contributors seem to find their way and their pace a lot more easily -and with less formal guidance required- than those first trying to join and/or with less experience.

So searching for a follow-up part-time internship (or junior dev position), parallel to some well-invested volunteering, seems to me the best way to go! Ideally a place where my experience in advocacy, webinars and panels, article writing, and SDO (Standards Development Organizations) involvement (ICANN, IETF, W3C), can be of use to the team.

My main motivation – a drive to work on my skills as I contribute to the maintenance and development of Open Sourced software, keeps me daydreaming with the idea of being able to remain in the communities that will one day see me as a main contributor.

Being privacy-oriented, certified in CCNA and Linux+, interested in DNS (previously involved in BIND as remote Jr. Dev, project written in C), OS and Browsers, and after having the great experience of working with Wireshark (written mostly in C) and Git (what do you know, also mostly written in C!) remotely through Outreachy, I’d love to remain part of a community that keeps me close to these areas with their projects:

Projects written in C -I can now implement pointers and references without panic and know about vtables (tnx jrnieder!)! Projects in C++ -I’m so looking forward to practicing with variadic expressions! Projects in Java -already miss playing with DOM after my graduation thesis project (fullstack web interface for data analysis); or also projects that use languages/tools I’m not too familiar with yet, such as Python and ML!

For this purpose, I think that having studied in China for 6 years, as well as lived in different countries in 3 continents, and speaking 3 languages rather fluently (ES-EN-CN), has provided me with a good perspective for clear communication with team members from different regions and time zones, which, given how these communities are usually very distributed across the globe, makes me hopeful (and capable!) of smooth transitions.

As I continue writing this post, I realize it’s a massive Cover Letter, but hey, I’m nothing if not compliant! And gotta do what needs to be done, which in this case, is to follow the lead of a very experienced and awesome program such as Outreachy. So if you’re still reading up to here, thank the organizers for encouraging us to give all these details; as a reserved female dev from Costa Rica, I don’t usually talk this much about myself! But if you’ve got something for me to listen, in English, Spanish, Chinese, or basic French (ehem), send me a line and I’ll (remotely) be there!

Also, feel free to visit my about.me page ^^

Thank you for reading!

“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 with WordPress.com
Get started