The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:59:38Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18280base32 encoding API doesn't work for a source length that is not a multiple o...2020-06-27T13:59:38ZDavid Gouletdgoulet@torproject.orgbase32 encoding API doesn't work for a source length that is not a multiple of 5 or 8Assuming `base32_encode()` here (but same issue goes for the decode function), it has a hard requirement of:
```
Limitation: Requires that srclen*8 is a multiple of 5.
```
Now, this has some drawbacks because `srclen` is the length in _...Assuming `base32_encode()` here (but same issue goes for the decode function), it has a hard requirement of:
```
Limitation: Requires that srclen*8 is a multiple of 5.
```
Now, this has some drawbacks because `srclen` is the length in _bytes_ of what we want to encode. So assuming I want to encode 32 bytes, well I can't because `32 * 8 == 256` which is shy of 4 bits to be a multiple of 8 (260).
But how fun, since I can only pass bytes to that function, how can I tell it to use a srclen of 260 bits (32.5 bytes)? It seems to me we need a function call that takes bits instead of bytes? Or give a positive float as `srclen` (sounds crazy)?
Or make `base32_encode()` more smart by using `floor((srclen * 8) / 5)` as the destination bytes length which will result in the right amount of bit (260 in this case). So that means, the caller must be smart and set the appropriate number of bytes + the extra bits. So to encode 32 bytes + 4 bit, the caller would have to pass a srclen of 33 and expect that 260 bit will be written and not 264.
(Setting parent ID to the proposal 224 key handling since it's a blocker to generate correctly the onion address).Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27896base32 padding inconsistency between client and server in HS v3 client auth p...2022-06-22T15:22:37ZTracbase32 padding inconsistency between client and server in HS v3 client auth previewThere seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 charac...There seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 characters in length and won't work otherwise (i.e., if = signs are removed), while the client would work without the padding (i.e., = signs removed) but will ignore the client's private key if the padding is present.
I don't think this affects how the feature works (which I haven't been able to test anyway because it doesn't seem to enforce authorization at this stage - it still seems to let everyone in), but at least it seems to affect which values are valid and allowed to be loaded when reading the config.
**Trac**:
**Username**: jchevalihttps://gitlab.torproject.org/tpo/core/tor/-/issues/28913Base32_decode should return the length of its result.2021-09-16T14:24:34ZNick MathewsonBase32_decode should return the length of its result.The base32_decode() API, for consistency with base64_decode, should return the number of bytes written.
This would also enable us to fuzz it with fuzz_strops.cThe base32_decode() API, for consistency with base64_decode, should return the number of bytes written.
This would also enable us to fuzz it with fuzz_strops.cTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21894Base32_encode: *actually* allow inputs of odd sizes2020-06-27T13:56:53ZNick MathewsonBase32_encode: *actually* allow inputs of odd sizesWhen we "fixed" legacy/trac#18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equa...When we "fixed" legacy/trac#18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equal to 0 or 3.
This is not _completely_ horrible, for two reasons:
* The extra bits that are read are never actually used: so this is only a crash when asan is enabled, in the worst case.
* The input sizes passed to base32_encode are only ever multiples of 5. They are all either DIGEST_LEN (20), REND_SERVICE_ID_LEN (10), sizeof(rand_bytes) in addressmap.c (10), or an input in crypto.c that is forced to a multiple of 5. So this bug can't actually trigger.
Nonetheless, let's fix it!Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15652Base64 code cleanups.2020-06-27T14:01:23ZYawning AngelBase64 code cleanups.The base64 encoder/decoder can use some love of the following sort:
* The code gated by `USE_OPENSSL_BASE64` should probably be removed, since we haven't used OpenSSL's base64 decoder since 2007, and enabling it will do weird and broke...The base64 encoder/decoder can use some love of the following sort:
* The code gated by `USE_OPENSSL_BASE64` should probably be removed, since we haven't used OpenSSL's base64 decoder since 2007, and enabling it will do weird and broken things (Eg: Inputs that aren't broken up into into lines that are < 80 characters will fail to decode correctly).
* It would be really nice to have a Base64 encode that doesn't automatically add `\n` characters.
* Having a routine to get the encoded output size makes for cleaner code.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19222base64_decode() unreachable heap corruption on 32-bit systems2020-06-27T13:58:54ZGeorge Kadianakisbase64_decode() unreachable heap corruption on 32-bit systemsHello,
this is a bug by `Guido Vranken` from our bug bounty program. After analysis, we found that there are no codepaths that allow the attacker to specify such a big input size to `base64_decode()` hence this bug should not be exploit...Hello,
this is a bug by `Guido Vranken` from our bug bounty program. After analysis, we found that there are no codepaths that allow the attacker to specify such a big input size to `base64_decode()` hence this bug should not be exploitable. More checking should be done, and there might be more instances of this rounding pattern around our codebase.
Here follows the bug report as received:
----
```
int
base64_decode(char *dest, size_t destlen, const char *src, size_t srclen)
{
...
...
if (destlen < (srclen*3)/4)
return -1;
if (destlen > SIZE_T_CEILING)
return -1;
```
The problem here is that the multiplication (by 3) occurs before the division (by 4).
For source strings larger than 0xFFFFFFFF / 3 == 0x55555555, an overflow will occur within this calculation. If the result of the overflow-affected calculation is smaller than what ```destlen``` is, then
this check will be passed and memory will be corrupted.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17868base64_decode_nopad() destination buffer length problem2020-06-27T13:59:57ZDavid Gouletdgoulet@torproject.orgbase64_decode_nopad() destination buffer length problemTL;DR; the `base64_decode_nopad()` doesn't work.
Here is a concrete example. We have `40 bytes` of binary data that we want to encode. With padding, that is using `base64_encode()` we end up with a size of `56 bytes`. Those resulting by...TL;DR; the `base64_decode_nopad()` doesn't work.
Here is a concrete example. We have `40 bytes` of binary data that we want to encode. With padding, that is using `base64_encode()` we end up with a size of `56 bytes`. Those resulting bytes, when passed to `base64_decode()`, the check on the destination buffer done in that function makes it that we need `42 bytes` and not the original `40 bytes`. This is due because of the padding.
One solution, instead of explicitly adding 2 bytes like it's been done in many places in the code, it is to use the `_nopad()` interface. However, the `base64_decode_nopad()` simply adds some `=` at the end with a new source buffer and passes along the base64_decode() function. However the `dstlen` that is the destination buffer length where the decoded data will go is not updated to reflect the new length of the source buffer so the call fails because of the `dstlen` check in the decode function.
Passing 40 bytes for `dstlen` and 54 for `srclen` (which is the expected value _without_ padding), the nopad() call changes `srclen` to 56 bytes but then `dstlen` should be 42 bytes else the call fails.
I'm not sure how to fix that properly apart from making `_nopad()` call allocating a new source buffer if needed. I would much prefer that than the caller adding bytes beforehand making the code cryptic and honestly unsafe to any future length changes.
Thoughts?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21214Based on measurement of #21205, write/analyze additional proposals and ticket...2020-06-27T13:57:21ZNick MathewsonBased on measurement of #21205, write/analyze additional proposals and tickets for lowering bw usage for directory stuffBased on the measurements we get from legacy/trac#21205, we'll probably learn more about some actual bandwidth needs, and the circumstances when dir BW is overused. We should add tickets to fix the bugs, possibly with proposals, based o...Based on the measurements we get from legacy/trac#21205, we'll probably learn more about some actual bandwidth needs, and the circumstances when dir BW is overused. We should add tickets to fix the bugs, possibly with proposals, based on what we find otu.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22123baseXX API strictness2021-09-16T14:32:30ZTaylor YubaseXX API strictnessWe should think about how strict to make decoders for our baseXX APIs. In some situations, it improves security to only have a single canonical encoding for any particular value. We should see where this is true in our code.
## Base16...We should think about how strict to make decoders for our baseXX APIs. In some situations, it improves security to only have a single canonical encoding for any particular value. We should see where this is true in our code.
## Base16
* case sensitivity (currently case-insensitive)
## Base32
* case sensitivity (currently case-insensitive -- also the standard default is uppercase and we use lowercase)
* padding strictness (currently no padding at all, even with odd lengths?)
* trailing bits strictness (in an odd-length decode, there might be leftover bits in the final non-padding character. for a canonical encoding, they should all be zero)
## Base64
* padding strictness
* padding `=` characters only at end (currently any padding characters terminate decoding)
* correct number of padding characters (currently not checked)
* whitespace? (maybe only if explicitly allowed?) currently we allow any whitespace
* trailing bits strictness (in an odd-length decode, there might be leftover bits in the final non-padding character. for a canonical encoding, they should all be zero)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40668bash-completion for tor2022-10-24T20:48:34Znyxnorbash-completion for torMade a bash-completion script for tor.
Miscellaneous addition.
It does not need to be in `core/tor`, I would just like some review from upstream (TPO) before trying to merge to the official repo on https://github.com/scop/bash-completio...Made a bash-completion script for tor.
Miscellaneous addition.
It does not need to be in `core/tor`, I would just like some review from upstream (TPO) before trying to merge to the official repo on https://github.com/scop/bash-completion/blob/master/completions/
It has all options, but it doesn't generate all arguments because that is too much work.
You can check the up to date version here https://github.com/nyxnor/tor-bash-completion/blob/main/tor
But if you just want to get a look at it.
```bash
# tor(1) completion -*- shell-script -*-
_comp_xfunc_tor_torrcopt()
{
_tor_torrc_opt="$(tor --list-torrc-options | sed "s|^|--|")"
COMPREPLY=($(compgen -W "${_tor_torrc_opt}" -- "$cur"))
}
_tor()
{
local cur prev words cword
_init_completion -s || return
case $prev in
## tor cli
--allow-missing-torrc | --ignore-missing-torrc | --verify-config | \
--list-torrc-options | --list-deprecated-options | \
--list-modules | --help | --version | --quiet | --hush )
return
;;
--hash-password )
## requires argument but not possible to complete
return
;;
--defaults-torrc | --torrc-file )
_filedir
return
;;
--dump-config )
COMPREPLY=($(compgen -W "short full" -- "$cur"))
return
;;
--list-fingerprint )
COMPREPLY=($(compgen -W "rsa ed25519" -- "$cur"))
return
;;
--keygen )
COMPREPLY=($(compgen -W "--newpass" -- "$cur"))
return
;;
--key-expiration )
COMPREPLY=($(compgen -W "sign" -- "$cur"))
return
;;
--format )
## depends on --key-expiration
COMPREPLY=($(compgen -W "iso8601 timestamp" -- "$cur"))
return
;;
--passphrase-fd )
COMPREPLY=($(compgen -W "$(ls /proc/$$/fd)" -- "$cur"))
return
;;
## torrc options
--AccelDir | --CacheDirectory | --DataDirectory | \
--ClientOnionAuthDir | --KeyDirectory | --HiddenServiceDir )
_filedir -d
return
;;
--ControlPortWriteToFile | --ControlSocket | --CookieAuthFile | \
--ExtORPortCookieAuthFile | --PidFile | --GeoIPFile | \
--GeoIPv6File | --ServerDNSResolvConfFile | \
--DirPortFrontPage | --GuardfractionFile | --V3BandwidthsFile )
_filedir
return
;;
--AvoidDiskWrites | --ConstrainedSockets | \
--ControlPortFileGroupReadable | --ControlSocketGroupWritable | \
--CookieAuthentication | --CookieAuhtfileGroupReadable | \
--CountPrivateBandwidth | --DataDirectoryGroupReadable | \
--DisableAllSwap | --DisableDebuggerAttachement | --DisableNetwork | \
--ExtORPortCookieAuthFileGroupReadable | --FetchDirInfoEarly | \
--FetchDirInfoExtraEarly | --FetchHidServDescriptors | \
--FetchServerDescriptors | --FetchUselessDescriptors | \
--HardwareAccel | --LogMessageDomains | --NoExec | \
--ProtocolWarnings | --RunAsDaemon | --SandBox | \
--TrunateLogFile| --UnixSocksGroupWritable | \
--UseDefaultFallbackDirs | --AllowNonRFC953Hostnames | \
--AutomapHostsOnResolve | --CircuitPadding | \
--ReducedCircuitPadding | --ClientDNSRejectInternalAddresses | \
--ClientOnly | --ClientRejectInternalAddresses | \
--ClientUseIPv4 | --ClientUseIPv6 | --ReducedConnectionPadding | \
--DownloadExtraInfo | --EnforceDistinctSubnets | \
--FascistFirewall | --SafeSocks | --TestSocks | \
--UpdateBridgesFromAuthority | --UseBridges | --UseEntryGuards | \
--LearnCircuitBuildTimeout | --DormantCanceledByStartup | \
--DormantOnFirstStartup | --DormantTimeoutDisabledByIdleStreams | \
--DormantTimeoutEnabled | --StrictNodes | --AddressDisableIPv6 | \
--AssumeReachable | --BridgeRelay | --DisableOOSCheck | \
--ExitPolicyRejectLocalInterfaces | --ExitPolicyRejectPrivate | \
--ExtendAllowPrivateAddresses | --IPv6Exit | --MainloopStats | \
--OfflineMasterKey | --ReducedExitPolicy | \
--ServerDNSAllowBrokenConfig | \
--ServerDNSAllowNonRFC953Hostnames | --ServerDNSDetectHijacking | \
--ServerDNSRandomizeCase | --ServerDNSSearchDomains | \
--BridgeRecordUsageByCountry | --CellStatistics | \
--ConnDirectionStatistics | --DirReqStatistics | \
--EntryStatistics | --ExitPortStatistics | --ExtraInfoStatistics | \
--HiddenServiceStatistics | --OverloadStatistics | \
--PaddingStatistics | --DirCache | \
--HiddenServiceEnableIntroDoSDefense | \
--AuthoritativeDirectory | --BridgeAuthoritativeDir | \
--V3AuthoritativeDirectory | --AuthDirHasIPv6Connectivity | \
--AuthDirListBadExits | --AuthDirListMiddleOnly | \
--AuthDirPinKeys | --AuthDirRejectRequestsUnderLoad | \
--AuthDirSharedRandomness | --AuthDirTestEd25519LinkKeys | \
--AuthDirTestReachability | --DirAllowPrivateAddresses | \
--V3AuthUseLegacyKey | --VersioningAuthoritativeDirectory | \
--HiddenServiceAllowUnknownPorts | \
--HiddenServiceDirGroupReadable | \
--HiddenServiceOnionBalanceInstance | \
--HiddenServiceMaxStreamsCloseCircuit | \
--HiddenServiceSingleHopMode | \
--HiddenServiceNonAnonymousMode | \
--PublishHidServDescriptors | \
--TestingTorNetwork | \
--TestingDirAuthVoteExitIsStrict | \
--TestingDirAuthVoteGuardIsStrict | \
--TestingDirAuthVoteHSDirIsStrict | \
--TestingEnableCellStatsEvent | \
--TestingEnableConnBwEvent )
COMPREPLY=($(compgen -W "0 1" -- "$cur"))
return
;;
--CacheDirectoryGroupReadable | --ExtendByEd25519ID | \
--KeepBindCapabilities | --ClientPreferIPv6DirPort | \
--ClientPreferIPv6ORPort | --ConnectionPadding | \
--UseGuardFraction | --VanguardsLiteEnabled | \
--UseMicroDescriptors | --GeoIPExcludeUnknown | \
--AssumeReachableIPv6 | --ExitRelay | \
--KeyDirectoryGroupReadable | --RefuseUnknownExits | \
--DoSCircuitCreationEnabled | --DoSConnectionEnabled | \
--DoSRefuseSingleHopClientRendezvous )
COMPREPLY=($(compgen -W "0 1 auto" -- "$cur"))
return
;;
--SafeLogging )
COMPREPLY=($(compgen -W "0 1 relay" -- "$cur"))
return
;;
--TransProxyType )
COMPREPLY=($(compgen -W "default TPROXY ipfw pf-divert" -- "$cur"))
return
;;
--AccountingRule )
COMPREPLY=($(compgen -W "sum max in out" -- "$cur"))
return
;;
--PublishServerDescriptor )
COMPREPLY=($(compgen -W "0 1 v3 bridge" -- "$cur"))
return
;;
--HiddenServiceExportCircuitID )
COMPREPLY=($(compgen -W "haproxy" -- "$cur"))
return
;;
--HiddenServiceVersion )
COMPREPLY=($(compgen -W "3" -- "$cur"))
return
;;
esac
if [[ $cur == -* ]]; then
_comp_xfunc_tor_torrcopt
COMPREPLY=($(compgen -W "--help --torrc-file --allow-missing-torrc
--defaults-torrc --ignore-missing-torrc --hash-password
--list-fingerprint --verify-config --dump-config
--list-torrc-options --list-deprecated-options --list-modules
--version --quiet --hush --keygen --newpass --passphrase-fd
--key-expiration --format ${_tor_torrc_opt}" -- "$cur"))
return
fi
} &&
complete -F _tor tor
# ex: filetype=sh
```https://gitlab.torproject.org/tpo/core/arti/-/issues/651Basic acceptance testing for 1.1.0 deliverables2023-01-10T18:23:24ZNick MathewsonBasic acceptance testing for 1.1.0 deliverablesHere's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful ...Here's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful cases
* [x] Configure Arti with a single bridge, not using a pluggable transport.
* [x] Configure Arti with a single bridge, using obfs4. (#332)
* [x] Configure Arti with a single bridge, using snowflake. (#333)
* [ ] Configure Arti with multiple bridges, including a few nonexistent ones.
In each of the successful cases, we should:
* Observe that we can browse and download successfully.
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
You can get bridges from `bridges.torproject.org`.
## Failing cases
* [ ] Configure arti to use bridges, using only a single nonexistent bridge.
* [ ] Configure arti to use bridges, using multiple nonexistent bridges.
In the failing cases we should:
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
## Complex cases
* [ ] Configure a list of bridges, and turn enable_bridges on and off. Make sure that Arti behaves correctly.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/web/snowflake/-/issues/3Basic front-end development for snowflake.torproject.org2024-03-06T13:40:23ZAshish SoniBasic front-end development for snowflake.torproject.orgConvert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-ban...Convert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-bandwidth)
* [x] Code Section - 4 (faqs)
* [x] Add Navbar
* [x] Make Website Responsive
* [ ] Multilingual SupportAshish SoniAshish Sonihttps://gitlab.torproject.org/tpo/core/arti/-/issues/28Basic path-generation logic2020-12-07T16:49:37ZNick MathewsonBasic path-generation logicI should extend tor-netdir (or some related crate) to build plausible paths through the Tor network.
At the very least for this milestone I want
* [x] Distinct relays
* [x] Making sure we know enough relays
* [ ] Avoiding relays in t...I should extend tor-netdir (or some related crate) to build plausible paths through the Tor network.
At the very least for this milestone I want
* [x] Distinct relays
* [x] Making sure we know enough relays
* [ ] Avoiding relays in the same family
* [x] Choosing exits that do what we want
* [x] Weighting more or less correctlyA1: minimal socksportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/10Basic report generation2023-08-09T00:27:17ZSilvio RhattoBasic report generationBasic reporting generation, outputting collected metrics in CSV and JSON formats.Basic reporting generation, outputting collected metrics in CSV and JSON formats.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21183Basic Usability Issues2020-06-27T14:38:17ZTracBasic Usability IssuesHi:
I'm a longtime UX'er, and new to using Tor. Some very basic heuristics I felt compelled to respond to, in a PDF—and was advised by a FOSS person, to submit in a ticket, here.
Namely:
- The "Tor Button" is illegible (recommended re...Hi:
I'm a longtime UX'er, and new to using Tor. Some very basic heuristics I felt compelled to respond to, in a PDF—and was advised by a FOSS person, to submit in a ticket, here.
Namely:
- The "Tor Button" is illegible (recommended replacement included)
- The "NoScripts" icon is illegible (recommended replacement included)
- Most of the functionality behind the TorButton should be in a preferences pane, not a toolbar button
- The three pieces of functionality appropriate for toolbar buttons, should each have their own buttons. Replacement icons and interaction pane recommendations, included.
Document here, if I'm not able to upload it myself:
https://drive.google.com/open?id=0BzRaXGZ006aoWHJLd0hBT3IyRUE
**Trac**:
**Username**: ninavizzhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/27064Batch merge for Relay Search patches2020-06-27T14:25:52ZirlBatch merge for Relay Search patchesPlease merge the 5 commits in my [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] branch. The last commit is fb630f0.Please merge the 5 commits in my [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] branch. The last commit is fb630f0.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/26856Batch merge for Relay Search patches2020-06-27T14:25:53ZirlBatch merge for Relay Search patchesPlease merge my branch [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] up to commit 97443f9.Please merge my branch [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] up to commit 97443f9.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/26700Batch merge for Relay Search patches2020-06-27T14:25:53ZirlBatch merge for Relay Search patchesPlease merge my [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] branch up to commit `8e0953f`.Please merge my [[https://gitweb.torproject.org/user/irl/metrics-web.git/log/?h=relaysearch-dev|relaysearch-dev]] branch up to commit `8e0953f`.https://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/7Batch mode2022-08-08T16:14:09ZSilvio RhattoBatch modeSupport for a batch mode operation:
* Support for running each site until a number of results are generated, then going to the next one.
* Batch can be stopped and resumed (especially if the generated candidates aren't acceptable).Support for a batch mode operation:
* Support for running each site until a number of results are generated, then going to the next one.
* Batch can be stopped and resumed (especially if the generated candidates aren't acceptable).Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19382Batch-close all tickets in Metrics/Tor Weather and remove that component2020-06-27T14:19:20ZKarsten LoesingBatch-close all tickets in Metrics/Tor Weather and remove that componentWe're not hosting Weather anymore, nor do we have plans to host it again. Should we batch-close all tickets in the Metrics/Tor Weather component? And should we remove that component, so that new tickets cannot get assigned to it?
Happ...We're not hosting Weather anymore, nor do we have plans to host it again. Should we batch-close all tickets in the Metrics/Tor Weather component? And should we remove that component, so that new tickets cannot get assigned to it?
Happy to do this, unless it's a bad idea.
Talking about these 50 tickets:
[[TicketQuery(status=!closed&component=^Metrics/Tor Weather)]]Jens KubiezielJens Kubieziel