Merge branch 'master' of i2pgit.org:i2p-hackers/i2p.www

i2p2www/blog/2024/05/15/2.5.2-Release.draft.rst

+===========================================
+{% trans -%}2.5.2 Release{%- endtrans %}
+===========================================
+
+.. meta::
+    :author: zzz
+    :date: 2024-05-15
+    :category: release
+    :excerpt: {% trans %}2.5.2 Release with HTTP fix{% endtrans %}
+
+{% trans -%}
+I2P 2.5.2 is released to fix a bug introduced in 2.5.0 causing truncation of some HTTP content.
+{%- endtrans %}
+
+{% trans -%}
+As usual, we recommend that you update to this release.
+The best way to maintain security and help the network is to run the latest release.
+{%- endtrans %}
+
+**{% trans %}RELEASE DETAILS{% endtrans %}**
+
+**{% trans %}Changes{% endtrans %}**
+
+- {% trans %}Console: Update rrd4j to 3.9.1-preview{% endtrans %}
+- {% trans %}Router: Publish G cap if symmetric natted{% endtrans %}
+
+**{% trans %}Bug Fixes{% endtrans %}**
+
+- {% trans %}i2ptunnel: Fix bug causing truncation of some HTTP content{% endtrans %}
+- {% trans %}i2ptunnel: Fix custom option form width (light theme){% endtrans %}
+- {% trans %}Tunnels: Fix selection of peers with expired RIs{% endtrans %}
+
+**{% trans %}Other{% endtrans %}**
+
+- {% trans %}Translation updates{% endtrans %}
+
+
+`{% trans %}Full list of fixed bugs{% endtrans %}`__
+
+__ http://{{ i2pconv('git.idk.i2p') }}/i2p-hackers/i2p.i2p/-/issues?scope=all&state=closed&milestone_title=2.5.2
+
+**{% trans %}SHA256 Checksums:{% endtrans %}**
+
+::
+      
+     1aa1ac29620886a7d744424318287c67dc9ead488e6ab434848597ee9db7ce18  i2pinstall_2.5.2_windows.exe
+     751f48cfb380c8796bd645621b149114d55f32cd4330784cb287be9413b02569  i2pinstall_2.5.2.jar
+     f23d0746d72a55cccbd17f40762e491ae1b42cdf55d7e73404d213a84985ca73  i2psource_2.5.2.tar.bz2
+     adba8b7512d27a44ed876ec4beb39a82ebb34dc243ec024aff289e91823fc0c7  i2pupdate_2.5.2.zip
+     0d1d09d3d8199ea1a2ea983f5023125449ea55e93e20f5fbf1b7ad9e466bb6fc  i2pupdate.su3

i2p2www/spec/i2np.rst

@@ -1201,6 +1201,14 @@ Notes
   For replies to regular lookups, this facilitates discovery of new floodfills
   and "backwards" searching (further-from-the-key) for robustness.
 
+* The key for an exploration lookup is usually generated randomly.
+  Therefore, the response's non-floodfill peer_hashes may be selected using an
+  optimized algorithm, such as providing peers that are close to the key but not
+  necessarily the closest in the entire local network database, to avoid an
+  inefficient sort or search of the entire local database.
+  Other strategies such as caching may also be appropriate.
+  This is implementation-dependent.
+	
 * Typical number of hashes returned: 3
 
 * Recommended maximum number of hashes to return: 16