PF submission stuck waiting for nearly 4 years

Hi SirDice , if I understand correctly, one can use poudriere to automatically integrate ones' own patches into packages, so one could apply patches like this for personal needs.

But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?
This is a very serious issue to me, as in particular cases (right now mostly nvidia related stuff, for example the unfixed resume-breaking bug in vesa.ko I already PRed in 2017, or the modifications necessary for Optimus combos already waiting 4 or 5 years for integration) there is no way around to build a modified base system, just to make things work.

Can a local poudriere repo cover these cases also?
 
Snurg said:
But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?
Click to expand...
It's called git. Branch the source and you can add your own patches.
 
I will post on the mailing list, been a while since I posted there. ;) I get the person is busy I was hoping there was more than one person who had the ability to commit the code.
 
It may just have fallen through the cracks. "I thought you were going to look at it." "No, I thought you were looking at it". I see these things happening at work too. When you ask 10 persons to do something, nobody does anything as they all think someone else is going to do it.
 
Snurg said:
But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?
Click to expand...
Of course using git(1) is the most correct solution to this. But if you don't contribute to base/world, there's a simple alternative: use a unionfs (mount_unionfs(8)) to mount the genuine sources below your working tree. Excerpt from my fstab(5):
Code: 
/src/12.2-REL   /usr/src                unionfs         rw,late,noatime,below,copymode=transparent  0       0
/src/12.2-REL   /home/paul/Projects/FreeBSD/src/12.2-REL unionfs rw,noauto,noatime,below,copymode=transparent       0       0
/src/12-STABLE  /home/paul/Projects/FreeBSD/src/12-STABLE unionfs rw,noauto,noatime,below,copymode=transparent      0       0
/src/13-STABLE  /home/paul/Projects/FreeBSD/src/13-STABLE unionfs rw,noauto,noatime,below,copymode=transparent 0       0
/src/14-CUR     /home/paul/Projects/FreeBSD/src/14-CUR unionfs rw,noauto,noatime,below,copymode=transparent 0       0
I have a directory patches in the root of my working tree, which holds the *.diff patches. Everything you do in the working tree will survive updates on the underlying source tree. Before each freebsd-update(8), I remount /usr/src as nullfs(5), so that my local changes & additions are completely shadowed. Then the sources get their updates on the underlying tree.
EDIT for the sake of completeness: alternatively, you can remove the src component from freebsd-update.conf(5) and use gitup(1) or git(1) to download & update the sources tree(s). /EDIT
SirDice said:
It may just have fallen through the cracks. "I thought you were going to look at it." "No, I thought you were looking at it". I see these things happening at work too. When you ask 10 persons to do something, nobody does anything as they all think someone else is going to do it.
Click to expand...
:) Oh yes. Of the few things I found out about human behaviour, one is this: when you ask in a crowd: "Can someone help me with this, please?", noone will help, all looking at each other & wait for the 1st to jump in. When instead you ask somebody specifically, if you don't know his/her name, fixate with your eyes or touch on the arm or shoulder, your chances to get help are much better.
 
Last edited:
Mjölnir said:
Of the few things I found out about human behaviour, one is this: when you ask in a crowd: "Can someone help me with this, please?", noone will help, all looking at each other & wait for the 1st to jump in. When instead you ask somebody specifically, if you don't know his/her name, fixate with your eyes or touch on the arm or shoulder, your chances to get help are much better.
Click to expand...

Bystander effect - Wikipedia

en.wikipedia.org en.wikipedia.org
 
  • Thanks
Reactions: a6h
With this patch, a standard pf nat (without any option) allow to create NAT hole: I don't think it's a "security downgrade" problem, because NAT was never desing for security.
Click to expand...
Also, from the RFC
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
...
Endpoint-Independent Mapping:

The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to any
external IP address and port. Specifically, X1':x1' equals
X2':x2' for all values of Y2:y2.
Click to expand...
This means machines behind NAT can expose arbitrary UDP and TCP ports to the Internet permanently. What could go wrong?

I don't want this. I hope it's put behind a feature flag if it's ever adopted.
 
