https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
== Summary ==
Cryptographic policies will be tightened in Fedora ''38''-39,
SHA-1 signatures will no longer be trusted by default.
Fedora ''38'' will do a "jump scare", introducing the change but then
reverting it in time for Beta.
Test your setup with TEST-FEDORA39 today and file bugs in advance so
you won't get bit by Fedora ''38''-39.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asosedki(a)redhat.com
== Detailed Description ==
Secure defaults are an evermoving target.
Fedora 28 had [[Changes/StrongCryptoSettings|StrongCryptoSettings]].
Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]].
Fedora 39 should have [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]].
By Fedora 39, the policies will be, in TLS perspective:
LEGACY
MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: SHA-1 hash or better (no DSA)
Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES)
Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
DH params size: >=2048
RSA params size: >=2048
TLS protocols: TLS >= 1.2
DEFAULT
MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: with SHA-224 hash or better (no DSA)
Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
DH params size: >= 2048
RSA params size: >= 2048
TLS protocols: TLS >= 1.2
FUTURE
MACs: All HMAC with SHA256 or better + all modern MACs (Poly1305 etc.)
Curves: all prime >= 255 bits (including Bernstein curves)
Signature algorithms: SHA-256 hash or better (no DSA)
Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
Key exchange: ECDHE, DHE
DH params size: >= 3072
RSA params size: >= 3072
TLS protocols: TLS >= 1.2
The flagship change this time will be distrusting SHA-1 signatures
on the cryptographic library level, affecting more than just TLS.
OpenSSL will start blocking signature creation and verification by default,
with the fallout anticipated to be wide enough
for us to roll out the change across multiple cycles
with multiple forewarnings
to give developers and maintainers ample time to react:
Fedora 36:
* SHA-1 signatures are distrusted in FUTURE policy (opt-in)
* TEST-FEDORA39 policy is provided
* creating and verifying SHA-1 signatures is logged to ease reporting bugs
Fedora 37 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning1]]:
* (was initially reserved to implement logging of SHA-1 signature operations)
'''Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning2]]''':
* policies are updated, most notably
* SHA-1 signatures are distrusted in DEFAULT policy
* changes are reverted in branched f38 in time for Beta and do not reach users
Fedora 39 [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]:
* changes reach users
The plan is subject to change if it goes sideways somewhere along the way.
So, in Fedora 36, 37 and ''38 released'' distrusting SHA-1 signatures
will be opt-in.
In ''Fedora 38 rawhide'' and Fedora 39 distrusting SHA-1 signatures
will happen by default.
== Feedback ==
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
A discussion]
has been raised on fedora-devel,
[https://lwn.net/Articles/887832 a summary] is available on LWN.
A change has the potential to prove disruptive and controversial,
with much effort being focused on stretching it out in time.
There seems to be a consensus that the change has to be done eventually,
but the ideal means of implementing it are in no way clear.
The decision to discover code reliant on SHA-1 signatures
by blocking creation/verification has not gathered many fans,
but not many alternative proposals have been raised in return.
A notable one, making the library somehow log the offending operations,
has been incorporated in the proposal,
though the effectiveness of it is yet to be seen in practice.
Another notable takeaway point is the need to call for testing,
which would be done in form of writing four Fedora Changes
and testing SHA-1 signature distrusting during Fedora 37 & ''38'' Test Days.
The change owner doesn't see the plan as an ideal one
and continues to be open for feedback.
== Benefit to Fedora ==
Fedora 39 will ship with more secure defaults
to better match the everchanging landscape of cryptographic practices.
TLS 1.0 / 1.1 protocol version will be disabled
as they're [https://datatracker.ietf.org/doc/rfc8996 deprecated],
minimum key sizes will be raised to keep up with the computational advances etc.
Distrusting SHA-1 signatures specifically is expected to trigger
a topical distribution-wide crackdown
on [https://eprint.iacr.org/2020/014 weak] cryptography,
raising the security of the distribution moving forward.
== Scope ==
* Proposal owners: implement changes described in Summary and
Dependencies sections
* Other developers:
Test your applications with TEST-FEDORA39 policy.
Move away from trusting SHA-1 signatures;
ideally in time for F38 branch-off,
for F39 release at the latest.
Follow [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]:
1. move away from trusting SHA-1 signatures entirely, or
2. distrust them by default and require explicit user opt-in to use a workaround
* Release engineering: Not sure if mass-rebuild is required if we
land the change right after f38 branch-off. Maybe a "preview"
mass-rebuild can be done with a special build in the F37 timeframe to
cut down on F38 FTBFS.
* Policies and guidelines: update needed
CryptoPolicies section of the packaging guidelines
will have to be updated to reflect that
SHA-1 signatures must not be trusted by default
and provide guidance for openssl and gnutls.
Components using workaround APIs must not use them without explicit user opt-in
and must be added to a list of applications using a workaround API.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: not with Fedora 37-era ones
== Upgrade/compatibility impact ==
See "User experience".
Upgrade-time issues aren't specifically anticipated;
if any were to arise, testing should find them in ''Fedora 38''-times,
to be fixed by Fedora 39 release at the latest.
Administrators willing to sacrifice security
can apply LEGACY or FEDORA38 policies.
== How To Test ==
=== Testing actively ===
On a ''Fedora 38 rawhide'' system,
install crypto-policies-scripts package and switch to a more restrictive policy
with `update-crypto-policies --set TEST-FEDORA39`.
Proceed to use the system as usual,
identify the workflows which are broken by this change.
Verify that the broken functionality works again
if you the policy is relaxed back
with, e.g., `update-crypto-policies --set TEST-FEDORA39:SHA1`,
file bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `,
mention this change page, the version of crypto-policies package
and the policies under which your workflow does and does not work.
Especially brave souls can dare to try
`update-crypto-policies --set FUTURE` instead,
though this policy is more aggressive than the upcoming defaults.
=== Testing passively ===
On a ''Fedora 38 released'' system, install a special logging tool from
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer
Run it and proceed to use your system.
Once the tool notifies you about
about soon-to-be-blocked SHA-1 signature operations,
identify the component and actions leading to these operations,
verify that repeating them leads to logging more entries.
Ideally also verify that switching to a stricter policy breaks the workflow.
File bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `
and link to this change page.
== User Experience ==
Things will break.
All kinds of things depending on SHA-1 signatures, openly and secretly.
* On Fedora 36-37 they'll break opt-in.
* '''On Fedora 38 rawhide they'll break by default.'''
* '''On Fedora 38 released they'll behave like in Fedora 37.'''
* On Fedora 39 they'll break by default again, including the released version.
== Dependencies ==
A small coordinated change with openssl is required.
In Fedora 38,
openssl should start distrusting SHA-1 signatures
when used with no configuration file.
This does not affect the majority of scenarios,
only applications that do not follow system-wide cryptographic policies.
All reverse dependencies of core cryptographic libraries are affected,
especially openssl ones relying on SHA-1 signatures.
== Contingency Plan ==
* Contingency mechanism: not needed for F38, change will be reverted
before Beta anyway
* Contingency deadline: not needed for F38, change will be reverted
before Beta anyway
* Blocks release? No
== Documentation ==
Workaround API
should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
Packaging guidelines should be modified accordingly.
== Release Notes ==
To be done, similarly to
https://pagure.io/fedora-docs/release-notes/issue/829
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello folks,
this is just a reminder that there is a Fedora Packager Dashboard that you
might not know about:
Go to https://packager-dashboard.fedoraproject.org/
Enter your FAS username, (sit down and relax for a while if coming for the
first time) and enjoy aggregated information about your Fedora and EPEL
packages from:
- Bugzilla
- Bodhi
- ABRT
- Koschei
- src.fedoraproject.org PRs
- orphans reports
- non-installability reports
- Fedora release schedule
- Package calendars (currently GNOME and Python, but extensible)
- and possibly more in the future
With various filtering options.
Also works for FAS groups or custom views of multiple users that can be used
for triages, e.g.:
https://packager-dashboard.fedoraproject.org/dashboard?users=churchyard,pvi…
See the help page for more:
https://packager-dashboard.fedoraproject.org/helpmepls
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_Two
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
libsoup 3 is a new API version of libsoup that provides support for
HTTP/2. We will remove libsoup 2 and all packages that still depend on
it.
== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
[[Changes/libsoup_3:_Part_One|We previously introduced libsoup 3 to
Fedora 37.]] Because applications will crash on startup if linked to
both libsoup 2 and libsoup 3 at the same time, and because many
libraries depend on libsoup, and because applications therefore have
limited control over which libsoup they link to transitively, this
transition was quite tricky and caused several serious problems during
the Fedora 37 development cycle. Fortunately, the trickiest part of
the migration to libsoup 3 is now behind us.
The next step is to remove libsoup 2 from Fedora. We propose to do
this for Fedora 39. This should happen sooner rather than later
because libsoup is a security-sensitive networking library and
maintaining an old version in Fedora indefinitely is inadvisable. We
know from experience that a deadline will be required in order to
ensure applications and libraries make the transition; otherwise, we
will wind up maintaining libsoup 2 indefinitely. Removing libsoup 2
from Fedora 38 seems too soon: applications need a little more time to
smoothly transition. Accordingly, we propose to remove libsoup 2 from
Fedora 39. The package will be retired in rawhide shortly after Fedora
38 is branched in February 2023. At this point, all packages that
still depend on it will break in rawhide. This rest of the year will
be available to fix broken packages before Fedora 39 is released to
users in October 2023.
This will likely cause some temporary problems and force some
compromises. E.g. we may have to drop software like ABRT or geoclue
from composes if not ported in time.
== Benefit to Fedora ==
Removing libsoup 2 ensures Fedora does not package an obsolete version
of a security-sensitive networking library. It will also eliminate the
possibility of linkage conflicts between libsoup 2 and libsoup 3,
which have been extremely annoying during the Fedora 37 development
cycle and will continue to plague us during Fedora 38 development.
== Scope ==
* Proposal owners: we will ensure the package is retired
* Other developers: software must be ported from libsoup 2 to libsoup
3. This may require substantial upstream effort.
* Release engineering: [https://pagure.io/releng/issue/10985 #10985]
* Policies and guidelines: no new policies needed
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: no alignment with objectives
== Upgrade/compatibility impact ==
Software that still depends on libsoup 2 will break.
== How To Test ==
Fortunately not much testing is needed. The main challenge of the
transition to libsoup 3 was testing applications to ensure they do not
crash on startup due to libsoup 2 vs. libsoup 3 conflicts. Such
conflicts will no longer occur once this change is implemented,
because libsoup 2 won't exist anymore. Of course, it's also good to
test applications to ensure they still work properly after being
ported to libsoup 3.
== User Experience ==
Applications that use libsoup 3 will support HTTP/2, which multiplexes
multiple HTTP requests over a single connection. Users may notice
significant performance improvements.
== Dependencies ==
$ dnf repoquery --whatdepends libsoup --latest-limit 1 --arch
'noarch,x86_64' --disablerepo='*' --enablerepo=rawhide
Fedora - Rawhide - Developmental packages for t 18 MB/s | 64 MB 00:03
Last metadata expiration check: 0:00:15 ago on Tue 23 Aug 2022 11:17:32 AM CDT.
abrt-retrace-client-0:2.15.1-4.fc37.x86_64
badwolf-0:1.2.2-3.fc37.x86_64
bookworm-0:1.1.3-0.8.20200414git.c7c3643.fc37.x86_64
cawbird-0:1.4.2-4.fc37.x86_64
cinnamon-0:5.4.11-1.fc38.x86_64
claws-mail-plugins-fancy-0:4.1.0-5.fc37.x86_64
claws-mail-plugins-gdata-0:4.1.0-5.fc37.x86_64
coin-0:1.3.0-7.fc37.x86_64
cutter-0:1.2.7-7.fc37.x86_64
darktable-0:4.0.0-3.fc37.x86_64
dino-0:0.3.0-4.fc37.x86_64
dleyna-renderer-0:0.6.0-15.fc37.x86_64
dleyna-server-0:0.6.0-14.fc37.x86_64
dmapd-0:0.0.91-4.fc37.x86_64
elementary-calendar-0:6.1.1-1.fc37.x86_64
elementary-code-0:6.2.0-2.fc37.x86_64
elementary-mail-0:6.4.0-1.fc36.x86_64
elementary-photos-0:2.7.5-2.fc37.x86_64
elementary-planner-1:3.0.7-1.fc37.x86_64
elementary-tasks-0:6.3.0-1.fc37.x86_64
emacs-1:28.1-3.fc37.x86_64
ephemeral-0:7.1.0-4.fc37.x86_64
exfalso-0:4.5.0-3.fc37.noarch
flatpak-builder-0:1.2.2-4.fc37.x86_64
fondo-0:1.6.1-3.fc37.x86_64
frogr-0:1.6-5.fc35.x86_64
gajim-0:1.4.7-1.fc37.noarch
gambas3-gb-gtk3-webview-0:3.17.3-2.fc37.x86_64
gamehub-0:0.16.3.2-5.fc37.x86_64
geany-plugins-geniuspaste-0:1.38-5.fc37.x86_64
geany-plugins-markdown-0:1.38-5.fc37.x86_64
geany-plugins-updatechecker-0:1.38-5.fc37.x86_64
geoclue2-0:2.6.0-3.fc37.x86_64
geocode-glib-0:3.26.4-1.fc37.x86_64
gfbgraph-0:0.2.5-2.fc37.x86_64
gnome-calculator-0:43~alpha-2.fc37.x86_64
gnome-games-0:40.0-3.fc36.x86_64
gnome-music-0:42.1-3.fc37.noarch
gnome-software-0:43.beta-3.fc38.x86_64
gnome-video-arcade-0:0.8.8-13.fc37.x86_64
goodvibes-0:0.7.4-2.fc37.x86_64
grilo-0:0.3.15-2.fc38.x86_64
grilo-plugins-0:0.3.15-1.fc38.x86_64
gssdp-0:1.4.0.1-3.fc37.x86_64
gssdp-utils-0:1.4.0.1-3.fc37.x86_64
gupnp-0:1.4.3-3.fc37.x86_64
gupnp-tools-0:0.10.3-2.fc37.x86_64
homebank-0:5.5.6-2.fc37.x86_64
libabiword-1:3.0.5-4.fc37.x86_64
libchamplain-0:0.12.20-7.fc37.x86_64
libdmapsharing-0:2.9.41-8.fc37.x86_64
libdmapsharing4-0:3.9.10-6.fc37.x86_64
libepc-0:0.4.0-23.fc37.x86_64
libepc-ui-0:0.4.0-23.fc37.x86_64
libgda5-tools-1:5.2.10-12.fc38.x86_64
libgda5-web-1:5.2.10-12.fc38.x86_64
libgdata-0:0.18.1-6.fc37.x86_64
libgepub-0:0.6.0-10.fc37.x86_64
libgovirt-0:0.3.8-5.fc37.x86_64
libgrss-0:0.7.0-15.fc37.x86_64
libgweather-0:40.0-4.fc37.x86_64
libmateweather-0:1.26.0-3.fc37.x86_64
libsoup-devel-0:2.74.2-3.fc37.x86_64
libtimezonemap-0:0.4.5.2-1.fc38.x86_64
libtranslate-0:0.99-113.fc37.x86_64
liferea-1:1.13.9-1.fc37.x86_64
linphone-0:3.6.1-49.fc37.x86_64
logjam-1:4.6.2-28.fc37.x86_64
meteo-0:0.9.9.1-3.fc37.x86_64
midori-0:9.0-11.fc37.x86_64
mmsd-tng-0:1.9-2.fc37.x86_64
mpdscribble-0:0.22-25.fc37.x86_64
osinfo-db-tools-0:1.10.0-4.fc37.x86_64
osm-gps-map-0:1.1.0-11.fc37.x86_64
ostree-tests-0:2022.5-2.fc37.x86_64
perl-HTTP-Soup-0:0.01-28.fc37.x86_64
polari-0:42.1-2.fc37.x86_64
pragha-0:1.3.3-23.fc37.x86_64
purple-chime-0:1.4.1-7.fc37.x86_64
python3-nbxmpp-0:3.1.1-1.fc37.noarch
remmina-0:1.4.27-5.fc37.x86_64
rest0.7-0:0.8.1-2.fc37.x86_64
rhythmbox-0:3.4.6-2.fc37.x86_64
rygel-0:0.40.4-2.fc37.x86_64
seahorse-0:42.0-2.fc37.x86_64
snapd-glib-0:1.58-5.fc37.x86_64
snapd-glib-tests-0:1.58-5.fc37.x86_64
snapd-qt-tests-0:1.58-5.fc37.x86_64
soup-sharp-0:2.42.2-7.20190810git0f36d10.fc37.x86_64
srain-0:1.4.0-3.fc37.x86_64
surf-0:2.0-14.fc37.x86_64
switchboard-plug-onlineaccounts-0:6.5.0-1.fc37.x86_64
taxi-0:2.0.1-3.fc37.x86_64
telepathy-gabble-0:0.18.4-19.fc37.x86_64
telepathy-salut-0:0.8.1-28.fc37.x86_64
uhttpmock-0:0.5.5-2.fc37.x86_64
vfrnav-0:20201231-30.fc37.x86_64
webkit2gtk4.0-0:2.37.90-1.fc38.x86_64
webkit2gtk4.0-devel-0:2.37.90-1.fc38.x86_64
xfce4-screenshooter-0:1.9.11-1.fc38.x86_64
xfce4-screenshooter-plugin-0:1.9.11-1.fc38.x86_64
xfce4-weather-plugin-0:0.11.0-4.fc37.x86_64
== Contingency Plan ==
* Contingency mechanism: restore libsoup 2 package
* Contingency deadline: beta freeze
* Blocks release? possibly, it will depend on which packages
successfully make the transition
== Documentation ==
[https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html
Migrating from libsoup 2]
== Release Notes ==
To-do
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/PcreDeprecation
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Upstream stopped the support for the old 'pcre' package. It only
supports the new 'pcre2' version, so Fedora should deprecate it so it
could later be retired and removed from Fedora entirely.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
as a final release and nothing else will be added/fixed in it. This
may lead to some unresolved CVEs, which would have to be resolved by
the maintainers. Unfortunately, due to our limited capacity, we
wouldn't have the time and experience to solve this by ourselves, so
we need to deprecate this package. After the deprecation is done, the
very next step would be starting the [[PcreRetirement|retirement
change]], so the package is removed from Fedora entirely.
The new 'pcre2' package is out for more than 7 years now and most of
the packages have already been ported to its redefined API.
[https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
Mail] about the changes in the pcre2.
=== Plan ===
1) File the BZ trackers for all of the dependent packages.
2) Document the deprecation.
3) Start the [[PcreRetirement|new change]] with the pcre retirement.
== Feedback ==
The early feedback from the community is in
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
this mailing thread]
== Benefit to Fedora ==
Fedora shouldn't support unsupported packages. When the future RHEL
versions fork from Fedora, it could lead to less secure RHEL as well.
By deprecating this package, we will send the message to the
maintainers that their packages should port to new pcre2 package and
any new package would have to use only new and supported pcre2
version.
== Scope ==
* Proposal owners: 3 steps mentioned in the
[https://fedoraproject.org/wiki/PcreDeprecation#Plan Plan].
* Other developers: Port their package to support the new pcre2.
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The old pcre package will be deprecated, so the new packages are not
able to require it and have to require the new pcre2 version of this
package.
== User Experience ==
Users will not be exposed to the possible vulnerable pcre package,
because the pcre2 is supported by the upstream community.
== Dependencies ==
This list is obtained by using and combining the output of the
following commands:
dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
'libpcre.so.1()(64bit)' --whatrequires 'libpcreposix.so.0()(64bit)' -s
| pkgname
dnf repoquery --disablerepo='*' --enablerepo=rawhide-source
--whatrequires pcre-devel | pkgname
=== List ===
*389-ds-base
*adanaxisgpl
*aide
*aircrack-ng
*anope
*apachetop
*bti
*ccze
*cegui
*cegui06
*clamav
*ClanLib
*clisp
*clover2
*coccinelle
*collada-dom
*compton
*condor
*cppcheck
*cyrus-imapd
*deepin-file-manager
*dogtag-pki
*EMBOSS
*eterm
*Falcon
*freeradius
*gambas3
*ganglia
*ghc-highlighting-kate
*ghc-pcre-light
*ghc-regex-pcre
*GMT
*gnote
*golang
*gource
*grep
*groonga
*gsmartcontrol
*haxe
*hydra
*hyperscan
*i3
*i3-gaps
*imapfilter
*Io-language
*kdelibs
*kdelibs3
*kdevelop
*kf5-kjs
*kf5-kplotting
*libast
*liblognorm
*libmodsecurity
*lnav
*logstalgia
*lumail
*medusa
*mle
*mod_auth_openid
*mod_auth_openidc
*mod_qos
*mod_security
*monotone
*ncid
*nekovm
*ngrep
*nmap
*ocaml-pcre
*oci-umount
*octave
*openCOLLADA
*openscap
*opensips
*pads
*pcre
*pdfgrep
*perl-re-engine-PCRE
*petsc
*php-pecl-apcu
*php-pecl-http
*php-pecl-oauth
*picom
*pl
*poco
*postgis
*powwow
*prelude-lml
*privoxy
*proxysql
*python-qutepart
*python-scss
*R
*rasqal
*regexxer
*remctl
*renderdoc
*rkward
*root
*rudiments
*sigil
*slang
*sord
*sslh
*suricata
*sway
*swig
*syncevolution
*syslog-ng
*the_foundation
*the_silver_searcher
*Thunar
*tin
*tintin
*tinyfugue
*trafficserver
*uwsgi
*vdr-epgfixer
*watchman
*wireshark
*wmweather+
*xastir
*xfce4-verve-plugin
*xgrep
*xmlcopyeditor
*zsh
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not
needed for this Change)
* Contingency deadline: N/A (not needed for this Change)
* Blocks release? No
== Documentation ==
There should be documentation of this change, so the users know that
the pcre is no longer supported and cannot be required by any Fedora
package. If an existing package requires the pcre package, it is
considered as a bug.
== Release Notes ==
Release notes should contain the information about the pcre
deprecation so the users know they won't be able to use its libraries
anymore.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Today we reached the Code Complete (100% complete) milestone on the
F37 schedule: https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
At this time, all F37 Changes should be 100% complete. You can
indicate this by setting the Bugzilla tracker to the ON_QA status. If
you need to defer a Change to F38 please NEEDINFO me.
Note that we are entering the Beta freeze. Additional package changes
to complete this Change will need an approved blocker or freeze
exception. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
for more information.
Changes that have not reached the ON_QA status will be given to FESCo
for evaluation of contingency plans.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello everyone!
I just completed the first run of FESCo's newly approved Inactive
Packager Policy[1]. Packagers that have been identified as inactive
have a ticket in the find-inactive-packagers repo[2]. One week after
the F37 final release, packagers who remain inactive will be removed
from the packager group. (Note that pagure.io is one of the systems
checked for activity, so commenting on your ticket that you're still
around will prevent you from showing up in the second round.)
Since this is the first time we've done something like this, it could
be a little rough. I appreciate your patience and understanding. If
you have suggestions for improvement, look for the open feature
issues[3] and file an issue in the find-inactive-packagers repo[4] if
it's not there already.
For the curious, here are the stats from today's run:
2550 users checked
913 of those had no activity on src.fedoraproject.org or pagure.io
835 of those had no activity in Bodhi
812 of those had no activity on the mailing lists
606 of those (~24% of packagers) had no activity in Bugzilla.
The script took a little under three hours to run.
[1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&sta…
[3] https://pagure.io/find-inactive-packagers/issues?tags=feature
[4] https://pagure.io/find-inactive-packagers/new_issue
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
We are planning to get everything in order before the beta freeze next week
so require a small outage.
Planned Outage - Updates / Reboots - 2022-08-17 20:00 UTC
There will be an outage starting at 2022-08-17 20:00 UTC.
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2022-08-17 20:00 UTC'
Reason for outage:
We will be making sure all servers are up to date and rebooted into the
latest kernels.
Affected Services:
Many services will be affected for short times as various servers are
rebooted. Users and Maintainers are advised to wait until after the outage
to avoid any service problems.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/10854
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Mark