Hello all,

Attached to this email is a patch that includes one fix and several
improvements for the net/i2pd port.

IMHO, the changes you are proposing are mostly a matter of personal preference. 
I see no sufficient reason to deviate from upstream configuration choices, 
which are are kind of the default way of configuring i2pd, and also what most 
users are expecting.


I believe there is a reason to deviate from the default configuration,
which is why I changed the port and sent a patch to the mailing list.

Rather than a matter of "personal preference", I should have framed my answer 
as a choice about different trade-offs.

Similar ports in the tree, such as net/tor, also modify the default
configuration.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/tor/patches/patch-src_config_torrc_sample_in

You're right that other ports like net/tor have patches like that. But is this 
a good enough reason to just copy and paste? My point was that there's no 
*practical* benefit to set i2pd's working directory as /var/i2pd instead of 
/var/lib/i2pd. On the contrary, there's a potential drawback, also on the 
practical level: the risk of confusing some users. The trade-off here is style 
and consistency on the one side vs. practicality on the other.

First, the patch addresses an issue related to log handling. By default,
i2pd uses a separate log file located at /var/log/i2pd/i2pd.log.
However, this file is not rotated by newsyslog(8), causing it to grow
without bounds. The proposed solution is to configure i2pd to write its
logs to /var/log/daemon by updating the i2pd.conf configuration file.

I personally like to have a separate log file for i2pd, and not mix its output 
with other things. That's a matter of taste, and anyway log rotation can be 
configured in /etc/newsyslog.conf .


Although log file rotation can be configured for the i2pd log file, it
is not configured by default. This causes the file to grow unbounded,
and users who are unaware of this issue may one day find out that their
/var partition is full, as happened to me. At the very least, add a note
to the README for the port to make users aware of this issue.

Thinking a bit more about this issue, I agree with you that sending i2pd logs 
to syslogd should be set as the default, instead of writing them to separate 
log file, albeit for a different reason: because rotating the log file is a 
little bit tricky in this case.

In order to rotate the log file, you have to restart the daemon, but it's good 
practice to stop i2pd gracefully: this is important for your peers and the 
operation of the I2P network as a whole. But to initiate a graceful shutdown, 
you either have to use the web interface or send a signal to the process with a 
command like `kill -INT $(cat /var/lib/i2pd/i2pd.pid)`. You then have to wait 
for the daemon to effectively stop, which usually takes 10 minutes.

You could add it as an instruction to the RC script so that the daemon always shuts down gracefully.


This is documented by the i2pd developers 
(https://docs.i2pd.website/en/latest/user-guide/run/), but anyway adding a note 
to the README about that sounds like a good idea to me.

Second, the directory used to store port-related files changes from
/var/lib/i2pd to /var/i2pd, which better aligns with the OpenBSD style.
To accomplish this change, the patch updates the PLIST, the RC script,
and the i2pd.conf configuration file.

It is true that /var/i2pd would "better align with the OpenBSD style", but 
apart from that stylistic issue, what's wrong with /var/lib/i2pd ? Using this directory 
does not prevent i2pd from running fine on OpenBSD, and it is referenced by all guides 
and tutorials on i2pd, so changing it could confuse new users. I don't think it would be 
worth introducing a lot of changes in the PLIST, rc script and default config file.


If anyone has any problems, they can consult the port tree to see how
the net/i2pd port works. Things are usually different in OpenBSD than in
Linux, which makes OpenBSD less convenient to use. However, convenience
is not the focus of this operating system.

We can agree that convenience is not the main focus of OpenBSD, it's definitely 
not Linux Mint, but even the most hardcore OpenBSD users are not opposed to any 
form of convenience ;-)

Finally, the i2pd.conf and tunnels.conf configuration files are adjusted
to improve security and usability. Specifically, the web interface and
the default IRC tunnel are disabled, log verbosity is reduced, and
additional address book sources for I2P aliases are configured.

