0317420398
I am currently working on https://github.com/ooni/probe-engine/issues/725 with an eye on https://github.com/ooni/probe/issues/1507. While approaching these issues, it seems that the `netx` codebase could use some consolidation (_coagula_) and some splitting (_solve_). The general idea of these changes is that I want to arrive to the situation where we have (1) a `New` factory method for each package under `netx` for which it makes sense (e.g., `dialer.New`, `tlsdialer.New`, `httptransport.New`), (2) a separate `Config` structure per package (e.g., `dialer.Config`) rather than having all the possible config into the same structure (3) part of the `urlgetter` code (and namely the low-level part) moved into the `netx` package. (See https://github.com/ooni/probe/issues/1591.) There is too much bureaucracy around writing a new experiment. Much of this bureaucracy will go (it seems) if we do what I have said above. After that, we will end up that you run tests by using the top-level `netx` package. (In any case, I am not of course 100% sure about all the changes that will come after, but this comment seems enough to set a direction.) These are the changes in this pull request: * refactor(netx): extract tlsdialer from dialer We want these two packages to be separate. Dialer was doing too much before. Separating TLS dialing code into a separate package allows us to have a `tlsdialer.New` factory that clearly conveys the meaning. Also, this would allow us to much more clearly separate configuration and simplify reasoning on what each factory does. * refactor(engine): move `tlsx` package inside `netx` and merge the `gocertifi` package inside it It would be tempting to merge everything inside `tlsdialer` but the reality is that also the `quicdialer` package needs to use the same code, therefore, it seems more tidy to actually have some tls extensions in `netx`. |
||
|---|---|---|
| .github/workflows | ||
| .vscode | ||
| CLI | ||
| cmd | ||
| debian | ||
| docs | ||
| E2E | ||
| internal | ||
| MOBILE | ||
| pkg | ||
| QA | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE.md | ||
| mk | ||
| Readme.md | ||
| testjafar.bash | ||
OONI Probe Client Library and CLI
The next generation OONI Probe: client library and Command Line Interface.
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
Please, report issues with this codebase at github.com/ooni/probe.
Please, make sure you tag such issues using the ooni/probe-cli label.
Repository organization
Every top-level directory contains an explanatory README file.
OONIProbe
Be sure you have golang >= 1.16 and a C compiler (when developing for Windows, you need Mingw-w64 installed). 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 android
Builds 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 ios
Builds 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.
Updating dependencies
go get -u -v ./... && 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.