sample_laplace_distribution should produce a valid result on 0.0

Destroying the signal with probability 1 in 2^-53^ isn't a great idea. Let's pick a sensible double value, and pass it through the function instead.

I suggest 2^-54^, but it really doesn't matter exactly what value we use, as long as it produces valid results, because the probability is so low.

Introduced in 45bc5a07

changed milestone to %Tor: unspecified in legacy/trac

added 026-backport-maybe in Legacy / Trac 031-unreached-backport in Legacy / Trac 034-removed-20180328 in Legacy / Trac 034-triage-20180328 in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac parent::25263 in Legacy / Trac points::0.5 in Legacy / Trac priority::medium in Legacy / Trac security-low in Legacy / Trac severity::normal in Legacy / Trac sponsor::Q in Legacy / Trac status::new in Legacy / Trac tor-relay in Legacy / Trac type::defect in Legacy / Trac version::tor 0.2.6.3-alpha in Legacy / Trac labels

Trac:
Keywords: security-low, 027-backport-maybe deleted, N/A added

I'll do these in 0.3.2, some of them are security-low.

Trac:
Status: new to assigned
Owner: N/A to teor

Turns out that the exact value of the signal is revealed, because it's added to INT64_MIN. That's a security issue.

Trac:
Keywords: N/A deleted, security-low added

Trac:
Sponsor: N/A to SponsorQ

We're still working out the best way to do this in the PrivCount in Tor spec. Let's revisit this issue when that's been reviewed on tor-dev@.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: 0.3.3.x-final

We should revise or close these tickets based on Appendix C in the latest privcount-shamir spec:

https://github.com/teor2345/privcount_shamir/blob/noise-limits/doc/xxx-privcount-with-shamir.txt

The good news is that we probably don't need to care about extreme values or binning, because properly implemented noise has known limits, and doesn't need binning.

0.2.8 is EOL, so we won't be backporting to it.

0.2.8 is EOL, so we won't be backporting to it.

Trac:
Keywords: 028-backport-maybe deleted, N/A added

Moving most of my assigned tickets to 0.3.4

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Remove 030-backport from all open tickets that have it: 0.3.0 is now deprecated.

Trac:
Keywords: 030-backport deleted, N/A added

Remove 026-backport from all open tickets that have it: 0.2.6 has been deprecated for some while.

Trac:
Parent: legacy/trac#23061 (moved) to legacy/trac#25263 (moved)

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

0.3.1 is end of life, there are no more backports. Tagging with 031-unreached-backport instead.

Trac:
Keywords: 031-backport deleted, 031-unreached-backport added

We should fix these issues by migrating these statistics to PrivCount in Tor. See legacy/trac#25263 (moved) and its parents for details.

Trac:
Owner: teor to N/A

0.2.9 is no longer maintained as of 1 January 2020. Therefore, we won't be backporting anything to it.

(None of these tickets are merge_ready, so we can just delete the backport tag.)

Trac:
Keywords: 029-backport deleted, N/A added

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

changed time estimate to 4h

moved from legacy/trac#23323 (moved)

added Bug label and removed 1 deleted label

added Relay + 1 deleted label and removed 1 deleted label

added 1 deleted label

removed milestone

closed

added Deferred label

added BugSmashFund label

added Security label and removed 1 deleted label

added Technical Debt label and removed 1 deleted label