That's also a matter of personal choice. I personally use the web interface, 
which is a very convenient way to interact with your daemon, and I guess that a 
lot of users are also expecting it to work. Security-wise, it's not too bad as 
long as you don't expose it publicly on the internet. If you don't like it, 
you're free to disable it in the configuration file.


Of course, it's terrible in terms of security. The web configuration
interface doesn't have a password by default, so any user on the system
can perform actions on the daemon, such as shutting it down and
deanonymizing you. It's another ticking time bomb, just like the
separate configuration file. If I had permissions in the repository, I
would remove the port right now for this reason alone.

You're right that the web interface definitely adds some attack surface. But what's the threat model exactly? 
The web interface allows "any user on the system", let's say a malicious user, to shut down the 
daemon, namely enables a denial-of-service attack. This malicious user could also access private information, 
like your router identity or the B32 addresses of your tunnels. That's probably what you mean by 
"deanonymizing you"... But bear in mind that "any user on the system" can easily get the 
machine's IP address anyway, which is usually what you want to conceal. And even with the web interface 
disabled, any local user could also access i2pd's configuration files, which are world-readable by default 
and can include some private information (encrypted LeaseSets keys in /etc/i2pd/tunnels.conf for example).

On the other hand, the web interface can be very useful to control and monitor 
the i2pd daemon. It's impossible to know what proportion of i2pd users rely on 
this feature, but my guess is that it is widely used, hence the i2pd developers 
enabled it by default.

I see net/i2pd as the ideal version of the I2P router for servers and desktop users who don't use I2P for BitTorrent. If you want a good web interface, the best option would be to use the original version (net/i2p), which has a very rich web interface.


In any case, we can also add a note to the README warning users about the risks 
associated with the web interface.

BTW, if you really think i2pd is so dangerous that it should be removed from 
the OpenBSD port tree, why are you using it in the first place? ;-)

The same applies for the IRC tunnel, log verbosity, etc. I guess most i2pd 
users are editing i2pd.conf and tunnels.conf anyway.

I don't use the IRC tunnel either, but I've always seen this configuration 
snippet as an example provided by the developers to demonstrate how to 
configure tunnels.


If you had checked my patch, you would have seen that the configuration
was not removed. I only commented it out to prevent you from having an
unnecessary open door to the network on your system that could be used
for malicious purposes. If an attacker knows you're using i2pd, they
will also know that this port is open locally.

I checked your patch, don't worry :-) IMHO you're exaggerating the risk 
introduced by this configuration snippet in tunnels.conf. If you don't have an 
IRC client, or any other program, with an active connection on 127.0.0.1:6668, 
I don't see how an attacker could exploit that, even if you have reasons to 
think that the IRC server is malicious or compromised. *In theory*, this tunnel 
could open a covert channel for a malicious application running on your 
machine, allowing it to exchange data with an IRC server over I2P. If your 
threat model is so high that such a targeted attack sounds likely to you, I 
wish you good luck, but fortunately you know how to edit i2pd's configuration 
;-)

I look forward to any feedback or suggestions.

At the end of the day, I think that porters should not set their personal 
configuration preferences as the default for all users; we should stick to 
upstream's choices as long as they're working under OpenBSD and don't introduce 
unnecessary risks. Moreover, i2pd's configuration is documented and the users 
can decide for themselves what's good for their use case.


It's like pouring oil on the floor at the entrance to a building and
expecting people to clean it up if they don't want to slip.

Sure, the i2pd developers and myself like to pour oil on the floor for no 
reason, and if nobody cares, we even may set it on fire and burn the entire 
building, just for the sake of it. Or maybe you're overreacting a little ;-)

Best regards,
David.


By the way, in my last patch, I forgot to use the LOCALSTATEDIR macro in
the certdir variable of the RC script. I am attaching the corrected
patch to this email.

Please find attached my counterproposal: a patch changing the main 
configuration file to send logs to syslogd by default, and adding a few useful 
explanations in the README.

David, this patch doesn't include all your ideas, but borrows some of them, and 
I hope you will consider it as an acceptable and constructive trade-off ;-)

Best regards.

Reply via email to