openbsd@systemfailure.net 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 ports@openbsd.org 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. > > > sonya@i2pmail.org 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.
No comments:
Post a Comment