While true and some will do it for that reason, I bet most do it simply because the friction to forking is so low.

Some might have an intention to work on it but then don’t or might start looking at it in detail then give up or get to busy or lose interest.

Others might just click it to save it for later.

And don’t forget all the people that click it by accident.

It’s not like it is a big investment to click the button.

I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c

I personally hate global menu bars. They do not work with focus follows mouse. The way menus currently work is fine for me and I would not want to lose that to, IMO, a much worst system. Any global menu implementation would need to be able to be disabled and better to have it off by default. And I would rather see effort in developing other features personally - though mostly as I would never use this feature.

* in your commands is expanded by the shell before tar sees them. It also does not expand hidden files.

So when you do admin/* the shell expands to all non hidden files inside admin. Which does not include admin/.htaccess. So tar is never told to archive this file, only the other non hidden files and folders. It will still archive hidden files and folders nested deeper though.

In the second example * expands to admin and the other does which are not hidden at that level. Then tar can open these dirs and recursivly archive all files and folders including the hidden ones.

You can see what commands actually get executed after any shell expansions if you run set -x first. Then set +x to turn that off again.

Here is an example using ls:

$ set -x; ls -A foo/*; ls -A *; set +x
+ ls --color=tty -A foo/baz
foo/baz
+ ls --color=tty -A foo
.bar  baz
+ set +x

One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.

Those are not port scans though. A port scan is when someone is systematically checking a large number of ports on a system to find which ones are open and possibly what is running on them. A random connection to a single port is not a port scan and not something pretending that other ports are open will help at all with. And open services are typically announced in some other way and don’t require scanning all ports on the whole internet to find. Though you may get connections from people that get the address wrong, or have an old IP that has been reused or something - those are not scans though.

Really it seems like you’re advertising your lack of imagination in this context than a legitimate lack of possible uses for spoofing open ports.

I never said that. I have mentioned actual use cases for wanted this in other comments in this thread - namely slowing down attackers by making them do more work by not being able to do quick checks for open ports. My responses here though are about the postulation that you could gain extra information with an open port in eBPF vs just a closed one or simply a service running on that port. Thus I do not think that is the reason you would want this. Never said there are no reasons at all that you would want to pretend ports are open.

What is a benign scan? Why do you need to scan a system if you are not trying to figure out what it is running - which is something only attackers or the server admins (looking for things that should not be exposed) would want to do. Any third party scanning for open ports I would consider an attack. Though it might just be an automated system looking for weaknesses - it is still an attack.

What is a fake port?

Port knocking does not require open ports though? It works by trying to connect to closed ports in a specific sequence does it not?

What extra information could you gather? Note I assume we are talking about a fake open port here, not an active service listening on a port that can communicate with the attacker. That could be done without eBPF though - so what advantage would eBPF have here?

And I assume this is more on the level of responding to pings than creating full connections? At which point you are only dealing with a single packet from the sender. So what value does responding give you here?

Would it even need to pretend it is open? If it can fake a port being open then it can tell when a close port is being pinged. So can outright block connections from those IPs without ever pretending it is open?