Updates to SECURITY.md files
by Brian Stansberry
One of our TODOs related to moving to Commonhaus is housekeeping related to
SECURITY.md files.
Note: This is initially intended as a discussion thread, not a call for
people to start making updates.
1) A lot of our SECURITY.md files say to report issues via email to
secalert(a)redhat.com. This is ok for now (i.e. this isn't a crisis) but we
should move to using a community address.
WildFly AS has a security(a)wildfly.org address, which is what we ask people
to use on a number of SECURITY.md files, including the one in the main
wildfly/wildfly repo. There's a small group of people who monitor that
address and react to posts on it. We bring in others to assist when needed.
I think all projects under the WildFly umbrella at Commonhaus should use
security(a)wildfly.org in their SECURITY.md. For sure repos under the WildFly
AS top-level project should. If other top-level projects have their own
different mechanisms, that's ok.
Thoughts?
2) Call for volunteers! We're considering adding GPG encryption
instructions to our recommended SECURITY.md content, so people can encrypt
their reports. If you're interested in helping with that, please let Darran
or I know. Tasks include working on:
* Evaluation of whether we should publish a GPG key for CVE reporting.
* Creation of said key including securely sharing of the private key with
the required audience.
* Coordination of publication of the public key on relevant SECURITY.md
files.
The last one I see as mostly being about drafting suitable language and
assisting with questions about how to incorporate the language.
Before people start changing lots of SECURITY.md files we should discuss a
bit here first and see what comes of #2 above. Changing dozens of files
only to turn around and change them again a few weeks later would be a
waste of valuable time.
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
10 months
Developer Certificate of Origin for WildFly projects
by Brian Stansberry
One of the few requirements that Commonhaus puts on its projects is that
they use either a Developer Certificate of Origin or some kind of
Contributor License Agreement system. This is a reasonable requirement and
I believe some projects associated with WildFly are already using a DCO.
If you're impatient, skip to #3 below...
A CLA isn't really practical to administer for an organization of our
scope; a DCO is far simpler.
There are three things we need to do for a good DCO system.
1) Add a dco.txt file in each repository. Commonhaus has a jbang script
"policy-panda"[1] that checks for this when run against a GitHub org.
You may have noticed that a few days ago I spammed 88 repos in the wildfly
and wildfly-extras GH org with PRs to add this file. In case it is helpful
for other orgs, the script is at [2].
2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. This is
also checked by the Commonhaus policy-panda script.
Narayana has nice text in [3] that I think is appropriate most anywhere.
(Note that the requested license/copyright header says "The Narayana
Authors". For repos in the wildfly and wildfly-extras orgs it would be "The
WildFly Authors".)
I don't think we should take immediate action on this, i.e. don't everyone
go off and start editing existing files separately. We can make a plan.
FWIW, my jbang script at [2] can also send up modification PRs, so if we
determine that big sets of repos should all use the same file it may be
helpful.
3) DCOs involve an attestation from the person submitting that code that
they agree with the DCO. This is typically done via a 'Signed-off-by' line
in the git commit message. This can be done via the -s flag (lower case) to
the git commit command.
I expect there will be lots of discussion around the logistics of adding
these signoffs! There already are in the brand new zulip thread around
this. Chatters -- please post a summary of the discussion to this thread as
many WF developers are not actively following zulip!
Note that the git commit flag for a signoff is "-s" NOT "-S" which is a
different thing that triggers gpg signing of your commit. GPG signing is
not an attestation of a DCO etc.
Rado has kindly created a WFLY issue[5] to track adding of software
enforcement of the signoff requirement. The details of that are another
topic to discuss.
[1] https://github.com/commonhaus/foundation/tree/main/templates/panda
[2] https://github.com/bstansberry/git-file-adder
[3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md
[4]
https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t...
[5] https://issues.redhat.com/browse/WFLY-20791
Best regards,
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
10 months
The Commonhaus haus-manager GitHub app
by Brian Stansberry
In various discussions related to onboarding to Commonhaus, I've made vague
comments about a bot (i.e. GitHub app) we need to install.
I've done some research and I understand better what it's all about. So,
FYI:
1) A minimal thing we need to do is give
https://github.com/apps/haus-manager-bot access to one repo. Logically that
would be https://github.com/wildfly/wildfly-governance as this particular
use case relates to governance.
The purpose of doing this is to configure GH perms for a private commonhaus
repo that's for the overall WildFly project, where we can store private
data or whatever related to WildFly. For example trademark info, domain
administration info etc.
In the 'wildfly' GH org we create a GH team, say 'commonhaus-triage'. The
members of this team would have GitHub 'triage' perms for the private
WildFly repo in the commonhaus org.
The action items here are to
* install the app
* create a team
* decide who is in the team
For the last bit we can start with Tom and I (who already have perms), but
if our top-level governance model was something like what's in
https://docs.google.com/document/d/1r2i17R6VtqGeslKlyH6lWVIQix0-QCiMa_6na...
I'd suggest putting the current Commonhaus Representative, Deputy
Commonhaus Representative and Project Lead for each Top-Level Project in
this team. This will let the project leads help with any administrative
tasks that are coordinated via the private project.
2) More interesting is it provides an optional feature where a GH org could
publish a CONTACTS.yaml file in some repo, and that file provides a list of
groups and the membership in each group. In the private repo mentioned
above we then maintain a mapping of groups to GH teams.
The haus-manager-bot will then keep the membership in the GH teams in sync
with what's in the CONTACTS.yaml files. Basically, this lets people use git
to control GH team membership, instead of relying on the GH UI.
This is totally optional; using this feature is not a Commonhaus
requirement. It's more a service they offer.
Choosing to use it can also be done on a per-GH org basis. So, if, say,
wildfly-elytron found value in it but narayana did not, that's fine; one
can use it and the other not.
AFAICT this also only operates on the mapped groups / teams. If an org
wanted to maintain some teams manually they could.
We talked during the governance call a couple weeks ago about the need to
audit and rationalize our GH groups. If an org wanted to use this
CONTACTS.yaml feature, populating the file would be a natural outcome of
that effort.
Best regards,
Brian
10 months
