Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Stephen Gallagher wrote:
> the %check section
> (which, if I remember correctly is run AFTER the creation of the
> binary RPMs)
No, it runs after %install but before the files are packaged up. It's
possible for %check to make changes to what was staged in %install and
have those changes appear in the package. I think removing that ability
would be an improvement, but that's how it currently is.
Any changes made by %check outside of %{buildroot} should not affect the
binary package though.
Björn Persson
pgp_7oqqyGrq5.pgp
Description: OpenPGP digital signatur
--
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: mdadm Update in Rawhide
Jonathan Wright via devel wrote: > My latest commit to rawhide adds signature verification and updates the > source URL to https. > > https://src.fedoraproject.org/rpms/mdadm/c/c8d54b071aea9605ab75f3c5ff67d44d306e7fb2?branch=rawhide A comment in the spec file says: # keyring should be one from https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys # which will vary depending on who did the release That's a long list. Can all of those people make mdadm releases? Please try to avoid replacing the keyring every time you upgrade the package to a new release. That would severely diminish the security benefit of the signature verification. You can have multiple keys if there are multiple people who make releases. For the current version of gpgverify you need to combine the keys into a single file. Simple concatenation seems to work. The Nginx package does that: https://src.fedoraproject.org/rpms/nginx/blob/8b7ceb13dd13cd18b9603872b2b5611be2d60029/f/nginx.spec#_253 This pull request would improve gpgverify to accept multiple key files, so you wouldn't need to concatenate them: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 Björn Persson pgp_VTg_skqTy.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "fedpkg local" builds fail for rust packages
Fabio Valentini wrote: > - Installing rust-*-devel packages on your local system (i.e. outside > of ephemeral build environments) is not supported. > - The "rust-*-devel" packages are build system implementation details, > if you want to say it like that. > - They are not shipped to users and are not useful for Rust developers. > - They are *only* intended to be installed in temporary chroots (like > those set up by mock). I don't know enough about Rust to understand how the perfectly normal usecase of installing libraries as RPM packages has been made so problematic. I'll just state my strong opinion that packages that aren't meant for software development should not have "-devel" in their names. Björn Persson pgp42QTPCqdJp.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Vít Ondruch wrote: > In any case, I prefer to use Gtk apps for Gnome and I assume this is the > case for Gnome users. Similarly I won't be surprised if KDE users prefer > QT apps. I suppose there might be some people who get so emotionally attached to a widget library that they don't want to use programs that use another widget library. Personally I use what works acceptably for my needs regardless of which widget library it's built on. I edit photos in Gimp (the origin of GTK) even though I currently use a desktop built on Qt. I edit text files in Kate (a KDE program) regardless of which desktop I'm using. I used Kmail for many years, even in Gnome 2 at times, until Kmail became so bad that I had to switch to Claws Mail, which happens to use GTK. I even used to endure Gnome Calculator's annoying Gnome-3-ness because it was the best calculator I had until it recently stopped working. I hope I'm not alone in using what works instead of getting hung up on widget libraries. > Mixing the DE and frameworks might not always work without issues. That's not usually a crippling problem in my experience. Each time the desktop I use breaks down, I switch to another. So far I've always been able to find one that could be configured to work acceptably. It's annoying when I have to spend time on that, but fortunately most of the important programs tend to survive. It would be really horrible if I'd have to log in to one desktop for programming and then switch to another for photo editing or word processing. Let's hope the discord never gets that bad. If I can manage to set a sensible theme that exists for both Qt and GTK, then most programs will look similar enough to not distract me from my work – except for those Gnome 3 programs that refuse to obey the theme. (And Firefox which just has to be different, but that has nothing to do with desktops or widget libraries as far as I can see.) Björn Persson pgp3XcsfmYYXs.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Michael Catanzaro wrote: > On Fri, Mar 29 2024 at 07:44:12 PM +01:00:00, Mikel Olasagasti > wrote: > > Do we know if GH release tarballs are safe? > > The tarballs generated by GitHub that just include the contents of the > git repo should be safe (at least from this particular issue), So it is reported. The bulk of the attack code is in the Git repository, but the line that triggers it is only in the release tarballs, according to the report – but that means that the attacker is or was able to push commits to Github, so at this point it would be foolish to blindly trust the Git repository or the Github-generated tarballs. Björn Persson pgp8nUs2fpGPZ.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Mikel Olasagasti wrote: > For whatever reason Source for xz was changed 2 months ago[1] to use > GH releases instead of tukaani.org site. The public key jia_tan_pubkey.txt did not change at the same time. It was introduced on 2023-05-04 when the package was updated to version 5.4.3. Apparently the current tarballs on github.com and older tarballs on tukaani.org were signed with the same OpenPGP key. Either the attacker has been preparing this for a long time, and is able to upload files to tukaani.org too, or else the attacker has compromised an honest developer and gained access to their secret OpenPGP key, their Github account, and probably all of their other credentials. Björn Persson pgpcAJciGABWI.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer landgraf for package aunit.
Pavel Zhukov wrote: > I see you have received review of the MR . Emails have been answered by > Bjorn too. If you don't have time to maintain Aunit, then please give me or Dennis access to the package so we can take care of it. Björn Persson pgpFCmfiDkSCT.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: do we need CONFIG_UPROBES=y in our kernels?
Marius Schwarz wrote: > From guest to host: you need to trust the host not to spy on you, your > data, connection targets aso. Correct. This is a fundamental principle. Users are at the mercy of the sysadmin. Programs are at the mercy of the operating system. Virtual machines are at the mercy of the host operating system. "The cloud" is just other people's computers, and those people have the power to spy on what you do on their computers. The processor vendors market so-called "secure enclaves" that are supposed to make it so that the host operating system can't see what a guest program does. Of course that means only that the vendor's firmware is the true host, so now the "host" and the guest are both at the mercy of the unfree and secretive firmware. And there have been news about firmware bugs that let attackers bypass the protection, rendering the enclaves useless. The solution is to consider security before you rent other people's computers, and keep secrets and sensitive data on your own hardware. Björn Persson pgpojY8pw6hQR.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Neal Gompa wrote: > It's extremely obvious that people want to use it. It's extremely obvious that *some* people want to use Wayland. It's equally obvious that some other people want to use X. It's also obvious that certain people want to make *everybody else* use Wayland. On the other hand I'm not seeing anyone trying to make everybody use X. Honestly this looks a lot like the usual human desire to force deviants into the mainstream mold. > Neither of you are aligning with the Fedora Foundation of Friends, Building artificial obstacles to make it difficult for other people to use what works best for them is not friendly. I'm seeing people trying to make it difficult to use X by relegating it to Copr. I have not seen anyone try to relegate Wayland to Copr. So who's actually being unfriendly here? The users will come when Wayland provides a better user experience than X. For *their* usecases, not only for yours. Björn Persson pgpK3GbmW35Af.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass rebuild: git push --no-verify
kevin wrote: > The mass rebuild is only doing a bump/rebuild. There's no reason it > should ever cause something that be caught by the hook, and if it did, > it would be better for it to do the commit anyhow and cause a failed > build. IMHO. If, hypothetically, a defect in the mass-rebuild script would corrupt thousands of spec files, how easy would it be to write a mass-revert script to repair the damage? The mass-revert script shouldn't just revert the latest commit in every package, because the corruption might not have happened in every package, and some might have been reverted manually in the meantime. The mass-revert script would need to verify that it reverts only commits done by the defective mass-rebuild script. If that's nontrivial to get right, then it seems to me that there is value in a hook that validates changes made by a script. Björn Persson pgppkAN1N_aVJ.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: side-tag with GCC 14.0.1 snapshot for Fedora 40
Jakub Jelinek wrote: > The f40-build-side-81394 side-tag contains new > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be > tagged into rawhide shortly before the mass rebuild. > > If there is anything you'd like to rebuild against it before the mass > rebuild (such as packages depending on Ada which like every year bumped > sonames of its shared libraries), please do so soon. Thanks for the side-tag. Most of the Ada packages – those that I have access to – are now rebuilt if I did everything right. The rebuild went smoothly this time. Björn Persson pgpS9LIgzjWcq.pgp Description: OpenPGP digital signatur -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
Kevin Kofler via devel wrote: > I am still opposed, because it is still a backwards-incompatible change that > breaks existing repositories (such as my Calcforge one) Backwards-incompatible changes are often made far too nonchalantly. This is not one of those cases. When it comes to cryptographic algorithms, backwards-incompatible changes are necessary from time to time. Cryptanalysis always progresses, and quantum computers loom at the horizon. Secure algorithms do not remain secure (except for One- Time Pad, which is mathematically proven but quite impractical). Maybe there will some day be a set of cryptographic algorithms that are mathematically proven to be secure for all eternity (and more practical than One-Time Pad). Until that day comes, all software, including your Calcforge repository, must be prepared to replace algorithms as needed. > just so that someone can tick a checkbox on some "security" checklist. As a packager you are responsible for all Fedora users' security. If you behave as if security is nothing but a pointless checklist, then you put all of our computers in jeopardy. An attacker who breaches your computer will be able to inject malware into Fedora through your packages. It is your duty to take security seriously as long as you have commit privileges to any Fedora packages. Björn Persson pgpF1As1bgQjX.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Adding Passim as a Fedora 40 feature?
Richard Hughes wrote: > I was thinking of adding Passim as a default-installed and > default-enabled dep of fwupd in the Fedora 40 release. Before I create > lots of unnecessary drama, is there any early feedback on what's > described in https://github.com/hughsie/passim/blob/main/README.md > please. I finally read the README, and, oh geez, this thing is even documented as assuming a friendly network! And it's being proposed to be enabled by default, which means it will run on laptops that move around between cafés, hotels, airports and all the hostile environments anyone can imagine. The document doesn't say what design decisions were made based on the assumption of a friendly network. All of those design decisions need to be reconsidered with the assumption that there are attackers on the LAN who will abuse Passim any way they can, and that Passim must deal reasonably with any and all attacks. Björn Persson pgpwa7vJgc1mo.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently
Matthew Garrett wrote: > On Sat, Aug 12, 2023 at 12:07:05PM +0200, Leon Fauster via devel wrote: > > Please do not clutter the user experience with such _additional_ > > informations. The user on such workstations are not always the > > administrator and such informations would not help/change the > > situation either. > > I think it's reasonable that this should be something under admin > control, but for the common default scenario where the single uesr is > also the admin it seems reasonable to let the user know that they'll no > longer receive security updates? Notifying the user only if they're a member of the wheel group seems like a reasonable default. Björn Persson pgpfQSwgSW2hh.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
Vitaly Zaitsev via devel wrote: > On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote: > > You could, for example, buy a supported Logitech > > Receiver > > I don't recommend anyone to buy this proprietary hardware: For years I tried to use Bluetooth mice, thinking a standard would be preferable over a proprietary protocol. But Bluetooth never worked well for me. It's not just mice. Everything I've tried to do with Bluetooth has been unstable and unreliable. Eventually I gave up and concluded that Bluetooth in Fedora is not a thing to rely on. The mice I've used that connect to Logitech dongles have always been responsive and never had any connection problems. Mouse cables get in my way and disturb my work. As long as GUIs and web programs require a mouse, I need a wireless mouse. Since Bluetooth is out, Logitech is it. I'd never use a wireless keyboard though. Whether Bluetooth or Logitech, I'm not going to type passphrases over some iffy radio protocol using a random number generator of unknown quality. Alexander Ploumistos wrote: > And thanks to fwupd and Logitech's embracing it, we had the fix in a > very short time. I never knew about it until now, because nothing notified me that a firmware update was available. I have now enabled fwupd-refresh.timer. I seem to get notifications only in SSH, not on the console, but that's something at least. If it had been on by default, then it would probably have been less than four years before I found out about those vulnerabilities. If the firmware files are properly authenticated, then I think notifications about firmware updates should be enabled on all installations. Björn Persson pgpR2_bpFfGGv.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
Bob Mauchin wrote: > I'm currently assessing what is needed by our binaries packages and will > take packages needed that have been orphaned. Thank you! I was getting really worried that Restic would drop out and I'd have to design a new backup solution yet again. Björn Persson pgpma3Ia4jGIB.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Looking at the screenshot, I wonder what percentage of users will read "Privacy", see that all the switches are on, and click "Next" in the belief that all the privacy features are on. Björn Persson pgp2ZQzLUmMNa.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Michael Catanzaro wrote: > The problem is if users are expected to answer, they are going to > probably answer No and it's effectively the same as an opt-in. But if > we have a default value, users will be inclined to leave the default > value. [...] > Remember, for avoidance of doubt, we will NEVER enable telemetry upload > without the user's consent, which is indicated by either (a) not > flipping the telemetry switch in gnome-initial-setup to the off > position, In other words, you expect that many users will click "Next" without thinking, and you intend to call that "consent". It's a popular tactic to make people "agree" to things without knowing it. Björn Persson pgpRT0A1SqC4E.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Michael Catanzaro wrote: > I would envision installing > eos-event-recorder-daemon via a Recommends: from the > gnome-control-center and gnome-initial-setup packages (and probably > also by adding it to the workstation-product comps group), so if you > don't have gnome-initial-setup or gnome-control-center installed, you > wouldn't get in on upgrade. I don't seem to have a package named gnome-initial-setup installed. gnome-control-center is installed, but fortunately it looks like I can remove it without losing anything important. I don't know what pulled in gnome-control-center or when, but I used XFCE for many years (until it became unusable on my laptop and drove me over to LXQT), and XFCE had ties to various gnomy things. > Certainly the metrics > components should not be installed for non-GNOME users as part of this > change proposal. Having some package installed is not the same thing as using a particular desktop environment. There are many possible reasons why packages get installed, and they won't always get removed when they're no longer needed. Among more than 4000 installed packages, there are surely several I'm not actually using, but examining them all to determine which ones can be removed would take a lot of work. > I think eos-event-recorder-daemon uses some sort of ring buffer to > eventually discard old events, so that storage space does not increase > forever and should not become an issue? That should make it somewhat less of a problem if it is so. It should of course be verified before data gathering is turned on. > (BTW, the GNOME 3 era concluded with the release of GNOME 40 in Fedora > 34, so I wouldn't except Fedora users to still be using GNOME 3. :) I need some way to distinguish between the Gnome that once was and the very different thing that took over the name "Gnome". Björn Persson pgpdVGkitXcGu.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
As a non-user of Gnome 3 who normally never runs any Gnome 3 settings programs, I get the impression that Fedora 40 will begin accumulating unused metrics somewhere in the filesystem. To prevent a constantly growing waste of storage space, I'll have to run one of two Gnome 3 settings programs – which may or may not require starting a Gnome 3 desktop session – and find the right switch to either turn on uploading or turn off collection. I'll have to remember to do that after upgrading around a year from now, and also on any new installations in the distant future. If my impression is wrong, then the change proposal needs to be amended. Björn Persson pgpgswP8SfU23.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
Jens-Ulrik Petersen wrote:
> it now defaults to normal green and adds the
> red error code from Stephan (maybe this part could still be improved?)
I like the red error code enough that I'm trying it out on my own
workstation. Yet I doubt it's suitable for the default prompt. I'll
remember what it means because I've configured it myself. To a beginner
who hasn't configured their prompt, the intermittent appearance of a
red number will be very cryptic.
If the error code is included, then appending it to the working
directory isn't the best choice. It looks like a part of the directory
name, especially to red/green blind users I expect. There should be a
space or other separator, but even then it could be ambiguous as
filenames can contain almost any characters. Writing the error code
before the username is less confusing. Users are unlikely to think that
the digits are part of their username.
This code expands to nothing if the exit code is zero, and to the exit
code followed by a space otherwise:
prompt_result_separator=' '
PS1='\[\e[0;31m\]${?#0}\[\e[0m\]${prompt_result_separator[!$?]}...'
Note also the "0;" in the beginning. I think all prompts should begin
with that to clear any attributes that may have been left behind by a
broken program. (Try "echo -e '\e[8m'" and see if it hides your prompt.)
Björn Persson
pgp_JLupc3tON.pgp
Description: OpenPGP digital signatur
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: How to deal with sysusers files inside the package
Ewoud Kohl van Wijngaarden wrote:
> I'm looking at converting my package (where I'm also the upstream) to
> use sysusers.d but I'd prefer shipping the sysusers.d file inside the
> source tarball rather than in packaging. This allows me to use the same
> definition on Debian, which I think is a huge benefit of systemd
> standardizing these kinds of things.
Yes, of course you'd want to do it that way, but Fedora isn't ready.
> The documentation[1] only mentions shipping it as a separate source, not
> inside the tarball. Should I simply replace %{SOURCE3} in the docs with
> the path from the extracted tarball?
My experience is that sysusers_create_compat can't be made to work with
a file extracted from the tarball. It requires a separate source file.
As long as user and group accounts must be added in the packaging, it's
more convenient to do it in the spec file than in a separate sysusers
file. Thus sysusers_create_compat seems rather useless to me.
If your program needs its user account only at run time (such as a
daemon that runs as non-root), then it's enough to drop the sysusers
file into /usr/lib/sysusers.d. The account will then be created at the
end of the RPM transaction, after all the packages have been installed.
In that case shipping the sysusers file inside the tarball should work,
and you don't need sysusers_create_compat.
If your package contains any files owned by the account it creates,
then installing the sysusers file is not sufficient. In that case the
account must be created in %pre before the files are installed, either
with sysusers_create_compat (which requires a separate source file) or
with plain old useradd or groupadd.
I've seen some discussion recently about integrating sysusers support
into RPM. That should allow an upstream sysusers file to work in all
cases, if I understand correctly. If your package currently works, then
I suggest waiting until the RPM integration is done before you change
how user accounts are created.
Björn Persson
pgpBEXmS0YDu0.pgp
Description: OpenPGP digital signatur
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Are we ready for ipv6-mostly networks?
Petr Menšík wrote: > Hello everyone, > > I have attended recently csnog.eu conference [1], where some interesting > presentations took place. They were usually in Czech, so it is not > something I am going to share more. But what took my interest were ipv6 > readiness with some exceptions. Fedora is ready to be run on dual-stack > IPv4 and IPv6 networks just fine. But the presentation were about future > case where we run most hosts on IPv6 network only, but allow some older > devices to take and use also IPv4 address. > > Fortunately there is roughly the same presentation[2] in English, which > took the place on RIPE 85 meeting. What catched my interest were talk > about Windows 11 and Apple systems are ready, but not really talk about > how any linux distribution is ready for such situation. It seems to me > we should improve the support for mentioned mechanisms in Fedora. Having watched the latter presentation, I understand that the idea is that, on a network with a limited pool of globally routable IPv4 addresses, IPv6-capable clients should use only IPv6 and refrain from requesting IPv4 addresses, so that addresses will be available to legacy devices that need IPv4. It seems to me that it would be very difficult for a DHCP client program to know whether the Fedora installation it's running on needs an IPv4 address. I think it would have to be manually configured. It's mentioned in the presentation that IPv6 support is required in Apple's App Store. That's not currently the case in Fedora. In my own opinion everything should by now assume IPv6 as the norm, and treat IPv4 as the legacy protocol that must still be supported for compatibility – but that's not Fedora's policy. The policy is as follows: | If an application contains native and stable support for both IPv4 and | IPv6, and support for IPv6 does not negatively affect IPv4 then both | MUST be enabled in the Fedora package. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_networking_support That means that IPv4-only programs are still quite welcome in Fedora if their lack of IPv6 support is an upstream limitation and not introduced by the packager. Thus the network configuration must expect that the user might run such a program and might need IPv4 connectivity. The policy should probably be changed before Fedora begins requesting only IPv6 addresses by default. Another concern is that the entire IPv6-mostly concept seems to assume devices that are strictly clients. It doesn't seem like it would work for anyone who runs any kind of server or peer-to-peer program. The idea seems to be that IPv6 clients will access IPv4-only servers over NAT64. Like all address translation, NAT64 is an obstacle to peer-to-peer communication. If you need to communicate with a peer who is stuck with an RFC 1918 address behind NAT on an IPv4-only network – a case that is still far too common – and you're using IPv6 and NAT64, then you and your peer will both be unable to connect to each other. If globally routable IPv4 addresses are available on the network where you are, then you'll want one so that your peer can at least connect to you. Users of peer-to-peer programs will want to configure their DHCP client to request an IPv4 address in case that need arises. Björn Persson pgp9M7lTUUnBU.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
Marián Konček wrote: > AFAIK Gnome Terminal is the only terminal that uses white background by > default. To my knowledge, all the other terminals use black background. If you can get *all* the terminal emulators amended so that users can configure the prompt color in the same dialog box where they configure the background and text colors, and also get that configuration to take effect across SSH, even between different operating systems, *only then* is it somewhat reasonable to expect users to also choose another prompt color when they set the background color. As long as the prompt is configured in a completely different place than the background, and separately on each server, the prompt must be readable by default on both light and dark backgrounds. Björn Persson pgprqT_maxZDz.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
Chris Adams wrote: > My personal (bike-shedding) preference is to not run external commands > on every prompt though; when a system is slow or having problems, those > can kill any chance at recovery or even troubleshooting. I agree. Please keep the number of things that can make the shell unusable minimal. Björn Persson pgpqIGrB30kK8.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
Jens-Ulrik Petersen wrote:
> In Fedora the bash prompt is not colored or highlighted by default.
>
> I personally find this a usability issue: it makes it hard to find previous
> commands between long outputs when scrolling back in a terminal.
I find myself pressing Enter several times before running a command to
be able to find the beginning of the output afterwards, so I agree. The
prompt should stand out more.
> For example I could suggest we change the default fedora bash prompt from:
> PS1="[\u@\h \W]\\$ "
> to something like:
> PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
>
> Then the PROMPT_COLOR envvar would make it easy for users to change or
> customize their prompt coloring anyway.
> For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
> seems readable in both dark or light terminals.
It seems popular among terminal emulators to make bold text extra
bright. That makes the bold green prompt a bit too bright for me on a
white background. It's nowhere near as bad as yellow on white, but a
little too bright to be comfortable. Once I turn off the brightening to
let bold text be the specified color, the bold green prompt works well
for me.
One way to avoid all the color issues could be to just make the prompt
bold by default. That would probably make it stand out enough in many
situations. I think it wouldn't help much for programmers compiling
software though, because GCC outputs filenames in uncolored bold text,
so even a bold prompt would blend in among the compilation errors.
Björn Persson
pgpo0PYGOraT4.pgp
Description: OpenPGP digital signatur
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: C-specific compiler parameters (was: Update on Changes/PortingToModernC)
Jakub Jelinek wrote: > On Wed, May 10, 2023 at 12:09:10AM +0200, Björn Persson wrote: > > Florian Weimer wrote: > > > I am going to explore a way to land -Werror=implicit-int > > > -Werror=implicit-function-declaration among the default compiler flags. > > > There's a bit of an issue because the C++ front end warns on > > > those flags, so we need another -specs= kludge that is incompatible with > > > Clang. > > > > It sounds like those parameters should be added only to CFLAGS, not to > > CXXFLAGS. > > > > __global_compiler_flags already contains things that cause warnings > > from the Ada and Fortran compilers. The Ada packages get the warning > > “'-Werror=' argument '-Werror=format-security' is not valid for Ada” > > over and over. It doesn't break any builds but it's annoying noise in > > the build logs. > > GCC 13 has a solution for that, one can add > -Wno-complain-wrong-lang > to > -Werror=format-security > etc. and avoid such warnings (that some compiler option is only appropriate > for a subset of GCC languages and it is compiling some other language). Thanks. That's an acceptable workaround, and seems to work as advertised. I may add it to build_adaflags if a central solution won't be accepted. It would still be better to use parameters only where they are meaningful. Longer command lines make troubleshooting more difficult. Björn Persson pgpxBrQsHBX2P.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
C-specific compiler parameters (was: Update on Changes/PortingToModernC)
Florian Weimer wrote: > I am going to explore a way to land -Werror=implicit-int > -Werror=implicit-function-declaration among the default compiler flags. > There's a bit of an issue because the C++ front end warns on > those flags, so we need another -specs= kludge that is incompatible with > Clang. It sounds like those parameters should be added only to CFLAGS, not to CXXFLAGS. __global_compiler_flags already contains things that cause warnings from the Ada and Fortran compilers. The Ada packages get the warning “'-Werror=' argument '-Werror=format-security' is not valid for Ada” over and over. It doesn't break any builds but it's annoying noise in the build logs. It would be better if __global_compiler_flags would contain only language-independent parameters, and language-specific parameters were added in build_cflags and build_cxxflags. Björn Persson pgprOqHou0Nu0.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The new version of Fedora Messaging Notifications will arrive this week
Aurelien Bompard wrote: > do you mind opening a ticket on FMN's tracker please? Done: https://github.com/fedora-infra/fmn/issues/901 Björn Persson pgpwJ54yOnOQ8.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The new version of Fedora Messaging Notifications will arrive this week
Aurelien Bompard wrote:
> If I understand correctly, you browser's javascript engine can't run the app?
That's how it seems at least. This error message might be relevant:
Error: SyntaxError: expected expression, got keyword 'import'
File: https://notifications.fedoraproject.org/assets/index-82e1ce33.js
Line: 19, column: 17689
Code:
login/fedora",name:"auth-login-fedora",component:()=>Jr(()=>import("./LoginFedora-631fa1c1.js"),[])}),t.isReady().then((
> which browser are you using?
Seamonkey. I originally switched to Seamonkey to keep the Web calm when
the ability to stop GIF animations was removed from Firefox. That's
still relevant in places, but these days the greatest advantage of
Seamonkey is that I don't have to relearn how to do things each time
Firefox's user interface gets reshuffled.
Björn Persson
pgpwD6uQ_jvxV.pgp
Description: OpenPGP digital signatur
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: The new version of Fedora Messaging Notifications will arrive this week
Aurelien Bompard wrote: > > I see only a blank page. So it has strict requirements for which > > Javascript runners can be used to run it, then? > > Yes, the UI is written in javascript (Typescript with Vue.js to be precise). > We should probably add a noscript tag to make that clearer. I won't see that. I have whitelisted Javascript from fedoraproject.org, so my browser will ignore the content of noscript and try to run the Javascript program. But the program requires something that my browser doesn't have, so nothing is displayed. The new FMN is far from alone. These demanding Javascript programs are becoming ever more common, and I can no longer avoid all of them. None the less it's frustrating each time I have to start another browser and cope with a worse user interface to run one of those programs. A locally installed program would have a file header specifying the executable format, or a shebang specifying which interpreter to use, and RPM dependencies would ensure that the correct interpreter is installed. For a web program there's no way to specify in the URL which Javascript interpreter shall be used to run the program, so I have to figure out and remember when I have to start the browser for demanding Javascript programs and when I can use the browser with the stable and sensible user interface. Björn Persson pgpIB3pZw10sf.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The new version of Fedora Messaging Notifications will arrive this week
Aurelien Bompard wrote: > OK, the switch is complete, the new notifications app is at > https://notifications.fedoraproject.org, and if necessary you'll see a link > to the old app there. I see only a blank page. So it has strict requirements for which Javascript runners can be used to run it, then? Björn Persson pgpmhakqztAuR.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Kevin Fenzi wrote: > On Sun, Apr 23, 2023 at 11:21:58PM +0200, Björn Persson wrote: > > Kevin Fenzi wrote: > > > We could probibly come up with some > > > better way to start new topics/discussions > > > > Yes I think I can come up with a better way. Give each tag its own > > email address, like a mailing list. That was very easy to come up with. > > I think you mean each category? I don't know Discourse but we're told that something called a tag is roughly equivalent to a mailing list. I suppose categories could have addresses too. > But you may want multiple tags on a post... Like Vít said, you can send to multiple addresses. That's how you cross-post to multiple mailing lists. The Discourse server would then read all the addresses and apply all of those tags and/or categories to the post. When there are multiple recipient addresses in the same domain, a well-behaved SMTP client is supposed to transmit a single copy of the message in a single SMTP session with multiple RCPT commands. Thus the Discourse server will receive only one copy. It is however possible that some badly written program might mishandle such a message and send a separate copy to each recipient address. Each copy would then still contain the whole list of addresses in the To and CC fields. If the Discourse server would read the header fields and not just the SMTP envelope, then the copies would appear as duplicate posts, each with the full set of tags, not as separate posts with one tag each. If duplicates would turn out to be a great nuisance, then the Discourse developers might want to add a deduplication feature. The Message-ID field would be useful for discovering duplicates, but deduplication should not be done based on the message ID alone. The full contents should be compared to ensure that the messages really are identical, in case some defective or malicious email client produces non-unique message IDs. As you can see, it doesn't take any great inventions to do this. The email standards already contain the necessary features. They just need to be implemented, if the Discourse developers are serious about supporting interaction by email. > But that also doesn't solve the spam problem... anyone could send to > those addresses, and indeed spammers will. ;( We're told that only sender addresses associated with a Fedora account are allowed to send to the single global new-topic address. Obviously that would apply to the tag (and category) addresses too. That's analogous to reducing spam to mailing lists by accepting posts only from subscribers. In what scenario do tag-specific new-topic addresses result in a worse spam problem than a single global new-topic address? > But perhaps this could be useful with some other way to autenticate > posts. I haven't seen spammers impersonate subscribers in the mailing lists. The occasional spam that gets into the mailing lists seems to be done by subscribing a disposable address and sending from that address. If spammers would start putting in a legitimate user's address as sender to get the spam into mailing lists or Discourse, then there's DKIM. I have found DKIM by itself ineffective, as most of the spam is DKIM- signed now, but DKIM combined with a requirement for a known sender address should be sufficient authentication to stop spam. The spammer would at least have to actually send from the same domain as the user they impersonate. For registered users whose email provider doesn't sign their messages with DKIM, a verification message could be sent that they have to reply to, like when signing up for a mailing list but repeated for every post that isn't a reply. There's also OpenPGP/MIME. But I rather doubt that such measures will be needed just to fight spam. Strong authentication is for preventing more targeted attacks than spam. Björn Persson pgpHIaugWIhhr.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Kevin Fenzi wrote: > We could probibly come up with some > better way to start new topics/discussions Yes I think I can come up with a better way. Give each tag its own email address, like a mailing list. That was very easy to come up with. You can write the tag after the plus sign if that makes it easier to implement. Instead of "fedoraproject+newto...@discoursemail.com" the address could be "fedoraproject+de...@discoursemail.com" or maybe "fedoraproject+devel/newto...@discoursemail.com". Or some other format. The local-part can be structured any way the Discourse developers like, as long as it's at most 64 bytes and adheres to the dot-atom-text syntax in RFC 5322. Björn Persson pgpWVzBgAke8P.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Kevin Fenzi wrote: > One bug I hit setting this up this weekend... some (but not all) of the > categories appear to have newlines in the List-ID: header. ;( > > ie, > > List-ID: Fedora Discussion | Ask Fedora Ask in English > > > Hopefully this is a bug that can be fixed... > > So the above won't really work as the MATCH doesn't include the second > line with the actual listid in it, only the description. ;( I think you'll have to blame Procmail for that. What you show is called folding in RFC 5322. It's valid syntax if the continuation line begins with whitespace, which it looks like it does. Folding is even recommended for lines longer than 78 characters. Programs that parse email are supposed to unfold folded lines. The complexities of text-based protocols provide for so much fun! Björn Persson pgp9IXcpXeGMk.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Matthew Miller wrote: > It is also possible to enable > new topics by email, but that's vulernable to impersonation (and spam) so > if we enable that there probably will be a moderation step. Email signed with OpenPGP/MIME solves the impersonation and spam problems. A message could be allowed to bypass the moderation after it's verified that it's signed with the correct public key for an email address registered in a Fedora account. DKIM also seems able to assert that a message is from a certain sender address, although almost all usage I've seen states only a domain name. But if those new topics can't be sent to a mailing-list-equivalent, but just end up in some sort of "other" bucket, then it seems useless anyway. Björn Persson pgpcbyFcDPtSX.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
Matthew Miller wrote: > There _are_ email notifications, You keep talking about "notifications". I don't want a notification saying "somebody said something; run our Javascript program to find out what it was". I want the actual message delivered to my mailbox. But some people in this thread talk as if it's possible to get the actual messages by email. I even see some hints that a proper tree view might be possible. But many others say the email features of Discourse are no good. The overall picture is unclear and far from convincing. > and you can interact by replying to them. You let the quarrel go this far before you even bothered to mention that? You're clearly not serious about selling the email features of Discourse. You're trying to convince email users that your preferred communication program is better than their preferred communication program. Users of various email programs are saying no, the program I have chosen works better for my needs. Do you also waste time trying to convince Emacs users to switch to Vi? Instead of trying to make everybody use the same Javascript program, what you should do is show how your preferred program implements the relevant standards to be interoperable with my preferred program, so that we can communicate while each using our respective programs. If it's not interoperable, then that's where the problem is. So how complete is Discourse's email functionality actually? Can it be used as a mailing list server, or not? > Do take a look at > > https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 Okay okay fine! I'll start up a browser in which the Javascript program even works and go read in the Javascript program about how I might not have to use the Javascript program. So it says a "tag" is supposed to be sort of like a mailing list, but there's only a single global email address for starting new threads. There's no way to send to a specific tag. Thus it's impossible to post to a specific mailing-list-equivalent. How am I supposed to ensure that my messages reach the appropriate audience? Maybe by replying? It's rather unclear how replies by email are handled, but I can guess that they're given the same tag as the message they reply to. If that's the case, then it almost seems like they *want* people to reply to an irrelevant thread instead of posting a new thread. I suppose a more likely explanation is that the email notifications are meant to draw users back to the Javascript program. Either way, according to that post the answer is no, Discourse is not usable as a list server. Those who want to replace Mailman with Discourse should work on improving its email capabilities until it can be used as a list server. Björn Persson pgpUVt9_aKC4f.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Auto-assign packager sponsors to tickets?
Jakub Kadlcik wrote: > > From this thread I get > > the opposite impression, that Pagure tickets are processed quickly and > > FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy > > is updated to ask for a Pagure ticket in every case. > > I get the same impression and I would agree with Otto's proposal to > get rid of the FE-NEEDSPONSOR entirely. To a beginner (in any project) it's cumbersome to file two separate requests in two different issue trackers for what feels like a single task. It's less of a barrier to beginners if they only have to deal with Bugzilla. On the other hand it's important that there are ways to become a packager without adding a new package, so a package review in Bugzilla can't be the only way to get sponsored. Therefore, if some automation can notify the sponsors in Pagure when a review is completed and still blocks FE-NEEDSPONSOR, that sounds like a better idea than getting rid of FE-NEEDSPONSOR. It would lower the barrier to entry for those beginners who begin by making a new package. > Apart from it not being > processed as effectively as the package-sponsor repo tickets, the > FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but > the ticket doesn't need to be sponsored, the contributor does. That > becomes weird when the contributor has more tickets at the same time > and so on). I would think most beginner packagers start with a single package. I had three myself, but they depended on each other so one specific package had to go first. A beginner with multiple independent packages, such that they can be reviewed and imported in arbitrary order, is probably an uncommon case. Björn Persson pgplreAZxcOhG.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: No koji builds during mass branching and updates-testing enablement
Fabio Valentini wrote: > As a follow-up from a recent discussion on Matrix/IRC, I'm proposing > the following change to the development cycle / release schedule: > > "Koji builds are blocked while mass branching and updates-testing > enablement are in progress." What will packagers see? Will builds be queued, and get processed when the lock is released? Will build attempts be rejected with a clear explanation? "You can't build while we're branching. Please try again later." Or will packagers start asking why they get an incomprehensible stack trace from fedpkg? Björn Persson pgpHuGO6RgD0M.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedpkg: Failed to get repository name from Git url or pushurl -> %build
Kenneth Goldman wrote: > Let's see if I have this right ... > > %build > %configure > %make_build > > are not three separate steps. %build is the overall step, and the next two > lines > are the build steps. The blank line terminates the %build. Correct? A blank line has no special meaning. A section continues until the next section begins. Björn Persson pgpmzB0onHLYx.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
Gordon Messmer wrote: > Contrary-wise: Because Fedora updates only contains the latest built, > once a build marked as a security fix is obsoleted by another build, > there is no longer any indication that a security issue existed in any > version, at which point "dnf update --security" no longer works. There are also other dangers with installing only security fixes. If a bugfix is released and packaged, and later it's discovered that the bug had security implications, then no security update will be made because the fix is already packaged. It might be possible to set a security flag on the update after the fact, but nobody will bother with that. I would therefore advise against using --security. If one can't install all the updates continuously, then one should use a more stable distribution than Fedora. Björn Persson pgp_GPr1Z148d.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update on SPDX license id adoption in Fedora
Jilayne Lovejoy wrote: > It is not scalable > for Richard to submit most of the licenses to SPDX and me to create the > files for those licenses... :) On the other hand, having many people learn a complex process and use it only once is very inefficient use of man-hours. > We have been implementing labels in the Fedora License Data repo to help > indicate what is needed next. Nothing notifies me about changes to labels, so they don't work as reminders that there's more work to do, but they have some value as confirmation that the next step in the procedure is what I think it is. Björn Persson pgp4sJN8o86Zp.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HyperKitty broken References and In-Reply-To headers
Eike Rathke wrote: > On Wednesday, 2023-02-22 00:46:19 +0200, Otto Liljalaakso wrote: > > > Ok, I found the other parts of the thread now. > > Something strange is going on here - it seems that when Arthur replies, > > threading breaks and I see separate subthreads in Thunderbird. > > Also lists.fedoraproject.org seems to be similarly confused. > > That's likely because > | User-Agent: HyperKitty on https://lists.fedoraproject.org/ > writes broken References and In-Reply-To headers: > > | References: < > | > > > | In-Reply-To: < > | > > > > Note the doubled <<>> and folding line break after first <. Yes, it looks like Hyperkitty has trouble with unfolding folded header fields. Kenneth's Message-ID fields are folded over two lines. That's unusual but perfectly valid syntax. It's even recommended by RFC 5322 because Kenneth's message IDs are rather long. This line folding seems to trigger some defect in Hyperkitty so that it fails to recognize the message ID each time somebody replies to Kenneth, and shows the reply as a separate thread. And then, when Artur uses Hyperkitty to reply to Kenneth, Hyperkitty seems to think the line break is part of the message ID, which results in that invalid syntax. That's just one example of how difficult it is to write a correct email parser. It's even a rather simple case compared to the monstrosities that are allowed in valid email syntax. Björn Persson pgp1A9BxCsgXQ.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Zdenek Dohnal wrote: > On 1/16/23 12:31, Björn Persson wrote: > > Robert Marcano via devel wrote: > >> The admin can implement CUPS > >> authentication but an ipp://localhost:6 open port entirely open to > >> anyone on the local machine to submit print jobs directly bypassing CUPS. > > > > In that case it's also accessible to all the untrusted Javascript junk > > that regularly runs in the user's browser. Because IPP is built on HTTP, > > a Javascript program can tell the browser to send an IPP request. What > > has been done to secure those "virtual printer devices" against DNS > > rebinding attacks? > > https://en.wikipedia.org/wiki/DNS_rebinding > > I'll ask IPP-USB upstream about it, stay tuned. What did upstream answer? Björn Persson pgp52ZeVNAUhQ.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
Gordon Messmer wrote: > If a maintainer enabled the _elf_require_fallback_versions macro > before a mass rebuild where the _elf_provide_fallback_versions macro > had been enabled globally, then the resulting package would have > versioned dependencies, and the packages it depends on might not have > versioned dependencies. That package wouldn't be installable. It seems to me that it would be much safer if the dependency generator would verify that the library package actually provides the generated dependency. If _elf_provide_fallback_versions is turned off in a single package for whatever reason, then dependent packages should only need rebuilding to pick up the unversioned dependency. The maintainers of the dependent packages shouldn't have to turn off _elf_require_fallback_versions manually. There are always some failures in each mass rebuild. If library L fails to build in Fedora N, and fails again in Fedora N+1, then under the current policy, L will be retired from Fedora N+2. If you turn on _elf_provide_fallback_versions in Fedora N, and then turn on _elf_require_fallback_versions in Fedora N+1, then any packages that use L will become uninstallable in Fedora N+1, half a year before L will be retired. Therefore, if you're going to rely on the FTBFS retirement process to ensure that all libraries provide version numbers, then you shouldn't turn on _elf_require_fallback_versions before Fedora N+2. Once the dependency generator has found the filename it gets the version number from, it would be easy to run rpm --query --provides --file | grep --quiet ^$ except that people keep saying that package builds shouldn't invoke RPM for some reason. Is there a way to do the above without actually invoking RPM? Björn Persson pgpM_h8XhTJd4.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
Gordon Messmer wrote: > In order to enable the requires feature on a single package (without a > mass rebuild in between), the maintainer would need to ensure that all > of the package's dependencies had been build after the provides feature > was enabled, and arrange to rebuild any that hadn't. If they fail to do that correctly, will their package become uninstallable due to unsatisfiable dependencies, or will it just get normal unversioned dependencies on those libraries that don't provide a version number? That should also be explained in the change proposal. Björn Persson pgpmzFCoPqNux.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
Gordon Messmer wrote: > Before merging that feature, RPM's maintainers are > interested in feedback from a wider audience. The Detailed Description describes the problem thoroughly, but fails to describe the solution. Unanswered questions include: · What exactly will be added to the dependencies? · How will the dependencies be generated? · Will packages require the version of a library that was present when they were built, even if they don't use any new interfaces? · Will they require that exact version, or that version or newer? · Will this make it even harder to achieve the ideal of reproducible builds? Yes I can find some of the answers elsewhere. I shouldn't need to go searching for answers. They should be available in the change proposal. Björn Persson pgpsKLzLivnaq.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Spec file encoding (was: fedpkg: Failed to get repository name from Git url or pushurl)
Kenneth Goldman wrote: > > -Original Message- > > From: Miro Hrončok > > > > On 16. 02. 23 14:50, Kenneth Goldman wrote: > > > Could not execute mockbuild: Could not query n-v-r of hello: 'utf-8' > > > codec > > can't decode byte 0x93 in position 259: invalid start byte > > > > That indicates it's not actually UTF-8. > > I can only report when I cut and paste the smart quotes > from the web page to the .spec file (Firefox -> emacs), I > get 0x93 and 0x94 and fedpkg reports that error. So apparently Emacs saved the file in some Microsoft encoding, probably Windows code page 1252, but FedPKG tried to read it as UTF-8. When I load the packaging tutorial I get UTF-8 from the web server, so it seems that something on your computer converted the text into a Microsoft encoding. Programs should generally use the character encoding specified in your locale, but FedPKG might be hardcoded to use UTF-8, perhaps justified by the policy that Fedora spec files must be UTF-8 encoded: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_encoding If you're going to cooperate with the rest of us in the Fedora project, then you'll need to handle UTF-8 in spec files. Sooner or later you'll encounter some non-ASCII characters. You may need to tell Emacs to read and write spec files as UTF-8, or you may need to fix your locale. Run "locale" to check. Going by your email address, en_US.utf8 is probably the right locale for you. Björn Persson pgpgPw846O9ko.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bootstrapping package with circular dependencies in koji
Jaroslav Skarvada wrote: > Thanks for the info, we will try it. It would be great to have it > documented somewhere in the guidelines Yes it would. This looks like a good place: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping "koji edit-tag --help" calls it "Set tag extra option". I would not have guessed that an "extra option" would transform into an RPM macro, nor that a "_with_" prefix would need to be added. Björn Persson pgpCIAUkIr_UN.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FYI... yubioath-desktop is slated to be removed from F38 repository
Gerald B. Cox wrote: > yubioath-desktop and potentially yubikey-manager-qt will not be included in > the F38 repository due to packaging issues. Just when it looked like they had gotten Yubioath-desktop to work properly, it disappears. It's so tiresome to have rugs pulled like this all the time. I wish I had a way to know which programs will continue to work, so I can rely on them. I suppose I'll try Ykocli and see if that's usable. > For additional information and suggested mitigations, please review: > https://discussion.fedoraproject.org/t/f38-yubioath-desktop-yubikey-manager-qt-will-no-longer-be-available-in-fedora-repository/45921/6 And that's such a fancy modern Javascript program that it can't even be scrolled in a browser with a stable user interface. Wonderful. Björn Persson pgpjS66OatxDZ.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
Michal Schorm wrote: > I'd like to learn why people would (not) like such a check or reminder. The maintainer sees the conditional every time they update the spec. They can remove it whenever it's convenient to them. There's no need to pester people about such non-urgent maintenance. It's not like something will break if the conditional isn't removed in time. Björn Persson pgpCf1F7Tm7T3.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()
Pavel Zhukov wrote: > Yes, that happens every year because of koji limitation. > Ada rebuild is not just mass-rebuild thing. > Because of circular dependencies: gprbuild buildrequires xmlada and > xmlada build requires gprbuild and both of them requires > gcc-gnat.so. they were built with > bootstrap of gprbuild should be done which requires manual steps (pretty > straightforward process and documented in xmlada and gprbuild spec files > though. thanks to Bjorn!) The bootstrap is actually needed only if something is seriously broken, or to add a new arch. GPRbuild is statically linked precisely to remain functional each time GCC or XMLada is upgraded, so that it can rebuild itself and the other Ada packages. Thus the dependency loop isn't normally a problem. A bump and a rebuild per package should be sufficient, but they must be done in the right order. A package can't be built if it requires a library that can't be installed. Therefore those libraries that depend only on Libgnat must be built first, so they become installable again. Once those packages appear in the buildroot, the packages that depend on them can be built. Then those packages in turn must be added to the buildroot before the third tier can be built. (I have now done all that for all packages I have commit access to. I rebuilt GPRbuild too, so it's now statically linked to the new Libgnat. Nobody needs to worry that the static linking will cause old code to linger.) For the mass rebuild to handle this automatically, two changes would be needed: · It would have to walk the dependency graph and build the packages in dependency order instead of alphabetical order. · It would have to make the newly built packages available to packages that depend on them, not set them aside and then tag them all in at the end. So as things stand, these rebuilds need to be done by a human who knows the dependency graph. Björn Persson pgp90fUD1Km8D.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()
Jakub Jelinek wrote: > On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote: > > Hello. GCC was updated to 13 in rawhide while the Fedora change was still > > being voted about by FESCo. > > > > Apparently, the following packages now don't install: > > There is a mass rebuild tomorrow. The Ada soname changes every year > and we've never rebuilt Ada packages separately for that, just during the > mass rebuild. Pavel and I have always rebuilt the Ada packages separately for the yearly soname change. They must be rebuilt in dependency order, and that's not how the mass rebuild does it. I'd be willing to cooperate to do the rebuild in a side tag, but I can't promise to always be available at a moment's notice. Björn Persson pgpUnwuNn9UUD.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Robert Marcano via devel wrote: > The admin can implement CUPS > authentication but an ipp://localhost:6 open port entirely open to > anyone on the local machine to submit print jobs directly bypassing CUPS. In that case it's also accessible to all the untrusted Javascript junk that regularly runs in the user's browser. Because IPP is built on HTTP, a Javascript program can tell the browser to send an IPP request. What has been done to secure those "virtual printer devices" against DNS rebinding attacks? https://en.wikipedia.org/wiki/DNS_rebinding Considering the attitude to security I've seen from CUPS before, I won't be surprised if they just assume that someone else will protect them from DNS rebinding attacks. Björn Persson pgpUOI2iQT6TU.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Fabio Valentini wrote: > Even if systemd prints nice diagnostic messages, they're useless if > nobody is going to see them. > And I doubt that many people know that pressing the Esc key makes > plymouth go away. Quite. Troubleshooting information as an Easter egg! Seriously people, is there some competition to produce the most textless user interface? Björn Persson pgpAmFa7dbrFg.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Lennart Poettering wrote: > dracut uses fixed offsets for the sections to be placed in memory > in. The values are simply hardcoded, literally specified address > offsets, that worked for the original authors. This typically works – > as long as your sections are not much larger than they were for the > people wo came up with these offsets initially. But as it turns out > this doesn't work for some cases. In such cases the sections will be > loaded into memory overlapped and bad things happen. Oh yuck! And the manpage is written as if dracut --uefi is expected to work reliably. I see no big eye-catching warning that such-and-such must be smaller than x bytes. Björn Persson pgpHBtrq05hJe.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
Vít Ondruch wrote: > Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): > > When the connection fails, the Xserver returns a reason in plain text. > > In that case, the reason for the connection being rejected would be > > „Swapped clients prohibited“. > > Appreciate that there is at least some explanation, but if I saw this > error, I would not be much smarter what is going on and how should I > proceed Yes, that's a really bad error message. My reaction would be "What nonsense is that? I haven't swapped any clients." If it had at least said "byte-swapped" it would probably have gotten me searching in the right direction, but if the X server wants to be helpful it should say "big/little-endian mismatch; the option AllowSwappedClients is off". Björn Persson pgptXffOuQJrN.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Gerd Hoffmann wrote: > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote: > > And if you chose your HW carefully you may even be able to register > > your own public keys, generate and sign your own built UKIs and re- > > enable SecureBoot after that... your choice! > > And when your hardware doesn't allow that you can still add your own > keys with mokutil so shim.efi will accept your self-signed UKIs. I'll see when I can take the time for a research project to figure out how customized UKIs can be produced, and develop a tool to do that. Probably never, because I have way too much to do already. Apparently there is no such tool and no plan to provide one, because surely that would have been mentioned under "User Experience". Björn Persson pgpMf3pOAD4my.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Gerd Hoffmann wrote: > On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote: > > > Switching the whole distro over to unified kernels quickly is not > > > realistic though. Too many features are depending on the current > > > workflow with a host-specific initrd (and host-specific kernel command > > > line), which is fundamentally incompatible with unified kernels where > > > everybody will have the same initrd and command line. Thats why there > > > is 'Phase 1' in title, so we can have more Phases in future releases > > > > > > > Whew! So usable kernels won't go away in F38. I only have to worry > > about being forced to build my own kernels in some unspecified future > > phase. Doom is still coming but no one knows when. That's *such* a > > relief. > > Note the proposal talks about adding support for ukis, not about > removing support for current separate kernel+initrd setup. That's not how I read "switching the whole distro over". Switching over means to remove the old thing and use only the new thing. I see you have changed that in the wiki. The change proposal looks less scary now. Björn Persson pgpGBZkeyfaau.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> Main motivation for this move is to make the distro more robust and more > secure. Improving security would be great, but it must be done in a way that allows the sysadmin to configure and repair the system and authorize the new configuration. > Switching the whole distro over to unified kernels quickly is not > realistic though. Too many features are depending on the current > workflow with a host-specific initrd (and host-specific kernel command > line), which is fundamentally incompatible with unified kernels where > everybody will have the same initrd and command line. Thats why there > is 'Phase 1' in title, so we can have more Phases in future releases > Whew! So usable kernels won't go away in F38. I only have to worry about being forced to build my own kernels in some unspecified future phase. Doom is still coming but no one knows when. That's *such* a relief. > A host-specific initrd / command line is needed today for: [...] > * configuration being specified on the kernel command line. > ** root filesystem being the most important one. > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > allow to remove this. Why link to a page that only contains a link to another page? Why not link directly to https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ That page makes it clear that omitting root= from the kernel command line is only an *option* which is proposed only "for simpler, appliance-like installations". My workstation and my laptop aren't appliance-like in the slightest. And on appliances you want a stable, reliable operating system, not a fast-moving, unstable one like Fedora. ** Troubleshooting being the second most important one. When the system won't boot, it's necessary to remove "quiet" and "rhgb" from the kernel command line to see how far the boot process gets and what error messages are printed. It may also be necessary to configure a serial console for example. The root filesystem is also relevant for troubleshooting, when I take a storage device out of a broken computer and connect it to another computer to inspect it. Suddenly there are two "discoverable" root partitions, and the kernel parameter is necessary to specify which one is the root filesystem, as stated under "Doesn’t this break multi-boot scenarios?": https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#doesnt-this-break-multi-boot-scenarios > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > F38). > > * Move away from using the kernel command line for configuration. I note that taking away the kernel command line is indeed a clearly stated goal, which will limit Fedora to simple, appliance-like uses. If any of what I wrote above misrepresents the change owner's intentions, then the change proposal is badly written and needs reworking to communicate the true intentions. Björn Persson pgpivDr3FEwyq.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Question about git signed tags
Vitaly Zaitsev via devel wrote: > On 29/11/2022 17:33, Todd Zullinger wrote: > > One of reasons being that it's (at least slightly) easier to > > notice a change to the public key / keyring when it's in > > dist-git versus the lookaside cache > > It depends on public key format. Armored (ASCII format) vs. binary keys. > > Storing binaries in Git is a bad idea. Why is that? Does 8-bit data break Git somehow? A key is a small file. It doesn't bloat the repository like a tarball would. When a key needs replacing, the new key is entirely different whether it's ASCII-armored or not, so there's nothing to gain by storing a diff instead of the whole file. ASCII-armor is for sending messages over old 7-bit protocols, just like Base64 and UUencoding. In 8-bit-clean channels ASCII-armor doesn't accomplish anything other than making the message slightly larger. I can't believe that Git wouldn't be 8-bit-clean. Björn Persson pgpo03OQ_8sm5.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Question about git signed tags
Bob Hepple wrote: > If we _do_ support "signed git tags" how do we code for it in the spec > file? As the builders lack Internet access, they can't pull directly from the upstream Git repository. To verify a signed Git tag during the build, it would be necessary to package up the whole Git repository (or enough of it to include the source code, the tag and the signature) and upload that instead of the source tarball. Then I suppose you would unpack the repository in %prep and run some Git command to verify the signature, probably "git verify-tag" which is described as "check the GPG signature of tags". gpgverify uses the command gpgv instead of gpg. It's a simplified verification method that fits this usecase better. If Git calls gpg and expects to find a keyring in the user's home directory, then you'd have to write the spec to prepare a suitable keyring, ensure that GnuPG will find that and no other keyring, and tell it to trust the correct key. It's far from trivial to get that right and secure. I'm not aware of any tooling for this other than gpgverify, so I suppose the answer is that Fedora does not support signed Git tags. It should also be noted that with gpgverify we verify the signature before we unpack the tarball. If a malicious tarball tries to attack some vulnerability in Tar or Gzip, then either the verification will fail and stop the build before the attack gets a chance to work, or else the tarball was already malicious when the upstream developer signed it. With Git I don't know how we could avoid unpacking the repository archive before we verify the signed tag. As to why the builders lack Internet access, I wasn't around when that was decided but it helps ensure that the source RPM packages actually contain the source code. Björn Persson pgpu7sPig6eMZ.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Some help with creating a group in a scriptlet please?
A package I'm reviewing needs to create a group, so it has a sysusers file. There's a problem getting sysusers_create_compat to work. https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ shows how to use it with a sysusers file as a separate numbered source. In this package the sysusers file is included in the upstream tarball, which seems appropriate if other distributions also use sysusers files. Somebody who knows syusers and scriptlets, please have a look at the review and comment on point 28: https://bugzilla.redhat.com/show_bug.cgi?id=2126785 Is there a way to use sysusers_create_compat with a file from the tarball, or is it necessary to have the sysusers file as a source separate from the tarball? The subpackage that needs the group during installation depends on the one that contains the sysusers file, so can sysusers_create_compat be avoided by running systemd-sysusers in a suitable scriptlet between the two packages? Björn Persson pgpnWcdiZTdIt.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ridiculous new Red Hat Bugzilla password security requirements
Kevin Kofler via devel wrote: > I have generated a new 20-character random password with "pwgen -s 20 1", See how easy that was. And your using random passcodes tells me that you keep them in a password manager, which means that you don't need to type the passcode, so you have no need to limit its length. Can't you find some actual problem to be angry over? Björn Persson pgpxgPVGDFVi5.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
Kevin Kofler via devel wrote: > Considering that we have been shipping these hardware codec interfaces for > years without any legal trouble, I find this absolutely ridiculous. The entire codec patent business is absolutely ridiculous. Such is the reality we must live in. Björn Persson pgpzmooEtzlFN.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Check out the Fedora Packager Dashboard!
Josef Skladanka wrote: > [...] document the UI changes you'd like to see, the different icon > choice you made, and explain why you believe those are more > "universally understood" or better. I would not choose different icons, because I believe it's impossible to draw a universally understood picture of an abstract concept. The closest you can get to universally understood is an English word, English being the most widely understood language in our time. > Thanks for taking the time to sum up your thoughts, we are looking > forward to seeing less "this sucks" and more "here's how I'd fix it, > though"! Quoting myself, here's how I'd fix it: Björn Persson wrote: > Rather than hiding the intelligible words in mouseover boxes, it would > be better to write them directly on the screen instead of the icons. That's clearly not how you like it though. And if you would actually accept such a change, then I'm sure you could make the change in like 1% of the time it would take me to get familiar with your code, set up a test environment, and make a pull request. As I also wrote: > It would be nice to have consistent terminology That means I would choose either "options" or "settings" and use that word consistently. Björn Persson pgpONmwdKHODG.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Check out the Fedora Packager Dashboard!
Zbigniew Jędrzejewski-Szmek wrote: > I think it > is important to remember that the page is _supposed_ to be "dense". > It is intended to pack a lot of information into a small area It leaves plenty of empty space on my screen. It seems to prioritize aesthetics over information density. Björn Persson pgppvLZZS0iXx.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Check out the Fedora Packager Dashboard!
Fabio Valentini wrote: > On Thu, Aug 25, 2022 at 11:43 AM Artur Frenszek-Iwicki > wrote: > > I'll forget the meaning and the numbers will go back to being visual > > clutter. It would be immensely helpful > > to have some symbolic icons next to the numbers, which would allow to > > easily guess what each of them means. > > Sounds like you need to clear your browser cache or something, because > there *are* symbols next to these numbers: > https://decathorpe.fedorapeople.org/packager-dashboard.png I too can see the icons when I allow fontawesome.com, but few of them help with understanding the numbers. The beetle for "bugs" and the speech bubble for "comments" are pretty obvious, but I still have to point to all the others to find out what they mean, and even then many of them seem completely random. How does a lightning bolt symbolize updates? What's the connection between a shield and priority? A triangle, a circle and a square combine into "overrides"? There are two different line chart icons. How does one remember which is which? And a seatbelt apparently means "orphans" somehow. I assume that "PRs" stands for "pull requests". The icon for that is the word "git". That's better than a random unrelated picture, but if a picture is just text, then it should be actual text and not a picture. It's also somewhat inaccurate because pull requests aren't a Git thing but a concept that some web interfaces layer on top of Git. Rather than hiding the intelligible words in mouseover boxes, it would be better to write them directly on the screen instead of the icons. If there is some idea that the icons should be language-independent, then the beetle also fails. Software defects are not called insects in all languages. > > Similarly, at the top of the page, I get a banner that informs me about FAS > > integration and says: > > > After linking the dashboard with your FAS through the settings menu... > > Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" > > gives exactly one match - > > that being the text in the banner. So there's no visible link to said > > "settings menu" anywhere. > > How do I access it? > > The big "gear" icon (the almost universal symbol for "Settings") in > the top panel should be what you're looking for. The gear is called "Options", and beside it is an icon called "Customize dashboard". "Settings" could refer to either of those. It would be nice to have consistent terminology, but hey, we can always click on everything and explore. The gear icon is also misleading. It alludes to machinery in motion, so it suggests a menu of commands to do things, rather than options or settings. There is a wrench icon that would be a good symbol for settings, but that apparently means Koschei. Björn Persson pgpmWCLh0Inux.pgp Description: OpenPGP digital signatur ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Important changes to software license information in Fedora packages (SPDX and more!)
Matthew Miller wrote: > All documentation related to Fedora licensing has moved to a new > section in Fedora Docs, which you can find at: > > https://docs.fedoraproject.org/en-US/legal/ Several links to other sections are broken. All five links under "Licensing in Fedora" should point to other pages instead of non-existent sections of the same page. Several links on https://docs.fedoraproject.org/en-US/legal/license-field/ contain two fragment identifiers. There can only be one. I haven't searched the other pages for similar errors. > Many software packages consist of code with different free and open > source licenses. Previous practice often involved “simplification” of > the package license field when the packager believed that one license > subsumed the other — for example, using just “GPL” when the source code > includes parts licensed under a BSD-style license as well. Going > forward, packagers and reviewers should not make this kind of analysis, > and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach > is easier for packagers to apply in a consistent way. Does that also apply to licenses that explicitly say how they may be combined? Are we supposed to write "GPL-3.0-or-later AND GPL-2.0-or-later AND LGPL-3.0-or-later AND GPL-3.0-only" or do those still combine into GPL-3.0-only? Björn Persson pgpfYcfegWXWG.pgp Description: OpenPGP digital signatur ___ 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: Change proposal: make Change proposals more obvious
Ben Cotton wrote: > On Thu, Apr 28, 2022 at 9:01 AM Neal Gompa wrote: > > We could also start the email subject with "CHANGE PROPOSAL" instead of > > "Change" > > I'm pretty sure I used to, but people were upset about how much space > it took in the subject so that you couldn't see what the actual > proposal was. And the word proposal *is* already in each subject line > (just at the end). Maybe spend two more letters and write "Proposal" instead of "Change"? "F37 Proposal: Frob the job knob (System-Wide Change proposal)" Once you write "proposal", the word "change" becomes rather redundant. What proposal doesn't propose any kind of change? If somebody doesn't want to change anything, they won't write a proposal. Björn Persson pgp8oCG3kFb03.pgp Description: OpenPGP digital signatur ___ 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: verifying signature for a package
Ben Beasley wrote: > It doesn’t really matter what the file is called. Personally, I would rename > it to oclock.gpg and add a brief spec file comment explaining where it came > from. I agree. It's important to document where the key came from, and the filename by itself would just be confusing. Björn Persson pgpTL5tFH4atr.pgp Description: OpenPGP digital signatur ___ 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: verifying signature for a package
Ben Beasley wrote: > Please see > https://src.fedoraproject.org/rpms/xfontsel/blob/a38f5a42fa7bc59378527cf05dabe29523675613/f/xfontsel.spec#_10 > for an example from the same group of X11 programs. What's described there is known as TOFU – trust on first use. Ben looked up which key made the signature, downloaded that key and added it to the Git repository. Initially this adds no security, as all that can be verified is that the tarball was signed by whoever signed it. The value of TOFU comes when the same key is used to verify another tarball. As long as the key in the Git repository remains unchanged, the signature verification can prove that each new release of Xfontsel is signed by the same person who signed the earlier releases. In this case I see that Oclock and Xfontsel are signed with the same key. That seems quite legitimate as both tarballs are from www.x.org. Instead of doing another, separate TOFU, you should copy Ben's xfontsel.gpg from the xfontsel Git repository. That way your initial Oclock package is not a first use of the key, but a second use, and when you invoke gpgverify it will prove that the Oclock tarball was signed by the same person who signed the Xfontsel tarball. Once you have the key, remember to pass all three parameters to gpgverify: --keyring, --signature and --data. Björn Persson pgpcFSmHuVaks.pgp Description: OpenPGP digital signatur ___ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > "In the bios, upgraded to 810 the option to enable legacy boot is greyed > out" > > So how do people propose the situation to be handled when firmware from > vendors, disables the legacy boot option via firmware update. I haven't seen anyone arguing that Fedora should drop UEFI support and enforce BIOS-booting even on brand new hardware, so I don't even understand what you're arguing against here. Obviously buyers of new computers whose bioses support only UEFI will have to use UEFI – and hope that those UEFI implementations are capable of booting Fedora. In case you meant to argue that bios updates will remove the need for Fedora to support BIOS-booting, this example does not support that position. The computer in question is at most a few months old. Twelve- year-old computers that never had UEFI support get no more bios updates and will never get UEFI support added. Anyway, it's not clear that the computer was shipped with a working legacy boot option. The forum post doesn't say that. It says only that the legacy boot option is unavailable and that the bios has been updated. By the way, the forum post is an example of a user who is dissatisfied with UEFI for some reason, and wants to boot in BIOS mode instead. Dropping BIOS-boot support from Fedora would presumably not make that person any happier. Björn Persson pgpTOibEFEGtI.pgp Description: OpenPGP digital signatur ___ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
Jóhann B. Guðmundsson wrote: > For example EU has regulation that requires vendors to have spare parts > available for 7–10 years after date of manufacturing so it makes sense > for the project to support hw no longer than a decade from the date of > it's manufacturing. I fail to imagine what use case you might have in mind where that requirement would interact with Fedora. If such regulation would be applied to Fedora, the closest equivalent would be that the Fedora Project would be required to provide bug fixes to old releases for seven to ten years, so Fedora would essentially have to be RHEL. If I had the kind of strictly specified system where any broken part must be replaced with an identical part, then I would definitely not run the constantly changing Fedora on it. Such a system would rather run RHEL, or something even more stable than RHEL. It makes no sense to take special care to keep the hardware unchanging for ten years, even when repairing it, and then replace the software twice a year with different user interfaces, changed behavior and a new set of bugs in every release. As for the kind of computers that Fedora is suitable for, I'll use them until they break, whether that happens after five or fifteen years, and then I'll replace the broken part or the whole computer with modern hardware that can be expected to last for many more years. If a broken part is less than three years old, then I have a right to get it repaired or replaced. Past the three-year limit I won't make any attempt to buy the exact same model to replace a broken motherboard (where the bios is stored). I'll take the opportunity to upgrade to the latest stuff when I need to buy a new motherboard anyway, so it will remain useful for as long as possible. That doesn't change at any seven- or ten-year limit. I seriously doubt I could find a seven-year-old motherboard on the market anyway. Used perhaps, but not from the vendor. If a computer doesn't break, I may eventually have to replace it when the processor can no longer keep up with the software's demands, but that takes much longer than ten years nowadays. Björn Persson pgpZ7ENGcIhpJ.pgp Description: OpenPGP digital signatur ___ 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: GNOME Online Accounts "Fedora" - Pre-authentication failed
Vitaly Zaitsev via devel wrote: > If Fedora's kinit will start asking for an OTP code in a separate field, > it would technically be possible to store the password in Gnome Keyring > and just ask for an OTP code once a week. It should ask for an OTP when the user does something that requires authentication, if the previous ticket has expired. Don't ask for authentication just for the sake of renewing a ticket when the user is doing something else. That would teach users dangerous habits. Björn Persson pgpkW8N6aTay3.pgp Description: OpenPGP digital signatur ___ 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: GNOME Online Accounts "Fedora" - Pre-authentication failed
Michael Catanzaro wrote: > On Thu, Apr 7 2022 at 12:30:42 PM -0400, Stephen Gallagher > wrote: > > Well, it *could* grow an interface to some of the password wallet > > services that support TOTP or HOTP codes (like Bitwarden, Lastpass, > > 1password, etc.) and configure it to query that service and append the > > code to the password. It doesn't help if you want/need a physical > > token, though. > > Good idea. Of course we'd probably want to use GNOME Keyring for this > (which does not currently support third-party services, but could in > the future). I suppose gnome-online-accounts would only need to store > the TOTP/HOTP seed and some config data. This sounds like you would store the password and the TOTP seed together in the same keyring. That's rather pointless. If you store two secrets together, then they are effectively a single secret, and the TOTP just adds an unnecessary step to the authentication protocol. It's better to generate a long random key for your "password", store that in your keyring, and not bother with TOTP. Two-factor authentication is when you have two secrets stored in two different storage media, for example one in Gnome Keyring and the other in a Yubikey. If the keyring is encrypted with a master passphrase, then that's also two-factor authentication. The encrypted key stored in the keyring is one factor, and the master passphrase stored in the user's brain is the other factor. In that case a TOTP seed stored in a Yubikey becomes a third factor. Björn Persson pgpBJJfbjJHPN.pgp Description: OpenPGP digital signatur ___ 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: Deprecate Legacy BIOS (System-Wide Change proposal)
JT wrote: > I realize some will have the attitude of "they can just not upgrade and > keep using their old Fedora versions". That's obviously not a solution for any Internet-connected computer. Even if you communicate only by moving files on USB sticks or diskettes, it's still dangerous to let known security holes accumulate. Björn Persson pgpzXxjDRbutY.pgp Description: OpenPGP digital signatur ___ 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: Deprecate Legacy BIOS (System-Wide Change proposal)
laolux laolux via devel wrote: > I am willing to throw away my still working notebook, producing a little bit > electronic waste when the time comes. I'm not. It remains to be seen how long Fedora will continue to work on my ten-year-old laptop, but when the time comes I will not trash it and buy a new one. Unless the hardware breaks first, I'll install some other distribution when the laptop is no longer welcome in Fedora. I'll probably go with Debian, which is usually good with not quite brand new hardware. This may reduce my ability and motivation to contribute to Fedora. I use this laptop to develop and test performance measurement tools. It handles build jobs, testsuites and virtual machines just fine. The days when a three-year-old computer was too slow to be useful are long gone. Björn Persson pgp52J6uYF2PH.pgp Description: OpenPGP digital signatur ___ 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: Landing a larger-than-release change (distrusting SHA-1 signatures)
Robert Relyea wrote: > 2) in fedora 38, SHA-1 gets turned of in the default policy and ships > that way. Isn't that the default already? I use the default crypto policy, and I had a case last year where Seamonkey and Firefox refused to talk to a certain web server, which I worked around by temporarily adding "SHA1" to /etc/crypto-policies/back-ends/nss.config. Björn Persson pgpQmPo25Lqfu.pgp Description: OpenPGP digital signatur ___ 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: Curl-minimal as default (System-Wide Change proposal)
Kamil Dudka wrote: > There seems to be demand for libcurl with IDN support on minimal Fedora > installations, so I created a pull request to enable it in libcurl-minimal: > > https://src.fedoraproject.org/rpms/curl/pull-request/13 Thank you. Björn Persson pgp2ZEu96gtIM.pgp Description: OpenPGP digital signatur ___ 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: Curl-minimal as default (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek wrote: > Apart from Dmitry, I don't think there were any opinions from folks > who would be directly impacted. I don't know which programs use Curl so I can't tell whether I'd be impacted. I understand that Yum uses it. Lack of IDNA in Yum would impact me if I had a private mirror, but I don't. For downloading files from a command line, my habit is to use Wget, so I guess I'm dodging that bullet. Björn Persson pgpBhrzmDJc5Y.pgp Description: OpenPGP digital signatur ___ 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: Curl-minimal as default (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek wrote: > According to ICANN [1], there were 8.3 mln IDN domains worldwide. And that's presumably only second-level domains. Nobody knows how many non-ASCII subdomains exist under ASCII second-level domains, since domain holders define subdomains at will without telling anybody. There are currently 153 non-ASCII top-level domains out of 1486 total, which is 10.3%: https://data.iana.org/TLD/tlds-alpha-by-domain.txt > Apparently .рф is fairly popular, with 1/5th of .ru registrations [3]. And that was eight years ago, only four years after рф was opened for registrations. > But from what I have seen, all those internationalized domains serve > as a redirect or backup to sites also available as ascii. In 2013 11% of рф domains redirected to ASCII domains, 50% were in use and not redirecting, and 39% were only registered but unused. Already in 2011, the year after the floodgates were opened, 34% were in use and not redirecting. This is according to page 116 of this report: https://web.archive.org/web/20141210151244/http://www.eurid.eu/files/publ/IDNWorldReport2014_Interactive.pdf But yes, it's still often necessary to resort to ASCII, either the ACE form (xn--gobbledygook) or a separate ASCII-only fallback domain. Email in particular remains a major drag. Only in 2012 was there enough consensus to publish a proposed standard for SMTPUTF8. Extensions to IMAP and POP followed in 2013. Support in various email-handling programs is still lacking. As long as people feel that they must have an ASCII domain for email, some will naturally choose to use that same domain for their website rather than using two separate domains. > And for command-line > tools or scripting, using those ascii versions seems quite likely… That's another area where support for IDNA is spotty, yes. OpenSSH still lacks support for example. So does Nmap. The Bind utils have incomplete and inconsistent support. "dig", "host" and "nslookup" can look up non-ASCII domain names, but if a server to query is specified, then they expect the server to have an ASCII-only name. "delv" lacks support entirely. This is the problem that you're about to make worse. People will find that support for IDNA is unreliable in various programs that use Curl under the hood. To work around the problem they'll resort to the ACE form, or to an ASCII-only domain they have for precisely that purpose. Thus you end up hampering the adoption of international domains even more. > So I'd definitely vote to enable libidn2 in curl-minimal, > _if_ there are people who'd actually use this for real. People can't use it until it's consistently supported, and you won't support it until people use it. Do you mean to wait for all the other command line programs to support IDNA first, and then, when the whole world is waiting for you, then you'll turn it on in Curl and people will start using it? Guess what – everybody else is also waiting for everybody else. This is the same deadlock that hampers IPv6, encrypted email and many other things. Everybody's waiting for everybody else to move first. Björn Persson pgp90R61gv1GJ.pgp Description: OpenPGP digital signatur ___ 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: Curl-minimal as default (System-Wide Change proposal)
> `curl-minimal`+`libcurl-minimal` are compiled with various > semi-obsolete protocols and infrequently-used features disabled: > DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP, > SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names. Disabling IDNA makes libcurl-minimal suited only for programs that only communicate with a predefined set of servers in ASCII-only domains. Any program that accepts user-provided URLs will need curl-full to be able to handle arbitrary domain names, even if the program speaks only HTTPS, HTTP and FTP. Björn Persson pgp4a7tFpzQPo.pgp Description: OpenPGP digital signatur ___ 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
2FA (was: Preventing account takeovers through expired domains)
Adam Williamson wrote: > However, it supports Google Authenticator-style OTPs. Folks > with infra privileges on their accounts (like me) are already required > to use these. It works fine. I preferred being able to use a yubikey so > I don't always have to open an app on my phone and retype a six digit > code when I need to log in to something, but that's just a minor > annoyance. You can produce compatible OTPs with a yubikey if you want. Install yubioath-desktop. You open an app on your workstation/laptop instead of on the phone, and paste from the clipboard instead of retyping. (Still not as good as U2F of course.) Björn Persson pgpxs9kMwtLFb.pgp Description: OpenPGP digital signatur ___ 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
2FA (was: Preventing account takeovers through expired domains)
Demi Marie Obenour wrote: > Security keys are the only form of 2fa that is immune to > phishing attacks. U2F and FIDO2 are said to be immune to phishing. HOTP, TOTP and various proprietary challenge-respone protocols are not immune. Björn Persson pgp_7IhtLa4JI.pgp Description: OpenPGP digital signatur ___ 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: Preventing account takeovers through expired domains
Mattia Verga via devel wrote: > Il 19/02/22 19:38, Björn Persson ha scritto: > > Zbigniew Jędrzejewski-Szmek wrote: > >> I think it'd be better to check the status weekly and only require > >> account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ > >> times in a row (where N=quarantine length in days). > > It will be fine as long as it's done before the domain is released for > > registration. Let's just not make it so tight that a little unscheduled > > downtime can open an attack window. > > > But this covers just the case where a domain is expired and free to take. Correct. I'm not saying it would be a panacea. > I agree this would be the easiest attack vector, but what about if it's > the user email only to expire and free to take? There are (at least, I'm > sure there were) some free email services that expire email addresses > not used for a year or so. Also, in a previous comment in this thread, > someone pointed out that also email addresses from universities or other > institutions can be "recycled". These are harder attack cases, but > they're possible. Do these services and institutions publish lists of expired email addresses and dates when they will be recycled? In that case they could be handled the same way as expired domains. > That's why I proposed a check against user activity rather than a check > against domain or email reachability. Doing one does not prevent doing the other. Disabling inactive user accounts makes sense because abandoned accounts are more likely targets for takeover. It can be expected to reduce the risk somewhat, but it's not a reliable way to prevent takeovers entirely. Zbigniew said that some registries use quarantine times as short as 14 days. You can't disable packagers just because they take a two-week vacation. Monitoring for expired domains is a reliable way to eliminate one attack vector, but not other attack vectors. Other countermeasures against other attack vectors are also needed. Existence of other attack vectors is not a valid argument against eliminating one attack vector. Björn Persson pgpN620LIbtFj.pgp Description: OpenPGP digital signatur ___ 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: Preventing account takeovers through expired domains
Zbigniew Jędrzejewski-Szmek wrote: > I think it'd be better to check the status weekly and only require > account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ > times in a row (where N=quarantine length in days). It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window. Björn Persson pgpqiv4u1U4Nr.pgp Description: OpenPGP digital signatur ___ 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
Preventing account takeovers through expired domains (was: Do we have any policy for disabling inactive users)
Vitaly Zaitsev via devel wrote: > We're talking about potentially hacked accounts, right? In this subthread I'm talking about *preventing* account takeovers so that they don't happen in the first place. One specific method of takeover that the Fedora Project would be able to prevent. I thought the quote I posted was perfectly clear. Evidently it wasn't. Allow me to explain the scenario step by step: Step 1: J. Doe joins the Fedora Project using a working email address, j@example.net. J. Doe gets sponsored and makes some packages. All is well so far. Step 2: Much later, the holder of example.net stops paying the renewal fee. The registry removes the domain from DNS. j@example.net ceases to exist. J. Doe forgets to update the address in their Fedora account. This has happened to 2818 NPM accounts according to the article I quoted. It can happen to Fedora accounts too. Possible step 3: A program on a Fedora Project server notes that example.net has been deactivated. The program removes the address j@example.net from J. Doe's account, or disables sending to the nonexistent address. Question: Does step 3 happen? I suspect that this program doesn't exist. I haven't seen any mentions of it. Step 4: The quarantine period ends. The registry releases example.net for registration. Step 5: Malicious Mallory registers example.net, sets up a mail server and configures the alias "j.doe". Suddenly j@example.net exists again, but now this address quite legitimately belongs to Mallory. Step 6: Mallory enters J. Doe's username into https://accounts.fedoraproject.org/forgot-password/ask and clicks on "Send". Branch 6A: If step 3 was not done, then a passphrase reset email is sent to j@example.net and is received by Mallory. Mallory takes over J. Doe's account and replaces any SSH and OpenPGP keys with his own. Malicious Mallory is now a Fedora packager in the name of J. Doe, and is empowered to insert malware into J. Doe's packages. Branch 6B: If step 3 was done, then no passphrase reset email is sent. Mallory's attack fails. Step 7: J. Doe tries to log in. Branch 7A: If step 3 was not done, then none of J. Doe's credentials work anymore. Mallory has control of the account and J. Doe is locked out. Branch 7B: If step 3 was done, then the account still belongs to J. Doe. The account system tells J. Doe to enter a new email address. The system sends a verification code to this new address. This is not a passphrase reset. It's an email address verification code, which J. Doe must paste into the web interface while logged in, to prove that the address belongs to the right person. After the new address is verified, J. Doe's account works normally again. Note that Mallory must do step 5 before step 6 for the attack to work, and the registry won't allow step 5 to happen before step 4. Therefore doing step 3 before step 4 ensures that step 6 cannot happen before step 3. That way the Fedora Project could reliably prevent this kind of attack. I hope this explanation is clear enough to be understood. In case of TL;DR, the short version is four posts upthread from here. So, does step 3 exist? Björn Persson pgpPIYU3U_oGq.pgp Description: OpenPGP digital signatur ___ 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: Do we have any policy for disabling inactive users
Vitaly Zaitsev via devel wrote: > On 15/02/2022 19:43, Björn Persson wrote: > > The packager would then be required to authenticate with their existing > > credentials – or prove their identity in some way that does not rely on > > ownership of the email address – and set a new email address in their > > account. > > How? I know only one suitable option - an email signed with a previously > added GPG key, but most users don't have it in their FAS accounts. Loss of an email address does not imply loss of a FAS passphrase, so in most cases they would just log in as usual. If they have lost both their passphrase and their email address, then yes, an OpenPGP key is one possible method. Theoretically an SSH key could also be used. I don't think there currently is an interface for managing a FAS account over SSH, but an ad-hoc manual method could be devised. Björn Persson pgpUzfufXTe4A.pgp Description: OpenPGP digital signatur ___ 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: Do we have any policy for disabling inactive users
Mattia Verga via devel wrote: > I also imagine the case where a user no more use their email address and > that become available to someone else. The new user may easily reset the > password and gain access to the old Fedora account (provided that the > old user didn't use 2fa). Here's an article about similar concerns regarding NPM: https://therecord.media/thousands-of-npm-accounts-use-email-addresses-with-expired-domains/ An excerpt: | Researchers said they found that 2,818 project maintainers were still | using an email address for their accounts that had an expired domain, | some of which they found on sale on sites like GoDaddy. | | The team argued that attackers could buy these domains, re-register | the maintainer’s address on their own email servers, and then reset | the maintainer’s account password and take over his npm packages. This seems like a risk for Fedora too, unless there are routines in place to prevent it. This particular method of account takeover could be reliably prevented, considering that expiry dates are public and domains are quarantined before they are released for registration by someone else. A program could monitor domains that are due for renewal. If a domain expires, then account recovery by email should be disabled for addresses in that domain. The packager would then be required to authenticate with their existing credentials – or prove their identity in some way that does not rely on ownership of the email address – and set a new email address in their account. Entering the old email address again would be allowed, in case they have recovered the domain, but they would have to prove that they can receive a confirmation message regardless of whether the new address is the same as the old address. Björn Persson pgpyrRQqN3QuW.pgp Description: OpenPGP digital signatur ___ 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: Do we have any policy for disabling inactive users
Ben Cotton wrote: > I would support removing the 113 who don't exist in Koji. If they have been that way for a long time, I suppose. Don't cause additional hurdles for newcomers just because their first review takes a while. Björn Persson pgp11SGC3hJR2.pgp Description: OpenPGP digital signatur ___ 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: Do we have any policy for disabling inactive users
Gary Buhrmaster wrote: > A quick (and likely > bad and incomplete) bugzilla search shows > over 1000 tickets where there are upstream > updates that are still in NEW status in > bugzilla and had been (initially) opened > over a year ago. I think that represents > around 350 unique people. Those people > may be otherwise active, of course, but > those packages themselves look to be > under maintained. Yes, that's a bad search. Till Maas told me eight years ago that the release monitoring tickets are supposed to remain open when the packages are upgraded. Thus an open Bugzilla ticket is no indication that the package is unmaintained. You need to check what version is actually in Rawhide. If the Bugzilla tickets should in fact not be left open, then they should be automatically closed just like they're automatically opened. Björn Persson pgpBscepj_kiv.pgp Description: OpenPGP digital signatur ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
Jakub Jelinek wrote: > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. Certain Ada source files trigger what looks like infinite tail recursion in add_sibling_attributes in dwarf2out.c: https://bugzilla.redhat.com/show_bug.cgi?id=2041667 Björn Persson pgpaayNBpxRq6.pgp Description: OpenPGP digital signatur ___ 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: New tool - license-validate
Miroslav Suchý wrote: > $ license-validate-v'GPL or (MIT and BSD)' > No terminal defined for 'G' at line 1 col 1 Approximately nobody will understand "No terminal defined for 'G'". Can the error message be improved? Björn Persson pgp5AIXhmHYUH.pgp Description: OpenPGP digital signatur ___ 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: new systemd in rawhide
Zbigniew Jędrzejewski-Szmek wrote: > This means that various libraries that were > previously always pulled in, are not listed as Recommends by the various > subpackages: [...] > Recommends are normally installed, but if you're using 'dnf --setopt > install_weak_deps=False' > or similar, please make sure that you install those libraries too if > appropriate. Was "not" supposed to be "now"? Otherwise these statements don't make sense together. Björn Persson pgpz2V_ix2CZt.pgp Description: OpenPGP digital signatur ___ 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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Michel Alexandre Salim wrote: > - do we want to allow any /local/ %wheel users to log in? This seems fine to me. > - or do we want to use a recovery passphrase of some sort? I'm not sure what you mean here. When a passphrase is called a recovery passphrase, it's usually because authentication is normally done some other way. For example, if you normally log in by inserting some kind of hardware token, then you may want a recovery passphrase to use in case the hardware token is broken or lost. As long as users normally log in with a passphrase, I see no need to have a separate passphrase for rescue mode. Root's or a wheel user's usual passphrase should be fine. > For F36 - I agree that it's better to *not* have a rescue mode than a > broken one. How about this as an end state we can realistically achieve: > - if the root password is set, rescue mode should appear in the GRUB > menu > - if the root password is not set > - rescue mode should not be listed > - if someone tries to invoke it, it should display an error rather > than prompting for a non-existent password This looks sane. If there is a separate boot entry for the rescue mode, then maybe Grub could be programmed to require a passphrase before it will boot that entry? Björn Persson pgp1LnefA7iK9.pgp Description: OpenPGP digital signatur ___ 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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
> A more user-friendly setup is to allow the password to be bypassed in > case it's not set. > > This does not pose an increased security risk: > - you can already boot with `init=/sysroot/bin/bash` anyway > - anyone with physical access to a machine can probably compromise it > - you can enforce the need for a root password in single-user mode by setting > it To disallow root login in normal operation, and then turn around when a problem occurs and open a root shell without any login at all, is inconsistent and will lead users to believe that their computer is more secure than it actually is. If Fedora is going to allow unauthenticated root access when there is a boot problem, then for consistency the same should be true in normal operation. Both root and other users should by default just be allowed in without any authentication – not over SSH or any kind of network access, but on local text consoles and GUI desktops. Anaconda's Root Account page should be changed to make the root account enabled and passphraseless by default, and on the User Creation page the checkbox "Require a password to use this account" should be unchecked by default. Anyone with physical access to a machine can probably compromise it, so it's pointless to ask for passphrases on the console, right? *That* would be a change that users would be aware of, unlike the one proposed in the Change proposal – and if users want to enforce the need for a passphrase, then they can set one, on user accounts as well as on the root account. When a root passphrase has been set, then that passphrase should be required in all situations – normal operation, rescue mode, single-user mode or whatever – and for consistency the same passphrase should be required in Grub before the boot parameters can be changed. A user who wants to enforce the need for a passphrase should be able to do that in one place, not three. Conversely, if it's considered correct that Anaconda forbids an open passphraseless root account and promotes setting a passphrase on the user account, then that policy should be applied consistently, even in rescue mode. This makes a root passphrase necessary so that rescue mode can work. Some day it may become possible to use a wheel user's passphrase in rescue mode. Then, and not before, can the root account be locked. In this case, Grub should also by default require root's or a wheel user's passphrase before boot parameters can be changed. That is consistent. Björn Persson pgpcT9reGtFmi.pgp Description: OpenPGP digital signatur ___ 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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Chris Adams wrote: > Once upon a time, Björn Persson said: > > Chris Adams wrote: > > > If the admin has done one thing to lock down the system, then they can > > > do another (removing the sulogin --force addition). > > > > How do you propose to ensure that the admin is made aware of the need > > to do that? > > The same way as any change - documentation. Introducing a new security hole is not just a change like any other change. Sysadmins read documentation to find solutions when they know that they have a problem to solve. They rarely read documentation to look for problems they don't know about, and they don't regularly re-read every document to look for potentially insecure changes. > > Experienced sysadmins won't just instinctively know that in this new > > release of this particular distribution they need to run this special > > command to prevent boot problems from granting root access to whoever > > can type on the keyboard. > > It's not a "special command", it's just removing an RPM Po-tay-to, po-tah-to. > I don't install a brand new OS and give it to users without checking it > out myself Does "checking it out" include breaking the system in every way you can think of, to see whether one of them yields a root shell? > (and reading at least the release notes). Do you also read the release notes of all previous releases just in case an obscure weakness was introduced in an old release that you never used, and has been in place since then? > This is NOT some new "hole" - out of the box, Fedora already allows > someone with console access to get root access (in less convenient, but > more confusing, ways). What you're actually saying is: There is an old hole that we hope sysadmins are aware of and know how to close if they need to, and therefore it's fine to punch another hole in a hidden place where sysadmins won't think to look. Björn Persson pgpjPAdAJ9zSj.pgp Description: OpenPGP digital signatur ___ 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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Chris Adams wrote: > If the admin has done one thing to lock down the system, then they can > do another (removing the sulogin --force addition). How do you propose to ensure that the admin is made aware of the need to do that? Experienced sysadmins won't just instinctively know that in this new release of this particular distribution they need to run this special command to prevent boot problems from granting root access to whoever can type on the keyboard. Björn Persson pgpUpKi2TnP15.pgp Description: OpenPGP digital signatur ___ 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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
> * at build time, we compute the Merkle tree for the files within a > package, then sign it and ship it as part of the rpm metadata; [...] > Note that the Merkle tree > is ''not'' shipped with the RPM itself (only its signature is) In that case, "ship it" above should be changed to "ship the signature", unless this is some distinction between "the RPM metadata" and "the RPM itself". If I enable FS-verity and later find that I need to patch a file to fix some problem, how do I as the sysadmin tell Linux that this change is authorized? Do I disable FS-verity for that specific file? Disable FS-verity globally? Add my own key to the kernel's keyring? Build and sign my own RPM package? What prevents an attacker from doing the same? Will files under /etc be covered, or will local configuration still be possible? Björn Persson pgpbMIhTbl4rJ.pgp Description: OpenPGP digital signatur ___ 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
