Fix aarch64 build on embree
Hello team, What is the way to disable `-mss2 for aarch64 build in embree? Spec file: https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec Scratch build result: https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571 Thanks in advance. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101193] Please branch and build perl-Authen-DigestMD5 for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2101193 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-1b0c6bc22e has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1b0c6bc22e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101193 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2100791] Add perl-Perl4-CoreLibs to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2100791 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-300cb2b824 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-300cb2b824 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2100791 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101385] perl-Socket-2.034 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2101385 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2022-738f473648 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-738f473648` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-738f473648 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101385 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote: > I have started the responsive maintainer process due to lack of contact > through bugzilla mail. Specifically, this is about an epel9 branch, > which has been repeatedly requested since March (including an offer to > maintain the branch) in > https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and > https://bugzilla.redhat.com/show_bug.cgi?id=2059757 . You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process. Of course, if after a certain amount of time, a maintainer is deemed completely non-responsive, you should go through the respective process. The Stalled EPEL Requests policy is just intended to provide a more expedient way to get a package branched for EPEL. [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy/ #stalled_epel_requests -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Anyone want to review swap? (rocm-opencl)
I'm looking to see if anyone wants to review swap with me: https://bugzilla.redhat.com/show_bug.cgi?id=2090823 Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, 2022-06-28 at 22:00 +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > That's part of what makes it hard to discuss things with you: > > the proposal _explicitly_ says that only some libraries will be bundled. > > (There's a separate section about this!) > > So it's not "all-bundled" but "some of the low-level libs are bundled". > > I am sorry, but I have to think that you are the one weasel-wording. The > proposal says in its subject that it wants to "Build all JDKs in Fedora > against in-tree libraries". Not "some in-tree libraries", just (unqualified) > "in-tree libraries", which in correct English defaults to meaning "all in- > tree libraries that are available". It really doesn't. It's ambiguous. Without more specific language it could mean either. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
One thing I forgot in my previous reply to this post: Zbigniew Jędrzejewski-Szmek wrote: > As you say, it's "SHOULD", and the maintainers argue that it'll be much > easier for them to do it in this way. I believe that the rationale for doing the opposite of a SHOULD ought to be much stronger than "it'll be much easier for them to do it in this way". The easy way is often not the right way, which is why we have packaging guidelines at all. In the particular case of bundling libraries, there are a few valid reasons for it that I can see, e.g.: * The bundled library is patched, and the project does not compile or has unfixable bugs with the upstream version of the library. * The bundled library is older or newer than the system version, and the project does not compile or has unfixable bugs with the version of the library packaged in Fedora, and providing a compatibility library is impractical (e.g., because the application is the only one needing that particular version of the library). * The bundled library has no canonical upstream version at all. * The upstream build system does not support building against the system version, and it is impractically hard to patch it downstream to do so. (But the packager should at least try to get a person more familiar with the build system to have a try at it.) None of these appear to be satisfied for OpenJDK, considering that there are configure switches (that will be toggled by the Change), and that OpenJDK works now with the system versions of the libraries. Hence, I see the use of bundled libraries as an unnecessary shortcut that degrades packaging quality for no good reason other than one person or team's convenience. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
Alex Chernyakhovsky writes: > I just replied on bugzilla. No one has attempted to contact me before. Well... as a Fedora maintainer, there's an expectation that you'll read your bugzilla email from time to time :) I know stuff happens, and from your bz comment it sounds like there was some issue posting comments. I'm glad to hear a branch is in the works - thanks! Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
A key on an encrypted disk can still prevent evil maid attacks, though an attacker with local access can still compromise the system. In the current system, an attacker with permissions required to read kernel memory can just ask the shim to boot their modified kernel. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Unresponsive maintainer: Alex Chernyakhovsky
Hi Alex + Fedora, I'm trying to contact Alex Chernyakhovsky, the maintainer of mosh. Does anyone know how to contact them? I have started the responsive maintainer process due to lack of contact through bugzilla mail. Specifically, this is about an epel9 branch, which has been repeatedly requested since March (including an offer to maintain the branch) in https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and https://bugzilla.redhat.com/show_bug.cgi?id=2059757 . Alex, while I regret that we're here a second time [1], please know that it's because we want to use this thing yinz built. If it would be helpful to you, I'm happy to either maintain or help co-maintain mosh. Per Fedora policy, check bug is: https://bugzilla.redhat.com/show_bug.cgi?id=2101951 Be well, --Robbie 1: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C3QOBXCDHVN4OWPVRM32IVE37CV36ZOT/ signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101943] New: perl-Text-Bidi-2.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2101943 Bug ID: 2101943 Summary: perl-Text-Bidi-2.17 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Text-Bidi Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 2.17 Upstream release that is considered latest: 2.17 Current version/release in rawhide: 2.16-2.fc37 URL: http://search.cpan.org/dist/Text-Bidi/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/8069/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Text-Bidi -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101943 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
Zbigniew Jędrzejewski-Szmek wrote: > That's part of what makes it hard to discuss things with you: > the proposal _explicitly_ says that only some libraries will be bundled. > (There's a separate section about this!) > So it's not "all-bundled" but "some of the low-level libs are bundled". I am sorry, but I have to think that you are the one weasel-wording. The proposal says in its subject that it wants to "Build all JDKs in Fedora against in-tree libraries". Not "some in-tree libraries", just (unqualified) "in-tree libraries", which in correct English defaults to meaning "all in- tree libraries that are available". (This may actually be a grammar error from the submitters, in which case that should have been fixed before voting on the proposal.) In the full text, the proposal includes the following list: > --with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" > --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" > --with-harfbuzz="bundled" It does not state whether these are all the libraries that upstream bundles in the tree or, if not, which ones will not be bundled. (So I cannot tell from the proposal's text whether the "all-bundled" term I used is an exaggeration or not.) It also does not state why these libraries in particular were selected to be bundled. I also do not see these libraries as being particularly "low-level", though anyway, IMHO, the lower-level a library, the worse an idea it is to bundle it. (E.g., trying to bundle glibc would be a horrible idea, but that is not what is being proposed here anyway. So I am not sure why you chose the word "low-level".) In addition to the libraries that will be bundled, there is also the switch to statically linking the system libstdc++, which is IMHO an entirely different change, and for which I do not see any possible benefit at all, since we will be using the exact same version of libstdc++ as before, just without the benefits of shared libraries. > The package is still build by Fedora maitainers, from controlled sources, > on Fedora infra. The only difference is that some libraries are in a > version that the upstream project has blessed. Instead of the version that the distribution has blessed, that is known to work together with all the other software in the distribution, and that does not require extra space for Java only. > The upstream project is big and has an extensive test suite and cares > about vulnerabilities as much as we do. But introducing a middleman (who needs to upgrade the bundled library and issue a security update for Java that we need to package, instead of directly packaging the upgraded library) necessarily increases the response time to security vulnerabilities. > You describe it as if the bundling would radically change things, but I > think that in this case the impact for users will not be noticable. The mailing list discussion had pointed out at least one user-visible issue, related to fontconfig support. And the increased disk space and RAM requirements will definitely be noticeable. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Sharpened Blade via devel wrote: > It would be stored with permissions for only root to read it, and you disk > should be encrypted, or none of this matters. It doesn't matter if your disk is encrypted. Whilst your computer is online, the contents are accessible. If your kernel memory is accessible through /dev/mem or /dev/kmem, there's a chance that your keys can just be read directly. One of the things secure boot can do is lock down *read* access to your raw memory/kernel virtual memory to make it harder for someone to steal your secrets. It's not a secure as using a TPM ought to be, though. And if you want to keep your key safe, you should really keep it in a removable hardware device. Leaving it on your hard drive, even with perms such that only root can read it isn't necessarily safe enough, sadly. David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Sharpened Blade via devel wrote: > [...] Software should be secure by itself, [...] That's impossible to achieve. Without hardware support, you cannot make your software secure. Further, human beings are involved in the writing of the software - and the larger the codebase and the more people involved, the more bugs there will be. Add to that the authors of Linux have spent ages providing all sorts of interesting ways for one process to affect another, from strace to /dev/mem to ebpf. David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
It would be stored with permissions for only root to read it, and you disk should be encrypted, or none of this matters. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 36 on Linux Saloon
https://www.youtube.com/watch?v=769-0f75Xag The last episode of Linux Saloon of June 2022 is about Fedora 36 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On 6/28/22 09:35, Vitaly Zaitsev via devel wrote: > On 28/06/2022 15:29, Zbigniew Jędrzejewski-Szmek wrote: >> We can treat this as an experiment. The hope is that Java upstream is >> big enough to be able to release updates for any CVEs in a timely manner, >> and that the RHEL/Fedora maintainers are able to provide updates in a timely >> manner. If it turns out this is not the case, we can unbundle again. > > Upstream doesn't care because their tests fails on modern libraries > versions. If the TCK fails with modern library versions, that is a problem with the TCK or with OpenJDK and needs to be fixed. Fedora should not ship outdated libraries because an upstream test suite is too restrictive. The main problem here is that the TCK is closed-source. If it were open to contributions, problems like this could be identified and fixed. Given the current situation, though, the best solution would be for Red Hat to create an alternate test suite that is free software. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: retiring python-language-server and python-pyls_black
At least python-language-server really is dead upstream[1], replaced by python-lsp-server, which is a maintained community fork. The python-pyls_black package isn’t usable without python-language-server, and nobody has stepped up to migrate it to python-lsp-server in over a year[2], so it’s looking pretty dead upstream, too. I agree with the general advice to orphan rather than retiring in most cases, but I think retirement is probably appropriate under the circumstances for these two packages. [1] https://github.com/palantir/python-language-server/issues/935 [2] https://github.com/rupert/pyls-black/issues/35 On Tue, Jun 28, 2022, at 12:18 PM, Maxwell G wrote: > Jun 28, 2022 7:28:39 AM Mukundan Ragavan : > >> I am retiring two packages - python-language-server and python-pyls_black > It's probably better to simply orphan the packages instead of > completely retiring them. See the policy [1]. Generally, retirements > are reserved for when a package is dead upstream, has unpatched CVEs, > is being renamed, or is otherwise no longer useful to Fedora. I believe > there's other IDEs that can make use of these packages. > > [1]: > https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#_orphaning_and_retiring_packages > -- > Maxwell G > Pronouns: He/Him/His > gotmax@e.email > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to > python-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grafana license change from ASL 2.0 to AGPLv3
On Tue, Jun 28, 2022 at 05:16:14PM +0200, Andreas Gerstmayr wrote: > I plan to submit a Grafana 8.5.6 rebase to Fedora rawhide in the coming > days. Why not to v9? -- Tomasz Torcz Morality must always be based on practicality. to...@pipebreaker.pl — Baron Vladimir Harkonnen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On 6/28/22 07:21, Florian Weimer wrote: > * Chris Murphy: > >> On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote: >>> >>> * Neal Gompa: >>> I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment. >>> >>> Right. It's not even clear to me why we enforce kernel module >>> signatures in Secure Boot mode, and disable a few other kernel features. >> >> If users can load arbitrary unsigned kernel modules or hibernation >> images, it silently circumvents UEFI Secure Boot. I agree this is a >> frustrating paradigm for users who want certain features like using >> 3rd party modules with a Fedora kernel, or using locked down kernel >> features, but I'm not sure what the alternative is. > > Do we revoke signatures on Fedora kernels with ring 0 escalations? > I don't think so. Other distributions share the same trust root and > do not revoke kernel signatures, either. Doesn't this mean there is > an existing bypass already, by booting through a vulnerable kernel, > exploiting it, and then chain-loading another kernel with secure boot > effectively disabled (but perhaps lying to userspace about the status)? Yes, it does. That is another reason that secure boot is basically security theater if one is using the default trust roots. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
> Demi Marie Obenour wrote: >> On 6/25/22 07:56, Roberto Ragusa wrote: >>> On 6/19/22 22:54, Sharpened Blade via devel wrote: >>> Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. >>> >>> How big is the demand for this kind of lockdown? As a >>> since-last-century Linux user, I'm choosing Fedora exactly to NOT >>> have all this signing/trusted boot complications on my systems and I >>> do not see a reason to turn Fedora into Android (or, worse, iOS). tl;dr: that's not what Secure Boot is; packed kernel+initrd images may be in the cards As one of the people responsible for getting Fedora's shim signed and therefore making Secure Boot work, I feel it's necessary to clarify that we don't agree with any of the misinformation in this thread: Secure Boot is not lockout. Secure Boot is not designed or even intended to keep you out of your own machine. The entire trust model assumes that if you have physical access, it's your machine: you can manipulate keys, and even turn Secure Booting off. If you don't own the machine... well, then you're an attacker, it's designed to keep you out, and as I'm not a blackhat, you'll get no help from me :) How you configure your own hardware, should you choose to do so, is your own business and I won't tell you how to do that. But as it adds a tangible security benefit, and even if you're doing custom module/kernel/etc. builds, it's really not very difficult to add your own key and sign. Secure Boot can be thought of as primarily a way to avoid attacker persistence on the system. Supposing someone otherwise roots the machine, by restricting boot targets to known good (as determined by machine owner or distro vendor), we make it much harder to (for example) deploy a bootkit, or load a malicious kmod. This isn't perfect (see the original post), but it's clearly better than not having it, and problems like "the initrd isn't signed" are eminently solvable. While I will not be responding to all the dangerously incorrect things that have or can be said, here's a sample reply: Neal Gompa writes: > I only care about secure boot enough to bootstrap a Free platform. False dichotomy. Secure Boot isn't nonfree, nor is the Fedora ecosystem somehow decoupled from it. > Secure Boot is generally not designed as a tool to provide security Wildly, dangerously incorrect. (And it's not a tool - many components work together to enable it, including the kernel.) > unless you rip out all the certs and use your own exclusively. At that > point, you can do whatever you want. If you're doing custom builds, you're of course encouraged to use your own certs. How you configure your own machine is, again, your business. > Most PCs are poorly designed to handle doing this procedure, and it's > too easy to accidentally break the computer entirely by doing so. It's > just not worth it. Groundless speculation, and not correct. > I treat Secure Boot purely as a compatibility interface. We need to do > just enough to get through the secure boot environment. Again, this misunderstands the security boundary. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Grafana license change from ASL 2.0 to AGPLv3
Upstream Grafana changed the license in Grafana v8 from Apache License 2.0 to Affero General Public License (AGPL) v3 [1] [2] [3]. I plan to submit a Grafana 8.5.6 rebase to Fedora rawhide in the coming days. [1] https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relicensing-to-agplv3/ [2] https://github.com/grafana/grafana/blob/6d0261263c6037abf3b1a4587735d1c1070ea9af/CHANGELOG.md#license-update [3] https://github.com/grafana/grafana/pull/33184 Cheers, Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 03:35:35PM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I don't think it makes sense to restart the discussion here. I disagree > > that there was (any) consensus on the mailing list. If you feel that it's > > better to use a non-Fedora JRE, that's certainly possible, please just do > > that if you want to. Personally, I see a lot of value in having Java > > for Fedora, and use it for my stuff. > > But the thing is, I am left with only the options of using an all-bundled > JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can > see how this is not a real choice. That's part of what makes it hard to discuss things with you: the proposal _explicitly_ says that only some libraries will be bundled. (There's a separate section about this!) So it's not "all-bundled" but "some of the low-level libs are bundled". > I have been using the Fedora-packaged Java all this time, and I indeed also > see a lot of value in it. But to me, this also implies that it is packaged > to Fedora standards and uses Fedora system libraries. Stopping to do so > destroys much of the value of having a Fedora package at all. The package is still build by Fedora maitainers, from controlled sources, on Fedora infra. The only difference is that some libraries are in a version that the upstream project has blessed. The upstream project is big and has an extensive test suite and cares about vulnerabilities as much as we do. You describe it as if the bundling would radically change things, but I think that in this case the impact for users will not be noticable. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, 28 Jun 2022 at 10:18, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 28/06/2022 15:52, Stephen Smoogen wrote: > > Since I do not see this decision changing, it is probably time for > > people negatively affected by this change to set up a COPR or some other > > build system which builds the packages as they were previously. > > I think it will be better to introduce the coffee-named-language-XX > packages and build them for the main Fedora repository without running > any Oracle's tests and certifications. > > Someone outside of the current team has to sign up to do that work either inside of Fedora or outside. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On 28/06/2022 15:52, Stephen Smoogen wrote: Since I do not see this decision changing, it is probably time for people negatively affected by this change to set up a COPR or some other build system which builds the packages as they were previously. I think it will be better to introduce the coffee-named-language-XX packages and build them for the main Fedora repository without running any Oracle's tests and certifications. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On 27. 06. 22 13:27, Richard W.M. Jones wrote:
==
FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
--
Traceback (most recent call last):
File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382, in
test_openssl_version
(s, t))
AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
Might be https://github.com/python/cpython/issues/90272
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)
On 6/27/22 22:35, Neal Gompa wrote: > On Sat, Jun 25, 2022 at 3:06 PM Vipul Siddharth > wrote: >> >> 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 == >> >> The `systemd-udev` package installs >> `"/usr/lib/systemd/network/99-default.link"`, >> which sets `Link.MACAddressPolicy=persistent`. This proposal is to >> change it to set `Link.MACAddressPolicy=none` to stop changing the MAC >> address. >> This is particularly important for bridge and bond devices. >> >> This change can either only apply to bridge/bond devices, or to >> various software devices. That is to be discussed. >> >> == Owner == >> >> * Name: [[User:thaller|Thomas Haller]] (NetworkManager) >> * Email: >> * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) >> * Email: >> >> >> == Detailed Description == >> >> On Fedora, udev by default changes the MAC address of a wide range of >> software devices. >> This was introduced by systemd 242 in early 2019 (Fedora 31), when >> `MACAddressPolicy=` was >> extended to affect more types of devices. >> >> With `MACAddressPolicy=persistent` udev's aim is to provide a stable >> MAC address, otherwise >> the kernel will assign a random one. However, that can cause problems: >> >> Firstly, software devices are always created by some tool that has >> plans for the device. The tool may not >> expect that udev is going to change the MAC address and races against >> that. The best solution >> for the tool is to set the MAC address when creating an interface. >> This will prevent >> udev from changing the MAC address according to the MACAddressPolicy. >> Otherwise, the tool should wait for udev to initialize the device to >> avoid the race. In theory, a >> tool is always advised to wait for udev to initialize the device. >> However, if it were not for MACAddressPolicy, >> in common scenarios udev doesn't do anything relevant for software >> devices to make that necessary. >> >> Secondly, for interface types bridge and bond, an unset MAC address >> has a special meaning >> to the kernel and the MAC address of the first port is used. If udev >> changes the MAC >> address, that no longer works. >> Now the generated MAC address is not directly discoverable as it is >> based on `/etc/machine-id` >> ([https://www.man7.org/linux/man-pages/man5/machine-id.5.html >> machine-id(5)]), among >> other data. Even if there were a tool to easily calculate the MAC >> address, it could be cumbersome >> to use it without logging into the machine first. The MAC address can >> directly affect the >> assigned IP address, for example when using DHCP. When booting a new >> virtual machine, the user might >> know the MAC address of the (virtual) "physical" interfaces. When >> bonding/bridging those >> interfaces, the bond/bridge would get one of the well known MAC >> addresses. `MACAddressPolicy=persistent` >> interferes with that. >> >> The goal of persistent policy is to provide a stable MAC address. Note >> that if the >> tool or user who created the interface would want a certain MAC address, they >> have all the means to set it already. That applies regardless whether >> the tool is >> iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor >> systemd-networkd >> rely on udev's MACAddressPolicy for setting the MAC address. This >> behavior is mostly >> useful for plain `ip link add`, but it's unclear which real world user >> wants this behavior. >> >> Of course, the user is welcome to configure the MAC address in any way >> they want. Including, >> dropping a link file that sets `MACAddressPolicy=persistent`. The >> problem is once udev sets a MAC address, >> it cannot be unset. Which makes this problematic to do by default. >> >> While Fedora inherited this behavior from upstream systemd, RHEL-9 >> does not follow this behavior >> ([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e694bfbc2b02a456c1056f252e/0028-udev-net-setup-link-change-the-default-MACAddressPol.patch#L43 >> centos9], >> [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For >> RHEL-8, this doesn't >> apply because the systemd there is too old to change the MAC address >> of most software devices. >> >> This could be either implemented by patching >> `/usr/lib/systemd/network/99-default.link` >> to have a different policy, or by dropping a link file with higher >> priority. In the latter >> case, that override could be shipped either by udev or even by >> NetworkManager. >> >> Another option is to change the scope of this proposal to only change to >> `MACAddressPolicy=none` for the device types where this causes the most >> issues >> (bridge/bond/team). >> >> >> == Feedback == >> >> This was also discussed on upstream systemd mailing list >>
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 03:05:32PM +0200, Ralf Corsépius wrote: > > > Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek: > > On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote: > > > > > It certainly is not true that the feedback was not considered by FESCo: > > > > there was a long discussion on IRC, and FESCo members also participated > > > > in > > > > the mailing list thread. > > > > > > Yet, the outcome is diametrically opposed to the mailing list consensus. > > > > I don't think it makes sense to restart the discussion here. I disagree > > And I disagree with you. > > This decision is such kind of harmful to Fedora, this decision should be > reverted. This decision communicates the attitude of FESCO not caring about > security, maintainablity and further related topics. I don't see that attitude in reading the IRC logs of the meeting, and I think that characterization is rather unfair to those involved. > > Personally, I see a lot of value in having Java packaged > > for Fedora, and use it for my stuff. > > So do I, but this doesn't invalidate the the thought of "bundling" and > "static linkage" being a prime security risk. I see people aware of the downsides of bundling and static linking, but they're not the sole factors to be considered. Our packaging guidelines on the topic of bundling are more nuanced and this is what FESCO has considered when evaluating this feature from what I can read in the meeting minutes. IOW, if people think the outcome is wrong, then the problem really lies with the agreed packaging guidelines wrt to bundling, not with FESCOs decision which looks to be in compliance with the stated guidelines. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28 2022 at 03:29:33 PM +0200, Zbigniew Jędrzejewski-Szmek wrote: We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again. I hope the Java maintainers ensure the RPM has proper Provides: bundled(foo) for each bundled library, including bundled dependencies of bundled libraries, so that Product Security can track CVEs. The FESCo approval to bundle should be contingent on adherence to this existing Fedora policy. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220628.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 8/163 (aarch64), 11/233 (x86_64) New failures (same test not failed in Fedora-Rawhide-20220627.n.0): ID: 1308598 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1308598 ID: 1308615 Test: aarch64 Workstation-raw_xz-raw.xz clocks@uefi URL: https://openqa.fedoraproject.org/tests/1308615 ID: 1308727 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1308727 ID: 1308755 Test: aarch64 universal install_repository_http_variation@uefi URL: https://openqa.fedoraproject.org/tests/1308755 ID: 1308789 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/1308789 ID: 1308801 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/1308801 Old failures (same test failed in Fedora-Rawhide-20220627.n.0): ID: 1308481 Test: x86_64 Workstation-live-iso clocks URL: https://openqa.fedoraproject.org/tests/1308481 ID: 1308483 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1308483 ID: 1308499 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1308499 ID: 1308515 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1308515 ID: 1308519 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1308519 ID: 1308523 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1308523 ID: 1308528 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1308528 ID: 1308625 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1308625 ID: 1308651 Test: x86_64 Workstation-upgrade desktop_login URL: https://openqa.fedoraproject.org/tests/1308651 ID: 1308656 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1308656 ID: 1308660 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1308660 ID: 1308682 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1308682 ID: 1308791 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1308791 Soft failed openQA tests: 96/233 (x86_64), 63/163 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20220627.n.0): ID: 1308529 Test: x86_64 Silverblue-dvd_ostree-iso clocks URL: https://openqa.fedoraproject.org/tests/1308529 ID: 1308561 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1308561 ID: 1308562 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1308562 ID: 1308565 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1308565 ID: 1308732 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/1308732 ID: 1308761 Test: aarch64 universal install_kickstart_user_creation@uefi URL: https://openqa.fedoraproject.org/tests/1308761 ID: 1308773 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1308773 ID: 1308779 Test: aarch64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/1308779 Old soft failures (same test soft failed in Fedora-Rawhide-20220627.n.0): ID: 1308407 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1308407 ID: 1308408 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/1308408 ID: 1308409 Test: x86_64 Server-dvd-iso install_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1308409 ID: 1308410 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1308410 ID: 1308411 Test: x86_64 Server-dvd-iso install_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1308411 ID: 1308412 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1308412 ID: 1308414 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1308414 ID: 1308415 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1308415 ID: 1308416 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1308416 ID: 1308418 Test: x86_64 Server-dvd-iso
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, 28 Jun 2022 at 09:37, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I don't think it makes sense to restart the discussion here. I disagree > > that there was (any) consensus on the mailing list. If you feel that it's > > better to use a non-Fedora JRE, that's certainly possible, please just do > > that if you want to. Personally, I see a lot of value in having Java > > for Fedora, and use it for my stuff. > > But the thing is, I am left with only the options of using an all-bundled > JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can > see how this is not a real choice. > > I have been using the Fedora-packaged Java all this time, and I indeed > also > see a lot of value in it. But to me, this also implies that it is packaged > to Fedora standards and uses Fedora system libraries. Stopping to do so > destroys much of the value of having a Fedora package at all. > > So, sure, I can just use Java from elsewhere, but that is exactly what I > do > not want. What I do want is being taken away from me. > > Since I do not see this decision changing, it is probably time for people negatively affected by this change to set up a COPR or some other build system which builds the packages as they were previously. It might help to see what kind of problems it has and if there are solutions which were not seen before. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request: Airspy HF+
Any news about this? I saw this, but it appears to not be working with Fedora 36: https://bugzilla.redhat.com/show_bug.cgi?id=1917510#c10 Also, airspyone_host-1.0.9-13 needs to be updated to airspyone_host-1.0.10. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On 28/06/2022 15:29, Zbigniew Jędrzejewski-Szmek wrote: We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again. Upstream doesn't care because their tests fails on modern libraries versions. Also, this only the first part of their proposal. The other part is to let them build the OpenJDK once and then ship prebuilt binaries to all supported Fedora releases. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
Zbigniew Jędrzejewski-Szmek wrote: > I don't think it makes sense to restart the discussion here. I disagree > that there was (any) consensus on the mailing list. If you feel that it's > better to use a non-Fedora JRE, that's certainly possible, please just do > that if you want to. Personally, I see a lot of value in having Java > for Fedora, and use it for my stuff. But the thing is, I am left with only the options of using an all-bundled JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can see how this is not a real choice. I have been using the Fedora-packaged Java all this time, and I indeed also see a lot of value in it. But to me, this also implies that it is packaged to Fedora standards and uses Fedora system libraries. Stopping to do so destroys much of the value of having a Fedora package at all. So, sure, I can just use Java from elsewhere, but that is exactly what I do not want. What I do want is being taken away from me. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 03:05:32PM +0200, Ralf Corsépius wrote: > > > Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek: > > On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote: > > > > > It certainly is not true that the feedback was not considered by FESCo: > > > > there was a long discussion on IRC, and FESCo members also participated > > > > in > > > > the mailing list thread. > > > > > > Yet, the outcome is diametrically opposed to the mailing list consensus. > > > > I don't think it makes sense to restart the discussion here. I disagree > > And I disagree with you. OK. > This decision is such kind of harmful to Fedora, this decision should be > reverted. This decision communicates the attitude of FESCO not caring about > security, maintainablity and further related topics. > > > Personally, I see a lot of value in having Java packaged > > for Fedora, and use it for my stuff. > > So do I, but this doesn't invalidate the the thought of "bundling" and > "static linkage" being a prime security risk. We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again. (Pfff, people are so angry about this… I would prefer to unbundle anything too. But sometimes a big upstream is just too big to fight on every front.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote: It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread. Yet, the outcome is diametrically opposed to the mailing list consensus. I don't think it makes sense to restart the discussion here. I disagree And I disagree with you. This decision is such kind of harmful to Fedora, this decision should be reverted. This decision communicates the attitude of FESCO not caring about security, maintainablity and further related topics. Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff. So do I, but this doesn't invalidate the the thought of "bundling" and "static linkage" being a prime security risk. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On 6/28/22 08:08, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 28, 2022 at 07:21:33AM -0400, Dusty Mabe wrote: >> >> >> On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote: >>> We have one ticket tagged with 'meeting', but there has been no >>> progress in discussion or implementation, so I'm cancelling today's >>> meeting. >> >> Hmm. That would be https://pagure.io/fesco/issue/2804 >> >> I don't really know what else I'm supposed to do to progress that. I can't >> really force people to discuss it on the list and I've been waiting two weeks >> to discuss it at the FESCO meeting. >> >> How come we can't talk about it at the FESCO meeting in its current form? > > Hi, > > I wasn't aware that you wanted to discuss it in the current form; all > that I could see was the lack of activity. It's still tagged with 'meeting', > so it'll be on the agenda next week. > Thanks! I also commented in the ticket to make it clear the current status. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > The whole proposal consists of a few parts. The part that was voted on > > was the first part. Various people opposed the whole proposal, but it > > was the later parts that raised the stronger opposition. > > I and others have also objected to the entire concept of bundling the > libraries where not absolutely necessary, with arguments given. > > > The first part is something that is really within maintainer discretion, > > It is true that the rules on bundling have become less and less strict over > time. However, there is still a SHOULD-grade requirement that system > libraries should be used where reasonably possible, to which the Change is > in blatant contradiction. As you say, it's "SHOULD", and the maintainers argue that it'll be much easier for them to do it in this way. You keep using strong words like "blatant" where they are blatanly inappropriate. > > and has no impact on other packages. > > Well, it has a potential impact at least on all packages depending on the > JDK/JRE. Also, security issues in the bundled libraries can cause the user's > whole Fedora installation to be compromised. > > > If the maintainer thinks that this will make it easier for them to deliver > > the package in this form, I don't think FESCo should block it. > > At that point, we gain very little from having the JDK/JRE in Fedora at all, > as opposed to a third-party RPM repository. Why bother shipping a Fedora > package at all if it does not follow Fedora best practices (SHOULD > guidelines) and in particular does not use Fedora-packaged libraries? > > > It certainly is not true that the feedback was not considered by FESCo: > > there was a long discussion on IRC, and FESCo members also participated in > > the mailing list thread. > > Yet, the outcome is diametrically opposed to the mailing list consensus. I don't think it makes sense to restart the discussion here. I disagree that there was (any) consensus on the mailing list. If you feel that it's better to use a non-Fedora JRE, that's certainly possible, please just do that if you want to. Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
Zbigniew Jędrzejewski-Szmek wrote: > The whole proposal consists of a few parts. The part that was voted on > was the first part. Various people opposed the whole proposal, but it > was the later parts that raised the stronger opposition. I and others have also objected to the entire concept of bundling the libraries where not absolutely necessary, with arguments given. > The first part is something that is really within maintainer discretion, It is true that the rules on bundling have become less and less strict over time. However, there is still a SHOULD-grade requirement that system libraries should be used where reasonably possible, to which the Change is in blatant contradiction. > and has no impact on other packages. Well, it has a potential impact at least on all packages depending on the JDK/JRE. Also, security issues in the bundled libraries can cause the user's whole Fedora installation to be compromised. > If the maintainer thinks that this will make it easier for them to deliver > the package in this form, I don't think FESCo should block it. At that point, we gain very little from having the JDK/JRE in Fedora at all, as opposed to a third-party RPM repository. Why bother shipping a Fedora package at all if it does not follow Fedora best practices (SHOULD guidelines) and in particular does not use Fedora-packaged libraries? > It certainly is not true that the feedback was not considered by FESCo: > there was a long discussion on IRC, and FESCo members also participated in > the mailing list thread. Yet, the outcome is diametrically opposed to the mailing list consensus. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 02:24:17PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 28, 2022 at 02:07:54PM +0200, Kevin Kofler via devel wrote: > > Zbigniew Jędrzejewski-Szmek wrote: > > > #2794 F37 Change proposal: Build all JDKs in Fedora against in-tree > > > #libraries and with static stdc++lib > > > APPROVED: FESCo approves the use of bundled libraries and static libstdc++ > > > for building Java (+5, 1, -0) > > > > WTF, why??? > > > > The feedback in the mailing list thread was overwhelmingly negative. We > > have > > brought up several strong reasons why doing this is a horribly bad idea. > > Why > > have those arguments and the mailing list consensus not been considered by > > FESCo? > > The whole proposal consists of a few parts. The part that was voted on > was the first part. Various people opposed the whole proposal, but it > was the later parts that raised the stronger opposition. The first > part is something that is really within maintainer discretion, and has > no impact on other packages. If the maintainer thinks that this will > make it easier for them to deliver the package in this form, I don't > think FESCo should block it. At least that's my motivation; for the > whole discussion see the logs [*]. It certainly is not true that the > feedback was not considered by FESCo: there was a long discussion on > IRC, and FESCo members also participated in the mailing list thread. > > Zbyszek > > [*] I wanted to link to meetbot here, but I can't get the new version to > cooperate. Here it is https://meetbot.fedoraproject.org/fedora-meeting/2022-05-31/fesco.2022-05-31-17.00.html https://meetbot.fedoraproject.org/fedora-meeting/2022-05-31/fesco.2022-05-31-17.00.log.html With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
retiring python-language-server and python-pyls_black
I am retiring two packages - python-language-server and python-pyls_black
These were originally packaged for spyder but is no longer maintained.
Instead, we have *-lsp-* packages that are used by spyder and actively
maintained. These are not needed by anything else.
$ dnf repoquery --repo=rawhide{,-source} --whatrequires
python3-language-server
Last metadata expiration check: 0:07:12 ago on Tue 28 Jun 2022 07:18:31
AM CDT.
python3-pyls_black-0:0.4.7-4.fc37.noarch
$ dnf repoquery --repo=rawhide{,-source} --whatrequires python3-pyls_black
Last metadata expiration check: 0:05:10 ago on Tue 28 Jun 2022 07:18:31
AM CDT.
--
GPG Key: E5C8BC67
OpenPGP_signature
Description: OpenPGP digital signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 02:07:54PM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > #2794 F37 Change proposal: Build all JDKs in Fedora against in-tree > > #libraries and with static stdc++lib > > APPROVED: FESCo approves the use of bundled libraries and static libstdc++ > > for building Java (+5, 1, -0) > > WTF, why??? > > The feedback in the mailing list thread was overwhelmingly negative. We have > brought up several strong reasons why doing this is a horribly bad idea. Why > have those arguments and the mailing list consensus not been considered by > FESCo? The whole proposal consists of a few parts. The part that was voted on was the first part. Various people opposed the whole proposal, but it was the later parts that raised the stronger opposition. The first part is something that is really within maintainer discretion, and has no impact on other packages. If the maintainer thinks that this will make it easier for them to deliver the package in this form, I don't think FESCo should block it. At least that's my motivation; for the whole discussion see the logs [*]. It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread. Zbyszek [*] I wanted to link to meetbot here, but I can't get the new version to cooperate. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On Tue, Jun 28, 2022 at 07:21:33AM -0400, Dusty Mabe wrote: > > > On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote: > > We have one ticket tagged with 'meeting', but there has been no > > progress in discussion or implementation, so I'm cancelling today's > > meeting. > > Hmm. That would be https://pagure.io/fesco/issue/2804 > > I don't really know what else I'm supposed to do to progress that. I can't > really force people to discuss it on the list and I've been waiting two weeks > to discuss it at the FESCO meeting. > > How come we can't talk about it at the FESCO meeting in its current form? Hi, I wasn't aware that you wanted to discuss it in the current form; all that I could see was the lack of activity. It's still tagged with 'meeting', so it'll be on the agenda next week. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
Zbigniew Jędrzejewski-Szmek wrote: > #2794 F37 Change proposal: Build all JDKs in Fedora against in-tree > #libraries and with static stdc++lib > APPROVED: FESCo approves the use of bundled libraries and static libstdc++ > for building Java (+5, 1, -0) WTF, why??? The feedback in the mailing list thread was overwhelmingly negative. We have brought up several strong reasons why doing this is a horribly bad idea. Why have those arguments and the mailing list consensus not been considered by FESCo? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
* Chris Murphy: > On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote: >> >> * Neal Gompa: >> >> > I treat Secure Boot purely as a compatibility interface. We need to do >> > just enough to get through the secure boot environment. >> >> Right. It's not even clear to me why we enforce kernel module >> signatures in Secure Boot mode, and disable a few other kernel features. > > If users can load arbitrary unsigned kernel modules or hibernation > images, it silently circumvents UEFI Secure Boot. I agree this is a > frustrating paradigm for users who want certain features like using > 3rd party modules with a Fedora kernel, or using locked down kernel > features, but I'm not sure what the alternative is. Do we revoke signatures on Fedora kernels with ring 0 escalations? I don't think so. Other distributions share the same trust root and do not revoke kernel signatures, either. Doesn't this mean there is an existing bypass already, by booting through a vulnerable kernel, exploiting it, and then chain-loading another kernel with secure boot effectively disabled (but perhaps lying to userspace about the status)? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote: > We have one ticket tagged with 'meeting', but there has been no > progress in discussion or implementation, so I'm cancelling today's > meeting. Hmm. That would be https://pagure.io/fesco/issue/2804 I don't really know what else I'm supposed to do to progress that. I can't really force people to discuss it on the list and I've been waiting two weeks to discuss it at the FESCO meeting. How come we can't talk about it at the FESCO meeting in its current form? Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Tue, Jun 28, 2022 at 01:12:25PM +0200, Petr Pisar wrote: > On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé > wrote: > > That's thinking about the problem from the wrong point of view. SecureBoot > > doesn't prevent an attacker from booting an OS that's different from what > > you installed, even without shim they could swap to a different Windows > > install. What SecureBoot does is to provide a mechanism to assert that > > what has booted matches the original install, and securely tie that > > condition to the release of secrets for example to LUKS key. > > > I think you mistaken SecureBoot with a TPM measurement. > > SecureBoot is indeed only about executing or not executing a code > which is signed by a trusted key. Naturally if there are multiple > trusted keys or a whole tree of signed firmwares, loaders, and > operating systems, then from SecureBoot point of view, they are > equivalent. Well actually I was really referring to the combination of the two. SecureBoot makes the use of TPM more practical / straightforward by avoiding the need to tie the policy to measurements that change on every software update, instead you can tie to a measurement associated with successful secure boot. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On 28/06/2022 09:26, Daniel P. Berrangé wrote: What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key. No, it doesn't. It just blocks the ability to load unsigned code. TPM 2.0 provides a boot chain verification mechanism. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé wrote: > That's thinking about the problem from the wrong point of view. SecureBoot > doesn't prevent an attacker from booting an OS that's different from what > you installed, even without shim they could swap to a different Windows > install. What SecureBoot does is to provide a mechanism to assert that > what has booted matches the original install, and securely tie that > condition to the release of secrets for example to LUKS key. > I think you mistaken SecureBoot with a TPM measurement. SecureBoot is indeed only about executing or not executing a code which is signed by a trusted key. Naturally if there are multiple trusted keys or a whole tree of signed firmwares, loaders, and operating systems, then from SecureBoot point of view, they are equivalent. On the other hand, attesting that a system booted into the same state as yesterday is a different problem and can be achieved without any signatures. E.g. with TPM-measuring each executed piece of code and configuration data. I can see where the misunderstanding comes from: The traditional TPM scenario requires the a user to establish the trust with TPM by seeding it with a new initialization vector. That's not practical in cloud computing where the user has no access to the hardware. Therefore CPU vendors came with a complicates structure of keys, derived keys. encrypted memory, enclaves inaccessible to a hypervizor etc. I don't know much about this. However, I believe that this security feature you are familiar to from the world of virtualization is not called SecureBoot. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20220628.n.0 changes
OLD: Fedora-Rawhide-20220627.n.0 NEW: Fedora-Rawhide-20220628.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:2 Upgraded packages: 122 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:949.12 KiB Size of upgraded packages: 1.71 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 127.39 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: librcc-0.2.12-21.fc37 Summary: RusXMMS Charset Conversion Library RPMs:librcc librcc-devel librcc-gtk2 librcc-gtk3 Size:868.05 KiB Package: python-mox3-1.1.0-5.fc36 Summary: Mock object framework for Python RPMs:python3-mox3 Size:81.07 KiB = UPGRADED PACKAGES = Package: anaconda-37.11-1.fc37 Old package: anaconda-37.10-3.fc37 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 17.30 MiB Size change: 30.27 KiB Changelog: * Mon Jun 27 2022 Packit - 37.11-1 - anaconda-modprobe: don't try and load cramfs (awilliam) - module-setup.sh: Don't ignore errors, unbound variable and pipe fails (miro) - Don't attempt to add frozen python modules to initramfs (miro) - Fix kickstart command order in new version (vslavik) - Ignore also ZFCPData temporarily (vslavik) - Temporarily ignore the new version of the zfcp command (vponcova) - Web UI: Fix betanag popover position (mkolman) - Web UI: Make it possible to close the disks alert (mkolman) - tests: update the order of commands (rootpw) in generated kickstart (rvykydal) - webui: Disable "Next" button if no disks are selected (mkolman) - dnf: apply the /etc/dnf/dnf.conf configuration file in the installer (rvykydal) - kstests on pr: run in separate anaconda directory (rvykydal) - Web UI: Show the "Checking disks" spinner for at least two seconds (vponcova) - Web UI: Show the "Checking disks" spinner (vponcova) - kstest on pr: use Permian GitHub ReportSender to show results (rvykydal) - Web UI: Vertically grow the wizard page (vponcova) - Web UI: Hide the footer if the wizard page is in progress (vponcova) - Web UI: Add the sleep function (vponcova) - Web UI: Remove the getSteps function (vponcova) - Web UI: Remove the wrapWithContext function (vponcova) - Add Circle Linux profile to Anaconda (bella) - Web UI: Don't try to replicate installation flags (vponcova) - Web UI: Remove an unused context from the wizard (vponcova) - Update pixel test reference image. (mkolman) - fix type (48353898+copperii) - Display keyboard accelerator properly (jstodola) - Revert "Temporarily keep setter methods for the OSCAP add-on" (vponcova) - Remove missing kickstart command for root ssh password login from common issues (rvykydal) - GUI: Show the dialog for a missing passphrase in an enlight box (vponcova) - GUI: Ask for a missing passphrase during automated installations (vponcova) - Create functions for a missing passphrase in pyanaconda.ui.lib (vponcova) - Add support for rootpw --allow-ssh (rvykydal) - Enable bootloader hiding on RHEL (rharwood) Package: bird-2.0.10-1.fc37 Old package: bird-2.0.9-2.fc37 Summary: BIRD Internet Routing Daemon RPMs: bird bird-doc Size: 2.81 MiB Size change: 5.63 KiB Changelog: * Tue Jun 28 2022 Robert Scheck - 2.0.10-1 - Upgrade to 2.0.10 (#2101352) Package: bodhi-client-6.0.1-2.fc37 Old package: bodhi-client-6.0.1-1.fc37 Summary: Bodhi client RPMs: bodhi-client Size: 78.95 KiB Size change: 117 B Changelog: * Mon Jun 27 2022 Aurelien Bompard - 6.0.1-2 - Replace the bodhi metapackage Package: bodhi-server-6.0.1-2.fc37 Old package: bodhi-server-6.0.1-1.fc37 Summary: Bodhi server RPMs: bodhi-composer bodhi-server Size: 4.47 MiB Size change: 280 B Changelog: * Mon Jun 27 2022 Aurelien Bompard - 6.0.1-2 - Relax the dependency on bodhi-client and bodhi-messages: we only need compatible versions. Package: btrbk-0.32.2-1.fc37 Old package: btrbk-0.32.1-1.fc37 Summary: Tool for creating snapshots and remote backups of btrfs sub-volumes RPMs: btrbk Size: 128.43 KiB Size change: 816 B Changelog: * Mon Jun 27 2022 Juan Orti Alcaine - 0.32.2-1 - Version 0.32.2 (#2101120) Package: butane-0.15.0-1.fc37 Old package: butane-0.14.0-1.fc36 Summary: Butane config transpiler RPMs: butane butane-redistributable Size: 29.32 MiB Size change: 1.48 MiB Changelog: * Fri Jun 17 2022 Robert-Andr?? Mauchin - 0.14.0-2 - Rebuilt for CVE-2022-1996, CVE-2022-24675, CVE-2022-28327, CVE-2022-27191, CVE-2022-29
[Bug 2101568] perl-Math-BigRat-0.2624 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2101568 Jitka Plesnikova changed: What|Removed |Added CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101568 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 37 Rawhide 20220628.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 37 Rawhide 20220628.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20220621.n.3: anaconda-37.10-3.fc37.src, 20220628.n.0: anaconda-37.11-1.fc37.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/37 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220628.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements
We have one ticket tagged with 'meeting', but there has been no progress in discussion or implementation, so I'm cancelling today's meeting. We've had a glitch in the process, and various tickets which were voted and approved offline were not announced. I'll do that now here in one fell swoop, together with tickets that were approved during the last week. (I tried to filter out tickets that were announced somewhere but not closed, but I might have missed something, so please excuse any duplication.) == Approved during one of the previous meetings #2794 F37 Change proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib APPROVED: FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0) == Voted and approved in the ticket #2809 Change proposal: Erlang 25 APPROVED (+4,0,-0) #2807 Change proposal: Supplement of Server distributables by a KVM VM disk image APPROVED (+3,0,-0) #2806 Change proposal: LLVM 15 APPROVED (+4,0-0) #2805 Change proposal: RPM Macros for Build Flags APPROVED (+4,0,-0) #2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0) #2798 Nonresponsive maintainer: Alfredo Deza adeza Approved by the people involved. #2797 Change proposal: Install Using GPT on x86_64 BIOS by Default APPROVED (+4,0,-0) #2796 Change proposal: BIOS boot.iso with GRUB2 APPROVED (+4,0,-0) #2795 Change proposal: Python: Add -P to default shebangs APPROVED (+5,0,-0) #2792 Nonresponsive maintainer: Ryan Brown ryansb APPROVED (+1,0,-0) #2791 F37 Change proposal: Perl 5.36 APPROVED (+4,0,-0) #2788 Change proposal: Strong crypto settings: phase 3, forewarning 1/2 APPROVED (+3,0,-0) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101385] perl-Socket-2.034 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2101385 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2022-738f473648 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-738f473648 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101385 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220628.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220627.0): ID: 1308279 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1308279 ID: 1308283 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1308283 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2068801] Please build perl-Text-CSV for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2068801 --- Comment #6 from Robert Scheck --- Requested epel9 branch: https://pagure.io/releng/fedora-scm-requests/issue/45334 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2068801 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2068801] Please build perl-Text-CSV for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2068801 Robert Scheck changed: What|Removed |Added Flags|needinfo?(lkund...@v3.sk) | Assignee|lkund...@v3.sk |redhat-bugzilla@linuxnetz.d ||e Status|NEW |ASSIGNED --- Comment #5 from Robert Scheck --- Great, thank you! Re-assigning to myself now. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2068801 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-36-20220628.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220626.0): ID: 1308263 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1308263 ID: 1308267 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1308267 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2068801] Please build perl-Text-CSV for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2068801 Johan Vromans changed: What|Removed |Added Flags|needinfo?(jvromans@squirrel | |.nl)| --- Comment #4 from Johan Vromans --- Hi Robert, I have given commit rights to epel-packagers-sig and made you collaborator for the epel* . Let me know if there is anything else I can do. Sorry for the delay, since I'm not involved in EPEL I usually ignore the messages ;). -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2068801 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Tue, Jun 28, 2022 at 08:42:43AM +0200, Vitaly Zaitsev via devel wrote: > On 27/06/2022 21:18, Sharpened Blade via devel wrote: > > Also, even when you cant remove Microsoft keys, you can still use the shim. > > If you can't remove Microsoft keys, you're nullifying the whole purpose of > secure boot, because anyone can use a signed shim to boot whatever they > want. That's thinking about the problem from the wrong point of view. SecureBoot doesn't prevent an attacker from booting an OS that's different from what you installed, even without shim they could swap to a different Windows install. What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key. IOW, the ability to boot another OS is degraded to merely a denial of service, not a data compromise, because the other OS will be prevented from accessing the encrypted disk. The ability to install your own keys, removing Microsoft keys, adds an additional layer that does let you lock down the machine further, but even without that it is still a useful technology [1]. With regards, Daniel [1] at least it could be except for the huge problem of not securing the initrd that we have. That's not a secure boot problem though, that's a Linux vendor problem -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: All maven RPM builds no longer possible
That is correct, we removed maven-javadoc-plugin from Fedora since we had found a way to build maven without it. xmvn has its own javadoc generator. On 27. 6. 2022 21:46, Jerry James wrote: On Mon, Jun 27, 2022 at 3:04 AM Graham Leggett via devel wrote: I just tried to start from "probably simplest spec file possible” as described below in order to package a maven artefact properly as an RPM: https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/ The build failed because the maven-javadoc-plugin package no longer exists, which is core to building the javadoc package required by the spec. I have since been down a dependency hell rabbithole to try and get something to work, with no luck to date. Googling has revealed that java code has been in various states of brokenness for a while, but we’re at a point where it isn’t possible to build any package using the maven macros in an RPM spec file at all. Are people aware things are this broken? My understanding is that xmvn has its own javadoc support, so maven-javadoc-plugin isn't used even if it is installed. Try adding this to %prep: %pom_remove_plugin -r :maven-javadoc-plugin -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On 27/06/2022 21:19, Sharpened Blade via devel wrote: Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed. Yes, but anyone can read your private keys to sign anything. Someone needs to implement support for hardware tokens, or at least TPM 2.0. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101385] perl-Socket-2.034 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2101385 Jitka Plesnikova changed: What|Removed |Added CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101385 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On 27/06/2022 21:18, Sharpened Blade via devel wrote: Also, even when you cant remove Microsoft keys, you can still use the shim. If you can't remove Microsoft keys, you're nullifying the whole purpose of secure boot, because anyone can use a signed shim to boot whatever they want. Also, if you remove Microsoft keys, you will need to sign the video and network card firmware with your own CA in order to work in SB mode. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2101193] Please branch and build perl-Authen-DigestMD5 for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2101193 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2022-1b0c6bc22e has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1b0c6bc22e -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2101193 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
