Re: MTU of i2pd for OpenBSD comments/issue

[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.