December 2017 - tor-commits - lists.torproject.org

[webwml/master] Add sections for trac (#18586) and reporting bad relays (#22412).
by hiro＠torproject.org 04 Dec '17

04 Dec '17

commit 9f5f29d3b01135ff66317af76046208a902a2cd3 Author: kat <kat(a)torproject.org> Date: Sun Dec 3 14:59:18 2017 -0500 Add sections for trac (#18586) and reporting bad relays (#22412). Add sections. Move security section to directly follow trac section. --- about/en/contact.wml | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/about/en/contact.wml b/about/en/contact.wml index 6105e9cb..2c7348f7 100644 --- a/about/en/contact.wml +++ b/about/en/contact.wml @@ -16,9 +16,11 @@ <li><a href="#support">Support</a></li> <li><a href="#irc">IRC</a></li> <li><a href="#twitter">Twitter</a></li> + <li><a href="#bugs">Bug Tracker</a></li> + <li><a href="#security">Security Issues</a></li> + <li><a href="#badrelays">Report Bad Relays</a></li> <li><a href="#email">Email</a></li> <li><a href="#mail">Mailing Address</a></li> - <li><a href="#security">Security Issues</a></li> </ul> <a id="support"></a> @@ -88,7 +90,34 @@ </ul> </p> - <a id="email"></a> + <a id="bugs"></a> + <h3><a class="anchor" href="#bugs">Bug Tracker</a></h3> + <p>You can report bugs other than <a href="#security">security + issues</a> using our <a href="https://trac.torproject.org/projects/tor" + >bug tracker</a>. Our + <a href="<page getinvolved/volunteer>">volunteer page</a> has + convenient links to <a href="<page getinvolved/volunteer>#Projects"> + project-related queries</a>.</p> + + <a id="security"></a> + <h3><a class="anchor" href="#security">Security Issues</a></h3> + <p>If you've found a security issue in one of our projects or our + infrastructure, please email the respective maintainer. You can find + their GPG fingerprint/key on our <a + href="https://db.torproject.org">developer ldap search page</a>. Due + to the many different projects we have, we do not offer a single + list for security issues.</p> + + <a id="badrelays"></a> + <h3><a class="anchor" href="#badrelays">Report Bad Relays</a></h3> + <p>If you find a relay that you think is malicious, misconfigured, + or otherwise broken, please check out our + <a href="https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays"> + wiki page</a> and <a href="https://blog.torproject.org/how-report-bad-relays" + >blog post</a> on how to report it.</p> + + + <a id="email"></a> <h3><a class="anchor" href="#email">Email</a></h3> <p>If you have Tor questions, please try to help yourself via the above support venues. Please don't use this contact address @@ -116,15 +145,6 @@ Seattle, WA 98194 USA<br><br> </address> - <a id="security"></a> - <h3><a class="anchor" href="#security">Security Issues</a></h3> - <p>If you've found a security issue in one of our projects or our - infrastructure, please email the respective maintainer. You can find - their GPG fingerprint/key on our <a - href="https://db.torproject.org">developer ldap search page</a>. Due - to the many different projects we have, we do not offer a single - list for security issues. - </div>  <div id = "sidecol">

1 0

[webwml/master] Merge remote-tracking branch 'kat/tor-users-dead-links'
by hiro＠torproject.org 04 Dec '17

04 Dec '17

commit bc2c344347a0d69af008941580a7c4c0c5f787ff Merge: 9f5f29d3 8d7dd7b6 Author: hiromipaw <hiro(a)torproject.org> Date: Mon Dec 4 18:16:51 2017 +0100 Merge remote-tracking branch 'kat/tor-users-dead-links' about/en/torusers.wml | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)

1 0

[torspec/master] Merge remote-tracking branch 'teor/bug23826-23828-v2'
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 48e41c559f5b5438838d15c4fd9a1b46c7296310 Merge: 0596c2c b523c5c Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Dec 4 11:48:43 2017 -0500 Merge remote-tracking branch 'teor/bug23826-23828-v2' dir-spec.txt | 38 ++++++---- proposals/283-ipv6-in-micro-consensus.txt | 111 ++++++++++++++++++------------ 2 files changed, 94 insertions(+), 55 deletions(-)

1 0

[torspec/master] Fix a minor size miscalculation in prop283
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit c0fbf526676ca86512d448e10901395e71ce2f78 Author: teor <teor2345(a)gmail.com> Date: Thu Oct 26 16:13:40 2017 +1100 Fix a minor size miscalculation in prop283 --- proposals/283-ipv6-in-micro-consensus.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt index 1334844..db57176 100644 --- a/proposals/283-ipv6-in-micro-consensus.txt +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -136,7 +136,7 @@ Target: 0.3.3.x 5. Data Size - This change removes 2-50 bytes from the microdescriptors of relays that + This change removes 7-50 bytes from the microdescriptors of relays that have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc consensus entries.

1 0

[torspec/master] Add consensus method 27, which adds IPv6 addresses to the micro consensus
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit fdc8f3e8c627cbd35c501f77cf81ebcaea70a3a6 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:32:31 2017 -0400 Add consensus method 27, which adds IPv6 addresses to the micro consensus Documents #23826. --- dir-spec.txt | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 846f7a9..7b636c4 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2386,8 +2386,10 @@ * the router advertises at least one IPv6 ORPort, and * AuthDirHasIPv6Connectivity 1 is set on the authority. A minority of voting authorities that set AuthDirHasIPv6Connectivity will - drop unreachable IPv6 addresses from the full consensus. But they can not - drop IPv6 addresses from microdescriptors. + drop unreachable IPv6 ORPorts from the full consensus. But they can not + drop IPv6 ORPorts from microdescriptors. Consensus method 27 in 0.3.3.x + puts IPv6 ORPorts in the microdesc consensus, so that authorities can + drop unreachable IPv6 ORPorts from all consensus flavours. "Stable" -- A router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF @@ -2712,6 +2714,9 @@ bandwith weights to 1 in our calculations, to avoid division-by-zero errors on unusual networks. + * If consensus method 27 or later is used, the microdesc consensus + may include an "a" line for each router, listing an IPv6 OR port. + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -2793,6 +2798,7 @@ "24" -- No longer lists routers that are not Valid in the consensus. "25" -- Vote on recommended-protocols and required-protocols. "26" -- Initialize bandwidth weights to 1 to avoid division-by-zero. + "27" -- Adds support for "a" lines in microdescriptor consensues. Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number @@ -3083,10 +3089,11 @@ [Any number] - IPv6 ORPorts are contained in microdescriptors and therefore omitted - in the microdescriptor consensus. + Identical to the "r" lines in section 3.4.1. - Not currently generated. + (Only included when the vote is generated with consensus-method 14 + or later, and the consensus is generated with consensus-method 27 or + later.) "p" ... NL

1 0

[torspec/master] Revise proposal 283 based on Nick's feedback
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit b523c5c4882ce13a5d9efe6f330b0f7d1d0b1167 Author: teor <teor2345(a)gmail.com> Date: Wed Nov 22 00:21:08 2017 +1100 Revise proposal 283 based on Nick's feedback --- proposals/283-ipv6-in-micro-consensus.txt | 109 ++++++++++++++++++------------ 1 file changed, 67 insertions(+), 42 deletions(-) diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt index db57176..da12cfa 100644 --- a/proposals/283-ipv6-in-micro-consensus.txt +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -1,6 +1,6 @@ Filename: 283-ipv6-in-micro-consensus.txt Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus -Author: Tim Wilson-Brown (teor) +Author: Tim Wilson-Brown (teor), Nick Mathewson Created: 18-Oct-2017 Status: Open Target: 0.3.3.x @@ -10,16 +10,21 @@ Target: 0.3.3.x Moving IPv6 ORPorts from microdescs to the microdesc consensus will make it easier for IPv6 clients to bootstrap and select reachable guards. - Since consensus method 14, authorities have voted for IPv6 address/port - pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the - full consensus. But for clients that use microdescriptors (the default), - IPv6 ORPorts are placed in microdescriptors. So these clients can only tell - if an IPv6 ORPort is unreachable when a majority of voting authorities - mark the relay as not Running. + Tor clients on IPv6-only connections currently have to use IPv6 Fallback + Directory Mirrors to fetch their microdescriptors. This does not scale + well. After this change, they will be able to fetch microdescriptors from + any IPv6-enabled directory mirror in the consensus. - This proposal puts reachable relay IPv6 ORPorts in an "a" line in the - microdesc consensus. This allows clients to discover unreachable IPv6 - ORPorts, even if a minority of voting authorities set + Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to + bootstrap over IPv6-only connections when using microdescriptors. After + this consensus change, they will be able to bootstrap without any client + code changes. + + For clients that use microdescriptors (the default), IPv6 ORPorts are + always placed in microdescriptors. So these clients can only tell if an + IPv6 ORPort is unreachable when a majority of voting authorities mark the + relay as not Running. After this proposal, clients will be able to discover + unreachable ORPorts, even if a minority of voting authorities set AuthDirHasIPv6Connectivity 1. 2. Proposal @@ -40,8 +45,8 @@ Target: 0.3.3.x 2.2. Remove IPv6 ORPorts from Microdescriptors - We specify that microdescriptors created with methods N or later do not - contain any IPv6 ORPorts. + We specify that microdescriptors created with methods N or later start + omitting IPv6 ORPorts. 3. Retaining Existing Behaviour @@ -55,22 +60,22 @@ Target: 0.3.3.x This means that: * if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be no IPv6 ORPorts in the consensus, - * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1, - unreachable IPv6 ORPort lines will be dropped from the consensus, but the - relay will still be listed as Running, + * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1: + unreachable IPv6 ORPort lines will be dropped from the consensus, but + the relay will still be listed as Running, and + reachable IPv6 ORPort lines will be included in the consensus. * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, - relays with unreachable IPv6 ORPorts will be dropped from the consensus. + relays with unreachable IPv6 ORPorts will not be listed as Running. + Reachable IPv6 ORPort lines will be included in the consensus. + (To ensure that any valid majority will vote relays with unreachable + IPv6 ORPorts not Running, 75% of authorities must set + AuthDirHasIPv6Connectivity 1.) We will document this behaviour in the tor manual page, see #23870. -3.2. Full Consensus IPv6 ORPorts - - The full consensus will continue to contain reachable IPv6 ORPorts. - -3.3. Clients that use Full Descriptors +3.2. NS Consensus IPv6 ORPorts - Tor clients that use full descriptors already ignore unreachable IPv6 - ORPorts, and have done so since at least 0.2.8.x. + The NS consensus will continue to contain reachable IPv6 ORPorts. 4. Impact and Related Changes @@ -103,36 +108,44 @@ Target: 0.3.3.x Their behaviour will be identical to the current behaviour for consensus methods M and earlier. When consensus method N is used, they will ignore - unreachable IPv6 ORPorts without any code changes. + unreachable IPv6 ORPorts without any code changes, as long as they are + using microdescriptors. 4.3.1.2. IPv6 ORPort Bootstrap Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to - bootstrap over IPv6 only connections when using microdescriptors. This + bootstrap over IPv6-only connections when using microdescriptors. This happens because the microdesc consensus does not contain IPv6 ORPorts. + (IPv6-only Tor clients on versions 0.3.0.2-alpha and later use fallback + directory mirrors to fetch their microdescriptors.) - When consensus method M is used, they will be able to bootstrap over IPv6 - only connections using microdescriptors, without any code changes. + When consensus method M is used, 0.2.8.x and 0.2.9.x clients will be able + to bootstrap over IPv6-only connections using microdescriptors, without any + code changes. 4.3.2. Future Clients 4.3.2.1. Ignoring IPv6 ORPorts in Microdescs Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6 - ORPorts once consensus method M or later is in use. (See #23827.) + ORPorts once consensus method M or later is in use. This requires some code + changes, see #23827. 4.3.2.2. IPv6 ORPort Bootstrap If a bootstrapping IPv6-only client has a consensus made with method M or later, it should download microdescriptors from one of the IPv6 ORPorts in - that consensus. Previously, IPv6-only clients would use fallback directory + that consensus. This requires some code changes, see #23827. + + Previously, IPv6-only clients would use fallback directory mirrors to download microdescs, because there were no IPv6 ORPorts in the - microdesc consensus. (See #23827.) + microdesc consensus. 4.3.2.3. Ignoring Addresses in Unused Directory Documents If a client doesn't use a particular directory document type for a node, - it should ignore any addresses in that document type. (See #23975.) + it should ignore any addresses in that document type. This requires some + code changes, see #23975. 5. Data Size @@ -140,22 +153,34 @@ Target: 0.3.3.x have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc consensus entries. - As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full + As of October 2017, 600 relays (9%) have IPv6 ORPorts in the NS consensus. Their "a" lines take up 19 KB, or 33 bytes each on average. - The microdesc consensus is 1981 KB, so this represents about 1% of its - uncompressed size. - Most tor clients are already running 0.3.1.7, which implements consensus - diffs. We expect that most directory mirrors will also implement consensus - diffs by the time 2/3 of authorities are voting for consensus method M. + The gzip-compressed microdesc consensus is 564 KB, and adding the existing + IPv6 addresses makes it 576 KB (a 2.1% increase). Adding IPv6 addresses to + every relay makes it 644 KB (a 14% increase). zstd-compressed microdesc + consensuses show smaller increases of 1.7% and 8.0%, respectively. - So we expect that this change will have a minimal impact, which is made - even smaller by compression and consensus diffs. + Most tor clients are already running 0.3.1.7, which implements consensus + diffs and zstd compression. We expect that most directory mirrors will also + implement consensus diffs and zstd compression by the time 2/3 of + authorities are voting for consensus method M. Consensus diffs will reduce + the worst-case impact of this change for clients and relays that have a + recent consensus. 6. External Impacts We don't expect this change to impact Onionoo and similar projects, because - they typically use the full consensus. + they typically use the NS consensus. + +7. Monitoring + + OnionOO has implemented an "unreachable IPv6 address" attribute: + https://trac.torproject.org/projects/tor/ticket/21637 + + Metrics is working on IPv6 relay graphs: + https://trac.torproject.org/projects/tor/ticket/23761 - Metrics doesn't currently graph IPv6 usage in Tor, but would like to in - future. + Consensus-health implements a ReachableIPv6 pseudo-flag for authorities + and relays: + https://consensus-health.torproject.org/

1 0

[torspec/master] Add consensus method 28, which removes IPv6 addresses from microdescriptors
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 52e70bd5064bd50ee1d84e810d3eeafd4092b246 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:42:52 2017 -0400 Add consensus method 28, which removes IPv6 addresses from microdescriptors Documents #23828. --- dir-spec.txt | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 7b636c4..5cf9770 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1475,7 +1475,7 @@ section 2.1.1. (Only included when generating microdescriptors for - consensus-method 14 or later.) + consensus-methods 14 to 27.) "family" names NL @@ -2386,10 +2386,10 @@ * the router advertises at least one IPv6 ORPort, and * AuthDirHasIPv6Connectivity 1 is set on the authority. A minority of voting authorities that set AuthDirHasIPv6Connectivity will - drop unreachable IPv6 ORPorts from the full consensus. But they can not - drop IPv6 ORPorts from microdescriptors. Consensus method 27 in 0.3.3.x - puts IPv6 ORPorts in the microdesc consensus, so that authorities can - drop unreachable IPv6 ORPorts from all consensus flavours. + drop unreachable IPv6 ORPorts from the full consensus. Consensus method 27 + in 0.3.3.x puts IPv6 ORPorts in the microdesc consensus, so that + authorities can drop unreachable IPv6 ORPorts from all consensus flavours. + Consensus method 28 removes IPv6 ORPorts from microdescriptors. "Stable" -- A router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF @@ -2717,6 +2717,9 @@ * If consensus method 27 or later is used, the microdesc consensus may include an "a" line for each router, listing an IPv6 OR port. + * If consensus method 28 or later is used, microdescriptors no longer + include "a" lines. + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -2799,6 +2802,7 @@ "25" -- Vote on recommended-protocols and required-protocols. "26" -- Initialize bandwidth weights to 1 to avoid division-by-zero. "27" -- Adds support for "a" lines in microdescriptor consensues. + "28" -- Removes "a" lines from microdescriptors. Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number

1 0

[torspec/master] Document current authority IPv6 reachability behaviour in dir-spec
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 99e11bd5de4549ce335da2013645ebd8b39d2347 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:47:26 2017 -0400 Document current authority IPv6 reachability behaviour in dir-spec This is the tor-spec part of #23870. --- dir-spec.txt | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index ffbe4d3..846f7a9 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2170,11 +2170,11 @@ "NoEdConsensus" if any Ed25519 key in the router's descriptor or microdesriptor does not reflect authority consensus. "Stable" if the router is suitable for long-lived circuits. - "Running" if the router is currently usable over the ORPorts that - an authority considers mandatory. Relays without this flag are - omitted from the consensus, and current clients - (since 0.2.9.4-alpha) assume that every listed relay has this - flag. + "Running" if the router is currently usable over all its published + ORPorts. (Authorities ignore IPv6 ORPorts unless configured to + check IPv6 reachability.) Relays without this flag are omitted + from the consensus, and current clients (since 0.2.9.4-alpha) + assume that every listed relay has this flag. "Valid" if the router has been 'validated'. Clients before 0.2.9.4-alpha would not use routers without this flag by default. Currently, relays without this flag are omitted @@ -2379,12 +2379,15 @@ canonically linked to its public key. "Running" -- A router is 'Running' if the authority managed to connect to - it successfully within the last 45 minutes on the ORPorts it considers - mandatory. Since 0.2.4.x, the mandatory ORPorts are: + it successfully within the last 45 minutes on all its published ORPorts. + Authorities check reachability on: * the IPv4 ORPort in the "r" line, and * the IPv6 ORPort considered for the "a" line, if: * the router advertises at least one IPv6 ORPort, and - * AuthDirHasIPv6Connectivity 1 is set on the authority + * AuthDirHasIPv6Connectivity 1 is set on the authority. + A minority of voting authorities that set AuthDirHasIPv6Connectivity will + drop unreachable IPv6 addresses from the full consensus. But they can not + drop IPv6 addresses from microdescriptors. "Stable" -- A router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF

1 0

[tor/master] Document the effects of AuthDirHasIPv6Connectivity
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 4b2995dc1d374e7434e98a326de7734d3ed57ca2 Author: teor <teor2345(a)gmail.com> Date: Wed Oct 25 13:15:35 2017 +1100 Document the effects of AuthDirHasIPv6Connectivity Fixes #23870 on 0.2.4.1-alpha. --- doc/tor.1.txt | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/doc/tor.1.txt b/doc/tor.1.txt index ba2bc13da..6fa468408 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -2345,9 +2345,29 @@ on the public Tor network. [[AuthDirHasIPv6Connectivity]] **AuthDirHasIPv6Connectivity** **0**|**1**:: Authoritative directories only. When set to 0, OR ports with an - IPv6 address are being accepted without reachability testing. - When set to 1, IPv6 OR ports are being tested just like IPv4 OR - ports. (Default: 0) + IPv6 address are not included in the authority's votes. When set to 1, + IPv6 OR ports are tested for reachability like IPv4 OR ports. If the + reachability test succeeds, the authority votes for the IPv6 ORPort, and + votes Running for the relay. If the reachability test fails, the authority + does not vote for the IPv6 ORPort, and does not vote Running (Default: 0) + ++ + The content of the consensus depends on the number of voting authorities + that set AuthDirHasIPv6Connectivity: + + If no authorities set AuthDirHasIPv6Connectivity 1, there will be no + IPv6 ORPorts in the consensus. + + If a minority of authorities set AuthDirHasIPv6Connectivity 1, + unreachable IPv6 ORPorts will be removed from the consensus. But the + majority of IPv4-only authorities will still vote the relay as Running. + Reachable IPv6 ORPort lines will be included in the consensus + + If a majority of voting authorities set AuthDirHasIPv6Connectivity 1, + relays with unreachable IPv6 ORPorts will not be listed as Running. + Reachable IPv6 ORPort lines will be included in the consensus + (To ensure that any valid majority will vote relays with unreachable + IPv6 ORPorts not Running, 75% of authorities must set + AuthDirHasIPv6Connectivity 1.) [[MinMeasuredBWsForAuthToIgnoreAdvertised]] **MinMeasuredBWsForAuthToIgnoreAdvertised** __N__:: A total value, in abstract bandwidth units, describing how much

1 0

[tor/master] Merge branch 'bug23826-23828_squashed'
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit f50d64b62eeb7c07f2e0dd7f23499880d208a434 Merge: cf3da63b9 a2c09f675 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Dec 4 11:43:11 2017 -0500 Merge branch 'bug23826-23828_squashed' changes/bug23826-23828 | 14 ++++++++++++++ doc/tor.1.txt | 26 +++++++++++++++++++++++--- src/or/dirserv.c | 19 ++++++++++++++----- src/or/dirserv.h | 1 + src/or/dirvote.c | 19 ++++++++++++++----- src/or/dirvote.h | 14 +++++++++++++- src/or/networkstatus.c | 4 +++- 7 files changed, 82 insertions(+), 15 deletions(-)

1 0