Could what has just happened to the AUR happen to FreeBSD ports?

bakul said:
I am tired of this sort of “concern trolling”. Why not talk about linux related problems in linux related forums and spare us of such discussions.
Click to expand...
because I'm a FreeBSD user and am genuinely concerned. I don't run it in production I'm not that brave, but I still don't want malware to wreck my home lab. No trolling involved. Negative attitudes today seem to abound. I would ask for the post to be deleted because of the attitudes people are giving but I won't because I think the genuine answers given by some are important and are worth keeping for others.
 
bakul it is not concern trolling to talk about FreeBSD and supply side attacks. The details why Arch Linux case is/isn't relevant for us is currently under discussion.

diizzy Ports have a checksum. The remote artifact can't change. If it changes, if it goes missing, it's a port build error.
We're talking about unmainteaned ports. We have Xyz 1.2 stale port, artifact still up there somewhere, building fine, but the Xyz is already at 1.8 and 2.x something

What happened in AUR case is somebody took those over. Cracauer explained how you can't drop in like into AUR and take ownership of them.
 
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.
Click to expand...
Plus that *BSD usually don't draw that much attention...
 
Tomolok said:
Plus that *BSD usually don't draw that much attention...
Click to expand...

Well yes, the AUR attack targeted developer credentials...now the fabled story that even FreeBSD core devs use Mac OSX for the desktop plays to our hand :D

BSDs are primarily used as servers or as building blocks for specialized OSes.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
Click to expand...
I think you got it a bit wrong.
Yes, we do have checksums and so do pretty much any other repo including AUR.

.SRCINFO - aur.git - AUR Package Repositories

aur.archlinux.org aur.archlinux.org

distinfo « mtf « archivers - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org

We do allow "random people" (aka contributors) to touch these, some committers are more lax than others when it comes to changes etc for the better or worse depending on your look at it.
 
Zare said:
Bottom line, AUR allowed random Internet people to take ownership of unmaintained ports and change them.
As far as I understand, with FreeBSD-ports such option is not on the table.

Whether we have 250 or 25k out of 30k ports stale, is not a risk if we don't allow random people to touch them.

Edit. P.S. Arch User Repo is hosted by Arch Linux but managed by "the community".
Lately there has been a developer around promoting his ports/packages thing. When I commented that nobody sane should use a 3rd party ports/packages system of some guy, I got backlash on the level that FreeBSD should really allow this modus for the project, that people should be able to plug in their alternatives, that it is the spirit of BSD and the rest of the bullshit. Well, there is your answer.
Click to expand...
I don't think there's anything that prevents something like FUR (FreeBSD User Repository) in addition to the existing portals, it's just a matter of having said repos and relevant signatures.

Also, I don't think FreeBSD or any OS, closed or open source, is imune to these kinds of attacks. The point of failure is always the same, be it what happened to Arch, XZ, etc. Someone with more or less effort just needs to gain the trust of the necessary people, lay low for a while and then it's a supply chain attack.

And, for the random internet person argument, aren't we all random people on the internet?
Is there any background check process to provide people with commiter access, and this by real legitimate entities?
 
fahrenheit said:
And, for the random internet person argument, aren't we all random people on the internet?
Is there any background check process to provide people with commiter access, and this by real legitimate entities?
Click to expand...

These are all completely different cases. The AUR problem is that it allows commits by non-committers, in effect. The XZ case was a carefully built up internet persona.

There is no formal background check.
 
  • Like
Reactions: mer
cracauer@ said:
These are all completely different cases. The AUR problem is that it allows commits by non-committers, in effect. The XZ case was a carefully built up internet persona.

There is no formal background check.
Click to expand...
That's trust-based and not really waterproof. A known committer with positive history can go there as well. While I only produce offline software, it would be interestinng to see an official checklist for administrators to avoid supply chain trouble.
The FreeBSD system is reliable thanks to a large amount of academic organisations that host the sources, so any fie difference will always be noticed soon. But how about the ports? What happens if a bad commiter plugs a rootkit in some obfuscated code that's auto-installed by make and makes it look like a nice visual update? Many users could build and install a malware as privileged user while unaware.
 
MG said:
That's trust-based and not really waterproof. A known committer with positive history can go there as well. While I only produce offline software, it would be interestinng to see an official checklist for administrators to avoid supply chain trouble.
The FreeBSD system is reliable thanks to a large amount of academic organisations that host the sources, so any fie difference will always be noticed soon. But how about the ports? What happens if a bad commiter plugs a rootkit in some obfuscated code that's auto-installed by make and makes it look like a nice visual update? Many users could build and install a malware as privileged user while unaware.
Click to expand...

A bad committer that obfuscates well will lead to a compromise.

Same for any organization. Google does background checks, but what really is the value? They aren't magic.
 
You must log in or register to reply here.
Back
Top