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 45bc5a0

changed milestone to %Tor: unspecified

added 026-backport-maybe 031-unreached-backport 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: unspecified parent::25263 points::0.5 priority::medium security-low severity::normal sponsor::Q status::new tor-relay type::defect version::tor 0.2.6.3-alpha 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: #23061 (moved) to #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 #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 to tpo/core/tor#23323 (closed)