[email protected] wrote:
Hi and thank you very much, both for your development efforts and for this
information.
The latest release of i2pd (2.61.0) is not in OpenBSD ports yet, in part
because there is an ongoing discussion about the pledge/unveil part on the
[email protected] mailing list.
Here's the entire thread: https://marc.info/?t=178465706100002&r=1&w=2 . The
most relevant messages for you are from Andrew Kloet, who is currently writing a
different implementation of pledge/unveil for i2pd, from Stuart Henderson (one of the
key figures in OpenBSD ports) and from Theo de Raadt (as you may know, he is OpenBSD
founder and lead developer).
Andrew sumbitted a pull request on i2pd's Github repo a few hours ago:
https://github.com/PurpleI2P/i2pd/pull/2436
I just read all these messages and haven't had time to write on the mailing
list yet, but I hope this discussion will reach a conclusion soon...
In the meantime, I'm adding Andrew and David to my response, to make them aware
of your message and my answer.
Best regards.
[email protected] wrote:
hello,
this is a note of a current 'i2pd' development state. please, ignore,
if not needed or out of your concern.
the following two commits implemented "pledge/unveil" restriction for a
"i2pd" daemon (https://github.com/PurpleI2P/i2pd.git):
$ git show -m -p b4e3059ce22db148e1146e8a3f07d1a58b4d38d2
$ git show dbe0aab063f003fe54edb5284586d844e418a74e
the result is an OpenBSD specific options section:
$ i2pd --help | grep -i openbsd
OpenBSD specific options:
--openbsd.pledge_file arg OpenbSD file with pledge rules
--openbsd.unevil_file arg OpenBSD file with unevil rules
--openbsd.unevil_enabled arg (=1) use unevil rues
--openbsd.pledge_enabled arg (=1) use pledge rules
also we've missed the "entry point" for pledge/unveil and now fail to
get/set proper MTU via SIOCGIFMTU and SOCK_DGRAM calls (as we call'em
after daemon process is "pledged"). until we fix it in i2pd
daemon routine logic, MTU should be set manually (autodetection is
broken):
$ i2pd --help | grep -i mtu
--ssu2.mtu4 arg (=0) MTU for ipv4 address (default: detect)
--ssu2.mtu6 arg (=0) MTU for ipv6 address (default: detect)
otherwise, the default value of:
"const size_t SSU2_MIN_PACKET_SIZE = 1280;"
is set.
until the fix is ready, we suggest to mention about this case in
"/usr/local/share/doc/pkg-readmes/i2pd"
thank you for your attention,
best regards,
sonya
I think OpenBSD's biggest problem starts when you move beyond the base
system. Once you rely on third-party software, things become much less
predictable because most developers do not use the security mechanisms
that make OpenBSD so strong in the first place.
That is frustrating even with relatively simple software such as i2pd.
With larger projects, it becomes much worse. I tried porting SimpleX
Chat to OpenBSD, and it was a nightmare. There is also a Monero port
that builds successfully but still has runtime problems.
Many people who care about security also care about privacy and
anonymity, but using modern privacy tools on OpenBSD is often far more
difficult than it should be. The system provides excellent security
features, yet much of the software that privacy-conscious users actually
need does not take advantage of them or does not work properly on
OpenBSD at all.
The main issue is that many developers focus on making their software
work on the most common platforms and stop there. Privilege separation,
process isolation, portability, and support for stricter operating
systems are often treated as secondary concerns.
I understand why. Privacy and anonymity software is already difficult to
develop and maintain. Still, software designed to protect users should
also take the security of the underlying system seriously.
Modern tools, including AI, can make porting, debugging, and identifying
platform-specific assumptions much easier. There is less justification
than ever for ignoring portability and basic security design.
