Re:_Issues_I¢ve_had_with_Void

On 16 Apr, Sulev-Madis Silber wrote:
> concern about getting backdoors info fbsd?
>=20
> lets think like criminal here
>=20
> it doesn't matter if contribution is anon or not. you could do both
> anyway
>=20
> as far as i know, i can't recall any cases like this here. maybe there
> are hidden ones. feel free to correct
>=20
> sadly there's nothing much one can do. it might still fall through
> cracks. there are number of things one can do here to mitigate the
> results. easiest would be to not run the same code everywhere. there
> are different versions of fbsd that could be used. this also catches
> accidental bugs. past that you need different oses. with different
> oses you also need different libs. and this only makes it harder for
> attack to succeed. but it's pretty hard always
>=20
> so unsure if any changes would need to be made. it would be
> ridiculously hard to verify all and this would essentially "ddos" the
> whole thing
>=20
> funnily, the recent unannounced ports system change around *kmod*
> ports versioning got my attention. turned out to be legit change
>=20
> then i mentioned to one port maintainer that changing up stream files
> could be compromise too
>=20
> now imagine if ports-upstream or base coder did this on purpose.
> pretty hard
>=20
> but i don't think that selfies with passports would help here. also
> don't forget that there are legit reasons for anonymity. there are
> weird states on this planet, etc. sure, same could have interest in
> hacking too
>=20
> but yeah. sadly, i wish fbsd would be more popular. but then, all bad
> things come along too! i would still try to make fbsd more popular
> tho, just too good to let them scare me
>=20
> if successful attack would go through, just remove the code and the
> attacker. and don't really blame one who got it in. similar to
> libarchive case
>=20
> fbsd is imho partially protected by it's pace. that's a drawback too.
> if you push the pace, you get mistakes. i've seen many happen in fbsd
> too. the problem was the pace, it has no name or face. in cba
> resulting changes were good. but yeah i frown on this. someone got
> annoyed i recall but that want never intent. idea was to keep quality.
> i have questioned the way the libxo or wg got in, for example. good
> ideas. way and pace, well...
>=20
> but yes, all those concerns are actually valid and worth to think
> about every so often
>=20
> both accidental bugs and deliberate attacks perspective
>=20
>=20
>=20
> On April 16, 2025 2:40:07 AM GMT+03:00, paige@paige.bio wrote:
>>How high of a standard is there for contributions to the core
>>components of FreeBSD (ie not ports) ?
>>
>>In my mind you guys would require some info about the contributor, as
>>in somebody with a real name as opposed to a gamer tag right?
>>
>>I=A2m just kinda pissed off at the sorry ass way some linux distros have
>>handled accountability and attribution, but particularly Void. My
>>sense is, with FreeBSD it matters a lot given the investment of the
>>people I know who have contributed to it over the years, I=A2m sure they
>>would like to believe this still matters and it=A2s too important to
>>allow contributions that can=A2t be definitively attributed to a real
>>person.
>>
>>I get with ports it=A2s a bit different, and that the Linux kernel is
>>not void. As a matter of fact I have a mirror of the ports distfiles
>>(at least about 400gb of them) and it=A2s scary to think about but it=A2s
>>at least a little less scary to me than the way Void handles package
>>management because I feel like somebody is willing to endorse at least
>>the core part of FreeBSD.
>>
>>Idk I guess I'm just starting to realize how much people don=A2t learn
>>from some mistakes. A couple of years ago when sshd got backdoored, it
>>was incredible to think that the attacker actually used coercive
>>tactics, and I=A2m sure a lot of people were shaken by it but it just
>>seems apparent to me that there are much simpler opportunities for
>>attacks against various Linux distributions.
>>
>>=D3=F4=DC=EB=E8=E7=EA=E5 =E1=F0=FC =F4=EF iPhone =EC=EF=F5
>=20

It's also possible to Trojan the compiler or other parts of the
toolchain.  Done skillfully, it could silently propagate to new compiler
releases.

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrust=
ingTrust.pdf