seccomp
BUG: propagate notify_used when merging filter collections
Merging filter collections didn’t carry over notify_used; if the source had SCMP_ACT_NOTIFY rules, the merged filter could skip requesting SECCOMP_FILTER_FLAG_NEW_LISTENER, yielding no listener FD. This ORs the flag from source to destination to keep seccomp notification working.
This bug was discovered with ZeroPath.
coverage: 89.024% (-0.02%) from 89.046% when pulling 6358d0eb78ed9a3a18cb48447419517aae8d2095 on MegaManSec:pass into 2bc718995e782a8473ba9db8509a398ef69b2edc on seccomp:main.
Hi @MegaManSec, thanks for catching this and sending a fix!
I would like to request to small changes to the PR/commit:
- Could you copy the problem and fix description at the top of this PR into the commit description? This preserves the explanation of the change in the git log so it easier for us to understand the logic behind the change in the future.
- Instead of using a GH "noreply" email in your sign-off, please use a proper email.
Thanks!
- Done!
- I would really prefer not to. This is to reduce the amount of spam I receive.
- Done!
Thanks!
- I would really prefer not to. This is to reduce the amount of spam I receive.
I see you've listed an email on the contact page of your website, is the problem you don't want to list it in the PR, or you don't want it in the git log at all? We really want to have an email address in the git log, it's helpful for a number of things.
I see you've listed an email on the contact page of your website, is the problem you don't want to list it in the PR, or you don't want it in the git log at all? We really want to have an email address in the git log, it's helpful for a number of things.
I've found that when I add my email address in any git log which is uploaded to github, i start to receive some type of spam on that email address in a matter of days; using the noreply github one allows it to be obvious where the PR is coming from (megamansec), while ensuring I don't receive that spam. Using the noreply github one also links to commit to my github account; which otherwise wouldn't be linked, as i remember.
Unfortunately, I think we really want an email address in the git log as I want the contact info to remain useful outside of GH.
Can I simply write another email address, but not sign with it? By signing with it, and for it to be associated with my github account, I need to do one of the following:
- Use my (github-exclusive) email address as the signer,
- Associate (register) a new email address on my github account, which means I will have two email addresses registered to my account, which defeats the purpose of point number one.
Since Github does not associate commits with a github account by the actual committer, but rather the Author and/or the committer of the commit, if this makes it difficult for me.
Thanks!
Can I simply write another email address, but not sign with it?
Perhaps some clarification would help here ... when I talk about a sign-off, I'm talking about the metadata at the end of the patch that satisfies the DCO requirement and looks like this:
Signed-off-by: name <email>
... it's entirely independent from anything GH does and from anything you may do with commit signing. So, yes, as long as you have a Signed-off-by: ... line with a valid email we're going to be happy :)
Hopefully that helps?
I'm talking about the metadata at the end of the patch that satisfies the DCO requirement and looks like this
No, that doesn't work, because the DCO bot does not like that the committer email address differs from the sign-off:
Commit sha: 6358d0e, Author: Joshua Rogers, Committer: Joshua Rogers; Expected "Joshua Rogers [email protected]", but got "Joshua Rogers [email protected]".
Don't worry about the DCO bot, we can override as needed. I just manually approved the rest of the CI, let's make sure it passes cleanly, but from what I saw in the PR I don't expect any problems.