Releases: i2p/i2p.i2p
I2P 2.3.0-15-rc **Release Candidate Needs Testers**
5287da1
zzzi2p
zzz
I2P 2.3.0-15-rc Release Candidate Needs Testers
This updated dev build fixes a regression discovered in the
InboundMessageDistributor where garlic replies were being dropped
inappropriately. It also includes the security improvements from
2.3.0-12 and 2.3.0-14-rc.
Help us test this release candidate
If you want to help, you can get a dev build at our official Github:
We depend on bug reports and feedback
The I2P network is getting some big upgrades this release and we're
excited to get them out to you. Please help us make the router better
by reporting your bugs. For more background on the recent changes, see:
- https://github.com/i2p/i2p.i2p/releases/tag/i2p-2.3.0-12
- https://github.com/i2p/i2p.i2p/releases/tag/i2p-2.3.0-14-rc
Please reach out to us at:
I2P 2.3.0-14-rc Release Candidate Needs Testers
I2P 2.3.0-14-rc Release Candidate Needs Testers
This updated dev build features the changes which were present in
the earlier 2.3.0-12 dev build, plus it updates and implements
handling for "Congestion Capabilities" a new feature which helps
us respond to attackers who attempt to congest the network by consuming
excessive resources.
Help us test this new feature for hardening the network against attack
If you want to help, you can get a dev build at our official Github:
What are Congestion Capabilities?
When you are using I2P to make connections, you can be one of two basic
things, a "Router" or a "Client." Routers make connections to eachother
and they form the I2P Network itself, and Clients are used to build applications
inside the I2P network like HTTP Servers, for instance by forming Tunnels
between routers. In order to build these connections, a Router broadcasts it's
"RouterInfo" to the Network Database, which is where Capabilities come in.
A RouterInfo contains a set of "Capabilities" which indicate what the Router
it represents is capable of. If it is capable of connecting directly or whether
it requires a relay/introducer, on which addresses, whether NTCP2 or SSU2, and
bandwidth tier are all expressed inside the RouterInfo. With this change, when a
router is nearing the limit of what it can handle, it will publish an additional
Capability in it's RouterInfo which will indicate the level of congestion it is
experiencing.
When other routers see that this router is in distress, they can then "back off"
and request fewer or none of their client tunnels be built through the affected
router, giving it time to recover and reducing the chances that it's resources will
be exhausted.
Please help us test the Congestion Capabilities, and report your issues at:
2.3.0-12 Important Dev Build
7ab0639
zzzi2p
zzz
I2P 2.3.0-12 Needs Testers!
I2P is closing in on the long-delayed release of the 2.4.0 router, which
contains a major redesign of one of the oldest and most essential shared
systems in I2P, the Network Database, or NetDB. The NetDB is I2P's DHT, a
variant of Kademlia which uses a technique called "Floodfill" to elect peers
to flood out information efficiently. If the DHT doesn't work, the routers that
make up the network won't be able to find the peers that it needs to operate, so
we have to be very sure that we've done it correctly.
TL:DR This change needs widespread testing
If you want to help, you can get a dev build at our official Github:
After downloading, copy the i2pupdate.su3 file to your I2P install directory and
restart. In about a minute, your I2P router will be upgraded to the new version.
Want to learn more? Read on...
This change will allow I2P to manage multiple versions of the NetDB, which may
co-exist in different "Contexts" on the same router, allowing them to enforce
secure behavior based upon their role when used by the router. In the new
design, a NetDB can assigned either a "main" role, or a "client" role.
In this new model, every router has a single "main" NetDB, which is used for
Floodfill operations, network maintenance, and detatched LeaseSet lookups.
However, routers that have Client Tunnels also have an equal number of client
NetDBs, which hold only the information required to operate their clients. When
a client publishes it's LeaseSet out a client tunnel, it is managed from within
the client NetDB, and when a client needs a LeaseSet, it is looked up and stored
in the client NetDB. This allows 2 things to change:
- when using the main NetDB, the router is able to handle every LeaseSet in
exactly the same way, including those belonging to it's own clients. - it allows us to maintain and organize multiple copies of a single LeaseSet
so that a client maintains a copy of all the LeaseSets it needs, and the client
is solely responsible for keeping them up to date.
This allows us to greatly simplify the way we handle LeaseSets by identifying
how the LeaseSet will be used with the context in which it is being stored. This
design can eliminate an entire hypothetical attack class where an attacker
attempts to confuse the DHT about the origins of a particular LeaseSet. As an
added benefit of employing this technique, the kinds of information that a NetDB
needs to use is known in advance. This is therefore a significant advance for
I2P's security and efficiency.
As I said in the pre-release forum post, this change has the potential to break
the network, and it cannot go live if we're not sure it's working correctly.
Please help us test the new NetDB, and report your issues at:
I2P 2.3.0 - Security Fixes, Tweakable blocklists, DTG API
This release contains fixes for CVE-2023-36325.
CVE-2023-36325 is a context-confusion bug which occurred in the bloom filter.
An attacker crafts an I2NP message containing a unique messageID, and sends that messageID to a client.
The message, after passing through the bloom filter, is not allowed to be re-used in a second message.
The attacker then sends the same message directly to the router.
The router passes the message to the bloom filter, and is dropped.
This leaks the information that the messageID has been seen before, giving the attacker a strong reason to believe that the router is hosting the client.
This has been fixed by separting the bloom filter's functionality into different contexts based on whether a message came down a client tunnel, an exploratory tunnel, was sent to the router directly.
Under normal circumstances, this attack takes several days to perform successfully and may be confounded by several factors such as routers restarting during the attack phase and sensitivity to false-positives.
Users of Java I2P are recommended to update immediately to avoid the attack.
In the course of fixing this context confusion bug, we have revised some of our strategies to code defensively, against these types of leaks.
This includes tweaks to the netDb, the rate-limiting mechanisms, and the behavior of floodfill routers.
This release adds not_bob as a second default hosts provider, and adds notbob.i2p and ramble.i2p to the console homepage.
This release also contains a tweakable blocklist.
Blocklisting is semi-permanent, each blocked IP address is normally blocked until the router is restarted.
Users who observe explosive blocklist growth during sybil attacks may opt-in to shorter timeouts by configuring the blocklist to expire entries at an interval.
This feature is off-by-default and is only recommended for advanced users at this time.
This release also includes an API for plugins to modify with the Desktop GUI(DTG).
It is now possible to add menu items to the system tray, enabling more intuitive launching of plugins which use native application interfaces.
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.
i2p-2.2.1
After the I2P 2.2.0 release, which was moved forward to accelerate mitigations for the DDOS attacks, we learned about a few developing issues which made it necessary to build and release new packages. This release fixes an issue within Ubuntu Lunar and Debian Sid where the router console was inaccessible using an updated version of the jakarta package. Docker packages were not reading arguments correctly, resulting in inaccessible configuration files. This issue has also been resolved. The docker container is now also compatible with Podman.
This release syncs translations with transifex and updates the GeoIP database.
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.
DETAILS
Changes
-
Fix missing Java options in docker/rootfs/startapp.sh -
Detect when running in Podman instead of regular Docker -
Update Tor Browser User-Agent String -
Update local GeoIP database -
Remove invalid signing keys from old installs -
Update Tomcat version in Ubuntu Lunar and Debian Sid
Full list of fixed bugs: http://git.idk.i2p/i2p-hackers/i2p.i2p/-/issues?scope=all&state=closed&milestone_title=2.2.1
i2p-2.2.0
github release of I2P version i2p-2.2.0 - these releases happened via systems that pre-date our use of github.
Please see the corresponding git tag, and the history.txt at the time of the tag, for more detailed information about the release.
This release was tagged on github on 2023-04-17
i2p-2.1.0
zzzi2p
zzz
a5d649b
zzzi2p
zzz
github release of I2P version i2p-2.1.0 - these releases happened via systems that pre-date our use of github.
Please see the corresponding git tag, and the history.txt at the time of the tag, for more detailed information about the release.
This release was tagged on github on 2023-04-17
i2p-2.0.0
zzzi2p
zzz
3d49093
zzzi2p
zzz
github release of I2P version i2p-2.0.0 - these releases happened via systems that pre-date our use of github.
Please see the corresponding git tag, and the history.txt at the time of the tag, for more detailed information about the release.
This release was tagged on github on 2023-04-17
i2p-1.9.0
zzzi2p
zzz
3995403
zzzi2p
zzz
github release of I2P version i2p-1.9.0 - these releases happened via systems that pre-date our use of github.
Please see the corresponding git tag, and the history.txt at the time of the tag, for more detailed information about the release.
This release was tagged on github on 2023-04-17
i2p-1.8.0
zzzi2p
zzz
8256f61
zzzi2p
zzz
github release of I2P version i2p-1.8.0 - these releases happened via systems that pre-date our use of github.
Please see the corresponding git tag, and the history.txt at the time of the tag, for more detailed information about the release.
This release was tagged on github on 2023-04-17