letsencrypt / pebble

0%

master: 8%

LAST BUILD ON BRANCH v2.0.2

branch: v2.0.2

CHANGE BRANCH

x

Reset

• v2.0.2
• cpu-repo-normalize
• master
• cpu-mention-non-default-ports
• v2.0.1
• cpu-no-pebble-client
• cpu-go12
• cpu-no-account-id-field-marshal
• cpu-no-clock-dep
• cpu-go-go-speed-racer
• test-cpu-go-go-speed-racer
• cpu-custom-redirect-status-code
• cpu-stricter-than-your-gradeschool-teacher
• v2.1.0
• v2.2.0
• cpu-use-latest-docker
• cpu-docker-use-go12
• v2.2.1
• v2.2.2
• cpu-fix-cname-clear
• cpu-mock-servfail
• cpu-go-1-13
• cpu-fix-keyrollover-err-check
• cpu-tls-one-three
• cpu-go-1-13-now
• cpu-pag-dir-and-nonce
• v2.3.0
• orders-not-deactivated
• rand-seed
• v2.3.1
• fix-ci
• dependabot/go_modules/github.com/miekg/dns-1.1.25
• challtestsrv-log-less
• main

Build # 1214

Build Type

push

travis-ci

Committed by jsha

Commit Message

fix dataraces, add -race install, add load-gen. (#232)

The `Authz()` method of the WFE was racey. First because it didn't lock the authorizations and orders it was working with. Second because the handling of displaying authorization challenges was working with `acme.Challenge` objects owned by `core.Challenge`'s that should have been locked for reading but were not. This mean the VA would datarace with the WFE when updating a validated challenge status.

To prevent future occurrences `travis.yml` is updated to install Pebble with the race detector enabled, and to run Pebble such that it will exit non-zero if a race is detected.

Since `Chisel2.py` is single threaded the Boulder `load-generator` is used for a short duration to drive concurrent request traffic. In practice before fixing the dataraces I found this would crash Pebble <30s.

Resolves https://github.com/letsencrypt/pebble/issues/230
Resolves https://github.com/letsencrypt/pebble/issues/228

Run Details

0 of 53 relevant lines covered (0.0%)

0.0 hits per line