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 |
||
|---|---|---|
| .. | ||
| dash | ||
| dnscheck | ||
| dnsping | ||
| example | ||
| fbmessenger | ||
| hhfm | ||
| hirl | ||
| httphostheader | ||
| ndt7 | ||
| psiphon | ||
| quicping | ||
| riseupvpn | ||
| run | ||
| signal | ||
| simplequicping | ||
| sniblocking | ||
| stunreachability | ||
| tcpping | ||
| telegram | ||
| tlsping | ||
| tlstool | ||
| tor | ||
| torsf | ||
| urlgetter | ||
| vanillator | ||
| webconnectivity | ||
| README.md | ||
Directory github.com/ooni/probe-engine/experiment
This directory contains the implementation of all the supported experiments, one for each directory. The OONI spec repository contains a description of all the specified experiments.
Note that in the OONI spec repository experiments are called nettests. Originally, they were also called nettests here but that created confusion with nettests in ooni/probe-cli. Therefore, we now use the term experiment to indicate the implementation and the term nettest to indicate the user facing view of such implementation.
Note that some experiments implemented here are not part of
the OONI specification. For example, the urlgetter
experiment is not in the OONI spec repository. The reason why
this happens is that urlgetter is an experiment "library" that
other experiments use to implement their functionality.
Likewise, the example experiment is a minimal experiment that does nothing and you could use to bootstrap the implementation of a new experiment. Of course, this experiment is not part of the OONI specification.