Wireshark

Code review: https://code.wireshark.org/review/#/dashboard/self

Read-only mirror: https://github.com/wireshark/wireshark

We use Git, which does all of these. Prior to that we used Subversion and prior to that we used CVS.

Git commits are built continuously using Buildbot: https://buildbot.wireshark.org/wireshark-master/waterfall

Automated builds, including source tarballs, Windows installers, and macOS installers are available at https://www.wireshark.org/download/automated/

We use Git.

https://wiki.wireshark.org/Development/ReleaseNumbers

We use Git tags.

Release notes are tracked in an AsciiDoc document in the sources. Notes for each release are sent as part of an announcement email and posted on the web site.

https://www.wireshark.org/docs/relnotes/ https://www.wireshark.org/lists/wireshark-announce/201607/msg00001.html

We request and report CVEs for each vulnerability that we or others find. These are included in the release notes and as separate advisories.

https://bugs.wireshark.org/

https://bugs.wireshark.org/

We try to triage and fix bugs as they come in. We also have yearly bug sprints at our conference (Sharkfest).

Most of these are addressed within a few days of posting.

Bugs are available at https://bugs.wireshark.org

Instructions are at the bottom of https://www.wireshark.org/security/

This is noted at the bottom of https://www.wireshark.org/security/

We typically respond within one or two days.

https://buildbot.wireshark.org/wireshark-master/waterfall

We support building with GNU Autotools, CMake, GCC, Clang, and Visual C++.

This is the case for Linux, macOS and other Unix-like systems. Building on Windows requires Visual C++.

We include a test suite in the "test" directory of the sources.

The test suite is a set of bash scripts.

Tests are run continuously by Buildbot.

We do this for the CLI as noted above, but the policy is informal.

Our test directory has had nearly 270 commits in the past 6 months (Mar 22 to Aug 8, 2016)

The master branch has "warnings as errors" compiler flags enabled for GCC, Clang, and Visual C++. We also use Coverity, Clang's scan-build, and the Visual Studio analyzer to look for problems.

We do this continuously.

We enable as many compiler warnings as is practical.

Several of our developers are experienced with secure software design. We also cover security in our documentation and in presentations at Sharkfest.

Due to the size and age of our code base, our developers routinely run into these sorts of errors.

We use common libraries such as GNUTLS where we can.

We have had to implement our own 802.11 decryption, but that's the primary purpose of the software.

All of our cryptography code is FLOSS, either our own or separate libraries.

Wireshark itself doesn't rely on cryptography as it is commonly used. Our purpose is to show users network traffic. In some cases we can decrypt the traffic. In some of those cases the mechanisms and keylengths are quite insecure.

Wireshark itself doesn't rely on cryptography as it is commonly used. Our purpose is to show users network traffic. In some cases we can decrypt the traffic. In some of those cases the mechanisms and keylengths are quite insecure.

Wireshark itself doesn't rely on cryptography as it is commonly used. Our purpose is to show users network traffic. In some cases we can decrypt the traffic. In some of those cases the mechanisms and keylengths are quite insecure.

Wireshark itself doesn't rely on cryptography as it is commonly used. Our purpose is to show users network traffic. In some cases we can decrypt the traffic. In some of those cases the mechanisms and keylengths are quite insecure.

Wireshark doesn't depend on any sort of authentication.

Wireshark itself doesn't rely on cryptography as it is commonly used. Our purpose is to show users network traffic. In some cases we can decrypt the traffic. In some of those cases the mechanisms and keylengths are quite insecure.

For the servers that we control, downloads are available over HTTPS.

Release announcements are signed using GPG. The signed content includes SHA256, RMD160, SHA1, and MD5 checksums for each of our release packages.

We make every effort to do so.

We try to maintain good operational security.

We use Coverity, Clang's scan-build, and the Visual Studio static analyzer.

I believe Coverity does this.

We look for and fix them as they are reported.

We try to run analysis at least daily, if not for each build. Coverity restricts us to twice a week.

We fuzz test and run our code under Valgrind continuously.

One of our tools (editcap) can introduce random errors into a packet capture. We use it for continuous fuzzing. Other organizations use other tools such as AFL to test our code and report errors to us.

We fuzz under Valgrind and under ASAN.

New bug reports are automatically created for fuzz failures. We try to fix new reports as quickly as possible.