f3912188e1
After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242 |
||
---|---|---|
.github/workflows | ||
.vscode | ||
CLI | ||
cmd | ||
docs | ||
E2E | ||
internal | ||
MOBILE | ||
pkg | ||
QA | ||
script | ||
testdata | ||
.eslintrc.json | ||
.gitignore | ||
CODE_OF_CONDUCT.md | ||
CODEOWNERS | ||
CONTRIBUTING.md | ||
go.mod | ||
go.sum | ||
LICENSE | ||
mk | ||
NOTICE.md | ||
PULL_REQUEST_TEMPLATE.md | ||
Readme.md | ||
testjafar.bash |
OONI Probe Client Library and CLI
The Open Observatory of Network Interference (OONI) is a non-profit free software project that aims to empower decentralized efforts in documenting Internet censorship around the world.
This repository contains core OONI tools written in Go:
-
the CLI client (cmd/ooniprobe);
-
the test helper server (internal/cmd/oohelperd);
-
the mobile library (pkg/oonimkall);
-
and all the related support packages (inside internal).
Every top-level directory in this repository contains an explanatory README file. You
may also notice that some internal packages live under internal/engine
while most others are top-level. This is part of a long-standing refactoring started when we merged
https://github.com/ooni/probe-engine into this repository. We'll slowly
ensure that all packages inside engine
are moved out of it and inside internal
.
Semantic versioning policy
The mobile library is a public package for technical reasons. Go mobile tools require
a public package to build from. Yet, we don't consider API breakages happening in
such a package to be sufficient to bump our major version number. For us, the mobile
library is just a mean to implement OONI Probe Android and OONI Probe iOS. We'll
only bump the major version number if we change ./cmd/ooniprobe
's CLI.
License
SPDX-License-Identifier: GPL-3.0-or-later
User setup
Please, follow the instructions at ooni.org/install/cli
to install ooniprobe
. If we do not support your use case, please let us know. Once
ooniprobe
is installed, try ooniprobe help
to get interactive help.
Reporting issues
Report issues at github.com/ooni/probe.
Please, make sure you add the ooni/probe-cli
label.
Build instructions
ooniprobe
Be sure you have golang 1.18.2 and a C compiler (Mingw-w64 for Windows). You can build using:
go build -v ./cmd/ooniprobe
This will generate a binary called ooniprobe
in the current directory.
Android bindings
Make sure you have GNU make installed, then run:
./mk ./MOBILE/android
to build bindings for Android. (Add OONI_PSIPHON_TAGS=""
if you
cannot clone private repositories in the https://github.com/ooni namespace.)
The generated bindings are (manually) pushed to the Maven Central package repository. The instructions explaining how to integrate these bindings are published along with the release notes.
iOS bindings
Make sure you have GNU make installed, then run:
./mk ./MOBILE/ios
to build bindings for iOS. (Add OONI_PSIPHON_TAGS=""
if you
cannot clone private repositories in the https://github.com/ooni namespace.)
The generated bindings are (manually) added to GitHub releases. The instructions explaining how to integrate these bindings are published along with the release notes.
miniooni
Miniooni is the experimental OONI client used for research. Compile using:
go build -v ./internal/cmd/miniooni
This will generate a binary called miniooni
in the current directory.
oohelperd
Oohelperd is the test helper server. Compile using:
go build -v ./internal/cmd/oohelperd
This will generate a binary called oohelperd
in the current directory.
Specifications
Every nettest (aka experiment) implemented in this repository has a companion spec in ooni/spec.
Contributing
Please, see CONTRIBUTING.md.
Updating dependencies
go get -u -v -d ./... && go mod tidy
Releasing
Create an issue according to the routine release template and perform any item inside the check-list.
We build releases using ./mk
, which requires GNU make. Try
the ./mk help|less
command for detailed usage.