security@ and security-team@ have no meaningful activity in at least
the last 6 months so I'm posting this here.
grub2 incorrectly initialises the boot_params from the kernel image
The gist is that the bug means the kernel can't determine UEFI secure
boot state, considers it not enabled, resulting in the kernel not
enabling certain checks it otherwise does when it knows secure boot is
enabled. Ergo, users who have secure boot enabled are not getting the
full benefit of secure boot, and this fallback is pretty much silent
(you'd have to be looking at kernel messages to know you're not
Fedora 26 has grub2-2.02-0.40.fc26.x86_64 which contains the fix. It
was proposed as a blocker bug, bug was rejected because it doesn't
have a formal security evaluation.
However, Fedora 24 didn't get the fix before going EOL. And Fedora 25
and Rawhide both still have this problem. And I think it needs
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
Option 1: Big batched update
1. Release F26 according to schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
Fedora Project Leader
I've got two nasty packages. One fails to pass the tests on BigEndian
arches (s390x, ppc64), another one fails to pass the tests on POWER
(ppc64 and ppc64le).
So I have several questions.
* Can I have a shell access to the ppc64 machine (which covers both
cases) where I can install packages and can run gdb / git / gcc?
* How maintainers are supposed to handle it?
* (A provocative one) - is it better to me just to set ExclusiveArch
and open a bugzilla ticket with build log of the failed build?
Sometimes it's hard to do anything even on supported architecture, so
asking me to support a package for the rarely used architecture (which
I don't even have access to) is, well, slightly overoptimistic, no?
With best regards, Peter Lemenkov.
I'm trying to do a build for the python-metar package (first time since
I adapted it after it was orphaned), but I constantly get this error
when I try to do a fedpkg build:
FAILED: BuildError: package metar not in list for tag f27-pending
does anyone know what is wrong, and how to solve it?
Could it be related to the fact that I renamed the spec file from
python-metar.py to metar.py in git?
(I did that since rpmlint gave me the error "E: invalid-spec-name")
I just orphaned apvlv, herbstluftwm, xsettingsd and python-tlslite. I do
no longer use them and only adopted them because they sounded useful or
I needed them back then. I cannot really tell about their upstream
status, they might not be completely dead. Please pick them up if you
would like to keep them in Fedora. Otherwise I will retire them
I just submitted my first package submission  to the official
repository. I guess it's time for an introduction :
I'm a computer science student from Lausanne, Switzerland. I've been
running on linux for 6 or 7 years now, and came back from archlinux 
to fedora a few months ago. Asides from my studies, I work part-time at
my university's IT desk and I'm part of an association promoting linux
and FOSS in general accross the campus. I also have some experience on
system administration but I'm not really familiar with redhat derivative
on servers (running debian everywhere).
Well... nice to meet you ? :)
 probably due to the lack of policy