The Protocol allows to mitigate the following risks related to end user packages:

• forged or modified packages by third parties after gaining control of MyBB-managed platforms or intercepting requests from end users,
• legitimate packages swapped with ones containing unauthorized modifications as a result of a man-in-the-middle attack or checksum collision attack,

Definitions

• Team Member Keys

  Personal keys owned by Team members and listed on the official About the Team page.

• Package Signing Keys

  Keys belonging to specific Team members used to sign official packages. Package Signing Keys are only used during the release process and should be protected with a strong password and stored and backed up safely.

• Announcement Channels

  Reputable third-party recordkeeping solutions allowing to independently establish dates of protocol events:

  • @mybbsecurity Twitter feed, maintained by Team members handling security issues.

• Archiving Services

  Reputable third-party archiving services providing snapshots of Package Signing Key listings:

  • web.archive.org

• Package Signing Permissions

  Team members of at least 90 days, familiar with PGP basics and related safety practices, who own a Team Member Key are permitted to participate in the package signing process. The eligibility is assessed in internal interviews conducted by members handling security issues.

• Package Signing Key Signing Permissions

  At least one member of the Management Team or a team Leader is required to authorize any signing key before adding it to the list by signing it with their Team Member Key. Authorizing own signing keys is not allowed.

• Team Web of Trust

  Although not required, it is recommended that Team members verify the authenticity of one another’s Team Member Keys by cross-signing them and uploading the signatures to public keyservers.

Software Setup

GnuPG is used for key and signature management — it is recommended to use version 2.1 or higher.

Before following any step of the Protocol, the GnuPG configuration file (~/.gnupg/gpg.conf — the location can be checked with gpg --version) should be updated to prioritize strong algorithms:

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Key Management

Creating Package Signing Keys

1. Create a 4096-bit RSA (sign only) key with Real name including your Community Forums name, your *@mybb.com e-mail address, and CODE SIGNING KEY as a comment.

   gpg --full-gen-key
   

   (gpg --gen-key on older versions)

2. Sign the created key with your Team Member Key.

   gpg -u TEAM-MEMBER-KEY-ID --sign-key PACKAGE-SIGNING-KEY-ID
   

3. Export the signed public key with metadata and post it internally for further processing.

   (gpg --fingerprint --list-sigs PACKAGE-SIGNING-KEY-ID && gpg --armor --export PACKAGE-SIGNING-KEY-ID) > PACKAGE-SIGNING-KEY-ID.TEAM-MEMBER-KEY-ID.asc
   

Adding Package Signing Keys

1. Have the key signed according to Package Signing Key Signing Permissions.

   gpg -u TEAM-MEMBER-KEY-ID --sign-key PACKAGE-SIGNING-KEY-ID
   

2. Trigger Archiving Services to save the new version of the Package Signing Keys listing and the key’s details page.
3. Add the key block with included signatures to mybb.com/download/keys/, denoting key owner’s username, full key fingerprint and date.

4. Announce the addition on Announcement Channels, denoting the key owner’s username and full fingerprint:

   ADDING Package Signing Key of ~Eve (FEED DEAF ABBA BEAD BABE FACE DEAD BEEF CEDE CAFE).
   

The key can be used to sign packages after 14 days have passed since it was added to the website and announced on Announcement Channels.

Removing Package Signing Keys

1. Have the key signatures revoked according to Package Signing Key Signing Permissions.

   gpg --edit PACKAGE-SIGNING-KEY-ID
   

   > revsig
   

2. Update the key block on the mybb.com/download/keys/ list to contain the revoked signature, denoting the removal date.

   (gpg --fingerprint --list-sigs PACKAGE-SIGNING-KEY-ID && gpg --armor --export PACKAGE-SIGNING-KEY-ID) > PACKAGE-SIGNING-KEY-ID.revoked.asc
   

3. Trigger Archiving Services to save the new version of the Package Signing Keys listing and the key’s details page.

4. Announce the removal on Announcement Channels, denoting the key owner’s username and full fingerprint:

   REMOVING Package Signing Key of ~Eve (FEED DEAF ABBA BEAD BABE FACE DEAD BEEF CEDE CAFE).
   

Package Signing Key Signature Continuity

At all times the Package Signing Keys should have at least one valid signature according to Package Signing Key Signing Permissions. Package Signing Key signatures that are invalidated due to personnel changes (e.g. the signing party is no longer a Team member) should be replaced by new ones.

Package Signing

1. Individual signing

   If any issues have been found, do not proceed and report them internally.

   1. Check for alerts, announcements and notices related to Project’s security and the current release process — do not proceed unless release-related issues have been resolved.
   2. Build the package(s) from repository’s source using supplied patches and metadata.
   3. Assure that the internal candidate package(s) and the one(s) generated are identical (full file content comparison).
   4. Check Announcement Channels for announcements related to your signing key.

   5. Make a detached signature of the package(s) using a valid Package Signing Key with SHA-512 as the digest algorithm:

      gpg -u PACKAGE-SIGNING-KEY-ID --armor --output package.zip.asc --digest-algo sha512 --no-version --detach-sign package.zip.asc
      

      and post it internally.

2. Release

   1. Signature verification

      Provided signatures are verified to assure Protocol conformance.

   2. Signature publication

      All signatures are distributed with the package(s). Whenever signatures are added, removed or updated Archiving Services are triggered to save the new version of the package(s) signature listing.