security: add timeline, contact, and priority info

[eslerm]

Late in the Mantic cycle Security approved three MIRs (LP#2030482 and two in LP#2038942). From this Security learned that we need to improve our documentation and set expectations.

@setharnold does Beta Freeze sound appropriate to you? That is tight, but feels workable.

@frank-heimes @xnox

[xnox]

I burned a lot of karma and brownie points because of that; and will still be paying for landing those........

I did not set a precedent.

[eslerm]

We were already discussing setting a timeline before the x13s packages.

This brief security MIR is an exception. - s390-tools

The director clause was added for exceptional cases, like hardware enablement.

The intent is to make things smoother, not to add blocks.

[setharnold]

Historically the security team has not been able to perform reviews with low enough latency and high enough throughput to deliver the necessary reviews early enough in the cycle -- we'd often be finishing them in the week before release, even if the consequences of the MIR succeeding or failing might require unrealistically large changes in short notice to implement or roll-back the changes.

We've wanted to have a submission deadline for years and it's perhaps fortuitous timing that we've got much more capacity at roughly the same as we've got some excellent examples of truly last-minute requests. :)

In an ideal world this wouldn't actually be much of a change -- hopefully everyone has the clear bulk of their work ready by feature freeze, and hopefully the MIR team has enough capacity to assign further security reviews as necessary, etc.

So, no, please don't take this personally -- but yes, the timing of those requests is a decent indicator of why we'd like the change.

Thanks

[alexmurray]

LGTM.

[slyon]

LGTM, except for the spelling fixes needed.

[cpaelzer]

Please fix the typos (or extend the checker), other than that LGTM

[setharnold]

This should address the spell-check errors, if I've done a good job of it anyway:

#42

Thanks

[didrocks]

Once PR #42 to fix the spelling mistakes merged into that one, looks good to me!

[setharnold]

Ha, apparently I only addressed warnings, and not errors. So, here's one to fix Mattermost: #43

[github-actions]

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, or 📝 job summary for details.

Unrecognized words (1)

Mattermost

To accept these unrecognized words as correct, you could run the following commands

... in a clone of the [email protected]:eslerm/ubuntu-mir.git repository
on the security-notice branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/main/apply.pl' |
perl - 'https://github.com/canonical/ubuntu-mir/actions/runs/6696241935/attempts/3'

Available 📚 dictionaries could cover words (expected and unrecognized) not in the 📘 dictionary

This includes both expected items (13) from .github/actions/spelling/expect.txt and unrecognized words (1)

Dictionary	Entries	Covers	Uniquely
cspell:cpp/src/stdlib-c.txt	278	2
cspell:python/src/python/python-lib.txt	2417	2
cspell:npm/dict/npm.txt	302	1	1
cspell:elixir/dict/elixir.txt	95	1
cspell:sql/src/tsql.txt	112	1

Consider adding them (in .github/workflows/spelling.yml) for uses: check-spelling/check-spelling@main in its with:

      with:
        extra_dictionaries:
          cspell:cpp/src/stdlib-c.txt
          cspell:python/src/python/python-lib.txt
          cspell:npm/dict/npm.txt
          cspell:elixir/dict/elixir.txt
          cspell:sql/src/tsql.txt

To stop checking additional dictionaries, add (in .github/workflows/spelling.yml) for uses: check-spelling/check-spelling@main in its with:

check_extra_dictionaries: ''

Warnings (1)

See the 📂 files view, the 📜action log, or 📝 job summary for details.

ℹ️ Warnings	Count
ℹ️ non-alpha-in-dictionary	19

See ℹ️ Event descriptions for more information.

✏️ Contributor please read this

By default the suggested command will add the listed items to the .github/actions/spelling/expect.txt. This is not always desired!

If a listed items is

• ... misspelled, then please correct them instead of changing the spell checker configuration.
• ... an actual word/term that has a high probability of showing up in future contributions, please add it to .github/actions/spelling/allow.
• ... an term/word that just you use or shouldn't generally be accepted, please add it to .github/actions/spelling/expect.txt.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push – it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

[cpaelzer]

All spelling issues fixed, plenty of approvals and pre-discussed at the sprint. Merging ...