https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
== Summary ==
Arm Pointer Authentication (PAC) is a method of hardening code from
Return Oriented Programming (ROP) attacks. It uses a tag in a pointer
to sign and verify pointers. Branch Target Identification (BTI) is
another code hardening method, where the branch/jump target is
identified with a special landing pad instruction. Outside of some
system support in glibc+kernel, packages gain the additional hardening
by compiling with the -mbranch-protection= flag available in recent
versions of GCC. In particular -mbranch-protection=standard enables
both BTI and PAC, with backwards compatible to armv8.0 code sequences
that activate on v8.3 (PAC) & v8.5 (BTI) enabled Arm machines.
== Owner ==
* Name: [[User:jlinton| Jeremy Linton]] & ARM SIG
* Email: jeremy.linton(a)arm.com
== Benefit to Fedora ==
PAC & BTI are code hardening features, they should serve to make
fedora more resistant to a couple further classes of runtime attacks.
By enabling this early, fedora is once again proven to be at the
leading edge of security and linux development. If everything works as
planned, this change will be invisible to the end user, except in
cases where the applications will trap behaviour that appears to be
caused by exploit attempts.
== Scope ==
* Proposal owners:
Work with individual package maintainers in the case of build failures
or runtime exceptions. In the latter case there are two possibilities.
First on v8.0 hardware, which is currently the most common, the
additional instruction sequences are treated as NOP's and should be
completely ignored by the hardware. It may be possible on v8.3/8.5
hardware that PAC or BTI may need additional tweaks for hand written
assembly which interacts with PAC/BTI enabled code.
* Other developers:
Assure their packages continue to compile and pass
unit/integration/etc tests on v8.0 hardware. Continue to monitor
runtime problems on v8.3+ for bugs, vs exploit attempts.
* Release engineering: (pending)
* Policies and guidelines:
At the moment, nothing needs to be changed as this should propagate as
the default set of RPM build flags.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
If everything works as planned, this should be transparent to the end user.
== How To Test ==
Testing falls into two categories. Assuring that the packages continue
to work on existing arm v8.0 hardware without PAC, and testing on
PAC+BTI enabled hardware. For the most part the expectation from the
fedora community is that package maintainers assure their packages
continue to work on existing systems. PAC+ hardware will be in limited
supply during the F33 development cycle, so the expectation is that
owners of that hardware will perform more complete systemwide testing
and report any defects found against the packages in question along
with fixes or hardware access.
== User Experience ==
(not supplied)
== Dependencies ==
There are various gcc and kernel related changes which have already
landed, but there continue to be a few cleanup patches trickling into
the toolchain/compiler as problems are discovered.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
Build affected packages with explicit compiler flags disabling the
feature. Worse case the top level rpm macros reversion, and a rebuild
of effected packages.
Contingency deadline: Beta target.
* Blocks release? No, except for major functionality loss due to core
package bug.
* Blocks product? No
== Documentation ==
Arm pointer authentication is a technology designed to make software
more robust by providing hardware assistance for code hardening. It
protects pointers by cryptographically signing them and verifying
their signatures when used, thereby mitigating certain attack vectors.
Core support is provided to applications and libraries transparently
via kernel and toolchain changes to generate hardended code. Branch
Target identification, similarly provides landing pads, to harden code
paths by restricting the processor from jumping into unexpected parts
of a function.
Further reference:
* https://developer.arm.com/architectures/learn-the-architecture/providing-pr…
* https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentic…
* https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
* https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
* https://lwn.net/Articles/789370/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Beginning today through 19 May, you may nominate candidates for the 4 open
seats on the Fedora Engineering Steering Committee (FESCo).
To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
FESCo is currently selecting the questions for the interview questionnaire,
which will be finalized before the beginning of the interview period. For
more information, see the Community Blog post:
https://communityblog.fedoraproject.org/fedora-32-elections-nominations-now…
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning Everyone,
A little while ago we have received the request on the infra issue tracker to
remove all maintainers of retired packages [1].
So today I decided to look at what this would look like and wrote a script that
queries PDC for the list of all branches on all projects [2], gather from it a
list of all the packages that are retired on all their branches (so all branches
are ``active=false``).
For each of these retired project, it queries dist-git to find out if they still
have maintainers in addition to the ``orphan`` user.
The outcome of this script can be found there:
https://pingou.fedorapeople.org/retired_packages_with_maintainers.log
Some stats about this:
- 881 RPM packages are retired and still have maintainers (out of 4322 retired
RPMs).
- 662 of them are not orphaned
- 42 modules are retired and still have maintainers (out of 42 retired modules).
- all of them are not orphaned
- 2 containers are retired and still have maintainers (out of 3 retired
containers).
- all of them are not orphaned
Which brings a couple of questions:
- Do we have a documented way to mark modules as orphaned or retired?
- Should we orphan all the RPM packages that are retired but not orphaned?
Finally, does everyone agree about the original request: "remove all maintainers
of retired packages"? Or should we bring this to FESCo?
Thanks for your inputs,
Pierre
[1] https://pagure.io/fedora-infrastructure/issue/8600
[2] https://pdc.fedoraproject.org/extras/active_branches.json (8+Mb file)
churchyard suggested we add a "Feedback" section to the Change
proposal template[1]. I see two benefits to this:
1. It provides FESCo a useful summary of the community feedback (and
in particular the reasoning behind rejecting alternatives) to simplify
the voting process
2. It improves the historical record so that future Fedorans can
understand why a change was implemented in a particular way and not
another
I have drafted proposed edits[2] to the Changes documentation that
would add an optional Feedback section to the template. I am opening
this up for community discussion before submitting it to FESCo for
approval.
The reason we chose to go with making this optional is that making it
mandatory would necessarily add additional wait time before proposals
are sent to FESCo. And also it's better to ease people into the idea.
:-)
[1] https://fedoraproject.org/wiki/Changes/EmptyTemplate
[2] https://pagure.io/fedora-pgm/pgm_docs/pull-request/2
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning Everyone,
A little while ago[1], we integrated anitya in dist-git itself, allowing to
stop using fedora-scm-request's[2] git repository to store this information.
However, this git repository is still being used to store bugzilla overrides
(i.e.: default assignee on bugzilla ticket when they differ from the point of
contact (main admin) of the package in dist-git).
Together with Karsten Hopp we worked on integrating this functionality on
pagure-dist-git[3], thus allowing to get rid entirely of the git repository at
fedora-scm-request[2].
This work has been deployed in staging today. We would very much appreciate if
you could take a few minute of your time and see if it works to your
liking: https://src.stg.fedoraproject.org/
The overrides information from production has been migrated yesterday to the
staging dist-git, so what you see in the UI reflects the current state of the
overrides in production as of yesterday.
Here is an example with an override:
https://src.stg.fedoraproject.org/rpms/0ad
One note: in the rpms namespace, the UI will always show you the default
assignee for Fedora and Fedora EPEL, regardless of whether the package is in
EPEL.
This is a shortcoming we are aware of and will be looking at fixing in the near
future but potentially after it has reached production.
Thank you for your understanding and help testing this,
Pierre
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
[2] https://pagure.io/releng/fedora-scm-requests
[3] https://pagure.io/pagure-dist-git/
https://fedoraproject.org/wiki/Changes/Nodejs14x
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
14.x series. As with 12.x, 10.x and 8.x before it, Fedora 33 will
carry 14.x as the default Node.js interpreter for the system. The 12.x
interpreter will remain available as a non-default module stream.
== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvetlik(a)redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 33 will ship with the latest LTS version of Node.js by default.
This will either be the `nodejs:14` module stream or else replicated
to the non-modular repository, depending on the status of other
release engineering work around supporting modular content in the
non-modular buildroots. To end-users, the experience should be
identical: `dnf install nodejs` will give them `nodejs-14.x` and the
matching `npm` package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
14.x release, Fedora 33 will also have the 12.x release available as a
selectable module stream.
== Scope ==
* Proposal owners:
The packages are already built for Fedora 33 in a non-default module
stream. On June 14th, 2020, the nodejs-14.x packages will become the
default in Fedora 33 (either by making the 14.x module stream be the
default stream or by rebuilding the packages as non-modular, depending
on other factors).
* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 14.x module
stream enabled as soon as possible. Issues should be reported to
nodejs(a)lists.fedoraproject.org
* Release engineering: [https://pagure.io/releng/issue/9426 #9426]
Release engineering and FESCo will need to approve the change to the
default module stream.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 31 or Fedora 32 with
the non-modular nodejs-12.x packages will be automatically upgraded to
the 14.x packages, which may cause issues. If users are running
software known not to support Node.js 14.x yet, they can switch the
system to use 12.x with dnf module commands.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 14.x being installed.
* Confirm that upgrading from Fedora 31 or Fedora 32 with nodejs-12.x
installed (non-modular) results in an upgrade to nodejs-14.x
* Confirm that upgrading from Fedora 31 or Fedora 32 with the
`nodejs:12` module enabled does *not* result in an upgrade to 14.x and
still has `nodejs:12` enabled on Fedora 33.
* Confirm that upgrading from Fedora 31 or Fedora 32 with the
`nodejs:14` module enabled upgrades successfully and still has
`nodejs:14` enabled on Fedora 33.
== User Experience ==
Users will have the 14.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 14.x, they will need to be updated, made
modular and dependent upon the `nodejs:12` stream or else removed from
Fedora 33.
Prior to the switchover date to Node.js 14.x as the default, packagers
are strongly encouraged to test their existing Node modules with 14.x
via the Modular version by running:
```
dnf reset nodejs
dnf module install nodejs:12/development
```
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 12.x as the default stream. This may require bumping
epoch or making the `nodejs:12` stream the default, depending on the
status of the modules-in-non-modular-buildroot work at the time.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v14.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V14.md
== Release Notes ==
Fedora 33 now ships with Node.js 14.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 12.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14
</pre>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis