Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, 2024-03-30 at 15:23 +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote: > > Once upon a time, Michael Catanzaro said: > > > I agree that running autoreconf on our packages makes sense to start > > > doing. Still, to avoid this backdoored m4 file, we would have needed > > > to stop using release tarballs altogether and switch to using git > > > tags directly instead. That would at least force the malicious > > > attacker to commit their code to version control, making it slightly > > > harder to hide the attack. > > > > Using a signed tarball is ideally better than a git tag (it's an extra > > level of author attestation)... but where both are available, it'd be > > nice to have a way to denote in the spec file that there are two URLs > > for the source. In this case, if both URLs were listed and something > > could be run to automatically fetch and compare them, the attack code > > would have been flagged. > > Tarball production should be reproducible. Then the maintainer can > both make a signature locally and make it public, and users can download > the auto-generated tarball. > > In fact, github tarball generation is stable. A few years ago they tried > to improve the compression method (i.e. .tar would be still identical, > but .tar.gz would be different), and after a huge outcry this was reverted. > They still haven't officially said that it's stable, but let's hope that > it never changes, at least not without a suitable advance warning. I do not know if this changed in the last couple of years, but tarballs in github are not stable (or weren't up to a couple years ago), they are cached for a period of time, so they may look stable in busy projects where you have regular downloads that keep the cache alive, but they are *regenerated* from the tag for seldom downloaded tarballs. And when that happens then hashes change. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- ___ 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: Orphaning all my packages
On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote: > Am 03.10.23 um 21:29 schrieb Simo Sorce: > > On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote: > > > Am 03.10.23 um 20:46 schrieb Sérgio Basto: > > > > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote: > > > > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce > > > > > wrote: > > > > > > Additionally *all* of the code is fully available in git form on > > > > > > gitlab > > > > > > as part of CentOS Stream. > > > > > > > > > > We all know or should know that this is false. It's easy enough to > > > > > disprove with a counterexample: > > > > > > > > > > https://access.redhat.com/errata/RHSA-2023:1918 > > > > > > > > > > Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in > > > > > CentOS Stream. It isn't there, and never will be. > > > > > > > > > > > > > it is here : > > > > https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9 > > > > > > > > > > > > > Since June 21 the strategy changed. Such commits do not get pushed > > > anymore. But you are right, to prove it a different example is necessary > > > ... > > > > You are wrong and have been mislead. > > Nothing has changed in how we develop and publish code in gitlab. > > > Nope, I do not argue about processes at all. Its about resulting code > fragments. Speak, having in gitlab version 8 of a package and in the > current/latest RHEL release (9.2) version 7 with backports of 8 doesn't > mean that the code is in gitlab. The code differs and its not > accessible. Thats all about. The code is still in gitlab, in most cases in directly accessible in individual commits. In some cases, like the one Michael mentioned, where a rebase landed early in the CentOS branch the code may land together with other changes, but it is not like it is not there. There are is a no regression policy in RHEL, so if CentOS is ahead it means it already has all of the code in question. And if there is an actual reason to need to know what exact change landed in RHEL there are several avenues to find out (just grab a developer subscription for example). I just find that this is generally just a mental exercise, but not something people do or need to do on a regular basis, and does not prevent any use, study, sharing or enjoyment of the code. Claiming the code is inaccessible sounds odd to me. But perhaps I am just old and remember when all you got from upstream was a tarball and you had to figure out what actual changes went in manually with diff ... no commits or commit messages and often not even a reasonable changelog ... Simo. -- Simo Sorce, DE @ RHEL Crypto Team, Red Hat, Inc ___ 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: Orphaning all my packages
On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote: > Am 03.10.23 um 20:46 schrieb Sérgio Basto: > > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote: > > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce > > > wrote: > > > > Additionally *all* of the code is fully available in git form on > > > > gitlab > > > > as part of CentOS Stream. > > > > > > We all know or should know that this is false. It's easy enough to > > > disprove with a counterexample: > > > > > > https://access.redhat.com/errata/RHSA-2023:1918 > > > > > > Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in > > > CentOS Stream. It isn't there, and never will be. > > > > > > > it is here : > > https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9 > > > > > Since June 21 the strategy changed. Such commits do not get pushed > anymore. But you are right, to prove it a different example is necessary ... You are wrong and have been mislead. Nothing has changed in how we develop and publish code in gitlab. Simo. -- Simo Sorce, DE @ RHEL Crypto Team, Red Hat, Inc ___ 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: Orphaning all my packages
On Tue, 2023-10-03 at 11:33 -0400, Todd Zullinger wrote: > Sérgio Basto wrote: > > On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote: > > > a project > > > where the primary sponsor and downstream no longer provides > > > source code freely and openly > > > > what you are talking about ? all RHEL Source are freely available on > > Centos Stream , and RHEL never was free . > > That's not the case, but I don't wish to go wildly off-topic > about it either. > > _Most_ of the source is available, but not all of it. This > is a case where -- for me -- close is not good enough. > > To each their own. Todd, you can definitely choose where to contribute and that is fine, and thanks for what you contributed till today. However, *all* of RHEL code is available with "free as in freedom" licenses to all RHEL customers, as the licenses dictate (and beyond as we apply the same rigor to *all* code as if all were GPLed). You can see that for free (gratis) by subscribing to the developer subscription if you are curious. Additionally *all* of the code is fully available in git form on gitlab as part of CentOS Stream. If that is not enough for you, that's fine, just do not spread false information. Thanks, Simo. -- Simo Sorce, DE @ RHEL Crypto Team, Red Hat, Inc ___ 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?
On Wed, 2023-08-30 at 09:11 +0100, Peter Robinson wrote: > On Mon, Aug 28, 2023 at 9:50 PM Simo Sorce wrote: > > > > On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote: > > > Once upon a time, Richard Hughes said: > > > > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel > > > > wrote: > > > > > whats the benefit of this "self-signed TLS certificate" (as it does > > > > > not provide any "security")? Is this stub for something later ... ? > > > > > > > > It's a good question. It provides encryption (so client A can provide > > > > the file to client B without client C being aware what's being sent) > > > > > > Without identification though, it doesn't do that, because there's no > > > way for client B to know it is really talking to client A - it could be > > > talking to client C with a man-in-the-middle attack and a different > > > self-signed cert pretending to be client A. > > > > It helps dealing with passive attacks, but not with active attacks. > > > > It could be improved by using TOFU, so that the window of impersonation > > is small, but requires clients to cache an association and then has > > weird failure modes to be dealt with if one of the actors get re-imaged > > or changes the cert for any reason. > > > > > > Richard, > > given your files are all independently integrity checked, you should > > probably not use a TLS connection, because it will be flagged up pretty > > rapidly if it is using a self-singed cert anyway. > > > > This thing works only within the same LAN, therefore already "within" a > > firewall so it does not need to cross any boundary for which encryption > > matters enough. > > > > Finally if an enterprise says TLS is a must you could give an option to > > use TLS if said enterprise provides the certs (they will probably > > disable the service anyway otherwise). > > What about integration with Let's Encypt as an option, the cert > registration/renewal process is then pretty automated. You need to have control of the service, you need an account in let's encrypt, and it needs to be reachable from let's encrypt via a DNS name. I thought about it for a second, but there simply are no working pre- requisites, the client changes address all the time, so the certificate will be marked invalid and not passing muster even if you were able to pass the hurdles of getting one from let's encrypt (which you won't in the general case). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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?
On Tue, 2023-08-29 at 20:07 +0100, Richard Hughes wrote: > On Tue, 29 Aug 2023 at 18:54, Simo Sorce wrote: > > That depends on how you are going to handle re-installs of peers in the > > network where the certificate will start mismatching ... > > In event of a mismatch I was going to ignore the peer; in most home > networks there'll be dozens of devices all offering the same data. Eventually all devices will end up ignoring each other? > > How do you handle certificate expiration ? > > At the moment, not, i.e. a 9999 year expiration. Ugh. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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?
On Tue, 2023-08-29 at 20:05 +0100, Richard Hughes wrote: > On Tue, 29 Aug 2023 at 17:06, Vít Ondruch wrote: > > The point was that `fwupdmgr get-devices` lists ~32 devices for my LP. I > > can't imagine that the metadata for these 32 devices would take 2 MBs. > > That is more likely data for all devices ever supported. > > It is the metadata for every device -- every fwupd client deliberately > gets the entire catalog rather than making a bespoke request like > Windows update. This ensures that the LVFS doesn't know what hardware > you have on your computer, and couldn't provide that kind of data even > if compelled to by law enforcement. The entire architecture is privacy > centric, and also allows it to scale to millions of devices without > having thousands of servers. You could have deltas, so that clients will not get the whole thing every day, but deltas compared to what they have already (which would be 0 bytes if thy are up to date). You reveal nothing of consequence by disclosing what version you already previously downloaded, and that you need just a delta. If a client has a too old version, you return an error, and they download the whole thing. This means it is up to you to decide how many delta files to keep for how long. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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?
On Mon, 2023-08-28 at 22:07 +0100, Richard Hughes wrote: > On Mon, 28 Aug 2023 at 21:50, Simo Sorce wrote: > > It could be improved by using TOFU, so that the window of impersonation > > is small, but requires clients to cache an association and then has > > weird failure modes to be dealt with if one of the actors get re-imaged > > or changes the cert for any reason. > > I was thinking of implementing TOFU; good idea or bad idea? That depends on how you are going to handle re-installs of peers in the network where the certificate will start mismatching ... How do you handle certificate expiration ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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?
On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote: > Once upon a time, Richard Hughes said: > > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel > > wrote: > > > whats the benefit of this "self-signed TLS certificate" (as it does > > > not provide any "security")? Is this stub for something later ... ? > > > > It's a good question. It provides encryption (so client A can provide > > the file to client B without client C being aware what's being sent) > > Without identification though, it doesn't do that, because there's no > way for client B to know it is really talking to client A - it could be > talking to client C with a man-in-the-middle attack and a different > self-signed cert pretending to be client A. It helps dealing with passive attacks, but not with active attacks. It could be improved by using TOFU, so that the window of impersonation is small, but requires clients to cache an association and then has weird failure modes to be dealt with if one of the actors get re-imaged or changes the cert for any reason. Richard, given your files are all independently integrity checked, you should probably not use a TLS connection, because it will be flagged up pretty rapidly if it is using a self-singed cert anyway. This thing works only within the same LAN, therefore already "within" a firewall so it does not need to cross any boundary for which encryption matters enough. Finally if an enterprise says TLS is a must you could give an option to use TLS if said enterprise provides the certs (they will probably disable the service anyway otherwise). There is one more option you could entertain, and that is to use a "well know" pre-shared key instead of certificates for authentication, will be faster, and will give you the "fake-secure" TLS tunnel without the self-signed cert headache I think ... (not endorsing this option, just mentioning it). HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: BiggerESP (Self-Contained Change proposal)
On Thu, 2023-05-11 at 12:52 -0500, Gregory Bartholomew wrote: > On Thu, May 11, 2023 at 10:10 AM Lennart Poettering > wrote: > > > > > (Moreover, read-only access doesn't cut it. If you want boot counting > > you want write access.) > > > > > Just interjecting a quick thought -- would it be possible to use FAT's > reserved sectors for the boot counting? (You can find a description of them > under the -R option in the mkfs.vfat man page.) I still think it would be > nice to be able to mirror the ESP with mdraid. But if the FAT filesystem is > writable by the bootloader, then that won't work. The reserved sectors are > specifically reserved for bootloader code by design and if write access by > the bootloader/firmware is limited to those sectors then there should be no > danger of filesystem corruption if software mirroring is used. Given changes to the ESP should be rare, it may make more sense to just teach the system to make a copy of the contents to a separate partition whenever changes are made, rather then relying on RAID 1 in this case. It would certainly be more robust. And could even be used as a "recovery" partition if you update the contents of the second partition only after successful reboot after update of the first... Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: BiggerESP (Self-Contained Change proposal)
On Wed, 2023-05-10 at 18:46 +0200, Lennart Poettering wrote: > On Mi, 10.05.23 11:20, Simo Sorce (s...@redhat.com) wrote: > > > It sounds reasonable for sure. > > The only concern is, given Microsoft creates at most 500MB ESP > > partitions, are we sure all UEFI systems out there will not choke on a > > 1GB one? > > Well, I don't really think we have a reason to believe that a 1G ESP > was any more problematic than a 0.1G ESP. I am not aware of any > reports, and given that FAT32 is mandated by UEFI since basically > always, I think there's no immediate reason to believe we are in > trouble. > > I think the only reasonable approach here is to pick a larger default > in a development distro, and collect feedback. > > > Can't we reduce the number of kernels by having *only* one UKI and a > > rescue one that can be used to restore the previous working UKI from > > /root if the active one fails? > > I'd kill the rescue concept as a separate kernel. Pre-compiled UKIs > provided by Fedora should be comprehensive and suitable enough to be > rescue images, I don't see why we need a second version of that. The > only difference between a rescue boot and a regular boot should be one > of parameterization, not of picking different kernel. The next paragraph you cut off was proposing just that :-) The reason why I still mentioned the rescue kernel is, as Dan mentioned that in order to use a single UKI for both regular and rescue function we'd need to be able to select between multiple signed command lines. Once that is possible, I definitely would go with A/B images and stop relying on years old rescue kernels as fallback. Simo. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: BiggerESP (Self-Contained Change proposal)
On Wed, 2023-05-10 at 12:00 -0400, Neal Gompa wrote: > On Wed, May 10, 2023 at 11:12 AM Simo Sorce wrote: > > > > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote: > > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering > > > wrote: > > > > > > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > > > > > I've been asked to consider converting /boot to a Btrfs subvolume so > > > > > that it no longer has a fixed space allocation to deal with the ever > > > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is > > > > > currently incompatible with how systemd views the world, because the > > > > > "discoverable partition spec" is wired to partitions, and there is no > > > > > equivalent spec for subvolumes of a volume. And I imagine that > > > > > XBOOTLDR (whatever that is) also would have a problem with this. > > > > > > > > This makese no sense. If you want /boot to just be a subvolume of the > > > > rootfs btrfs, then this would imply it's also covered by the same > > > > security choices, i.e. encryption. We want to bind that sooner or > > > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > > > feasible from a boot loader environment. > > > > > > > > Hence, the place the kernel is loaded from (regardless if you call it > > > > /efi or /boot or /boot/efi, and regardless what fs it is) must be > > > > accessible from the boot loader easily, without requiring > > > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > > > > > > > Hence: btrfs subvols won't work for this > > > > > > If we're not using LUKS for encryption, then this is not a problem. > > > We're generally looking toward encrypting subvolumes individually > > > using the upcoming Btrfs native encryption capability rather than > > > using LUKS. That allows us to > > > > > > 1. Pick which subvolumes are encrypted > > > 2. Pick the security binding method per subvolume > > > > > > For example, the root and home subvolumes would use TPM or some other > > > non-interactive binding. The user subvolume in home would decrypt with > > > user login. > > > > Neal, > > I think you are barking up the wrong tree here. > > > > The design of the boot loader *nedds* to be simple. > > > > Simple means, VFAT and *no trust* in the filesystem, individual files > > are signed and verified. > > Only the bare minimum *necessary* is in the boot partition, which means > > kernel images and the bare minimum init image needed to unlock and > > mount the root partition. > > > > There is no point in building a more complex system than that and load > > tons of garbage drivers in the EFI. > > > > Booting is a staged system, and should be kept as simple as possible to > > avoid duplication (which means subtle bugs and a ton of maintenance > > overhead). > > > > This proposal isn't better. Neither Windows nor macOS put critical > operating system code in the ESP, and we shouldn't either. But you > want to put kernels in the ESP? That's the wrong approach too. > > As soon as you throw UKIs in the mix, you've completely broken that > because now the absolutely most valuable code for your system is in a > "hostile" environment. At least we can make /boot authenticated and > tamper resistant as a Btrfs subvolume. Sorry but this really doesn't compute. Either you can verify signatures and then it doesn't matter that someone can tamper with the file system, or you can't and then you always have evil maid approaches to replace grub with malicious code anyway. There is no added safety or unsafety about any of these schemes. > I would rather have a multi-stage boot process, where the first stage > does just enough to unlock and load the OS volume to load the real > boot environment. I do not see any advantage, loading a kernel is what the first stage should do, then the kernel+initimage can do everything you need. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: BiggerESP (Self-Contained Change proposal)
On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote: > On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > == Summary == > > > > > > This change will increase the minimum size of the ESP to be 500MB, > > > which is also the same value used by Microsoft for Windows 10 and > > > newer. > > > > This is both too much and not enough. Essentially, this grows the ESP, > > but also leaves the XBOOTLDR partition large. Overall, the users pays > > twice, and on some systems 1.5GB is not insignificant. OTOH, 500 or > > 512 MB seems not enough: three big UKIs and a rescue kernel and and > > some Windows blobs and a firmware update would likely overflow. > > > > If we want to change the default here, let's do some proper cleanup: > > 1. the split between ESP and XBOOTLDR is only useful in the case where > >ESP already existed and was small. If the installer is *creating* > >an ESP, it should just make it large enough. > > 2. having a second partition with a second (different) file system > >implementation just increases the footprint and attack surface for > >no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT > >in almost all realistic scenarios). > > 3. if there are bootloaders that don't read one or the other partition > >as they should, fix them. > > > > Then we can make the ESP 1 GB *and* save space compared to current > > defaults. > > > > (Point 2. is not really *necessary* for the size changes, but it'd be > > nice to get rid of this anachronism if this area is being touched.) > > I guess this might not be surprising, but this proposal makes a ton of > sense to me and has my full support, FWTW It sounds reasonable for sure. The only concern is, given Microsoft creates at most 500MB ESP partitions, are we sure all UEFI systems out there will not choke on a 1GB one? Can't we reduce the number of kernels by having *only* one UKI and a rescue one that can be used to restore the previous working UKI from /root if the active one fails? Or perhaps just have always 2 UKI (current, and former working). Do we actually need a separate dedicated rescue UKI? Can't rescue be implemented by booting the previously working UKI with a "rescue" command line option ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: BiggerESP (Self-Contained Change proposal)
On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote: > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering > wrote: > > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > I've been asked to consider converting /boot to a Btrfs subvolume so > > > that it no longer has a fixed space allocation to deal with the ever > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is > > > currently incompatible with how systemd views the world, because the > > > "discoverable partition spec" is wired to partitions, and there is no > > > equivalent spec for subvolumes of a volume. And I imagine that > > > XBOOTLDR (whatever that is) also would have a problem with this. > > > > This makese no sense. If you want /boot to just be a subvolume of the > > rootfs btrfs, then this would imply it's also covered by the same > > security choices, i.e. encryption. We want to bind that sooner or > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > feasible from a boot loader environment. > > > > Hence, the place the kernel is loaded from (regardless if you call it > > /efi or /boot or /boot/efi, and regardless what fs it is) must be > > accessible from the boot loader easily, without requiring > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > > > Hence: btrfs subvols won't work for this > > If we're not using LUKS for encryption, then this is not a problem. > We're generally looking toward encrypting subvolumes individually > using the upcoming Btrfs native encryption capability rather than > using LUKS. That allows us to > > 1. Pick which subvolumes are encrypted > 2. Pick the security binding method per subvolume > > For example, the root and home subvolumes would use TPM or some other > non-interactive binding. The user subvolume in home would decrypt with > user login. Neal, I think you are barking up the wrong tree here. The design of the boot loader *nedds* to be simple. Simple means, VFAT and *no trust* in the filesystem, individual files are signed and verified. Only the bare minimum *necessary* is in the boot partition, which means kernel images and the bare minimum init image needed to unlock and mount the root partition. There is no point in building a more complex system than that and load tons of garbage drivers in the EFI. Booting is a staged system, and should be kept as simple as possible to avoid duplication (which means subtle bugs and a ton of maintenance overhead). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
On Sat, 2023-04-22 at 12:16 -0700, Adam Williamson wrote: > On Sat, 2023-04-22 at 10:37 -0700, Kevin Fenzi wrote: > > On Fri, Apr 21, 2023 at 02:30:45PM -0700, Adam Williamson wrote: > > > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote: > > > > > > > > > For lists that are active, the split is confusing — when should > > > > > something be on the packaging list rather than devel? What happens > > > > > when > > > > > something is related to both Cloud and Server, or Workstation and KDE? > > > > > One can post to both lists, but if someone replies and isn’t > > > > > subscribed > > > > > to both, the conversation gets split. > > > > > > > > Do Fedora mailing lists reject mail from non-members, and redirect > > > > follow-ups? > > > > > > Many lists *hold* mail from non-members, because mailing lists get tons > > > of spam. So the mail won't get through until an admin approves it. That > > > might happen right away...or it might happen in two days, when the mail > > > is no longer relevant. We can't really just let all mails from non- > > > members through because...spam. > > > > Right. I don't think we have many (or possibly any) lists that still > > hold email from non-members. The flood of spam is just too high for that > > for the last N years. So, almost all our lists are set to reject non > > member posts. :( > > ah, I hadn't noticed that change :/ I could've sworn I still sometimes > get hold notices when I send meeting announcements to lists I'm not > subscribed to... In theory we could make it simpler by sending back a message that requires just a click to subscribe/authorize the email by a real user, if they intend to do so, on their first email to a mailing list. We could also allow posting to other mailing lists if the email address is subscribed to any other list. I realize this would require working on mailman and that is probably something we do not want to spend time on ... After all you have to subscribe to discourse as well to be able to post ... so there is no huge difference here. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
On Fri, 2023-04-21 at 15:39 -0500, Carl George wrote: > As Matthew stated, Ben has measured it and fewer people are > participating on the mailing list over time. We are already leaving > out many contributors. This is an interpretation, but are we sure we are missing them because the mailing list is uninviting, and not just because the pool of interested people is shrinking? > Those conversations are largely moving to > issue trackers, which are also not perfect but are clearly more > appealing than email for many people. Issue trackers are a pretty good way to deal with issues, we should have a better issue tracker that makes those conversations better, not discourage them to make everything flow in non-descript mailing lists or forums... > Discourse has the potential to > be a more attractive alternative than both email and issue trackers. And less attractive to people that work better with mailing lists and issue trackers... > To me this seems like a solid strategy for reversing the trend and > getting more people participating in development discussions. I really dislike this fixation on numbers. We need higher quality and we need to discuss what is really needed. Numbers shouldn't be priority number one, unless there are other underlying issues. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
On Fri, 2023-04-21 at 14:27 -0400, Matthew Miller wrote: > On Fri, Apr 21, 2023 at 11:37:20AM -0400, Simo Sorce wrote: > > So I registered the account, added the email I want to get > > notifications at, and selected a few topics. > > > > First impressions. > > > > It is absolutely confusing to figure out how to watch topics. > > If you select a category and a topic you do not get the notification > > bell to watch them. > > If you select just a topic you get it. > > Topics are all in random order. When you select some topic by searching > > you sometimes are then proposed a different one (? renames ?) > > A terminology thing: I think what you are calling "topics" discourse calls > "tags". Each discussion or thread is what discourse calls a "topic". Sorry, I did mean tags. > Watches are by category, by tag, or by individual topic. > > > > > I found no way to watch all, and let my client sort it out ... which > > would need client filtering, because the stupid gmail filtering can't > > handle header fields (#@#%$@#). > > Watching at the category level is probably the closest thing here. That is, > watch Project Discussion and News & Announcements at least. That will > include all topics under those categories regardless of tag. > > As for Gmail, see > https://gist.github.com/tpopela/e2f17bf8eac15bee734b993e170f4dfa. > I'm trying to get Tomas to write a Discourse post about that. I've seen this before and it is a total monstrosity that works for those that use the Web UI, but for those that pulls from IMAP like me just makes everything worse, as those scripts run with delay, no thanks. I expect they will also break suddenly whenever gmail decides to change something, so I am not investing my time in that at all. Note that I use gmail only because I am forced to, so I have no desire in further exploring the matter, personally speaking, I have other tools to cope with filtering if I need to. > > > They come several minutes (at least 5 minutes, as the email is *sent* > > that much later, and the sent date is set to when the email is sent, > > not to when the post is made) after the actual message is posted in > > discourse, I do not care much, I generally read asynchronously as well, > > but it is sometimes annoying not to be able to establish the real time > > a post was made. > > Oh that's interesting. I'll bring that up. The five minute delay is actually > a site-wide configuration option: it gives time for the poster to make any > quick typo fixes, add tags they forgot, etc. before the mail is sent. (The > default is 10.) > > > The only way to know who posted is by looking at the From field, where > > the description of the notification email address is changed to include > > the display name of the poster. That is a bit confusing at times. > > > > There is no formatting in the mail that tells me who is someone > > replying to, or which message in the thread it was being replied to (I > > disabled sending me the whole thread with each notification, I may re- > > enable it). > > Do you have "Include an excerpt of replied to post in emails" checked? > Does that help? I have it, it seem it does nothing, as no excerpt is added. > > The test part so far is otherwise decently rendered, and for image > > posts it is clear enough that there is something to look at in the html > > part. *however* the images are not embedded in the email, so all that > > information is unavailable offline or for archival (and in my > > configuration requires to actively pull images as I configured my > > client to not pull 3rd party content automatically for privacy and > > security reasons). > > Reasonably enough. There might be an option to embed images -- I'll look. > For what it's worth, the images should all (and only) come from the > dedicated CDN site for our hosting, and there's no linked tracking on our > side or Discourse's. There's probably logs somewhere, though. The privacy statement is about why I do not configure my client to download in general, not referred to discourse specifically. Point is the image is not embedded, so you need to be online to be able to pull at all whenever you read the message. It also means if the CDN removes/renames that content at some point in the future, the message sitting in my mailbox is now broken. > -- > Matthew Miller > > Fedora Project Leader > ___ > 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/co
Re: It’s time to transform the Fedora devel list into something new
On Fri, 2023-04-21 at 10:44 -0400, Matthew Miller wrote: > On Thu, Apr 20, 2023 at 08:24:48PM -0500, Chris Adams wrote: > > Once upon a time, Matthew Miller said: > > > I am proposing that over the course of 2023, starting with the Changes > > > process, we move Fedora development conversations from this mailing list > > > to > > > the Discourse-based Fedora Discussion. > > > > I feel this is a case of trading one group of people (email list users) > > for a different group of people (web forum users). > > I don't think this is _really_ a "there are two kinds of people in the > world..." situation. Of course there are some people who have preferences > (strong or weak) for one or the other, and completely legitimate pros and > cons to each. But I don't want to "trade" anyone. I'd like to bring everyone > along. > > > > I have seen this > > done multiple times over the years, tried to follow a few times, and > > always dropped off fairly rapidly. I'm solidly in the "email list > > users" group. > > Is there anything which could be different this time which would make it > better for you? So I am trying to see how it works to follow those discussions via email (sorry this is the only way, following via web simply doesn't work for me). So I registered the account, added the email I want to get notifications at, and selected a few topics. First impressions. It is absolutely confusing to figure out how to watch topics. If you select a category and a topic you do not get the notification bell to watch them. If you select just a topic you get it. Topics are all in random order. When you select some topic by searching you sometimes are then proposed a different one (? renames ?) I found no way to watch all, and let my client sort it out ... which would need client filtering, because the stupid gmail filtering can't handle header fields (#@#%$@#). And if you can't watch all it means you can watch only know topics, and anything new will simply be missed. It would be useful to be able to say "watch all except these specific topics", which are the ones you realize are uninteresting to you and explicitly start to filter out. I could do that filtering after receiving though, so being able to watch all is the minimum requirement to be able to follow anything. [late edit: in a plot twist, if you select a category, then you get a new meta-tag call all-tags, and you can watch that ... I selected that now and will see if I can block specific tags somehow later or filter them on my end] I couldn't find a place to list all the topics I am watching ... only way I found so far is to click on all the tags in a notification to see if any of them has the bell thingy ... On the actual notifications I am receiving: They come several minutes (at least 5 minutes, as the email is *sent* that much later, and the sent date is set to when the email is sent, not to when the post is made) after the actual message is posted in discourse, I do not care much, I generally read asynchronously as well, but it is sometimes annoying not to be able to establish the real time a post was made. The only way to know who posted is by looking at the From field, where the description of the notification email address is changed to include the display name of the poster. That is a bit confusing at times. There is no formatting in the mail that tells me who is someone replying to, or which message in the thread it was being replied to (I disabled sending me the whole thread with each notification, I may re- enable it). The test part so far is otherwise decently rendered, and for image posts it is clear enough that there is something to look at in the html part. *however* the images are not embedded in the email, so all that information is unavailable offline or for archival (and in my configuration requires to actively pull images as I configured my client to not pull 3rd party content automatically for privacy and security reasons). I have not tried to reply to anything, so I do not know how that will fare. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Hi Matthew, you say: "We're missing people", and I think, "who?". And who are you going to miss if you move to discourse? I will be candid, I tried to use forums since the old phpBB times, it never works for me. I have no time to go roaming over forums except if a search engine brings me there. The mailing list make messages land in my client, on which I am very efficient, therefore I can check all messages once a day, and respond if I find a worthy topic. Unless this discourse has some great mail bridge (it doesn't) or maybe an rss feed (I do not use those at work, but I guess I could ?) So that I can skim messages on my terms, I think I (and those like me) will be the next "missing people". Btw I could make exactly the same quote about any forum that Major made for Mailing lists, messy discussions are messy and a forum does not make them easier to follow by any means (perhaps except for those that chose inferior email readers). All that said, why waste time with this discussion? Your own post communicates to me (whether you intended it or not) that in the end the thread that will be generated by this post won't matter, because this is just a courtesy post and you already think that the opinion of the "minority of self selected mailing list lovers and dinosaurs" does not matter much. On Thu, 2023-04-20 at 17:20 -0400, Matthew Miller wrote: > It’s time to transform the Fedora devel list into something new > ======= -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Future of encryption in Fedora
On Thu, 2023-04-06 at 12:56 -0400, Owen Taylor wrote: > On Thu, Apr 6, 2023 at 12:32 PM Simo Sorce wrote: > > > On Mon, 2023-04-03 at 16:18 -0500, Michael Catanzaro wrote: > > > On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane > > > wrote: > > > > This seems like exactly the kind of discussion that belongs on the > > > > devel > > > > list, not on a website that I have to remember to visit for updates. > > > > > > There is a notification bell in the right sidebar. Click it. ;) > > > > > > > Or we can simply ignore that discussion until it lands in devel with a > > change proposal. > > > > Discussing on the forum was a suggestion from zbyszek and I think he > proposed it in the same spirit that I agreed to the proposal - as an > experiment in trying to align technical discussions more closely with the > overall direction of the Fedora project for communication. > > I think we can see both pros and cons in how it's gone - on the good side, > people are involved that might not be involved otherwise, there's an easily > accessible public record of the conversation that is more readable than > even a good mailing list archive, and having richer markup available is > genuinely useful. > > On the downside, spam limits on new posters have gotten in the way in some > cases, and people have had some trouble figuring out how to use the quoting > features, resulting in disconnected responses. > > Yes, there will eventually be change proposals, which will be discussed > here (unless anything changes...) but I would strongly encourage people to > get involved now in the discussion if they care about the topic - the more > we can get things right early, the better. Sorry Owen, discourse is too disruptive for me to spend time on. I did try to skim the discussion and I think you have quite a few hints already that this is not an easy path. What I would recommend though, is to split this monster of a proposal in smaller progressive steps. You do not need to get everything super-tight-secure on the first try (you won't be able to anyway), and building it in steps will allow you to also (hopefully) offer a more fine-grained choice/configuration later on. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Future of encryption in Fedora
On Mon, 2023-04-03 at 16:18 -0500, Michael Catanzaro wrote: > On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane > wrote: > > This seems like exactly the kind of discussion that belongs on the > > devel > > list, not on a website that I have to remember to visit for updates. > > There is a notification bell in the right sidebar. Click it. ;) > Or we can simply ignore that discussion until it lands in devel with a change proposal. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Changes to Bugzilla API key requirements
On Fri, 2023-02-24 at 11:55 -0500, Solomon Peachy via devel wrote: > On Fri, Feb 24, 2023 at 05:55:55AM +0100, Kevin Kofler via devel wrote: > > Ah right, I had forgotten about that issue. I do not think I will ever > > understand the fascination some projects have for JIRA. It is proprietary, > > and IMHO the web UI for users to report bugs in JIRA is very confusing at > > times. (The Bugzilla one can be confusing at times as well, but at least it > > is familiarly confusing. ;-) ) > > Middle management *LOVES LOVES LOVES* Jira. Not middle management is generally as confused as other users. Where Jira is really helpful is project management, and when you have many, large, interconnected sub teams and sub projects, Jira really has tooling that helps. Of course like all tools it has its good things, and its bad compromises, the UI being one of them. But the data model behind it allows a lot of functionality (it is basically an SQL database), and the dashboards and other prepackaged widgets allow exploration of the data to a level that bugzilla does not allow (or if it does at considerably harder cost, so high very few ever bother trying). > As for everyone else... let's just say that it's not repeatable in polite > company. > > (I admit I'm surprised that "Free Software for Everything" Red Hat is > chosing to base something so fundamental to their business on a highly > proprietary tool. I suppose O365 is just a matter of time...) One of the bad things is that Jira is not Open Source, and I think we'll ultimately may end up regretting the choice, but not in the short term (there is no equivalent really in the open source world) ... and pragmatically, in the long run we are all dead, so while we wait for something better, we will have to use the least worst. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: TSS maintainer volunteer
On Fri, 2023-02-10 at 19:49 +, Kenneth Goldman wrote: > I would like to volunteer to maintain the two TSS packages in Fedora: tss2, > tss2-devel. > > I currently maintain the source. > > I would appreciate any tips on what steps I should take. I think you should contact the current maintainer first. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
On Fri, 2023-01-13 at 12:28 +0100, Miro Hrončok wrote: > On 13. 01. 23 0:35, Chuck Anderson wrote: > > For receiving/filtering emails, you can filter on the List-Id: header > > rather than the To: or Cc: headers. In that way you can differentiate > > between normal list distribution and Bcc:. If there is no List-Id: > > header, the mail can be directed to your Inbox rather than the mailing > > list folder (if that is how you filter your messages) or otherwise > > flag it as important, etc. > > I am afraid this does not work properly with gmail. > Gmail will receive two emails with identical content but different headers > (one > with List-Id and one without) and it will "consolidate" the two email into > one > by randomly dropping one of them entirely. Even if gmail drops the headers, they know at time of receive what is what (bad magic) so if you use google's own filtering you can tell it to file messages sent to "this list" under a specific tag, you can also tell it to keep in inbox if you are explicitly in CC or TO (potentially requires two separate filters to do that selectively). It sucks, but it can be worked with to some degree... If you do your own filtering after fetching emails maybe you should consider a better hosting for your emails... > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Unannounced? lua-libs soname change
On Tue, 2023-01-10 at 20:29 +0100, Hans de Goede wrote: > Hi, > > lua-5.4.4-4.fc37 in F37 release provides both: > > liblua-5.3.so()(64bit) > liblua-5.4.so()(64bit) > > aka both of: > > /usr/lib64/liblua-5.3.so > /usr/lib64/liblua-5.4.so > > but the recent update to lua-libs-5.4.4-7.fc37 only provides: > > liblua-5.4.so()(64bit) > /usr/lib64/liblua-5.4.so > > And the same appears to be happening in F36 (I did not check): > > This is causing the following fails to install cegui bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=2156354 > https://bugzilla.redhat.com/show_bug.cgi?id=2156356 > https://bugzilla.redhat.com/show_bug.cgi?id=2156626 > > and the following fails to install megaglest bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=2156357 > > I can rebuild cegui (and issue updates of it for f36 + f37), > which I think might be easier/better then restoring the > liblua compat build. > > And I guess I can also take care of megaglest while at it, > but first I wanted to make sure that this is the right > way to move forward with fixing this... ? Soname breakage should not happen in stable releases... liblua should be rebuilt to provide the older so name and if not possible with the new code, reverted back via epoch change or some patching -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: static USERMODEHELPER_PATH
On Fri, 2023-01-06 at 18:21 +0100, Lennart Poettering wrote: > On Fr, 06.01.23 10:10, Steve Grubb (sgr...@redhat.com) wrote: > > > Hello, > > > > On Friday, January 6, 2023 9:33:12 AM EST Lennart Poettering wrote: > > > On Do, 05.01.23 20:17, Steve Grubb (sgr...@redhat.com) wrote: > > > > I work on RHEL security problems. I have been looking into a number of > > > > exploits and I think we have a problem that has an easy fix. We are not > > > > using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There > > > > are a number of exploits that overwrite the path to modprobe and then > > > > pass something weird that causes modprobe to be invoked. But instead of > > > > modprobe, it's their reverse shell. > > > > > > umh is such a problematic interface. The processes forked off that way > > > live in a weird netherworld besides the init system, in the root > > > cgroup (and that even though inner cgroups in cgroupsv2 are not > > > supposed to have processes in them) without any of the resource or > > > security restrictions we otherwise make on all of userspace. > > > > One approach to solving this is to use selinux policy. > > selinux cannot apply resource controls, not can it arrange processes > properly in the cgroup tree, nor can it apply seccomp filters, > namespacing and so on. > > selinux can do some things, sure, but an init system is not a MAC, it > does a lot more (and also a lot less). > > > Yeah, that's another approach that may have merit. But with the asynchronous > > nature of that approach, I don't know how the kernel would know it can now > > make calls into the module it needed to have loaded. > > Well, umh is async too in a way, kernel must wait for the userspace > process to finish. There's not much of a difference to say "fork off + > wait for process exit" and "send netlink message to userspace + wait > for reply". If I remember correctly the claim was that umh is robust if the user space fails and just terminates. As then the kernel know user space is gone, whether it got the data it needed or not and can stop waiting. While messages may never get replied to and require handling timeouts and then handling the case a user space process was slow and ignoring late replies. Not sure this is really a good point given waiting indefinitely for a user space program that hangs for some reason seems worse to me. When I had to code a call from knfsd to user space for GSS-Proxy I used unix sockets. I think that is better than netlink in some cases as sockets are simpler to handle from user space programs and are also easily namespaced... Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote: > How do you plan to handle system recovery? For VMs this is much > less of a concern, but on bare metal there needs to be a way for > a local, authenticated administrator to obtain a root shell on > the system console even if the root filesystem cannot be mounted. > This has saved my system more than once. > > Also, how will Xen be supported in this model? Will the hypervisor > be part of an alternate UKI? CCing Marek Marczykowski-Gorécki of > Qubes OS. It is all answered in the large amount of text you quoted, if you read it carefully. The old kernel+inird does not go away, so you disable secure boot and just use the good old methods, or worst case you use a recovery disk (or USB drive, or whatever you use to install) if you damaged the boot partition. Anything that is not explicitly supported likewise will use the old kernel + custom initrd, you just disable secure boot. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote: > I note that taking away the kernel command line is indeed a clearly > stated goal, which will limit Fedora to simple, appliance-like uses. I for one, haven't touched once the command line in this laptop that has 4 years. So I welcome simplification for that *common* case. Given nobody is taking away the initrd way all you will have to do (at most, if you use it) is to disable secure boot and regain the ability to change the kernel command line and build your own initrd or even your own kernel if you so like. 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! Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote: > Yeah, I seriously doubt this. Linux's model for supporting > confidential computing is not user-friendly, so I expect low adoption > and resistance once the flaws become apparent to would-be users. > Neal, you are being unnecessarily negative. And user-friendliness is directly related to the fact we do not have good support for it. This proposal would make SecureBoot fundamentally transparent, and if you don't see it and it works, I see no resistance happening. SecureBoot may not be to your liking but is what is installed on 99% of modern hardware sold, so it is a good idea to first show you can support it. Then if you have interested you can propose "something better". Finally, unless this proposal harms Fedora I do not see why oppose it. If, as you fear, it won't work ... then it won't and we'll try something else. However, having some knowledge of the (security side of the) matter I do not see why it wouldn't work, once all the pieces fall in place. In fact I would love to be able to test this, every time I run updates I dread the many minutes wasted regenerating initrd when I have a pretty standard configuration that requires really no special drivers... the only issue probably being the use of LVM for the root filesystem, which I hope we'll have a way to deal with (but I can do without on the laptop). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Thu, 2022-12-01 at 00:41 +, Daniel Alley wrote: > I'm quite not sure how one would go about empirically measuring > something like that - at least in the general case. It might be an > interesting research topic. So no, unfortunately I don't really have > hard evidence for this. We did run discovery for this in RHEL when we started the SHA-1 deprecation process. Some embedded implementations were found but the vast majority of programs used one of the available libraries for SHA-1. I do not expect SHA-256 to be any different. so empirically I can tell you there isn't anywhere as much "vendoring" in C as you claim. Using dynamically linked libraries is well establish and the reason why sometimes the dependency chain is ... monstrous. > I just know that of all the C libraries I've looked at, in my > personal experience it seems to be a very common phenomenon to copy > or reimplement code that in Rust you would just import and re-use. Perhaps this is true in the niche you are interested in? > It's just a pattern that one notices frequently when it comes to C > libraries, especially crossplatform ones that can't rely exclusively > on the existence of a Linux-like package manager. Yes, those kind of libraries tend to be quite bad in this regard, OTOH it can be done right. For example the NSS library generally carries copies of external dependencies, but the configure script looks for a system version and links to the one if available on build. So if you looked at NSS you may think it vendors, and it does, but smartly and in a way that is compatible with systems integration. > If you want specific examples, the ones that pop to mind are: > > * zchunk and deltarpm both reimplement / "bundle" multiple different > hashing algorithms > * libcomps implements about 4 different relatively common data > structures I am not sure this qualify as vendoring/bundling, kind of borderline but I see why you added it as a case. > * GTK appears to contain a bundled, forked copy of the CRoaring > library > > > > > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, 2022-11-30 at 18:26 +, Simon Farnsworth via devel wrote: > On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote: > > On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote: > > > I feel like there is insufficient recognition of the extent to which C > > > libraries do "bundling". Not "bundling" in the sense of vendoring a > > > whole library, but in the sense of including one-off implementations of > > > basic data structures, configuration parsers, hashing algorithms, etc. I > > > would love to hear anyone argue that 100 different variations of > > > "sha256.c" across 100 different packages better follows the spirit of the > > > "no bundling" guidelines than a vendored crate named "sha256" with 100x > > > as many eyes on it, and a higher likelihood to actually be updated if a > > > problem is found. > > > > > > > > > > > Many of the tiny, "sprawling" Rust dependencies are like this - not all of > > > them of course, but many. > > > > But ... none of these "tiny" Rust crates are dynamically linked in > > Fedora anyway - because Rust doesn't really support that? > > So I fail to see your point there, unless you meant to say "C projects > > don't 'bundle', they just often 'copy' some code into their projects"? > > > I think the point he's making is that developers don't write common > functionality from scratch, in general. We reuse code from elsewhere. > > It's just that in C, I'll copy-and-paste code from the web into my library or > application, not necessarily even bothering with a full "vendoring", whereas > in Rust, I'll use the crc crate (say), or the base64 crate, or other simple > utility crate. > > The result is that I have N implementations of common functionality, each > with > its own unique quirks and security risks, in my C binaries; but my C binaries > have only a small number of dependencies. > > In Rust, however, I'm directly reusing the small utility crate, and while I > may use `cargo vendor` to import the crate's source into my tree, I'm > unlikely > to edit it. The result is that a Rust binary has a larger number of > dependencies than the equivalent C program, because I'm depending on a crate > instead of copy-and-pasting the code and "hiding" it from the packager. > > This is a challenge for Fedora: how do we cope with a world where instead of > having a few tens of dependencies, and a lot of copy-and-paste code, we have > hundreds of dependencies, but no copy-and-paste code? > > One answer is to say that Rust is bad for encouraging developers to depend on > small crates instead of copying-and-pasting "small" utilities around. > Another > (which you're doing a great job of) is to package up all the dependencies, > so > that we represent the true dependency tree in RPM. Yet another would be to > manually decide which dependencies get bundled, and which don't - doing the > same thing as the C world does to keep its dependency count down. This is a bit of a misleading characterization. - the amount of copying in C programs is overblown in my opinion (no data provided to back this up though) - dependency minimization for C programs/libraries is assumed but no data provided to back it up. - the dilemma is how to manage rust programs not to decide what to bundle or not, that's basically decided upstream Although there are certainly instances of copying/paste in C code, the vast majority of reuse comes through linking to utility libraries dynamically, which makes distro-level maintenance much easier because you have only once place to fix/rebuild/distribute when there are serious issues. The problems with Rust crates (or go modules, or any other "vendoring"), is that not only you have to go and find each place where a problematic crate was vendored; you also have to figure out, often under pressure, if the crate can simply be summarily updated or if you need a backport because the vendoring application can't cope with the semantic changes that happened in the problematic crate's new version. Multiply this by N packages using M different versions of the problematic crate. Although vendored crates can be tracked (this i much better than copy/pasting), with additional tooling, the distribution remains on the hook for solving the same problem in N packages, without easy coordination. Some upstream may be quick and do the work for you, some may not care, disappear etc... or are simply too slow for the urgency the distribution has leading potentially to diverging solutions ... Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc __
Re: HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates
On Tue, 2022-11-22 at 17:13 +0100, Fabio Valentini wrote: > - rust-curve25519-dalek Asymmetric cryptography in pure rust should not be used, there is still no support in the language for constant time operations, which means there is a fat chance these implementations are susceptible to trivial timing attacks. The only caveat is if the "pure rust" implementation actually embeds assembly optimization for modular arithmetic that are explicitly addressing constant time computation. I am not aware of that being the case in any rust libraries yet. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: FF 107.0 scratch builds - just for fun
On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote: > On 11/20/22 17:40, Simo Sorce wrote: > > On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote: > > > On 11/20/22 07:24, Bojan Smojver via devel wrote: > > > > Now that nss 3.85 has been built, I thought I'd have a go at building > > > > FF 107.0, given that's been out for a few days and original builds > > > > failed in koji, because nss was too old at the time. > > > > > > Has switching to bundled NSS been considered? For browsers anything > > > that holds up an update is very, *very* bad. > > > > Casually handling crypto libraries is very, *very* worse. > > Has there ever been a case where Fedora’s NSS was not vulnerable to > something that the bundled NSS was vulnerable to? To be clear, I am > referring to the NSS shipped by Mozilla as a part of Firefox. > Another option would be to ensure that NSS is promptly updated. NSS is generally updated in order to release Firefox, I am not aware of a chronic issue here. We compile NSS differently than what Mozilla does, for example we use the Fedora OS trust anchors, and the Fedora Crypto-Policies, etc.. it is not just about vulnerabilities, system integration matters too. But we *have* released patches for security vulnerabilities in NSS w/o requiring also a full recompile and retesting of Firefox. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: FF 107.0 scratch builds - just for fun
On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote: > On 11/20/22 07:24, Bojan Smojver via devel wrote: > > Now that nss 3.85 has been built, I thought I'd have a go at building > > FF 107.0, given that's been out for a few days and original builds > > failed in koji, because nss was too old at the time. > > Has switching to bundled NSS been considered? For browsers anything > that holds up an update is very, *very* bad. Casually handling crypto libraries is very, *very* worse. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, 2022-11-11 at 12:42 -0500, Colin Walters wrote: > > On Fri, Nov 11, 2022, at 5:53 AM, Petr Pisar wrote: > > > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > > all of them stamps from various data formats rather than trying to fake > > them? > > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > > removing the time attribute from the RPM format completely? > > This is what ostree has done since its inception. And it broke some software, I know because i had to fix it. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: RPM Sequoia (System-Wide Change proposal)
getting love lately. Insofar as quirks and gotchas, I'm not a > > great judge of that at the moment, but I don't think it could be worse > > than what we have with GnuPG. > > > > The missing "digest-in-progress" thing is an issue, I guess. Have we > > raised the issue with them about it? > > No, because beneath the surface it didn't seem all that appetizing > afterall. See > https://sequoia-pgp.org/blog/2021/05/06/202105-thunderbird-rnp-and-the-importance-of-a-good-api/ > > for an example (even bearing in mind that a blog post from a competitor > may be necessarily a little opionated), but its reputation/security > record doesn't seem that great. > > It's something to keep an eye on of course, it would be good to have > alternatives available. > > > > > > As for bootstrap, there will always (have to) be a way to build rpm > > > without depending on Rust. Even if that meant no signature verification > > > support in such a configuration. > > > > > > > Eck. What about the x509 based stuff we were talking about last year? > > All the crypto backends RPM supports now support that stuff out of the > > box. > > > > Embedded x509 signatures (certs) to replace GPG signatures could work > > as an alternative. > > x509 seems to be loathed even more than PGP, so it doesn't seem that > appetizing either. > > If someone with known crypto-clue would send patches they would be > looked at, *I* have no prejudice about x509 because I also have no clue > about it. Ditto for Signify, which often gets brought up in these > discussions. > > And yet, that all is largely irrelevant for the subject at hand: no > matter what, rpm will need OpenPGP support for years to come because > existing content will need to remain usable for a long, long time. Just to throw a little fire in here :-D We are starting to look at what it means to sign content with PQC algorithms. One of the factors (not the only one) is the recent CNSA 2.0 recommendations: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF One of the possible impediments, besides finding a decent implementation, zeroing in on the algorithm(s) to select and support, and a gazillion other small but critical details, is the format. At this time, as far as I know, there is no OpenPGP work of any kind on supporting PQC algorithms. Furthermore the way we use signatures in RPM really has no resemblance to the scenarios OpenPGP was built for. So we should consider whether moving to PQC will also mean moving off OpenPGP as our signature format and into something simpler. Panu, I will try to engage the RPM team once we have a settle a little more on the cryptography part. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)
On Wed, 2022-09-28 at 14:21 +0200, Neal Gompa wrote: > I'm (personally, though IANAL) of the opinion that the hobbling of > crypto libraries is probably no longer necessary and can be retired > entirely. The method of producing the stripped sources is > reproducible, so from our guidelines perspective, it's fine. But I do > think it's probably obsolete, and I hope Red Hat Legal concurs. Just FYI, we are working towards removing hobbling and replacing with compilation switches that clearly and permanently disable questionable material in the binaries. It is just not a very high priority item because the hobbling works fine but we will get there, and hopefully we'll get to a point where we do not need to disable as much stuff either. But no promises right now, resources are what they are and we are not aware of actual issues caused by hobbling. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Inactive packagers to be removed after the F37 release
On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote: > On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote: > > > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen > > wrote: > > > I'm not entirely convinced. See this paper: > > > https://eprint.iacr.org/2020/1298.pdf > > > > I only read the abstract of this paper, but looks like the researchers > > have found that FIDO is indeed unphishable. Seems their attack relies > > on websites allowing downgrade to weaker forms of 2FA. > > Yup. The thrust of the paper is: in the real world FIDO2 is usually > deployed alongside older/weaker forms of 2FA, so an attacker can > pretend to the victim that FIDO auth didn't work and convince them to > try a weaker method instead, then phish that. > > Which is a reasonable point, but not necessarily relevant to us. We > *could* require only strong auth and not have weaker fallback methods. So I have been thinking about this, how do you deal with the inevitable fact that keys get lost or stop working if there is no alternative authentication method? I guess people can enroll 2 separate keys (if Feodra Infra will allow that), but not everyone has the means to do that. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: rpm with sequoia pgp
On Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote: > On 9/2/22 17:31, Neal H. Walfield wrote: > > Hi all, > > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > Sequoia PGP. > > > >https://rpm.org/wiki/Releases/4.18.0 > >https://sequoia-pgp.org/ > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > With this note, I'd firstly like to make the Fedora community more > > aware of this project. (I don't think it has been mentioned here > > yet.) > > > > Second, although the internal OpenPGP backend is still the default > > backend, it will be removed in rpm 4.19: > > > >https://github.com/rpm-software-management/rpm/issues/1935 > > While that was the initial goal, I suspect we may have to stretch this a > bit. I think we'll first need a release where the upstream default is > something else, and then in the next release we can actually look at > axing it. > > > > > It is probably best to start the transition as soon as possible to > > work out any kinks. > > > > In that vein, I'd like to offer my help. Making this type of change > > needs to be done carefully. Perhaps these are questions or concerns. > > I'd like to hear them and respond to them. There is also technical > > work that needs to be done. I'm more of a developer than a packager, > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > help in any way I can. > > Since rpm 4.18 gained the Sequoia support afterall, we can and should > look into swapping over in Fedora 38. That'll help sorting out any rough > edges and make it easier to eventually swap the default in upstream as > well. We probably need to do this with a change process as anything > rpm-related tends to be system/distro wide in a sense (see below) > > Once the dust from 4.18 has settled (final is expected in a couple of > weeks) we can start digging into this, although nothing prevents > starting with other "paperwork" etc. > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > This may well be a blocker on Fedora level, in part to keep container > etc images small but also for distro crypto policies and FIPS (neither > of which nettle supports AIUI). With my Crypto Team hat on I do not see this as a blocker for Fedora in the short term, we can start with nettle and then move to OpenSSL later. For RHEL we may prefer OpenSSL for various reasons above, but I would note that although we do not certify nettle directly under FIPS we do indirectly as part of GnuTLS, so it is certainly tested cryptography. In fact nettle might be a slightly better choice in some cases for container images because it is much smaller than OpenSSL. Finally nettle could even be statically built into sequoia (together with gmp) if we need even smaller footprint or we are concerned about potential rpm breakage during upgrades. I am not saying we want to do this, but it is an option that OpenSSL 3 won't provide as easily. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On Fri, 2022-06-24 at 11:42 +0200, Miro Hrončok wrote: > On 24. 06. 22 11:23, Dmitry Belyavskiy wrote: > > > > > > On Fri, Jun 24, 2022 at 11:20 AM Daniel P. Berrangé > <mailto:berra...@redhat.com>> wrote: > > > > On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote: > > > On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > > > > On 22. 06. 22 21:05, Vipul Siddharth wrote: > > > > > We are going to deprecate openssl1.1 package, stop shipping the > > > > > corresponding devel package, and stop respecting crypto policies > > in > > > > > openssl1.1 package itself. > > > > > > > > +1 to deprecating it > > > > > > > > > > Great! > > > > > > -1 to stop shipping the devel package, this would mean we cannot > > build at > > > > least: > > > > > > > > - Python 2.7 > > > > despite our long term efforts, many things still need that, > > e.g. gimp, > > > > firefox (some builds do, then some don't), thunderbird etc., see > > > > https://fedora.portingdb.xyz/ <https://fedora.portingdb.xyz/> > > > > > > > > Or Python 3.6 (shipped for developers targeting RHEL 7/8). > > > > > > > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we > > please > > > > leave the > > > > devel package? > > > > > > > > > > I'm not sure that if we don't remove the devel package, we will > > provide > > > strong enough motivation to get rid of the deprecating packages. > > > > If the openssl maintainers really strongly want to remove the > > devel pacakge, then don't call this deprecation because that > > is misleading. Call this purging openssl1.1 from the entire > > distro, such that it can only be used by 3rd party apps who > > have previously compiled against older Fedora openssl-devel. > > Be open about fact that this will cause FTBFS for any Fedora > > packages that stil uses openssl1 and their removal from the > > distro if they can't port to openssl3 very quickly. > > > > Do I correctly understand that the situation with Python is the most > > problematic? > > Are we able to solve it somehow? > > > > What I'm afraid of is that if we just declare the deprecation, we will stay > > with this package forever. > > Not forever, just until Python 2.7 is removed :D > > Seriously thou, my proposal is: > > - deprecate it now > - announce it goes away when RHEL 8 maintenance support ends > > Following the guidelines for deprecated packages: > https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ > ># This is when RHEL 8 maintenance support is expected to end ># https://access.redhat.com/support/policy/updates/errata ># The life-cycle time spans and dates are subject to adjustment >Provides: deprecated() = 20290531 > > You are going to support OpenSSL 1.1 in RHEL 8 until that day anyway. > > This is also when we plan to remove Python 3.6: > https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/W74WYEVGYAE57KVLCG73I75LZYKKUMXS/ > > And if Python 2.7 isn't removed by then, we can rip it out together with > OpenSSL 1.1 in Fedora 50. > Are you going to maintain it till Fedora 50 in the meantime? Simo. > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: "The system is going down for suspend NOW!" broadcast messages
On Mon, 2022-04-25 at 16:28 +0200, Petr Pisar wrote: > V Mon, Apr 25, 2022 at 12:54:10PM +0200, Sandro Mani napsal(a): > > Since some recent update (can't pinpoint which exactly), everytime the > > system suspends, it sends a "The system is going down for suspend NOW!" > > broadcast message to all terminals. Any idea anyone how to switch this off? > > (Running up-to-date rawhide). > > > What's wrong with the message? Do you not want to notify all the users of your > system that it will be powered down? On a workstation? No, you already know you are suspending and there is no need to spam terminals, you want them to stay as they are so when yo un-suspend the output is not "corrupted". > This message is emitted by shutdown tool. That tool has --no-wall option to > disable the message. You need to find out what executes that command and then > patch it. It could be e.g. systemd/logind. Is this an upstream change? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Thu, 2022-04-07 at 15:26 -0400, Neal Gompa wrote: > On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce wrote: > > > > On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote: > > > > > > > > > > > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa : > > > > > > > > > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede > > > > > proposed. I think Fedora Server and Fedora Cloud would be interested > > > > > in such a thing, given all the caveats right now with dropping BIOS > > > > > support for server-class hardware. > > > > > > > > As the soul who currently coordinates and moderates the work of the > > > > Server WG, I would be very much in favor of such a SIG as a possible > > > > way out. If it's good enough, that is. > > > > > > > > Just coming up with the idea of removing the (new) installation of such > > > > a central part from one release to the next leaves me speechless. > > > > That's tens of thousands of devices / users affected and we don't even > > > > know how many tens of thousands. And then phrases like "..will remove > > > > it anyway". What else is there to say? > > > > > > > > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We > > > > need a completely different spirit in this area. > > > > > > > > Don’t get me wrong. Lack of resources to maintain something is > > > > completely legitimate. But I expect more open-mindedness and > > > > willingness for constructive alternatives. And none of that is evident > > > > in the Change proposal, nor in the discussion here (by the change > > > > proposal authors). > > > > > > > > And it is OK for me to migrate to UEFI only in the long run. But not > > > > that way. > > > > > > This summarizes my feelings about the proposal very well. > > > > > > We should look to the Xorg → Wayland transition for inspiration: > > > it's long, it's messy, it requires a lot of effort from people doing > > > the work, and it's still not finished. Those are the downsides. But > > > the big upside is that we're not leaving users who need Xorg in the > > > ditch. > > > > > > A similar pattern should be followed here: encourage users to switch, > > > fix bugs so that $new is better than $old in all cases we care about, > > > iterate until the number of users on $old is negligible, > > > *then* announce that $old is not supported, but keep it working, > > > and only after that start cutting off parts of $old. > > > > > > The proposed plan seems to be to jump to the last two steps before the > > > middle parts have been done. Based on the examples posted to this > > > thread, it'd leave our users and developers with 10%–30% of hardware > > > unsupported by the next installer. It also depends on changes that are > > > only *planned* in external projects like VirtualBox and libvirt. > > > > > > Sorry, but the plan needs to be inverted to at least make sure that > > > the UEFI works for all the cloud providers and virtualization software > > > in a testable way, and then switch to UEFI as the default in as many > > > places as possible. Then we can talk about dropping support for BIOS, > > > taking into account how many users are still left with BIOS-only > > > hardware. > > > > FWMOIW this sounds like the most reasonable comment I have seen here. > > > > The plan is nice, it is just trying to get to the end goal too fast, > > more nuanced steps are necessary and more time. > > Too many users would be left behind otherwise. > > > > I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"? For What My Opinion Is Worth :-) > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote: > > > > > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa : > > > > > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede > > > proposed. I think Fedora Server and Fedora Cloud would be interested > > > in such a thing, given all the caveats right now with dropping BIOS > > > support for server-class hardware. > > > > As the soul who currently coordinates and moderates the work of the Server > > WG, I would be very much in favor of such a SIG as a possible way out. If > > it's good enough, that is. > > > > Just coming up with the idea of removing the (new) installation of such a > > central part from one release to the next leaves me speechless. That's tens > > of thousands of devices / users affected and we don't even know how many > > tens of thousands. And then phrases like "..will remove it anyway". What > > else is there to say? > > > > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need > > a completely different spirit in this area. > > > > Don’t get me wrong. Lack of resources to maintain something is completely > > legitimate. But I expect more open-mindedness and willingness for > > constructive alternatives. And none of that is evident in the Change > > proposal, nor in the discussion here (by the change proposal authors). > > > > And it is OK for me to migrate to UEFI only in the long run. But not that > > way. > > This summarizes my feelings about the proposal very well. > > We should look to the Xorg → Wayland transition for inspiration: > it's long, it's messy, it requires a lot of effort from people doing > the work, and it's still not finished. Those are the downsides. But > the big upside is that we're not leaving users who need Xorg in the > ditch. > > A similar pattern should be followed here: encourage users to switch, > fix bugs so that $new is better than $old in all cases we care about, > iterate until the number of users on $old is negligible, > *then* announce that $old is not supported, but keep it working, > and only after that start cutting off parts of $old. > > The proposed plan seems to be to jump to the last two steps before the > middle parts have been done. Based on the examples posted to this > thread, it'd leave our users and developers with 10%–30% of hardware > unsupported by the next installer. It also depends on changes that are > only *planned* in external projects like VirtualBox and libvirt. > > Sorry, but the plan needs to be inverted to at least make sure that > the UEFI works for all the cloud providers and virtualization software > in a testable way, and then switch to UEFI as the default in as many > places as possible. Then we can talk about dropping support for BIOS, > taking into account how many users are still left with BIOS-only > hardware. FWMOIW this sounds like the most reasonable comment I have seen here. The plan is nice, it is just trying to get to the end goal too fast, more nuanced steps are necessary and more time. Too many users would be left behind otherwise. simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Wed, 2022-04-06 at 19:30 -0700, Luya Tshimbalanga wrote: > Reading the comments, it seems the overlooked word is “depreciated” > meaning users will have time to properly transition their hardware. The actual word is "deprecated", but I am pretty sure it applies to HW that is also very depreciated at this point. Sorry could not resist the pun :-) > It seems the proposal suggests an opportunity to revisit the boot-loader > like the heavily downstream patched grub2 deeming too complex to > maintain in long term. Additionally, this proposal gives time to explore > alternative boot loader like systemd-boot (mainly for x86-64 > architecture and useful for desktop and workstation) and rEFi (?) to > further reduce the code burden. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote: > On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy wrote: > > > > On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes wrote: > > > > > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > > > > indicate Apple and Microsoft trust the driver itself. It is trusting > > > > the providence of the blob, in order to achieve an overall safer > > > > ecosystem for their users. > > > > > > > > We either want users with NVIDIA hardware to be inside the Secure Boot > > > > fold or we don't. I want them in the fold *despite* the driver that > > > > needs signing is proprietary. That's a better user experience across > > > > the board, including the security messaging is made consistent. The > > > > existing policy serves no good at all and is double talk. If we really > > > > care about security more than ideological worry, we'd sign the driver. > > > > > > At the very least, it would require that Fedora have a separate key > > > that is trusted and not the same one used for shim/grub/kernel. > > > > If Fedora is going to sign it, rather than improving the local signing > > experience, absolutely it should be signed with a separate key. The > > design should assume a revocation is going to happen at some point. > > > > > We > > > certainly aren't proposing that we use the standard Fedora keys to > > > sign a binary blob that runs in kernel space from a company who was > > > most recently hacked last month? > > > > No way. > > > > I don't think there's a mechanism for it, but I'd prefer Fedora sign > > the 3rd party's key rather than their binary. Maybe it's a small > > distinction at the end of the day. > > > We have not set up an infrastructure for it, but in all honesty, there > is no technical reason that any 3rd party repository building and > packaging the driver could not have done such a thing a couple of > years ago. The mechanism has been there, pesign can sign modules. > Now, asking Fedora to trust that key is a different issue, but users > have to reboot after installing the nvidia drivers anyway, so clicking > to accept the key isn't too much of a hurdle to jump through at that > point. There is potentially an even easier solution. Ideally dkms (or whatever) could simply generate a key, sign the module and manage to get the public key in the right place so that the module can be verified. But this is hard work I guess, and nobody cares about Secure Boot enough to do it? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Support FIDO Device Onboarding (Self-Contained Change proposal)
On Tue, 2022-03-29 at 14:38 +, Peter Robinson wrote: > > > > > Can we get a link to the actual software stack being > > > > > proposed? > > > > > The link in this proposal is a marketing post ... > > > > > > > > Yes, that was an oversight, for reference: > > > > https://github.com/fedora-iot/fido-device-onboard-rs > > > > > > For reference it's under scope where I mentioned the > > > implementation > > > and clearly forgot to add the link. > > > > > > > This is pretty neat! What kind of stuff can be done with this > > onboarding system? > > It's designed to be small and straight forward, do one job securely Where is the security part coming from ? Does this require devices to be pre-registred/pre-seeded with some root of trust? Or is it TOFU ? Or something else? > and succinctly. It's extendable by SIMs (Service Information Modules) > and ATM we have a small set of SIMs to do things like add a > user/ssh-key, add a file and run a command. We'll be adding > functionality like the ability to specify OTA update URLs. > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Support FIDO Device Onboarding (Self-Contained Change proposal)
Can we get a link to the actual software stack being proposed? The link in this proposal is a marketing post ... On Tue, 2022-03-29 at 09:50 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/FIDODeviceOnboarding > > == Summary == > Package and enable the > [https://fidoalliance.org/fido-alliance-creates-new-onboarding-standard-to-secure-internet-of-things-iot/ > FIDO Device Onboarding] software stack for Zero Touch Onboarding on > Fedora IoT. > > == Owner == > * Name: [[User:pbrobinson| Peter Robinson]] > * Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org] > * Name: [[User:runcom| Antonio Murdaca]] > * Email: [mailto:amurd...@redhat.com| amurd...@redhat.com] > > > == Detailed Description == > > The ability for an IoT or Edge device to be plugged in and > automatically onboard itself with zero user interaction is critical to > be able to scale IoT/Edge to millions of devices. To do this in a > secure way with open standards across the industry is even more > critical. The FIDO IoT working group has worked with leaders in the > silicon industry such as Intel and Arm to produce the FIDO Device > onboarding spec which allows a device credential, a root and chain of > trust to ensure the secure onboarding of a device without the need of > stored credentials. > > == Benefit to Fedora == > > The benefit to Fedora is to allow the IoT Edition to demonstrate the > use of leading edge open industry protocols for onboarding IoT and > Edge devices. > > == Scope == > * Proposal owners: > ** Package the rust implementation of the FIDO device onboarding stack > including client, rendezvous service, owner onboarding service and > prototype manufacturing service. > ** Enable the client service by default for IoT Edition > ** Add the client service to the IoT Edition deliverables > > * Other developers: > ** No impact > > * Release engineering: [https://pagure.io/releng/issue/10720 #10720] > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > There is no upgrade impact. FIDO FDO is a single use onboarding > protocol and will not impact existing IoT user systems. > > == How To Test == > > * Test with FDO all-in-one services. Documentation will be available > for testing. > > == User Experience == > > No impact to non IoT Edition users. > > The user experience for the IoT Edition is still evolving and this > will be updated as things fall into place later in Spring and early > Summer 2022. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: Not shipping FDO as a package in Fedora or > including it in the IoT Edition > * Contingency deadline: GA > * Blocks release? No. > * Blocks product? No. > > == Documentation == > N/A (not a System Wide Change) > > == Release Notes == > Fedora IoT Edition supports the FIDO Device Onboarding 1.1 > specification for zero touch onboarding of IoT and Edge devices. > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Problem with SSL in Fedora 36
On Mon, 2022-03-14 at 16:35 +, José Abílio Matos wrote: > On Monday, 14 March 2022 11.04.56 WET Simo Sorce wrote: > > Have you tried setting crypto policies to LEGACY in case the server is > > old and supports only bad cryptography? > > > > Simo. > > How do I do that? > > Running update-crypto-policies always returns an error saying that the > argument is not recognised: > > [root@griffin ~]# update-crypto-policies –-set LEGACY > usage: update-crypto-policies.py [-h] [--set [POLICY] | --show | --is-applied > > --check] [--no-reload] > update-crypto-policies.py: error: unrecognized arguments: –-set LEGACY > [root@griffin ~]# update-crypto-policies –-show > usage: update-crypto-policies.py [-h] [--set [POLICY] | --show | --is-applied > > --check] [--no-reload] > update-crypto-policies.py: error: unrecognized arguments: –-show > [root@griffin ~]# update-crypto-policies –-check > usage: update-crypto-policies.py [-h] [--set [POLICY] | --show | --is-applied > > --check] [--no-reload] > update-crypto-policies.py: error: unrecognized arguments: –-check > > What am I missing? If you have actually copy/pasted from the terminal it looks to me you used an incorrect character when trying to pass a long option, at least my MUA shows me you prepend long option names with "–-" instead of using the correct "--", maybe your terminal uses the same glyph to represent to different characters? Simo. > > Regards, > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Problem with SSL in Fedora 36
Have you tried setting crypto policies to LEGACY in case the server is old and supports only bad cryptography? Simo. On Sun, 2022-03-13 at 09:43 +, José Abílio Matos wrote: > In one, and just one, of my email accounts the upgrade to F36 failed with > this: > > The underlying socket is having troubles when processing connection to > imap.xxx.xx.xx:993: Error during SSL handshake: error:0A0C0103:SSL > routines::internal error > > No email program works, I tried kmail, trojitá, thunderbird. The connection > fails immediatelly with the above error. > > Where should I fill this report, under openssl? > > Searching a bit this seems related to: > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > Regards, > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: RHEL moving to issues.redhat.com only long term
On Sat, 2022-03-12 at 10:15 +0100, Florian Weimer wrote: > * Simo Sorce: > > > On Fri, 2022-03-11 at 13:52 +, Peter Robinson wrote: > > > > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters > > > > wrote: > > > > > Long term if Bugzilla slowly morphs into only being used by > > > > > Fedora, > > > > > personally I'd prefer to have bugs/issues in gitlab instead. > > > > > > > > Yes, I personally think gitlab.com would be a good replacement for > > > > src.fedoraproject.org and bugzilla.redhat.com. > > > > > > I disagree as the interface for agile development like sprints, > > > kanban > > > and other team tools is rudimentary at best and really not suitable > > > for anything more than the basics and is not a patch on the > > > functionality and plugin ecosystem that is available in Jira. The > > > gitlab functionality there is a toy in comparison. > > > Bugzilla has no support for any sprints or kanban at all, so I do not > > see how this is relevant. > > These features are disabled for the Fedora product in > bugzilla.redhat.com, but the code is there. Perhaps you have different > views what tool support for these processes should look like? This was exactly my point, Fedora does not use sprints/kanban with bugzilla now, so it does not seem like a fair comment to complain that another bug tracker proposed as replacement does not have them either, unless suddenly there is a need for them (I personally see no need to have a fedora specific sprint/kanban system). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: RHEL moving to issues.redhat.com only long term
On Fri, 2022-03-11 at 13:52 +, Peter Robinson wrote: > > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters > > wrote: > > > Long term if Bugzilla slowly morphs into only being used by > > > Fedora, > > > personally I'd prefer to have bugs/issues in gitlab instead. > > > > Yes, I personally think gitlab.com would be a good replacement for > > src.fedoraproject.org and bugzilla.redhat.com. > > I disagree as the interface for agile development like sprints, > kanban > and other team tools is rudimentary at best and really not suitable > for anything more than the basics and is not a patch on the > functionality and plugin ecosystem that is available in Jira. The > gitlab functionality there is a toy in comparison. Peter, Bugzilla has no support for any sprints or kanban at all, so I do not see how this is relevant. Unless your claim is that Fedora absolutely needs a sprint/kanban based organizational tool which would surprise me. I personally do not think Fedora should tie itself to Red Hat's Jira. For community oriented development Jira is simply not a great tool IMO, because it is built with a "traditional" organization in mind, not for community use. Keeping it simple is actually an existential requirement for Fedora where we have so many drive-by volunteers. Complex on-boarding becomes quickly an impenetrable barrier to participation. This is another reason I think common forges issue systems, while limited are a better fit for community issue reporting than either Bugzilla or Jira, because they are simple and immediately available. You can easily write automation to pull in/mirror issues into your own Jira projects if that's what you use for work and feel the need for, IMO. And just to be clear I am both a *heavy* Jira and Bugzilla user (including writing automation for both and other stuff via bots) for work, so I think I can say I know what I am talking about. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: RHEL moving to issues.redhat.com only long term
On Thu, 2022-03-10 at 19:28 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote: > [...] > > Also I always resented that I need two separate accounts to deal with > > Fedora packages, > > It's been possible to log in with FAS credentials (automatically if you > have an active Kerberos ticket) into bugzilla for quite some time now. > I still have my old bugzilla account but I'm not sure it's required > anymore. Ah thanks, I missed that change, obviously my experience is now almost 2 decades long since I had to create my account, but I still think that having bugs and code in the same place is a big win for a project like Fedora, it is the same model followed by most upstream projects at this point and seem to be working well. > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: RHEL moving to issues.redhat.com only long term
On Thu, 2022-03-10 at 09:44 -0500, Colin Walters wrote: > > On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux > > release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > I think it's unfortunate to replace the FOSS Bugzilla with > proprietary software. I am eternally conflicted about this with > respect to GitHub (xref > https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is > not as compelling of a user experience upgrade. > > A continual challenge related to this I feel is using the same > software to track product bugs with potentially sensitive customer > data in it, and public open development. > > To link these things, I quite commonly move Bugzilla discussion that > has no need to be private to Github, because I know Github is always > public (from our PoV). > > One thing that may help is to at least use different themes (e.g. > blue colors for public CentOS issues, red for RHEL?) on > issues.redhat.com. > > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. Given how we use bugzilla (we do not really use any big feature there) in Fedora I would give a big +1 to use an issue tracker embedded in the forge we use to store the packages (whether that is pagure, gitlab, github, or something else). Also I always resented that I need two separate accounts to deal with Fedora packages, I think reducing that to host all in the same place with the same authentication will also be a positive factor in fostering collaboration, less barriers. It will also reduce administrative overhead of having to configure components/ownership/etc in multiple places and what not. Finally by having issues and code in the same place it means we can easily connect commits/PRs/MRs to the issues meaning our issue tracker a lot more useful, and will allow us to have better content also in our updates, where today associating an update to an issue (a bz) is not happening as well as it could. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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)
On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > That sounds like a terrible plan. We should make newer hashes > the default, and we can make tools print a warning if sha1 is used > where it shouldn't, but please don't break things on purpose. > > For many many things sha1 is just fine. Just like md5 or even > crc32. Not everything is about cryptographic security. I would like to make it clear that this is just for *Cryptographic Signatures*, this is not a plan to block SHA-1 for all uses. And for Cryptographic Signatures everything is about cryptography and SHA-1 is not safe anymore. And to be extra clear this means: Certificates, TLS session setup, DNSSEC (although a lot of signatures are still SHA-1 based there ...), VPNs session establishment, PGP, etc... > Also, users will want to verify old signatures essentially forever. This is only reasonable for stuff like emails, where you may have a reasonable expectation that the archived messages have not been tampered with after the fact. Allowing verification of signatures with SHA-1 for any "online" communication would be pointless. > This should be always possible. And finally, the world is huge, > and other users will provide sha1 signatures no matter what we do, > and it is better to check those than to completely ignore them. We need to move the needle at some point. We will be able to set LEGACY crypto policies to allow SHA-1 verification, but we need to be First and Secure here as well. Simo. > > Zbyszek > > (This is a bit like browsers disliking self-signed certs and http:// > — it certainly is OK to make users aware of the issue, but actually > disallowing those is terribly annoying and will only result in users > jumping to different tools.) > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote: > On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi wrote: > > > > So, I'll go ahead and be a bad guy here: > > > > Perhaps it's time to just retire i686 completely? > > > > Steam is available as a flatpak, and old software thats 32bit only and > > can't be rebuilt could just be run from a f36 container? > > > > This would save us: > > > > * all the builder resources > > * all the multilib calculation time/space in composes > > > > If we don't want to retire it now, when will we? > > I have considered this option, but I don't think we can do that yet. > > For example, as far as I know, you need the 32-bit host libraries for > running 32-bit Windows applications in Wine. > Dropping that would make our Wine packages almost useless, since a > large fraction of Windows software still isn't 64-bit. > > But I could be wrong. And if we indeed don't need wine.i686 to run > 32-bit Windows apps, retiring i686 entirely would be an option, I > agree. > (I myself am using the Steam flatpak you mentioned. It works well, and > I don't need 32-bit libs on my host system at all, which is nice.) Wouldn't wine problem be solved by providing the 32bit version as a flatpak if still needed for some corner cases? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
On Thu, 2022-02-10 at 16:57 -0500, Ben Cotton wrote: > On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > since you have the script handy, could you check how many (non-pp) > > packagers would be reported as inactive pretty please? Maybe with the > > inactivility threshold raised to 1 year instead of 0.5 y. > > I had to run it a second time with the listing disabled because the > first time the output was too long for my terminal's scrollback. :-) > > But! Of 2453 packagers, 1514 have not submitted a Koji build since at > least 2021-02-11. 1311 of those have not submitted a Koji build since > at least 2020-02-06. An additional 113 do not exist in Koji. > > > I think that if we disabled completely inactive accounts after a year > > or two, this would be reasonable from security perspective. There are > > many many packages which are now maintained by other people so packagers > > can effectively maintain co-ownership without committing to a package > > for years. > > I have concerns with this approach. I would guess there's a long tail > of packagers that maintain relatively few packages. These packages > might not have frequent upstream releases or require new manual > builds. Someone who hasn't needed to build a package in 13 months may > still be active in other ways and it would be hostile to strip them of > packager permission in that case. We'd want to be very careful about > how we define "active" (which is a thorny question project-wide that > we don't have a great answer for). We'd also want to give people the > chance to say "no, I'm still here", which makes this a fairly manual > process. If we were to automate it, we absolutely should have a > trivial way for people to regain packager status (i.e. not have to get > re-sponsored, etc). > > I would support removing the 113 who don't exist in Koji. And maybe > any packagers without a build over an exceedingly long period of time > (say 5 years?) as a starting point. Some may be backups for others, and do not normally create builds but collaborate to the maintenance via patches. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Package notes feature causing build paths to be embedded
On Thu, 2022-02-03 at 22:02 +, Luca Boccassi wrote: > > On 03. 02. 22 16:36, Simo Sorce wrote: > > > > I've just tried to build python-gssapi with notes enabled after > > krb5 was fixed > > and it builds fine. > > > > See https://src.fedoraproject.org/rpms/python-gssapi/pull-request/4 Nice! Especially the auto build deps, which I tried to enable but was failing for me, so I ended up reverting that change. > It looks like it's not the first time that krb5-config causes issues > because it picks up state from the build env: > > https://bugzilla.redhat.com/show_bug.cgi?id=1997021 > https://bugzilla.redhat.com/show_bug.cgi?id=1204646 > https://krbdev.mit.edu/rt/Ticket/Display.html?id=8159 > > We had similar problems long ago with libpcap's own tool, before the > project made available a pkg-config file, which is much simpler and > nicer (and doesn't fall apart when cross-compiling). Is there any > reason to keep using these specialized binaries over pkg-config these > days? Or is it just a matter of doing the work to gradually switch > over? The latter, but it needs to happen in upstream and needs to take in account that pkg-config is not available in all architectures, so it is hard to sell, as it makes he code more complicate to preserve both mechanism. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Package notes feature causing build paths to be embedded
On Thu, 2022-02-03 at 16:22 +0100, Petr Pisar wrote: > V Thu, Feb 03, 2022 at 09:26:09AM -0500, Simo Sorce napsal(a): > > On Thu, 2022-02-03 at 15:15 +0100, Petr Pisar wrote: > > > V Thu, Feb 03, 2022 at 08:56:20AM -0500, Simo Sorce napsal(a): > > > > On Thu, 2022-02-03 at 10:09 +0100, Florian Weimer wrote: > > > > > * Richard W. M. Jones: > > > > > > > > > > > Thinking about this a bit more, the implementation of this feature > > > > > > simply seems to be wrong. RPM already has a final stage where it > > > > > > strips ELF files and builds debuginfo. Why wasn't the addition of > > > > > > package notes done there? > > > > > > > > > > The package notes are in an allocatable section, to be mapped at run > > > > > time, so that they end up in core files. As far as I know, it's not > > > > > reliably possible to add such data to an ELF file after the final > > > > > (non-relocatable) link. > > > > > > > > > > We would have to pre-allocate some fixed space and fill it in later. > > > > > > > > > > Cleaner approaches are possible if we teach the core dumper how to > > > > > copy > > > > > select data from non-allocated sections. I think we would then need > > > > > just a placeholder program header. > > > > > > > > While it is nice to discuss future options, do we have a way to fix > > > > FTBFS's in rawhide _now_ ? > > > > > > > You can disable embedding the package notes by undefining > > > _package_note_file > > > macro in the package which builds in the linker flags. See > > > <https://src.fedoraproject.org/rpms/perl/c/4751b01e52fad1ef9c3012675791d979436ff8fe.patch> > > > for an example. Kudos to Jitka. > > > > No I could not, because I still got the dependent krb5 package to bring > > in another unavailable linker script. > > > > FTR we resolved this by rebuilding krb5-libs *without* notes, and then > > I could rebuild python-gssapi also without notes. > > > > However I resent a bit that I had to chase down this problem myself, > > days after it had already been exposed, and basically manually disable > > this feature for a large part of Fedora (anything that links to krb5 > > now is missing these notes, rights?) > > No. krb5-libs will miss its notes. But python-gssapi will contain its correct > notes. (Provided python-gssapi links to krb5-libs dynamically. I don't know > whether the notes only record a source package name the ELF file belongs to, > or whether they try to track origin of all object files the ELF consists of.) I had to undefine notes on python-gssapi as well, so not notes, period. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Package notes feature causing build paths to be embedded
On Thu, 2022-02-03 at 15:15 +0100, Petr Pisar wrote: > V Thu, Feb 03, 2022 at 08:56:20AM -0500, Simo Sorce napsal(a): > > On Thu, 2022-02-03 at 10:09 +0100, Florian Weimer wrote: > > > * Richard W. M. Jones: > > > > > > > Thinking about this a bit more, the implementation of this feature > > > > simply seems to be wrong. RPM already has a final stage where it > > > > strips ELF files and builds debuginfo. Why wasn't the addition of > > > > package notes done there? > > > > > > The package notes are in an allocatable section, to be mapped at run > > > time, so that they end up in core files. As far as I know, it's not > > > reliably possible to add such data to an ELF file after the final > > > (non-relocatable) link. > > > > > > We would have to pre-allocate some fixed space and fill it in later. > > > > > > Cleaner approaches are possible if we teach the core dumper how to copy > > > select data from non-allocated sections. I think we would then need > > > just a placeholder program header. > > > > While it is nice to discuss future options, do we have a way to fix > > FTBFS's in rawhide _now_ ? > > > You can disable embedding the package notes by undefining _package_note_file > macro in the package which builds in the linker flags. See > <https://src.fedoraproject.org/rpms/perl/c/4751b01e52fad1ef9c3012675791d979436ff8fe.patch> > for an example. Kudos to Jitka. No I could not, because I still got the dependent krb5 package to bring in another unavailable linker script. FTR we resolved this by rebuilding krb5-libs *without* notes, and then I could rebuild python-gssapi also without notes. However I resent a bit that I had to chase down this problem myself, days after it had already been exposed, and basically manually disable this feature for a large part of Fedora (anything that links to krb5 now is missing these notes, rights?) only relying on hearsay and some brave soul giving tips. It is also now littering spec files with disablement of this feature, which will make it harder to re-introduce it once these problems are solved (or will cause abandonment of the feature, with fragments of unused spec files all over the place). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Package notes feature causing build paths to be embedded
On Thu, 2022-02-03 at 10:09 +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > Thinking about this a bit more, the implementation of this feature > > simply seems to be wrong. RPM already has a final stage where it > > strips ELF files and builds debuginfo. Why wasn't the addition of > > package notes done there? > > The package notes are in an allocatable section, to be mapped at run > time, so that they end up in core files. As far as I know, it's not > reliably possible to add such data to an ELF file after the final > (non-relocatable) link. > > We would have to pre-allocate some fixed space and fill it in later. > > Cleaner approaches are possible if we teach the core dumper how to copy > select data from non-allocated sections. I think we would then need > just a placeholder program header. While it is nice to discuss future options, do we have a way to fix FTBFS's in rawhide _now_ ? My time is limited and I want to upgrade one of my packages and this is blocking me. Is opening a FESCO ticket the only way ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Package notes issues with python wheel building
So I got this bug about FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2049643 These are bindings to C libs and use gcc to build .so files. Upon investigation the issue is that the default linker flags seem to point to non existing package note files, so the build fails. It was suggest to disable notes for this package via: %undefine _package_note_file However this just changed the error from a linker script named against the python package to a linker script named against the krb5 dependency. This is what I get in a scratch build: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note-krb5-1.19.2-4.fc36.1.x86_64.ld: No such file or directory How do I solve this? I need to update to a new version of python-gssapi but I cvan't build it right now. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 22:17 +, Zbigniew Jędrzejewski-Szmek wrote: > Since auditd is started by systemd, you just _have_ to trust systemd. > If control over the manager is lost, the manager can just do anything > it wants, masquerading as any user. So the logging provided by recording > of the direct signal is only a "good will" effort, fairly easy to spoof > if you've actually gained some inappropriate privileges. The logging > that systemd does is effectively just as trustworthy as the audit log > as long as the system integrity is maintained. I think this is really a key point TBH. Auditd trusts the kernel to behave correctly, and I think all problems could be solved by also trusting systemd-init to provide correct info. At the point auditd would simply trust the uids systemd can pull via scm credentials or some dedicated kernel facility if more is needed and get over the "dbus steals my knowledge" issue. Steve, what would it take for auditd to trust systemd's information? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 20:09 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 06, 2022 at 01:55:50PM -0500, Steve Grubb wrote: > > Hello, > > > > On Thursday, January 6, 2022 1:02:36 PM EST Zbigniew Jędrzejewski-Szmek > > wrote: > > > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote: > > > > On Thu, 2022-01-06 at 16:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > I know that you said that the scripts are needed because of "magic > > > > > stuff™" that the scripts do, but sorry, that's not a justification: > > > > It is the justification. The audit system has regulatory requirements > > imposed > > on it. This is required by common criteria and subsequently depended on for > > PCI-DSS, CIS, DISA STIG, NIST risk management framework, and many other > > security or regulatory schemes. > > > > > > > > > *everything* that can be done using a shell script can also be > > > > > reimplemented independently. Right now audit pulls in the whole > > > > > initscripts stack, this should all be replaced by some small helper. > > > > I moved it to initscripts-service in rawhide. > > > > > > > (Maybe a separate binary, or a small shell script, or maybe something > > > > > in auditctl…. I don't know because I don't know audit.)> > > > > It would be better if there was a systemctl solution. Any solution I > > implement will be met with you need to migrate to systemctl. There have > > been > > multiple bz opened and closed on this. > > > > > > As I understand the bug, it's not a question of whether the thing can > > > > be done, but whether it can be known *who did it*. > > > > Exactly. And "who" means login uid, pid, and their security label. You can > > only get this if the signal is sent from the user's context. > > > > > There is no magic functionality in the kernel that specifically records > > > that something was executed by some specific script. > > > > There actually is magic in the kernel that records who sent a signal to the > > audit daemon and the necessary atributes. This functionality has been > > there > > since at least 2005. It's not new. > > Right, so is /usr/bin/stop-audit with the following contents the solution: > --- > #!/bin/sh > set -e > exec kill $(systemctl show -P MainPID auditd) > --- > ? I do not believe this is currently usable for audit because the information on who requested to kill the process is lost this way. In terms of audit you can audit that user XYZ ran /usr/bin/stop-audit, however the process that actually then kills the audit daemon will not have the magic markers in the kernel side and will instead be the systemd process. This breaks the audit log chain, as there is no way to audit that systemd is operating on behalf of that user. The audit trail chain is broken by the systemcl -> systemd jump. This is the problem that need to be solved to get rid of audit's use of shell scripts that directly perform operations wrt the kernel. I wonder if another option is to have the audit code in the kernel intercept systemcl messages sent to systemd and interpret the commands and log what they are asking ... Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 20:01 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 06, 2022 at 01:17:01PM -0500, Simo Sorce wrote: > > On Thu, 2022-01-06 at 18:02 +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote: > > > > On Thu, 2022-01-06 at 16:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > > I know that you said that the scripts are needed because of "magic > > > > > stuff™" > > > > > that the scripts do, but sorry, that's not a justification: > > > > > *everything* that > > > > > can be done using a shell script can also be reimplemented > > > > > independently. > > > > > Right now audit pulls in the whole initscripts stack, this should all > > > > > be replaced > > > > > by some small helper. (Maybe a separate binary, or a small shell > > > > > script, or > > > > > maybe something in auditctl…. I don't know because I don't know > > > > > audit.) > > > > > > > > As I understand the bug, it's not a question of whether the thing can > > > > be done, but whether it can be known *who did it*. > > > > > > There is no magic functionality in the kernel that specifically records > > > that > > > something was executed by some specific script. If that scripts sends a > > > signal > > > somewhere, you can send the same signal with the same sender info and the > > > same privileges > > > using bash/python/C/Rust or even assembly. So the "who did it" information > > > can be provided in a different way without pulling in the initscripts > > > stack, > > > or it is bogus, or maybe even both. > > > > In this case the "who" is the user, not the script. > > Yes, obviously the user is outside of the machine and "user" always > means some program running under the UID assigned to the user. > All I'm trying to say is that if you can make one implementation of this > program (e.g. a set of bash scripts) send some bit of information, you can > make another implementation send the same signal. > > > The problem of going through systemctl is that the "who" is lost > > because all the audit system can see is that systemd started the > > action. Basically the communication between systemctl and systemd masks > > the identity of the user that initiated the action. > > Yes, systemctl doesn't save this information. So audit uses some > alternative command to send this information somewhere. This > alternative command should just send this bit of information where appropriate > and then call systemctl. More-or-less as things are now, but without > the initscripts baggage. I believe the problem is that it is not just a fire and forget signal, any kernel syscall can be traced back to that user by this method, so anything the "scripts" do can be audited. > > I believe a solution needs to be found between systemd and the audit > > subsystem in general so that we remove this whole class of issues > > altogether. > > If there's a need to add something to systemctl or systemd, we can do > it. But it's never been clearly articulated afaik. I am afraid the hurdle, so far, is that there is a belief that the only way to get valid audit logs when systemd-init is involved is to trust the whole of it, which would require the development of a whole trusted audit subsystem/hand-off within systemd. I think that potentially one option would be to provide a kernel audit API that systemd could be trusted to use to set the user ids so that the audit subsystem is given those when there is the systemctl -> systemd hand-off. But that requires the audit and systemd teams to agree on what that trust and those controls means, and figure out how to comply to all regulations in the process of adding this stuff. This is probably no small feat. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 18:02 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote: > > On Thu, 2022-01-06 at 16:16 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > I know that you said that the scripts are needed because of "magic stuff™" > > > that the scripts do, but sorry, that's not a justification: *everything* > > > that > > > can be done using a shell script can also be reimplemented independently. > > > Right now audit pulls in the whole initscripts stack, this should all be > > > replaced > > > by some small helper. (Maybe a separate binary, or a small shell script, > > > or > > > maybe something in auditctl…. I don't know because I don't know audit.) > > > > As I understand the bug, it's not a question of whether the thing can > > be done, but whether it can be known *who did it*. > > There is no magic functionality in the kernel that specifically records that > something was executed by some specific script. If that scripts sends a signal > somewhere, you can send the same signal with the same sender info and the > same privileges > using bash/python/C/Rust or even assembly. So the "who did it" information > can be provided in a different way without pulling in the initscripts stack, > or it is bogus, or maybe even both. In this case the "who" is the user, not the script. The problem of going through systemctl is that the "who" is lost because all the audit system can see is that systemd started the action. Basically the communication between systemctl and systemd masks the identity of the user that initiated the action. I believe a solution needs to be found between systemd and the audit subsystem in general so that we remove this whole class of issues altogether. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: IMA signing questions
On Thu, 2022-01-06 at 10:16 +, Patrick マルタインアンドレアス Uiterwijk
wrote:
> Hi Ken,
>
> >
> > I want to add "intro to IMA signing" instructions to
> > https://docs.pagure.org/koji/signing/ . I wrote a basic PR at
> > https://pagure.io/koji/pull-request/3206 but it lacks technical
> > details.
>
> That'd be cool!
>
> >
> > - How do I generate my own new keypair so I can IMA-sign an RPM?
>
> You can generate the key with the standard OpenSSL commands.
> For example, an RSA key can be generated like:
> openssl genrsa | openssl pkcs8 -topk8 -nocrypt -outform DER -out
> privatekey.der
Just a heads-up that genrsa is deprecated and genpkey -algorithm RSA
(or better RSA-PSS) should be used instead (genrsa will simply fail in
FIPS mode for example).
Simo.
> (do note that the key will need to be in DER format).
>
> You can then generate a corresponding (self-signed) certificate for
> validation with:
>
> openssl req -x509 -key privatekey.der -out certificate.pem -days 365 -keyform
> DER
>
> >
> > - Can I use my existing GPG keypair?
>
> Mathematically, yes. Practically, no.
> The key format RPM (libimaevm) reads for signing is DER, so you'd have to
> convert the actual key bits from the GPG format to DER.
>
> >
> > - How do I IMA-sign files in an RPM locally (apart from Koji)? (Is it
> > the --signfiles option from rpmsign(8)?)
>
> Yes, it's the --signfiles option.
>
> >
> > - How do I inspect the IMA signatures on an existing RPM?
>
> The signatures are stored in the FILESIGNATURES rpm sighdr (with tag
> RPMTAG_SIG_BASE + 18, so 274), as a hex-encoded string array.
> I have some code for reading and parsing the signatures at
> https://github.com/fedora-iot/rpm-head-signing/blob/main/rpm_head_signing/extract_rpm_with_filesigs.py
> .
>
> >
> > - When I gpg-sign an RPM with "Key A" and IMA-sign an RPM with "Key
> > B", does Koji "know" about Key B at all?
>
> Koji at this moment does not look at or touch the FILESIGNATURES header.
> It copies it into its signature store (because the tag is in the sighdr), and
> will re-insert it into the resulting RPM, but it has no clue it's even there.
> This also means that the RPMs that are signed with {rpm_key=keyA,
> ima_key=keyB} and {rpm_key=keyA, ima_key=keyC} are seen as having the same
> signature, and thus would result in the hub rejecting the new signature until
> the old one gets removed.
> It would absolutely be useful to have this information also stored in koji
> and a part of the index for the signatures, but that hasn't been done yet.
>
> Patrick
> ___
> 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
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
___
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: cmake on Rawhide is broken
On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote: > On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote: > > On 03/12/2021 17:41, Miro Hrončok wrote: > > > > > The bundled openssl in opae worries me still, but that's not causing > > > issues in dependency resolution any more. > > > > I think FESCo should create a strict policy on bundling cryptographic > > libraries. > > Well bundling a binary from upstream is already against policy > so I don't see how that helps. > > The problem isn't a lack of policy, it's that the packager didn't > notice those files or didn't realise they weren't allowed. So the opae-2.0.0 tarball has libcrypto embedded-in what is the process now ? This stuff is used for a Python tool that is used to sign some binary, almost certainly there is absolutely no reason to bundle libcrypto, the tool should probably be unbundled and turned into a regular python module opae depends on. Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ... Simo. > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
On Tue, 2021-11-30 at 15:57 -0800, Adam Williamson wrote: > On Tue, 2021-11-30 at 22:39 +, Sérgio Basto wrote: > > On Tue, 2021-11-30 at 16:03 -0500, Matthew Miller wrote: > > > On Tue, Nov 30, 2021 at 11:13:19AM +, Sérgio Basto wrote: > > > > I don't use sudo , and I'm against the use of sudo , Fedora > > > > tradition > > > > do things as root . > > > > > > I hope we don't! Doing things with least required privilege is an > > > important > > > security principle, one which was actually pioneered here with the > > > usermode/consolehelper tools and then policykit and dbus helpers for > > > GUI > > > applications. And we've been putting people in `wheel` by default and > > > configuring sudo in the corresponding way since... F15, I think. > > > > yes , I mean be administrator with sudo (more than like in Debian, is > > like in Ubuntu) and do commands like `sudo dnf` I guess . > > As subject says "Users are administrators" and use sudo to execute all > > kind of administration, I prefer do `su -` and execute the commands, > > that what I meant by "I don't use sudo" . > > You know you can just do "sudo su" if you prefer that style, right? I use "sudo -i" all the time ... "sudo su" is a bit of a waste ... > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: deltarpm usefulness?
On Sat, 2021-11-06 at 07:43 +, Daniel Alley wrote: > > On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski- > > Górecki wrote: > > I do think we should drop drpms or make them more useful, but I > > don't > > think there's any security angle here. (see below) > > > > drpms work by downloading the delta, then using it + the version > > you > > have installed to recreate the signed rpm (just like you downloaded > > the > > full signed update) and then the gpg signature is checked of that > > full rpm, > > just like one you downloaded. If the drpm is tampered with it won't > > reassemble and it will fall back to the full signed rpm. > > Sorry to resurrect this thread. > > Another issue - which is not per-se a security issue but it's still a > problem - is that deltarpm uses md5 checksums pervasively. They're > everywhere. And it uses its own implementation of md5 which doesn't > respect FIPS, so even when the user has *explicitly* configured their > system to not use md5 for anything security-relevant, libdeltarpm > won't know or care. md5 used as a checksum to only detect network transmission issues is not a problem, and is not under the purview of the FIPS certification. As mentioned above the actual packages are still finally reassembled and the signature checked, so that is what matters in terms of security (those algorithms and computations need to be FIPS approved and the implementation certified). HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: openswan/libreswan VPNs and NetworkManager
On Tue, 2021-11-02 at 13:15 +0100, Petr Pisar wrote:
> V Tue, Nov 02, 2021 at 09:46:28AM +, Mattia Verga via devel napsal(a):
> > I was trying to set up a VPN to my work company network. It seems I need
> > to use IPSec XAuth PSK, so I found some guide in internet that says to
> > set up a libreswan VPN.
> > I'm facing several problems, first of all I'm using Plasma KDE which
> > seems to not have a GUI for setup/editing libreswan VPNs. Plasma-nm only
> > has support for openswan. I've reported that upstream and downstream. So
> > I went setting up the VPN through nmcli: it doesn't work, but that's not
> > my point here.
> >
> > I was wondering how both plasma-nm and nmcli allow to setup an openswan
> > VPN since openswan has been retired in Fedora many years ago... it also
> > seems to work (well, in some way, since the connection fails) even if
> > there's no NM plugin or openswan package installed.
> > How is it possible? Does NM bundles some openswan library itself? If so,
> > is it updated (latest Fedora openswan build was 8 years ago) or there
> > may be any security concern?
> >
> An explanation is that you mistaken IPsec as a protocol and Openswan as an
> implementation of the protocol. There are multiple implementations of IPsec.
> E.g. in Fedora we have Strongswan and Libreswan. And NetworkManager plugins
> for both of them:
>
> # dnf repoquery --qf '%{name} %{summary}' |grep IPsec
> NetworkManager-l2tp NetworkManager VPN plugin for L2TP and L2TP/IPsec
> NetworkManager-l2tp-gnome NetworkManager VPN plugin for L2TP and L2TP/IPsec -
> GNOME files
> NetworkManager-libreswan NetworkManager VPN plug-in for IPsec VPN
> ike-scan IKE protocol tool to discover, fingerprint and test IPsec VPN servers
> libreswan Internet Key Exchange (IKEv1 and IKEv2) implementation for IPsec
> openvswitch-ipsec Open vSwitch IPsec tunneling support
> strongswan An OpenSource IPsec-based VPN and TNC solution
>
> So the answer is that nmcli in Fedora does use Openswan. It uses Strongswan or
> Libreswan.
Petr,
your message comes back quite unclear.
I think what you mean is that because there were multiple related
implementations of IPsec all derived by the same old project that NM
decided to support them all under the name "openswan", but it is
compatible also with configuring libreswan and strongswan which were
forks of this project in the past and then developed independently.
Just to be clear, IPsec *is* a protocol, and Openswan *is* an
implementation, it's just the NM treat all of these implementation the
same and handles them all with a single plugin.
It's be nice if NM renamed it's plugin to something that just uses the
name IPsec, it would avoid a lot of confusion.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
___
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: Drop NIS(+) support from PAM (System-Wide Change proposal)
On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote: > Stephen John Smoogen writes: > > > Mainly because it is the authentication service equivalent of > > telnet**. Very simple to set up, very simple to use, and very easy to > > steal all the information about logins, users, and setups. [...] > > ... well, compared to what? LDAP commonly distributes crypttext > passwords and databases with about the same amount of discernment and > theft-enablement as ypserv. Plaintext as in telnet makes an appearance > nowhere but with yppasswd, AFAIK, which is nonessential. LDAP is normally deployed on a secure channel (TLS or GSSAPI), that the client can cryptographically check. NIS is a clear text protocol that can be trivially MitMed to provide arbitrary information to the target system. Also generally LDAP *does not* in fact distribute passwords, most systems use the LDAP Bind operation to test a password and the LDAP server does *not* provide access to password hashes. I thin k it is legitimate to question whether it is yet time to drop this obsolete protocol (NIS) on backwards compatibility grounds. But on security grounds it is indefensible, don't go there. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: crypto-policies and a certain usage of SHA-1
On Fri, 2021-10-15 at 10:33 -0500, Michael Catanzaro wrote: > On Fri, Oct 15 2021 at 10:10:38 AM +0200, Björn Persson > wrote: > > My question is: Is it true that this usage of SHA-1 makes the TLS > > session weak, so that it's correct to forbid it in the crypto policy? > > Hm, I think Fedora's crypto policy should not be stricter than upstream > Firefox. This should probably be allowed. > > Enterprise distros are intentionally trying to be stricter and > completely remove SHA-1, but Fedora is not an enterprise distro and > breaking websites that work fine everywhere else is not OK for Fedora. > > > Or could it be that Qualys is right? Perhaps SHA-1 is fine for this > > use > > case, even though it's too weak for other use cases, and the crypto > > policy should allow it? > > SHA-1 is blocked in certificate signatures because those can be > attacked offline. Signatures in the TLS handshake are entirely > different. I'm hardly an expert, but I think the attacker only has a > few seconds to generate a hash collision before the user gives up and > closes the browser tab. Spending several months trying to find a > collision is not an option here. Am I wrong? Session keys are important not just for MiTM attacks, but also for store and decrypt attacks. TLS connections often channel a host of important private information that can be quite valuable even weeks or years after they are transmitted, including credentials. A weak session key will allow store and later decryption of communications, therefore retrieval of sensitive data. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Boot menu always displayed again?
FYI: I recreated the file anyway and it works now. The difference seem to be that there is a new second comment line at the top of the file about not modifying it. Was the format changed and no update scriplet provided at some point ? Simo. On Wed, 2021-09-08 at 15:23 +0200, Petr Pisar wrote: > V Wed, Sep 08, 2021 at 09:01:42AM -0400, Simo Sorce napsal(a): > > If I try to do this I get an error: > > # grub2-editenv - set menu_auto_hide=1 > > grub2-editenv: error: environment block too small. > > > > What the issue here ? > > Perhaps /boot/grub2/grubenv is corrupted and grub2-editenv is not very good at > reporting errors. This happens when the file was accidentally truncated. Does > it have 1024-byte size? > > If it does not, back up the file and reinitilize it with > "grub2-editenv - create" and then insert the original values with > "grub2-editenv - set ...". If you don't have UEFI system, you will need to > reistall grub in MBR to locate the new file's position on a block device and > write the position into the newly installed loader. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Donate 1 minute of your time to test upgrades from F34 to F35
On Tue, 2021-09-07 at 18:14 +0200, Miroslav Suchý wrote: > Do you want to make Fedora 35 better? Please spend 1 minute of your time and > try to run: > > # Run this only if you use default Fedora modules > # next time you run any DNF command default modules will be enabled again > sudo dnf module reset '*' > > sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \ > > --enablerepo=updates-testing --enablerepo=updates-testing-modular \ > > distro-sync > > This command does not replace `dnf system-upgrade`, but it will reveal > potential problems. > > You may also run `dnf upgrade` before running this command. > > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the actual upgrade. > > But very likely you get some dependency problem now. In that case, please > report it against the appropriate package. > > Or against fedora-obsolete-packages if that package should be removed in > Fedora 35. Please check existing reports against > > fedora-obsolete-packages first: > > https://red.ht/2kuBDPu > > > and also there is already bunch of "Fails to install" (F35FailsToInstall) > reports: > > https://bugzilla.redhat.com/buglist.cgi?bug_id=1927313_id_type=anddependson=tvp_id=12125305# > I got this, not sure what to file against: Error: Problem: package perl-Mozilla-LDAP-1.5.3-35.fc33.x86_64 requires libperl.so.5.32()(64bit), but none of the providers can be installed - perl-libs-4:5.32.1-477.fc34.x86_64 does not belong to a distupgrade repository - problem with installed package perl-Mozilla-LDAP-1.5.3- 35.fc33.x86_64 - package perl-libs-4:5.32.1-471.module_f35+12589+8a7d3254.x86_64 is filtered out by modular filtering - package perl-libs-4:5.32.1-471.module_f35+12574+98410e7f.x86_64 is filtered out by modular filtering (try to add '--skip-broken' to skip uninstallable packages) HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Boot menu always displayed again?
On Wed, 2021-09-08 at 15:23 +0200, Petr Pisar wrote: > V Wed, Sep 08, 2021 at 09:01:42AM -0400, Simo Sorce napsal(a): > > If I try to do this I get an error: > > # grub2-editenv - set menu_auto_hide=1 > > grub2-editenv: error: environment block too small. > > > > What the issue here ? > > Perhaps /boot/grub2/grubenv is corrupted and grub2-editenv is not very good at > reporting errors. This happens when the file was accidentally truncated. Does > it have 1024-byte size? It is exactly 1024 bytes in size. With a ton of # characters in the tail. > If it does not, back up the file and reinitilize it with > "grub2-editenv - create" and then insert the original values with > "grub2-editenv - set ...". If you don't have UEFI system, you will need to > reistall grub in MBR to locate the new file's position on a block device and > write the position into the newly installed loader. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Boot menu always displayed again?
On Wed, 2021-09-08 at 09:21 +0200, Hans de Goede wrote: > Hi, > > On 9/7/21 1:34 PM, Vít Ondruch wrote: > > > > Dne 07. 09. 21 v 9:26 Hans de Goede napsal(a): > > > Hi, > > > > > > On 9/6/21 5:13 PM, Vít Ondruch wrote: > > > > Not sure if that is intentional, but if I am not mistaken, boot menu > > > > used to be hidden if there were no issues, but it seems to be always on > > > > ATM. Is this intentional? > > > What is the output of running: > > > > > > sudo grub2-editenv - list > > > > > > ~~~ > > $ sudo grub2-editenv - list > > boot_success=1 > > boot_indeterminate=0 > > saved_entry=ec300db9bfdf4776bc07b7f4281374a5-5.14.1-300.fc35.x86_64 > > > > $ uname -a > > Linux localhost.localdomain 5.14.1-300.fc35.x86_64 #1 SMP Fri Sep 3 > > 16:27:33 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > > ~~~ > > Ok, so for some reason this is missing the "menu_auto_hide=1" setting. > > You can fix this by running: > > sudo grub2-editenv - set menu_auto_hide=1 > > The question is why anaconda did not do this though. How did you install > this system? > > If I try to do this I get an error: # grub2-editenv - set menu_auto_hide=1 grub2-editenv: error: environment block too small. What the issue here ? (This machine has been installed a while ago, and then upgraded over time) Simo. > > I have reported this against grub2: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2001885 > > I've added the same comment there. > > Regards, > > Hans > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Is OpenSSL 3.0 still planned for Fedora 35?
On Tue, 2021-08-03 at 07:52 -0400, Neal Gompa wrote: > On Tue, Aug 3, 2021 at 7:10 AM Simo Sorce wrote: > > > > On Tue, 2021-08-03 at 06:50 -0400, Neal Gompa wrote: > > > On Tue, Aug 3, 2021 at 5:59 AM Simo Sorce wrote: > > > > > > > > On Mon, 2021-08-02 at 17:43 -0400, Neal Gompa wrote: > > > > > On Mon, Aug 2, 2021 at 5:39 PM Stephen Gallagher > > > > > wrote: > > > > > > > > > > > > On Mon, Aug 2, 2021 at 11:11 AM Simo Sorce wrote: > > > > > > > > > > > > > > I think at this stage it may be safer to defer to F36, and land > > > > > > > OpenSSL > > > > > > > 3.0 in rawhide right after F35 forks out. > > > > > > > > > > > > > > > > > > > I'm generally in agreement here; I think it's too much risk too late > > > > > > in the cycle. Could you re-propose the Change for F36? > > > > > > > > > > I'm not sure I agree, but the Change owners can request the proposal > > > > > to be deferred to F36, which I *personally* would accept if > > > > > they intended to import OpenSSL 3.0 into Rawhide *right* after > > > > > branching. No more delaying it since it's clearly being done in RHEL > > > > > (which is already super-backwards to begin with). This Change has > > > > > already been deferred once (it was originally planned for F34). I > > > > > don't want it deferred again without a plan to work on it *in Fedora*. > > > > > > > > > > Otherwise, just abandon the Change entirely. > > > > > > > > Neal, > > > > you are addressing this as if the OpenSSL maintainers are being > > > > capricious. > > > > > > > > We deferred the introduction of OpenSSL 3.0 in Fedora because we did > > > > not want a mess in a distribution that is actually used, out of concern > > > > for our users. > > > > > > > > We can "dump" OpenSSL 3.0 in Fedora at any time, but we consciously > > > > choose not to as to avoid pain for users. We cannot drop the Change > > > > because we have to introduce OpenSSL 3.0 at some point, we just want to > > > > introduce it when it's right for Fedora. > > > > > > > > > > My irritation comes from the lack of communication from the Change > > > owner. This Change has already been deferred once (for good reason, > > > mind you). I'm annoyed that this is being deferred again because this > > > time the Change owner hasn't said *anything* at all. Everyone else > > > seems to be speaking (even Florian, which confuses me). I wouldn't > > > mind the Change being deferred again for solid technical reasons, but > > > I don't know how to trust that this Change is ever going to get done > > > because zero work happened and zero communication happened. > > > > The fact work isn't visible, doesn't mean nothing happened. > > > > To most people, it appears that nothing has happened, yes. It would > have been nice to know that stuff happened. Lemme push back on you right here. Did you express interest in this change before? Did you write to Sahana when you realized you had not seen the communication you wanted? > > That said, upstream broke the ABI between alpha and beta1 so we are > > very happy that we "have done nothing" in Fedora and delayed the > > change. > > > > Sure, but the Change proposal[1] explicitly says that the work would > start *after* the beta release in June. The beta release came out June > 17[2], and nothing happened afterward in Fedora, presumably because > Sahana was working on rebasing to it in CentOS Stream 9, which > completed a month later[3]. Note that now Beta 2 came out a week > ago[4], which seems to carry *some* ABI stability (which is a surprise > to me, honestly...). > > From my naive point of view, once that rebase work was complete, I > would have expected the same effort to land in Fedora, since we > already had the openssl1.1 compatibility package created a year > ago[5]. Then we could have integrated it as part of the mass build > last week instead of needing a targeted rebuild for it in a side-tag. It would have been nice, but also a disaster to rush changes into Fedora. There was also no strong need. We are aware of exactly ZERO packages clamoring to get OpenSSL 3.0 in Fedora right now. > For what it's worth, there seem to be 633 source packages that produce > 940 b
Re: Is OpenSSL 3.0 still planned for Fedora 35?
On Tue, 2021-08-03 at 06:50 -0400, Neal Gompa wrote: > On Tue, Aug 3, 2021 at 5:59 AM Simo Sorce wrote: > > > > On Mon, 2021-08-02 at 17:43 -0400, Neal Gompa wrote: > > > On Mon, Aug 2, 2021 at 5:39 PM Stephen Gallagher > > > wrote: > > > > > > > > On Mon, Aug 2, 2021 at 11:11 AM Simo Sorce wrote: > > > > > > > > > > I think at this stage it may be safer to defer to F36, and land > > > > > OpenSSL > > > > > 3.0 in rawhide right after F35 forks out. > > > > > > > > > > > > > I'm generally in agreement here; I think it's too much risk too late > > > > in the cycle. Could you re-propose the Change for F36? > > > > > > I'm not sure I agree, but the Change owners can request the proposal > > > to be deferred to F36, which I *personally* would accept if > > > they intended to import OpenSSL 3.0 into Rawhide *right* after > > > branching. No more delaying it since it's clearly being done in RHEL > > > (which is already super-backwards to begin with). This Change has > > > already been deferred once (it was originally planned for F34). I > > > don't want it deferred again without a plan to work on it *in Fedora*. > > > > > > Otherwise, just abandon the Change entirely. > > > > Neal, > > you are addressing this as if the OpenSSL maintainers are being > > capricious. > > > > We deferred the introduction of OpenSSL 3.0 in Fedora because we did > > not want a mess in a distribution that is actually used, out of concern > > for our users. > > > > We can "dump" OpenSSL 3.0 in Fedora at any time, but we consciously > > choose not to as to avoid pain for users. We cannot drop the Change > > because we have to introduce OpenSSL 3.0 at some point, we just want to > > introduce it when it's right for Fedora. > > > > My irritation comes from the lack of communication from the Change > owner. This Change has already been deferred once (for good reason, > mind you). I'm annoyed that this is being deferred again because this > time the Change owner hasn't said *anything* at all. Everyone else > seems to be speaking (even Florian, which confuses me). I wouldn't > mind the Change being deferred again for solid technical reasons, but > I don't know how to trust that this Change is ever going to get done > because zero work happened and zero communication happened. The fact work isn't visible, doesn't mean nothing happened. That said, upstream broke the ABI between alpha and beta1 so we are very happy that we "have done nothing" in Fedora and delayed the change. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Is OpenSSL 3.0 still planned for Fedora 35?
On Mon, 2021-08-02 at 17:43 -0400, Neal Gompa wrote: > On Mon, Aug 2, 2021 at 5:39 PM Stephen Gallagher wrote: > > > > On Mon, Aug 2, 2021 at 11:11 AM Simo Sorce wrote: > > > > > > I think at this stage it may be safer to defer to F36, and land OpenSSL > > > 3.0 in rawhide right after F35 forks out. > > > > > > > I'm generally in agreement here; I think it's too much risk too late > > in the cycle. Could you re-propose the Change for F36? > > I'm not sure I agree, but the Change owners can request the proposal > to be deferred to F36, which I *personally* would accept if > they intended to import OpenSSL 3.0 into Rawhide *right* after > branching. No more delaying it since it's clearly being done in RHEL > (which is already super-backwards to begin with). This Change has > already been deferred once (it was originally planned for F34). I > don't want it deferred again without a plan to work on it *in Fedora*. > > Otherwise, just abandon the Change entirely. Neal, you are addressing this as if the OpenSSL maintainers are being capricious. We deferred the introduction of OpenSSL 3.0 in Fedora because we did not want a mess in a distribution that is actually used, out of concern for our users. We can "dump" OpenSSL 3.0 in Fedora at any time, but we consciously choose not to as to avoid pain for users. We cannot drop the Change because we have to introduce OpenSSL 3.0 at some point, we just want to introduce it when it's right for Fedora. Simo. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Is OpenSSL 3.0 still planned for Fedora 35?
I think at this stage it may be safer to defer to F36, and land OpenSSL 3.0 in rawhide right after F35 forks out. Simo. On Mon, 2021-08-02 at 15:00 +0200, Miro Hrončok wrote: > Hello Sahana, Ben, other Fedorans, > > We have an accepted change proposal to include OpenSSL 3.0 in Fedora 35: > >https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > The contingency deadline is "Before release" which is not very specific. > > At this point, we are not yet on OpenSSL 3.0 in Fedora 35. > What is the plan regarding the upgrade? > > The change tracking bugzilla has a question posted in June: "OpenSSL3 beta is > out, do we have some updated repository for testing in Fedora? What's the > plan > now?" But there is no answer. > > The mass rebuild is over. Branching is in 1 week. > "Change Checkpoint: Completion deadline (testable)" is in 1 week. > The beta freeze is in 3 weeks. > > Do we still plan to upgrade to OpenSSL 3.0 in Fedora 35? Should we defer this > change to Fedora 36 instead? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Wed, 2021-07-14 at 14:13 -0400, Paul Wouters wrote: > On Mon, 12 Jul 2021, Simo Sorce wrote: > > > > SQLite is a general-purpose tool. Not every use of SHA-1 is > > > cryptographically relevant. Most uses in the context of SQLite probably > > > aren't, so the removal just annoys users for no good reason. > > > > Note that this is a Sqlite decision, from RHEL engineering we only > > requested the removal in digital signatures and where integrity > > protection is required for security. > > Also note that we do not require full removal, just that SHA-1 is not > > used unless users intentionally change configuration. > > How does this affect users of NSS who have created "default" databases, > eg using certutil -N ? Do these use SHA1? If so, can they be migrated > to SHA2? Automatically ? I do not think this feature is used by NSS, CCing Bob. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Undetected ABI change in libkcapi (rawhide)
On Mon, 2021-07-12 at 16:53 +0200, Ondrej Mosnacek wrote: > On Mon, Jul 12, 2021 at 4:32 PM Simo Sorce wrote: > > > > Hello, > > I just rebased libkcapi in Rawhide, without realizing there was an ABI > > change. > > The ABI change should affect only S390 but I am discussing with the > > author on handling this better given the library does use symbol > > versioning. > > It is already being discussed here: > https://github.com/smuellerDD/libkcapi/issues/115 > I have been discussing privately with Stephan, good to know there is a public issue. > Please in the future at least look at open pull requests before you > push something to dist-git. I had started the rebase to 1.3 already > [1], but was holding it off because of the ABI change (though to be > fair I didn't note that in the PR). Sorry did not know you were working on this, I was helping Sahana taking up some slack, and I am new to the package. > > So I may "revert" this ABI change in short order. > > > > Apologies if any build will have issues between today and when I will > > be able to handle it, if you have any concerns please let me know. > > AFAIK, no other package in Fedora currently links against libkcapi, so > there should be no impact on other packages. > > [1] https://src.fedoraproject.org/rpms/libkcapi/pull-request/24 That makes it easier, but I still do not want to break potential users. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Undetected ABI change in libkcapi (rawhide)
Hello, I just rebased libkcapi in Rawhide, without realizing there was an ABI change. The ABI change should affect only S390 but I am discussing with the author on handling this better given the library does use symbol versioning. So I may "revert" this ABI change in short order. Apologies if any build will have issues between today and when I will be able to handle it, if you have any concerns please let me know. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Fri, 2021-07-09 at 20:22 +0200, Florian Weimer wrote: > * Ben Cotton: > > > == Detailed Description == > > The use of SHA-1 is no longer permitted for Digital Signatures or > > authentication in RHEL-9. Due to this reason, there is a need to > > remove SHA-1 extension from sqlite in RHEL-9 and therefore also > > Fedora. The removal of the extension was discussed with sqlite > > upstream development, who confirmed, that it is safe to remove it and > > should not impact other functionality of sqlite. > > Why can we keep SHA-1 in coreutils and Git, but not in SQLite? That > does not make sense to me. > > SQLite is a general-purpose tool. Not every use of SHA-1 is > cryptographically relevant. Most uses in the context of SQLite probably > aren't, so the removal just annoys users for no good reason. Note that this is a Sqlite decision, from RHEL engineering we only requested the removal in digital signatures and where integrity protection is required for security. Also note that we do not require full removal, just that SHA-1 is not used unless users intentionally change configuration. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: OpenLDAP 2.5 - Fedora Release - Help Needed
On Fri, 2021-06-18 at 16:27 +0200, Simon Pichugin wrote: > Hi folks, > my name is Simon Pichugin and I am a maintainer for OpenLDAP. > > Recently, OpenLDAP has released 2.5 version. > It has quite a big amount of changes - > https://www.openldap.org/software/release/announce.html > And it includes a pretty important "Upgrading from 2.4.x" section - > https://www.openldap.org/doc/admin25/guide.html#Upgrading%20from%202.4.x > Also, OpenLDAP on Fedora currently has links to a versioned library: > > ❯ ldconfig -p | grep libldap > libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2 > libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2 > Hi Simon, is upstream releasing libraries with the versioned name in? Or was this a Fedora packaging decision? Are they actually breaking ABI between 2.4 and 2.5 ? > This makes it harder to upgrade as a lot of packages depend on the > versioned one (and the new package has only libldap-2.5.so.2 library. (I > even filed an issue to sudo but I think it's not related to them much - > https://github.com/sudo-project/sudo/issues/105 ) > I suggest carefully reading the sections that talk about SONAME in here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ > I came here for advice as the upgrade can be a sensitive subject for many > users. > > What I think can be done: > >- Rework openldap-compat package for openldap 2.5, so it will include >libldap-2.4 libs (both with and without '_r'). I am not exactly sure what's >the proper way to do this (make a tarball with the compiled libldap-2.4 >libs and place it to the repo - would be okay?) No, you would probably want to have a separate package with its own sources. >- Openldap 2.5 package will include only libldap-2.5.so.2 library and >while testing we will tag it with some build tag so we can make sure that >everything builds with it successfully. Are there any API changes in 2.5 ? I am wondering, is this just a gratuitous rename from upstream? Or will there be issues building code because API changed? What about the ABI? If the ABI hasn't changes we could even think about just providing symlinks ... > I am not sure how we can help openldap-servers package users. Should we > create a change proposal that will include all of the information about the > upgrade (from the OpenLDAP Upstream guide)? And hope that they will read it > before the package upgrade? Is there any other way to notify them during > 'dnf update'? One way to deal with this, if you create a compat package, is to provide the 2.4 slapcat tool that is needed to perform the database conversion. Then create an UPGRADE file with pointers in it to the relevant documentation and *copy* it to the config directory (or somwhere appropriate) in the pre-upgrade script if the package we are upgrading to is from < 2.5 version. Then add a check in the systemd unit file that will *prevent* the server from being started if that file is present. Inside the file the last instruction will be to delete the file. This means the upgrade will not be seamless as the ldap server will not restart until manually fixed, but at least it will be manageable by admins. > Please, share any of your thoughts on this issue. I'll come to a decision > sometime soon as we need to get OpenLDAP 2.5 at least in some state to the > Fedora Rawhide so it can be properly tested. > > Thank you for all of your great work on our awesome Fedora! > > Sincerely, > Simon > > P.S. the PR for 2.5 change was filed by a community member and we already > have some discussion there - > https://src.fedoraproject.org/rpms/openldap/pull-request/6 Thanks for bringing this up, I do not envy the position you are in, hairy upgrades are hairy. Have you checked if debian or any other distro already have something. We may want to look at other people's clever ideas, and if good it may make sense to align so we have similar way to handle upgrades and users using multiple distributions will find it easier. HTH, Simo. > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedor
Re: Can't login with kinit using 2FA
On Thu, 2021-06-17 at 07:54 -0500, Michael Catanzaro wrote: > On Thu, Jun 17 2021 at 10:09:26 AM +0100, David Howells > wrote: > > What if you're not using gnome? > > Then you should install fedora-packager-kerberos? Or fedora-packager, > which has a dependency on fedora-packager-kerberos. > > Anyway, at first I thought that gnome-online-accounts needed a > dependency on this new fedora-packager-kerberos if special kerberos > configuration is required now, but as Kevin explained that dep is only > required if using OTP, and OTP doesn't work with gnome-online-accounts > anyway, so we're fine. (Well, as fine as we can be when enabling OTP is > an irreversible trap that will permanently break your > gnome-online-accounts, requiring the creation of a new FAS account to > recover.) I am pretty sure you can ask an admin to fix the FAS account if really needed. OTP cannot be reversed by users themselves, but admins can fix it if really needed. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)
On Thu, 2021-05-20 at 15:58 -0400, Colin Walters wrote: > > On Thu, May 20, 2021, at 8:21 AM, Daniel P. Berrangé wrote: > > > Lets say the Fedora base image is refreshed with updated RPMs on a weekly > > basis. Each application republishes their app containers on an arbitrarily > > different schedule, maybe fortnightly, monthly, whatever. Thus out of > > 10 different apps deployed, you could easily find yourself shipping 10 > > different versions of the base image. > > This of course is the big difference between flatpak and > docker/podman/kubernetes as they work today. flatpak dynamically links base > images (by having apps go into `/app`). > > I can't think of a hard reason that podman couldn't learn to dynamically link > base images too with the same approach of having the app bits live in `/app`. > Or honestly, in many cases we could just forcibly dynamically link layers, > for most of the OpenShift platform we just have big statically linked Go > binaries that don't overlay anything on the host (no package installs etc). > > One could imagine something like this in a Containerfile: > > ``` > FROM quay.io/fedora:rust as buildroot > COPY . /build > RUN cargo build --release > > FROM DYNAMIC quay.io/fedora > COPY --from-buildroot /build/target/release/myapp /usr/bin/myapp > ``` > > Where the `DYNAMIC` part here opts-in to dynamic linking like flatpak, and > the overlayfs is dynamic instead of static. Having a couple of user containers using podman now occupying a lot of space in my user home, I would appreciate this option. It would be *especially* nice if it were possible to *rebase* (a la git) such containers to a later fedora release as well in time [I am ok if the rebase fails and I have to revert]. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Wed, 2021-05-12 at 16:35 -0400, Ben Cotton wrote: > == Benefit to Fedora == > This change makes the Fedora systems installed by Anaconda more secure > from remote password guessing attacks targeting the root account as it > would no longer be possible to configure a system that allows root to > login via SSH with password. > > A smaller benefit is making the root password configuration screen > less confusing by removing the "Allow SSH root login with password" & > Anaconda code cleanup related removing code related to setting up the > override in sshd. To be honest I object to this characterization. There is no added security given the default is not changed. This only removes a valid option that users that install images for testing locally on their computer use. It just makes it harder but does not change the security of Fedora one yota, as uses can still log in after install and re-enable root login with passwords, or use a kickstart file to do the same. If this is being done because maintaining the option for Anaconda developers then just say that. Otherwise do not do this change and let people that need it for convenience have it. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Fri, 2021-04-30 at 20:42 +0200, Martin Kolman wrote: > On Fri, 2021-04-30 at 15:23 +0100, Richard W.M. Jones wrote: > > On Fri, Apr 30, 2021 at 03:37:54PM +0200, Vitaly Zaitsev via devel > > wrote: > > > On 30.04.2021 15:21, Richard W.M. Jones wrote: > > > > Not everything is exposed to the internet. Please leave the > > > > option, > > > > disabled by default and with a suitable warning if you like. > > > > > > Why are you still using passwords in 2021? SSH keys are much more > > > secure and easier to use. > > > > Because distributing SSH keys to temporary VMs is hard? Not > > everything is a long-lived machine connected to the internet. > What about creating an admin user instead ? It's effectively the same > ammount of clicks - instead of setting a root password and checking the > "Allow SSH root login with password" checkbox, create a regular user > and check the "make this user an admin" checkbox. > > Regular users, including users with admin (sudo/wheel) privileges, can > of course still login with password via SSH just fine. This is not useful to use things like rsync or scp/sftp to transfer files maintaining permissions/attributes/etc.. for doing quick local testing, development, or other ephemeral things this option is reasonable and there is no need to remove it. And also to run commands it is not great, if you end up using su/sudo without password, then you just made a process more complicated without adding much if any security. > > Rich. > > > > -- > > Richard Jones, Virtualization Group, Red Hat > > http://people.redhat.com/~rjones > > Read my programming and virtualization blog: > > http://rwmj.wordpress.com > > virt-top is 'top' for virtual machines. Tiny program with many > > powerful monitoring features, net stats, disk stats, logging, etc. > > http://people.redhat.com/~rjones/virt-top > > ___ > > 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 > > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Kdump with full-disk LUKS encryption
On Mon, 2021-04-19 at 18:24 +0100, Daniel P. Berrangé wrote: > On Mon, Apr 19, 2021 at 01:12:07PM -0400, Simo Sorce wrote: > > On Mon, 2021-04-19 at 12:02 +0100, Richard W.M. Jones wrote: > > > On Mon, Apr 19, 2021 at 06:00:38PM +0800, Kairui Song wrote: > > > > 2. LUKS2 prefers Argon2 as the key derivation function, designed to > > > > use a lot of memory. kdump is expected to use a minimal amount of > > > > memory. Users will have to reserve a huge amount of memory for kdump > > > > to work (eg. 1G reserve for kdump with 4G total memory which is not > > > > reasonable). > > > > > > I'm just going to sympathise with you rather than provide a good > > > answer here ... We had the same problem in libguestfs where Argon2 > > > used too much memory for our small appliance when opening LUKS2 disks. > > > We had to simply increase the amount of memory reserved, which is far > > > from ideal. > > > > Or you could switch to use PBKDF2, it is still a supported and > > reasonable option. > > libguestfs has to open whatever disk image the user gives it, and whoever > built the image originally decided whether it uses Argon2 or PBKDF2. My bad, I thought you were creating new partitions. Yeah argon2 has that "problem". In theory there is a tradeoff between memory vs CPU power, but it seem our implementation decided to go for memory and not give the option to use the more time consuming but less memory hungry algorithm. Simo. > Regards, > Daniel > -- > > : https://berrange.com -o-https://www.flickr.com/photos/dberrange > > :| > > : https://libvirt.org -o-https://fstop138.berrange.com > > :| > > : https://entangle-photo.org-o-https://www.instagram.com/dberrange > > :| > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Kdump with full-disk LUKS encryption
On Mon, 2021-04-19 at 12:02 +0100, Richard W.M. Jones wrote: > On Mon, Apr 19, 2021 at 06:00:38PM +0800, Kairui Song wrote: > > 2. LUKS2 prefers Argon2 as the key derivation function, designed to > > use a lot of memory. kdump is expected to use a minimal amount of > > memory. Users will have to reserve a huge amount of memory for kdump > > to work (eg. 1G reserve for kdump with 4G total memory which is not > > reasonable). > > I'm just going to sympathise with you rather than provide a good > answer here ... We had the same problem in libguestfs where Argon2 > used too much memory for our small appliance when opening LUKS2 disks. > We had to simply increase the amount of memory reserved, which is far > from ideal. Or you could switch to use PBKDF2, it is still a supported and reasonable option. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM (System-Wide Change proposal)
On Fri, 2021-04-16 at 16:31 +, David Cantrell wrote: > > https://fedoraproject.org/wiki/Change/CyrusSaslBerkeleyDBtoGdbm > > > > == Summary == > > cyrus-sasl package was built with libdb requirement, now it is replaced by > > gdbm. > > > > == Owner == > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > * Email: dbelyavs(a)redhat.com > > > > > > > > == Detailed Description == > > This change switches the default backend Key-Value DB used by sasldb > > plugin from BerkeleyDB to GDBM and provides a migration tool for > > automatic conversion from old to new format. > > > > > > == Benefit to Fedora == > > According to more restrictive libdb licence policy exists effort to > > remove libdb's dependencies. > > cyrus-sasl package can now be built without libdb requirement. > > > > > > == Scope == > > * Proposal owners: > > * Other developers: The owners of the packages depending on cyrus-sasl > > sasldb plugin should provide the documentation about the migration > > procedure. > > > > * Release engineering: [https://pagure.io/releng/issue/10084] > > * Policies and guidelines: not needed for this Change > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Objectives: > > > > > > == Upgrade/compatibility impact == > > The migration script should be used to upgrade the particular > > databases used by specific applications via sasldb plugin > > > > > > == How To Test == > > * Install the new version of the cyrus-sasl. > > * Use the migration tool bdb2current provided by the package to > > migrate your sasldb file > > * update the configuration file to point on the new sasldb file > > * restart the application if necessary > > * Check that auth is still working > > > > > > == User Experience == > > not provided > > > > == Dependencies == > > A lot of application use cyrus-sasl sasldb plugins. Their maintainers > > were notified via email and some of them have responded. > > > > > > == Contingency Plan == > > * Contingency mechanism: Revert the shipped configuration > > * Contingency deadline: Beta freeze > > * Blocks release? Yes > > > > > > == Documentation == > > Here is the notification sent to known developers of the depending packages: > > > > New version of the cyrus-sasl is planned to use the gdbm database for > > the sasldb plugins. > > > > I've implemented the patch > > (https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/3#request_diff) > > changing the default DB and implementing the migration tool to make > > the switching from BerkeleyDB to GDBM seamless. > > > > I kindly ask you to check the information in the following spreadsheet: > > https://docs.google.com/spreadsheets/d/1z5eTSm3rtlKtEKPCxhI_wE861Xzg8kbvI...: > > > > whether your package is affected by the proposed change > > whether the migration tool is suitable for your purposes > > > > and let me know or mark the results in the table > > > > > > == Release Notes == > > a new version of the cyrus-sasl package is landing in rawhide. > > > > This version changes the database used to store saslauthdb data. This > > is part of the move to deprecate use of Berkley DB. The new package > > will use GDBM instead. > > > > We provided a tool to perform migrations for database should that be > > needed by a package: > > > > The syntax of the migration tool is > > bdb2current > > > > Please check whether your packages use the sasldb plugin and provide a > > relevant migration guideline. > > A couple of questions: > > 1) The contingency plan does not make it clear how users revert if > the BDB version of Cyrus SASL has to return. Does the migration tool > leave a copy of the previous db file or files in place that can be > used by the BDB version of Cyrus SASL? Should the new file be > migrated back in case of changes post-migration? The migration tool creates a new file, so the previous DB should remain available. We do not really have a way to convert back though, modifying the migrations script to go ther way around should be possible, but unclear if that is really required as you have a backup of th user's db at time of migration. > 2) I'm curious why GDBM was chosen instead of something like sqlite. > > Thanks, > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email t
Re: Proposal to deprecated `fedpkg local`
On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote: > Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): > > Vít Ondruch writes: > > > > > Thx everybody for their responses and sorry for such controversial > > > topic. I am not going to propose this upstream after all. However I have > > > few takeaways: > > > > > > 1) I see responses of Fedora long timers and I understand that you > > > have polished workflows. But I really think that for newcomers, mock > > > should be the preferred way. I'd love to see documentation adjusted to > > > prefer mock everywhere. > > > > > > 2) I would really love you to stop using VMs for your build/testing. > > > With exception of Kernel and Kernel related issues, the argument of > > > "mock being slow" can't stand. Every VM will be more resources hungry > > > then mock, slowing every your task. > > > > > > 3) The argument of mock being slow can't stand, because in one of my > > > examples I posted elsewhere in this thread, I picked up the simplest > > > package I could and the build took 7 seconds. This is certainly not > > > slow, in this time you can't even switch to your email client to check > > > your emails. > > So far on this thread, you've asked feedback on a proposal, and then > > when provided with feedback you didn't like, repeatedly argued with our > > comments and told us we're wrong. This is not a good way to engage with > > feedback. > > I have provided the numbers here: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ > > where I tried to point out that I don't perceive build of trivial > package done in 7s to be slow. For nontrivial package the mock overhead > is negligible. Nobody replied (in constructive way). On various places, > I have suggested to use "--no-clean" option for repeated builds. But in > the whole thread, there was no confirmation that anyone would use it. > > Yet I am repetitively told that mock is slow, you repeat it down bellow > once again without any evidence. Your only argument to this discussion > is that mock is slow, because you believe so and other people have said > so. I would really appreciate if I was given some specific > counterargument supported by numbers. That "mock is slow" is just one of the claims, and not the prevalent one at that. It is also inconvenient. Takes disk space and bandwidth I do not care for. It is complex to use when what you care is to fit the current running systems. And in general, for those that do not use it is yet another thing to learn to use that I personally do not care for learning as I have no need for it. You are claiming that "fedpkg local" is bad, we are responding it is not, we use it and it works better for us. As for many other things there isn't just one true way, mock works best for you, and local works best for others, why is that a problem ? Simo. > > Vít > > > > In particular, *numerous* people have told you that mock builds are > > slow for us. Instead of telling us that we're wrong about our own > > experience because it doesn't match yours, make an effort to understand > > what the difference is between them. Or accept it for what it is: > > feedback that *you asked for*. > > > > Thanks, > > --Robbie > > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: Proposal to deprecated `fedpkg local`
On Wed, 2021-01-27 at 17:17 +0100, Vít Ondruch wrote: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? Sorry I a completely against this. I use fedpkg local very often, and mock is something I never use. If I need a clean build environemnt I simply launch a scratch build in koji. When I used fedpkg local I very much do not care for a clena environment and may *very* well depend on the actual packages I have currently installed. In short, I am not amused by this proposal, it is about removing an extremely useful tool. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: Server Side Public License (SSPL) v1
On Thu, 2021-01-21 at 13:16 +, Mat K. Witts wrote: > > ...the SSPL is intentionally crafted to be aggressively discriminatory > towards a specific class of users. > > Who are they? > > Can you identify this class of users please? Wow resurrecting a 2019 thread ? A thread where the exact same question was asked also aggresively *and* responded to by Ben Cotton ... Troll much ? -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: libelf now depends on openssl
On Fri, 2021-01-15 at 14:22 -0500, Colin Walters wrote: > > On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote: > > There is of course no problem to have it in Fedora, but if this is > > something that is going to end up in RHEL one day, it would be better > > to do the work now to make it use OpenSSL rather than scramble later. > > Isn't it at least part of the purpose of Fedora ELN to detect situations like > this earlier? A dependency on boringssl in the Fedora "Everything" > repositories is a distinct thing from it in ELN. If there was a change that > brought it into ELN, AFAIK the ELN builds wouldn't fail, presumably we'd want > to treat it as an important bug and possibly drive reverting the change in > "Everything" or so, right? > > Similarly, we definitely would try really hard to avoid adding another crypto > library to Fedora CoreOS. > > So I think the use of the bare term "Fedora" here isn't right. At the moment the only impediment to add a crypto library in Fedora, that I know of, is legal issues (like patents). The barrier is higher in RHEL. ELN and Fedora Core OS are still Fedora, so I leave it to the maintainers and FESCO to decide if they want to add any rules or restrictions to Fedora. I would rather not see unbounded proliferation of crypto library, given quality issues in those components are not merely bugs, they are often serious CVE with potentially dire consequences (loss of key material or other confidential information), but I am not signing up to be in the Fedora Crypto police, I have enough on my hands as RHEL Crypto Police :-D > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: libelf now depends on openssl
On Fri, 2021-01-15 at 09:33 -0600, Michael Catanzaro wrote: > On Fri, Jan 15, 2021 at 9:47 am, Simo Sorce wrote: > > Which is one of the reasons we do not admit boringssl in RHEL. > > > > There is of course no problem to have it in Fedora, but if this is > > something that is going to end up in RHEL one day, it would be better > > to do the work now to make it use OpenSSL rather than scramble later. > > It won't even wind up in Fedora since we need WebKit to remain > GPL-compatible. So WebRTC stays disabled until upstream finds a way to > get rid of boringssl. The plan is to switch from libwebrtc to GStreamer. > > So not such a big deal for me right now, but might be a big deal for > anyone hoping to transition to openssl 3.0 anytime other than exactly > the same time debuginfod does. The transition to openssl 3.0 may be a little bumpy for libraries indeed, but there isn't much we can do about it. We'll definitely try to minimize impact as much as possible. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: libelf now depends on openssl
On Fri, 2021-01-15 at 10:25 +0100, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote: > > > On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel > > > wrote: > > > > Do the boringssl symbols not have hidden visibility in libwebrtc? > > > > If they > > > > do, why are they getting interposed anyway? If they don't, why > > > > not? I assume > > > > the library is private to libwebrtc and its symbols should not be > > > > exported. > > > > > > libwebrtc is a static lib, and so is boringssl. So all symbols, > > > except unused symbols, will be directly included in libwebkit2gtk. > > > In release builds, they would then be hidden by a linker script, but > > > in developer builds everything is exported because API tests depend > > > on internal symbols. > > > > Would it be possible to get rid of boringssl? Having yet another > > crypto library is ... bad. > > Especially since it's not expected to be used outside of Google: > > > BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. > > > > Although BoringSSL is an open source project, it is not intended for > > general use, as OpenSSL is. We don't recommend that third parties > > depend upon it. > > <https://boringssl.googlesource.com/boringssl/> Which is one of the reasons we do not admit boringssl in RHEL. There is of course no problem to have it in Fedora, but if this is something that is going to end up in RHEL one day, it would be better to do the work now to make it use OpenSSL rather than scramble later. HTH, Simo. > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > ___ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: Fedora TPM1.2 Support
On Fri, 2020-12-04 at 11:59 -0700, Jerry Snitselaar wrote: > Simo Sorce @ 2020-12-04 07:32 MST: > > > On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote: > > > On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce wrote: > > > > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote: > > > > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the > > > > > > question with regards to opencryptoki-tpmtok if it should be > > > > > > changed in > > > > > > Fedora as well, so I thought I'd see what everyone thinks about > > > > > > future > > > > > > TPM1.2 support in Fedora. I know at one point in the last year or so > > > > > > trousers almost dropped from Fedora due to being orphaned for quite > > > > > > a > > > > > > while. From what I could find the following packages have > > > > > > dependencies: > > > > > > > > > > > > ecryptfs-utils - --disable-tspi > > > > > > openconnect - looks like it will only build support if > > > > > > trousers-devel is > > > > > > there, and makes use of tpm2-tss as well. > > > > > > strongswan - --enable-tss-tss2 instead of --enable-tss-trousers? > > > > > > tboot - the trousers dependency was just in a policy tool > > > > > > that has now > > > > > > been deprecated upstream. > > > > > > opencryptoki-tpmtok - --disable-tpmtok > > > > > > > > > > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific > > > > > > packages. > > > > > > > > > > > > Another thing is that in the kernel there currently is no way to > > > > > > build > > > > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2 > > > > > > would still be there. > > > > > > > > > > > > I don't think Fedora needs to drop the tpm1.2 support if people > > > > > > want to > > > > > > continue supporting it, but wanted to put the question out there > > > > > > and see > > > > > > how everyone felt. > > > > > > > > > > I think it should be dropped, tpm2 has been shipped in hardware for 5+ > > > > > years and tpm1 has security issues, so I think the time is now to drop > > > > > it. Please do a Fedora Change proposal to ensure it's communicated > > > > > properly. > > > > > > > > Won't that hurt people that have keys trapped in a TPM 1.2 device ? > > > > > > Won't it hurt RHEL users in similar ways? > > > > It may, but that is RHEL, and this Fedora, no ? > > > > > What is the likelihood of > > > those users actively upgrading anyway? > > > > Upgrades in RHEL are a much bigger deal, and usually better researched > > (also rare, usually people reinstall there). > > > > In Fedora distro-upgrading w/o looking too hard at release notes is > > common. > > > > Of course the amount of people that uses TPM 1.2 in Fedora is probably > > very small, so this change may be ok, but I just wanted to raise the > > issue. > > > > Is there a way, after update to still use TPM 1.2 at all (even if it > > requires installing copr/other repo packages)? Or will people need to > > roll back their system to access those secrets at all ? > > > > Simo. > > Yes, the kernel support in the driver would still be there. Currently > the driver code can't be compiled for just tpm1.2 or tpm2.0. So it > would be a matter of getting userspace tools to talk to it. So a container with a previous fedora version+tools would be a way to "deal" with it at least temporarily? (for example to decrypt data and transition to TPM2.0 to re-encrypt it or similr...) -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
Re: Fedora TPM1.2 Support
On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote: > On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce wrote: > > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote: > > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the > > > > question with regards to opencryptoki-tpmtok if it should be changed in > > > > Fedora as well, so I thought I'd see what everyone thinks about future > > > > TPM1.2 support in Fedora. I know at one point in the last year or so > > > > trousers almost dropped from Fedora due to being orphaned for quite a > > > > while. From what I could find the following packages have dependencies: > > > > > > > > ecryptfs-utils - --disable-tspi > > > > openconnect - looks like it will only build support if trousers-devel is > > > > there, and makes use of tpm2-tss as well. > > > > strongswan - --enable-tss-tss2 instead of --enable-tss-trousers? > > > > tboot - the trousers dependency was just in a policy tool that > > > > has now > > > > been deprecated upstream. > > > > opencryptoki-tpmtok - --disable-tpmtok > > > > > > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific > > > > packages. > > > > > > > > Another thing is that in the kernel there currently is no way to build > > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2 > > > > would still be there. > > > > > > > > I don't think Fedora needs to drop the tpm1.2 support if people want to > > > > continue supporting it, but wanted to put the question out there and see > > > > how everyone felt. > > > > > > I think it should be dropped, tpm2 has been shipped in hardware for 5+ > > > years and tpm1 has security issues, so I think the time is now to drop > > > it. Please do a Fedora Change proposal to ensure it's communicated > > > properly. > > > > Won't that hurt people that have keys trapped in a TPM 1.2 device ? > > Won't it hurt RHEL users in similar ways? It may, but that is RHEL, and this Fedora, no ? > What is the likelihood of > those users actively upgrading anyway? Upgrades in RHEL are a much bigger deal, and usually better researched (also rare, usually people reinstall there). In Fedora distro-upgrading w/o looking too hard at release notes is common. Of course the amount of people that uses TPM 1.2 in Fedora is probably very small, so this change may be ok, but I just wanted to raise the issue. Is there a way, after update to still use TPM 1.2 at all (even if it requires installing copr/other repo packages)? Or will people need to roll back their system to access those secrets at all ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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