For gaming it usually suffices to run something like net/miniupnpd in combination with PF. Works for other applications like P2P or Skype and others. Most modern applications support UPnP (most home modem/routers have this functionality too).
 
I don't mean to be harsh, but I'm not a fan of Upnpd either. It does the same thing. Allows random machines on the inside network to punch arbitrary holes through your firewall.

The only way to do something semi-secure in this setup is to set up a default deny for outgoing and only allow some combinations of host and port for outgoing connections. Even then you'd be subject to browser hijacking attacks, or malware that used well-known ports to do its work. It seems like far more work than just doing the static port mappings for the few games that need them (I'm looking at you Nintendo Switch).

That reminds me, I gotta go turn a bunch of those off now that my kids have moved on to other games.
 
Jose said:
This means machines behind NAT can expose arbitrary UDP and TCP ports to the Internet permanently. What could go wrong?
Click to expand...
Nothing at all. That is, if you didn't misuse NAT for "security", of course.

OTOH: let's talk IPv6. You wouldn't want to use NAT there, right? And you would (of course) add filtering rules on your firewall box? Why is IPv4 still an issue (e.g. for gaming?) Maybe this patch just got obsolete anyways…
 
Zirias said:
Nothing at all. That is, if you didn't misuse NAT for "security", of course.

OTOH: let's talk IPv6. You wouldn't want to use NAT there, right? And you would (of course) add filtering rules on your firewall box? Why is IPv4 still an issue (e.g. for gaming?) Maybe this patch just got obsolete anyways…
Click to expand...
The absence of NAT is one of the reasons for poor adoption of IPv6. We learned in the '90s that putting every machine on the Internet with a public IP is a really bad idea.

Edit: We relearned this lesson with AWS "classic" networking. Hence why everyone uses VPCs now.
 
You're getting it the wrong way around. The single worst misconception about NAT was always the idea, that it would help security, cause "hey, you're not reachable", which was NEVER true. It was always just a workaround for a shortage of addresses. There's never an alternative to writing sane packet filtering rules for your specific needs.
 
Well this bad misconception has been working pretty well for me and most people for several decades now. I'm going to stick with what works if you don't mind.
 
Mjölnir said:
there's a simple alternative: use a unionfs (mount_unionfs(8)) to mount the genuine sources below your working tree.
Click to expand...
Damn good idea! Thank you ???
I will research how to do it this way, as I do not believe regular users are willing to set up a github account, just to customize the system.

This would make easy to offer various patches in the postinstaller, so these the user wants can just be sort of "overloaded" over the source tree.

For example in cases the maintainer says "I don't like this bugfix/patch/modification so I ignore it", or says "I don't understand the bug due to lack of technical knowledge" and thus refuses the fix, the user then could easily decide himself.

And when good fixes/patches/modifications are widely used and prove reliable, this kind of voluntary testing could benefit the whole community, too.
It might help weed out bugs/regressions in advance, and also provide positive feedback that can help judge whether a patch is actually mature.
I am now thinking about what could be the best way to report user experience with patches/fixes that have been suggested but are not being integrated for whatever reason.
 
Yeah, well I guess I'm dreaming about the past 20 years of no intrusions both in my professional life and in my personal setups. But I'll run out and implement your suggestions right away.
 
No, you're wrong. Stalemate.

Come back when you have some actual vulnerabilities you want to talk about.
 
NAT can be deployed easily. IPv6 deployments did not account for the security and privacy "features" of NAT and IMO, that's what hobbled its rollout. Putting the ethernet MAC in the interface identifier? I mean, thanks a lot for THAT idea.

"write a firewall ruleset" is not what you tell consumers.
 
I'm not sure what you're talking about with snake oil. NAT has by default, clear security and privacy benefits that connecting machines directly to the internet via IPv6 with no firewall does not confer. There is not a phrase or term for an IPv6 firewall ruleset or translation mechanism that will give the same benefits.
 
I find it interesting you have no capability to explain your position on "lol NAT security."

For my part, as to what the "benefits" are, I'll simply assert that NAT prevents arbitrary enumeration of the computers behind the NAT and in general, access to open ports on those machines.
 
You must log in or register to reply here.
Back
Top