Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On 9/15/22 00:59, Kevin Kofler via devel wrote: Alexander Sosedkin wrote: That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage. Please read the actual proposal: this is about SHA-1 *signatures*. Not the hash itself. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 ke, 14 syys 2022, Kevin Fenzi wrote: On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote: On ke, 14 syys 2022, Stephen Smoogen wrote: > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy > wrote: > > > > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > > certificate authority that is trusted by the KDC as well. For example, > > by FreeIPA CA which is already ran by the Fedora project infrastructure > > team. An alternative is to set up certificate mapping and validating > > rules. > > > > If someone from Fedora Accounts team wants to experiment with this, I > > can guide you what to do. > > > > There is no continual running Fedora Accounts 'team'. There are 2-3 system > administrators split between releng, operations and continual > firefighting. There are also a team of developers who are split between > CentOS Stream initiatives and other work. Changes like this need to have > more than just an 'oh I have finally an afternoon free where all the other > crap in the build infra is actually working for once.. lets dive into IPA' I understand all of that myself. I think what is important here is to plan to work together so that eventually we can implement this. Right and while I agree with what smooge says there, I'm definitely interested in improving things as we can. I really would prefer a detailed plan however, not 'lets enable everything we can and see what sticks'. :) Oh, for sure 'enable everything' is not what I or others suggest either. ;) This whole thread is about agreeing or disagreeing whether Fedora as a project would want to have better security methods to identify and authenticate its contributors when performing tasks that have large impact. Yep. I'm in agreement that we want to... but there's always tradeoffs. A few random things to mention: * I don't think requiring FIDO2 for all packagers is tenable. It may well be that we could get donations or funding to get hardware for all packagers, especially if we wait for the current inactive process to finish, but even so, we will run into problems of people who can't get one shipped to them or gets lost in the mail, etc. There would also be a delay "hey, you are now a packager, look for a token in the mail in the next few weeks before you can do anything" Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers? There is probably a value in defining what functions critical to have strongly authenticated and identified to the distribution at large. For example, right now even 2FA OTP requirement is not mandatory for certain package groups. * I'd really prefer to avoid going back to certs. People have all kinds of problems with certs. I think it would cause a lot of confusion. (Unless I am misunderstanding what use is proposed for them). If Fedora contributors would have had access to Fedora's FreeIPA web UI We actually do have external access to the web UI. We just don't advertise it much. Ok, that's good to hear in case we need to experiment with our accounts before the Fedora Accounts UI is expanded to cover other authentication methods. or IPA API directly, we wouldn't even need to have a conversation about PKINIT and certificates. We could have added instructions how to request and associate a certificate with your account. But since Fedora Accounts system is the frontend to Fedora Project's FreeIPA deployment, we cannot simply do that. However, FreeIPA-wise, smartcards are supported now for Kerberos authentication, so we as Fedora contributors could benefit from that. What would this use of certificates do here? Authenticate you to get a kerberos ticket? Allow you to login to the account interface? The former. I am only considering all of this to allow Kerberos authentication with stronger methods. Smartcards are more accessible these days than, say, FIDO2 tokens. A card reader cost is around 10EUR (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR), a smartcard is typically your government-issued ID in many countries. Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close enough to a lower boundary. Anyway, using a soft-based smartcard e.g. using NSS database stored on a usb flash drive and accessible via PKCS11 could also be an option. The problem here is to attest to a server side it is protected by the client but this is a common problem to all different methods. Even storing a key-pair on your hard drive would work with Kerberos PKINIT without any problem. CentOS folks still use certs for their koji: https://wiki.centos.org/Authentication#TLS_certificate (and thats using the same account system/ipa servers as fedora). I hope we can plan to work together on this improvement again, similar how we did with the initial rewrite of Fedora Accounts on top of FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, perhaps CPA t
Re: Remaining packages in need of a Python 3.11 rebuild
On 2022-09-14 07:01, Miro Hrončok wrote: Hello folks! luya dlib dlib @bizdelnick @luya ASSIGNED https://bugzilla.redhat.com/2098694 Bundles old pybind11 which is not Python 3.11 compatible, needs to be unbundled or at least updated. Upstream is waiting for the stable release of Python 3.11 to do the change. As for unbundling, could someone from Python team propose a suggestion for testing please? Thank you. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:01, Miro Hrončok wrote: Hello folks! ... Will be retired one week before the freeze anyway barbecue it's an old NEW. I don't always spell "because" as "barbecue". But when I do I copy-paste it to the email 8 times 🤦 -- 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
Re: libFLAC soname bump
Hi Miroslav, On Mon, Sep 12, 2022 at 04:36:47PM +0200, Miroslav Lichvar wrote: > flac-1.4.0 changes the libFLAC and libFLAC++ sonames. There are also > some incompatible changes in the API, but I didn't see any packages > failing to built due to these changes. > > The following packages need to be rebuilt: > > I tried to rebuild them all except chromium which I suspect would take > too much space and time. Only ardour6, audacity, and xmms2 failed, for > unrelated reasons. > All the packages on your list except the 4 you listed in the paragraph above should be built now, please check if anything is missing: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=58420&order=-build_id&latest=1 Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, 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:49 -0700, Adam Williamson wrote: > The hardcore way is to say "welp, too bad, your account's gone, > create > a new one and start over, including going through the maintainer > process again", but that might be a bit *too* hardcore. > > This is a perennial issue, though, and the weakest point of the whole > FIDO2 concept overall, including in the way it's being promoted to a > mass audience as password-less auth for everything. The official > story > is you should also enrol a backup phone or tablet or something that > you > keep at home, then if you lose your main phone, you can get into the > system with the backup device, enrol a new main device, and unenrol > the > lost/stolen main device. > > But if you *aren't* rich enough to have spare phones/tablets lying > around the place, or you just manage to lose both, the story is > basically "you go into an Apple store or call up Google or Samsung > etc. > and somehow convince them you are you and they will then auth a new > device onto your account". So, awkward squishy human processes again. To follow up on some of these points, IIRC the weakest chain in the link is alternate factors (SMS is strictly inferior to TOTP for example) and social engineering (poorly trained tech support or they just don't care). A sufficiently advanced attacker may not even have to take over an account to create a legitimate looking phishing e-mail or phone call. There's been recent stories of hackers having insider knowledge that would normally be difficult to obtain for less sophisticated attackers. I think the first step would be to create a threat model and then go from there, incorporating all of the points brought up in this thread. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 18:35 -0400, Simo Sorce wrote: > 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. Same way you deal with people losing their passwords or current 2FA tokens: slowly and awkwardly. Basically, have a human deal with it, and establish as best they can that the person claiming they lost their tokens really is the person who ought to have them. Of course, if you do issue new tokens, send an alert about this to all known contact methods for the account, so if it *was* an Evil Person doing it, and the Evil Person hasn't also compromised all of those contact methods too, the Real Packager will know something funky has happened and - hopefully - reach out and get the account frozen again. The hardcore way is to say "welp, too bad, your account's gone, create a new one and start over, including going through the maintainer process again", but that might be a bit *too* hardcore. This is a perennial issue, though, and the weakest point of the whole FIDO2 concept overall, including in the way it's being promoted to a mass audience as password-less auth for everything. The official story is you should also enrol a backup phone or tablet or something that you keep at home, then if you lose your main phone, you can get into the system with the backup device, enrol a new main device, and unenrol the lost/stolen main device. But if you *aren't* rich enough to have spare phones/tablets lying around the place, or you just manage to lose both, the story is basically "you go into an Apple store or call up Google or Samsung etc. and somehow convince them you are you and they will then auth a new device onto your account". So, awkward squishy human processes again. -- 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, 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: Inactive packagers to be removed after the F37 release
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. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On Tue, 2022-09-13 at 16:46 +, Timo S via devel wrote: > $ sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 - > -enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null > && echo --enablerepo=updates-testing-modular) --assumeno distro-sync > Last metadata expiration check: 0:08:47 ago on Tue 13 Sep 2022 > 19:34:54. > Error: > Problem 1: problem with installed package nodejs-electron-19.0.16- > 1.3.x86_64 > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libavif.so.13()(64bit), but none of the providers can be installed > - nodejs-electron-19.0.16-1.3.x86_64 does not belong to a > distupgrade repository > - libavif-0.9.3-3.fc36.x86_64 does not belong to a distupgrade > repository > Problem 2: problem with installed package 0ad-0.0.25b-2.fc36.x86_64 > - package 0ad-0.0.25b-2.fc36.x86_64 requires > libboost_filesystem.so.1.76.0()(64bit), but none of the providers can > be installed > - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a > distupgrade repository > Problem 3: problem with installed package signal-desktop-5.58.0- > 1.7.x86_64 > - package signal-desktop-5.58.0-1.7.x86_64 requires (nodejs- > electron(x86-64) >= 19 with nodejs-electron(x86-64) < 20), but none > of the providers can be installed > - package nodejs-electron-19.0.16-1.3.x86_64 requires > libjxl.so.0.6()(64bit), but none of the providers can be installed > - package nodejs-electron-19.0.16-1.3.x86_64 requires > libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be > installed > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libjxl.so.0.6()(64bit), but none of the providers can be installed > - package nodejs-electron-19.0.16-1.4.x86_64 requires > libjxl.so.0.6(JXL_0)(64bit), but none of the providers can be > installed > - libjxl-0.6.1-9.fc36.x86_64 does not belong to a distupgrade > repository > (try to add '--skip-broken' to skip uninstallable packages) Hi, where did you get signal-desktop and nodejs-electron ? is not is any known repo that I'm aware -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Alexander Sosedkin wrote: > That's a reason why my initial thread [1] has been named > "Landing a larger-than-release change (distrusting SHA-1 signatures)": > flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote: > On ke, 14 syys 2022, Stephen Smoogen wrote: > > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy > > wrote: > > > > > > > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > > > certificate authority that is trusted by the KDC as well. For example, > > > by FreeIPA CA which is already ran by the Fedora project infrastructure > > > team. An alternative is to set up certificate mapping and validating > > > rules. > > > > > > If someone from Fedora Accounts team wants to experiment with this, I > > > can guide you what to do. > > > > > > > There is no continual running Fedora Accounts 'team'. There are 2-3 system > > administrators split between releng, operations and continual > > firefighting. There are also a team of developers who are split between > > CentOS Stream initiatives and other work. Changes like this need to have > > more than just an 'oh I have finally an afternoon free where all the other > > crap in the build infra is actually working for once.. lets dive into IPA' > > I understand all of that myself. I think what is important here is to > plan to work together so that eventually we can implement this. Right and while I agree with what smooge says there, I'm definitely interested in improving things as we can. I really would prefer a detailed plan however, not 'lets enable everything we can and see what sticks'. :) > This whole thread is about agreeing or disagreeing whether Fedora as a > project would want to have better security methods to identify and > authenticate its contributors when performing tasks that have large > impact. Yep. I'm in agreement that we want to... but there's always tradeoffs. A few random things to mention: * I don't think requiring FIDO2 for all packagers is tenable. It may well be that we could get donations or funding to get hardware for all packagers, especially if we wait for the current inactive process to finish, but even so, we will run into problems of people who can't get one shipped to them or gets lost in the mail, etc. There would also be a delay "hey, you are now a packager, look for a token in the mail in the next few weeks before you can do anything" * I'd really prefer to avoid going back to certs. People have all kinds of problems with certs. I think it would cause a lot of confusion. (Unless I am misunderstanding what use is proposed for them). > If Fedora contributors would have had access to Fedora's FreeIPA web UI We actually do have external access to the web UI. We just don't advertise it much. > or IPA API directly, we wouldn't even need to have a conversation about > PKINIT and certificates. We could have added instructions how to request > and associate a certificate with your account. But since Fedora Accounts > system is the frontend to Fedora Project's FreeIPA deployment, we cannot > simply do that. However, FreeIPA-wise, smartcards are supported now for > Kerberos authentication, so we as Fedora contributors could benefit from > that. What would this use of certificates do here? Authenticate you to get a kerberos ticket? Allow you to login to the account interface? CentOS folks still use certs for their koji: https://wiki.centos.org/Authentication#TLS_certificate (and thats using the same account system/ipa servers as fedora). > I hope we can plan to work together on this improvement again, similar > how we did with the initial rewrite of Fedora Accounts on top of > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, > perhaps CPA team could consider scheduling this effort as part of the > initiatives. Yeah, I would like that. Perhaps we could setup a meeting soon and dicuss plans? I'm open to video meeting, but we could also do IRC to keep things more open... > Let me round up methods that we have supported now or plan to add in > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to > issuance of a Kerberos ticket that can be used for communicating with > the rest of Fedora services: > - basic password-based authentication > - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an > external RADIUS server for validation of a string passed as >a 'password' or 'token' value > - use of a certificate stored on a supported PKCS11 token (smartcard, >softtoken (SoftHSMv2, NSS) or just in plain keypair files) > - use of OAuth2 device authorization grant against some OAuth2 IdP (new >in FreeIPA 4.9.10+) > - (future) use of a FIDO2/WebAuthn token > > Fedora accounts system implements the management of the first two > methods right now. And possibly the 3rd... What does 'device' mean in the 4th one? :) We do have https pushes using oauth/oidc token right now. Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh keys and thus use FIDO2 for ssh actions if we wish.
Fedora CoreOS Meeting Minutes 2022-09-14
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:30:52 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-09-14/fedora_coreos_meeting.2022-09-14-16.30.log.html . Meeting summary --- * roll call (dustymabe, 16:30:56) * Action items from last meeting (dustymabe, 16:33:05) * ACTION: travier Reach out to the podman team for the conmon-rs transition (dustymabe, 16:34:54) * tracker: F37 Test Week (dustymabe, 16:35:30) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1225 (dustymabe, 16:35:33) * Fedora CoreOS next stream was rebased to Fedora Linux 37 content! (dustymabe, 16:37:05) * open floor (dustymabe, 16:40:34) * update barriers for key rotation (bgilbert, 16:43:59) * LINK: https://github.com/coreos/fedora-coreos-streams/pull/561#issuecomment-1244815916 (bgilbert, 16:44:02) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629 (bgilbert, 16:49:45) * AGREED: We will replace our existing barrier instructions to add an update barrier for the last build of N-1 when the first build/release of N happens. Basically option 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629 (dustymabe, 17:08:35) * open floor (dustymabe, 17:09:07) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/567 (bgilbert, 17:12:54) * LINK: https://docs.edgeless.systems/constellation/architecture/images (travier, 17:14:15) * LINK: https://mobile.twitter.com/EdgelessSystems/status/1569630921036386308 > if you want to retweet from the FCOS account (travier, 17:16:18) * LINK: https://github.com/edgelesssys/constellation-fedora-coreos-config/commit/4c8eafd344522696cb616f61bc03271888c479e3 :) (travier, 17:17:35) Meeting ended at 17:19:02 UTC. Action Items * travier Reach out to the podman team for the conmon-rs transition Action Items, by person --- * travier * travier Reach out to the podman team for the conmon-rs transition * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (85) * bgilbert (42) * zodbot (18) * travier (13) * lucab (6) * jbrooks (5) * Nemric (1) * spresti[m] (1) * marmijo (1) * aaradhak (1) * ravanelli (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
[WIP][gpgme rebase to 1.18.0] Ask for comaintainership of dependant packages
Hello, I am planning to update gpgme to 1.18.0 in rawhide and since there is SONAME bump in libqgpgme, I am asking to be a co-maintainer of these dependant packages: - https://src.fedoraproject.org/rpms/isoimagewriter (main admin: lupinix) - https://src.fedoraproject.org/rpms/kdepim-addons (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-libkleo (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-mailcommon (main admin: rdieter) - https://src.fedoraproject.org/rpms/kf5-messagelib (main admin: rdieter) - https://src.fedoraproject.org/rpms/kget (main admin: than) - https://src.fedoraproject.org/rpms/kleopatra (main admin: rdieter) - https://src.fedoraproject.org/rpms/kmail-account-wizard (main admin: rdieter) - https://src.fedoraproject.org/rpms/kmail (main admin: rdieter) - https://src.fedoraproject.org/rpms/trojita (main admin: kkofler) Thanks in advance, Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
GAP 4.12 and a package review swap
The gap package has a new version available (4.12), which comes with significant improvements over 4.11. I've been working on updating the entire gap stack [1] for the new version. The spec files have been simplified and made more uniform, which should aid future maintenance. I need one new package as part of this effort. Who would like to swap reviews? gap-pkg-standardff: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2126927 There is a COPR [2] with the relevant builds, including the new package [3]. Footnotes: [1] Every package named gap-pkg-*, plus gap, GAPDoc, and xgap. [2] https://copr.fedorainfracloud.org/coprs/jjames/GAP4.12/ [3] https://copr.fedorainfracloud.org/coprs/jjames/GAP4.12/build/4836940/ -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
I've updated https://fedoraproject.org/wiki/Changes/NodejsRepackaging with the results of this discussion. I'll go the `nodejs-$MAJOR-unversioned-command` route. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, 2022-09-07 at 17:47 +, Maxwell G via devel wrote: > I think this is a bad idea. It's quite hostile to packagers. It will > break rawhide for months and make it very difficult to stabilize the > distro before the beta freeze or do any type of rebuild. It very well > may > affect other Changes. It will still cause untold problems even if you > revert it before the beta freeze. Please test this in COPR (as Miro > already said) or somewhere else instead of destabilizing the distro. > You > can analyze the COPR failures and report bugs just like the Python > SIG > does for new Python major versions. I have no stake in this but participated in the test day (I don't think anyone else did?) so I would like to give my 2 cents. First for the results. I only noticed two issues: RPM Fusion signing keys and libimobiledevice no longer pairing with phones. Both are "trivial" issues. The former is a quick fix, the latter the maintainer has been notified and has expressed interest in modifying the codebase to switching from SHA1 to something like SHA256. COPR also had issues but again, that was a quick fix. Secondly, I agree that it is hostile to packagers. I filed an issue and the packager was kind of blindsided by the proposal. I have no issue with the term jump scare because I think such a radical change does need to "scare" people otherwise complacency leads to people being slow to migrate (see Python 2 -> 3 and people forking 2, despite having over a decade to switch to 3 for example). So maybe such a big change should have more communication and emphasis. Now while I only found a few issues doing testing, I have no doubt other people will have more exotic setups like specific hardware, VPNs, third party repos, etc. where things will break. Although I should say that I did testing across a wide variety of software including Tor, git, SSH and so on so assuming a relatively vanilla setup, most people should be fine. Anyway I agree on paper about testing it on COPR to avoid affecting the main distro, but I think that something like this can only encourage people to fix (or drop) software if there is intentional breakage. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi wrote: > > On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > > > How about this: > > > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > > > I'm open for proposals on the wording. =) > > Well, I guess it depends on if you still want to implement it and then > plan to roll it back or not... see below. > > > > > Rework the change so it's basically planning on making this change in > > > f38. > > > > That makes it closer than currently, > > defeating the purpose of letting people prepare. > > True, it possibly makes the timeline shorter. > If thats a concern, perhaps you would consider just targeting f39 and > for f38 just doing test days and reminders asking developers to test > instead of changing it and then changing it back? > > > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > > and decides if it can remain on in f38 and if not, it gets reverted and > > > moved to f39. > > > > Not sure how it's better than reverting in branched f38 but not rawhide, > > unless the goal is to hasten the change. > > It's better because it seems more direct and honest to me. > It means you are landing a change and trying to get it done, not landing > it to break people and then at the last minute after people rush to fix > things, removing it again. I also suspect there will be some feet > dragging due to this: "Oh, it's broken now, but they are going to revert > it anyhow, so I won't do anything". If this helps, from the perspective of tracking rawhide, we flip the switch and don't revert it. So the "they'll revert it" argument doesn't work at least for rawhide. > > > In the run up to f38 beta we could: > > > > > > * run a series of test days. perhaps one before you enable it in > > > rawhide, one a month or two later and one right before f38 beta > > > freeze? > > > > I'm for more test days. > > There was one held already and I'm open for holding more in the future. > > Plus I should attempt some side-tag mass-rebuild or equivalent, > > but I, unfortunately, won't get to it until October at the earliest. > > Sure, understand time is low for everyone. ;( > > > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > > tests on a compose or updates? This might be a good thing to try and do > > > before landing it in rawhide. > > > > Sounds great if that's a possibility, but I don't know how to approach it. > > Perhaps Adam can chime in here... > > > > * setup a tracking bug to track the issues, so we can make a more > > > informed decision before f38 beta. > > > > > > Thoughts? > > > > If the core of your proposal is > > * make it happen in f38 and revert and push back to f39 only if necessary > > as opposed to > > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > > but not f38 branched (the current proposal) > > then I can't say I understand what you are trying to achieve with > > that. > > I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just > kidding, it will not take effect until next cycle. That just seems to be > dishonest to our users. > > > IMO it makes the switch less certain, more frantic and more abrupt, > > while I was trying to smoothen it out in time as far as possible. > > I don't think it's possible to cleanly spread out a change like this > over more than 1 long fedora cycle. That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. > > So +1 on all the accompanying activities possible, > > -1 on expediting the switch. > > ok. I'm not sure where the rest of fesco is on this, but I guess we will > see. :) > > Thanks for listening. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Donate 1 minute of your time to test upgrades from F36 to F37
# dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Fedora 37 - x86_64 22 MB/s | 81 MB 00:03 Fedora 37 openh264 (From Cisco) - x86_64 3.0 kB/s | 2.5 kB 00:00 Fedora Modular 37 - x86_64 4.5 MB/s | 3.8 MB 00:00 Fedora 37 - x86_64 - Updates 237 B/s | 257 B 00:01 Fedora Modular 37 - x86_64 - Updates 722 B/s | 257 B 00:00 Fedora 37 - x86_64 - Test Updates 4.1 MB/s | 5.0 MB 00:01 Fedora Modular 37 - x86_64 - Test Updates 266 kB/s | 267 kB 00:01 RCM Tools for Fedora 37 (RPMs) 7.5 kB/s | 4.5 kB 00:00 RPM Fusion for Fedora 37 - Free 528 kB/s | 680 kB 00:01 RPM Fusion for Fedora 37 - Free - Updates 192 B/s | 257 B 00:01 Error: Problem: problem with installed package 0ad-0.0.25b-2.fc36.x86_64 - package 0ad-0.0.25b-2.fc36.x86_64 requires libboost_filesystem.so.1.76.0()(64bit), but none of the providers can be installed - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) On Mon, Sep 12, 2022 at 8:00 AM Miroslav Suchý wrote: > > Do you want to make Fedora 37 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 '*' > > dnf --releasever=37 --setopt=module_platform_id=platform:f37 \ > --enablerepo=updates-testing \ > $(rpm -q fedora-repos-modular >/dev/null && echo > --enablerepo=updates-testing-modular) \ > --assumeno 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. > > > The `--assumeno` will just test the transaction, but does not make the actual > upgrade. > > > In case you hit dependency issues, please report it against the appropriate > package. > > Or against fedora-obsolete-packages if that package should be removed in > Fedora 37. Please check existing reports against > > fedora-obsolete-packages first: > > https://red.ht/2kuBDPu > > and also there is already bunch of "Fails to install" (F37FailsToInstall) > reports: > > https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109&bug_id_type=anddependson&format=tvp&list_id=12486533 > > Thank you > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Donate 1 minute of your time to test upgrades from F36 to F37
OK, third time is the charm. I finally got the command right. Everything went just fine.: sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync $ sudo dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Copr repo for PyCharm owned by phracek 54 kB/s | 44 kB 00:00 Fedora 37 - x86_64 14 MB/s | 81 MB 00:05 Fedora 37 openh264 (From Cisco) - x86_64 2.4 kB/s | 2.5 kB 00:01 Fedora Modular 37 - x86_642.1 MB/s | 3.8 MB 00:01 Fedora 37 - x86_64 - Updates 333 B/s | 257 B 00:00 Fedora Modular 37 - x86_64 - Updates 313 B/s | 257 B 00:00 Fedora 37 - x86_64 - Test Updates 1.4 MB/s | 5.0 MB 00:03 Fedora Modular 37 - x86_64 - Test Updates 273 kB/s | 267 kB 00:00 google-chrome 11 kB/s | 3.6 kB 00:00 RPM Fusion for Fedora 37 - Nonfree - NVIDIA Driver 14 kB/s | 14 kB 00:01 RPM Fusion for Fedora 37 - Nonfree - Steam3.0 kB/s | 2.2 kB 00:00 Dependencies resolved. [...] Transaction Summary == Install 55 Packages Upgrade2348 Packages Downgrade95 Packages Total download size: 2.6 G Operation aborted. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 14/09/2022 17:26, Michael Catanzaro wrote: If you want to protect against *both* threats, use a security key, but you've already pushed back against requiring a hardware purchase. I never click on links from emails, instant messengers, etc. I'm using fkinit and my simple custom systemd user timer to keep my Kerberos ticket up to date. I don't want to buy a smartphone just to do TOTP: no way. KeePassXC supports TOTP, HOTP and Steam 2FA. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On 9/14/22 09:40, Scott Beamer wrote: I just copied and pasted from the OP... Ok, but you have to be aware that your email client might reformat the text and mess up the lines. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > How about this: > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > I'm open for proposals on the wording. =) Well, I guess it depends on if you still want to implement it and then plan to roll it back or not... see below. > > > Rework the change so it's basically planning on making this change in > > f38. > > That makes it closer than currently, > defeating the purpose of letting people prepare. True, it possibly makes the timeline shorter. If thats a concern, perhaps you would consider just targeting f39 and for f38 just doing test days and reminders asking developers to test instead of changing it and then changing it back? > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > and decides if it can remain on in f38 and if not, it gets reverted and > > moved to f39. > > Not sure how it's better than reverting in branched f38 but not rawhide, > unless the goal is to hasten the change. It's better because it seems more direct and honest to me. It means you are landing a change and trying to get it done, not landing it to break people and then at the last minute after people rush to fix things, removing it again. I also suspect there will be some feet dragging due to this: "Oh, it's broken now, but they are going to revert it anyhow, so I won't do anything". > > > In the run up to f38 beta we could: > > > > * run a series of test days. perhaps one before you enable it in > > rawhide, one a month or two later and one right before f38 beta > > freeze? > > I'm for more test days. > There was one held already and I'm open for holding more in the future. > Plus I should attempt some side-tag mass-rebuild or equivalent, > but I, unfortunately, won't get to it until October at the earliest. Sure, understand time is low for everyone. ;( > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > tests on a compose or updates? This might be a good thing to try and do > > before landing it in rawhide. > > Sounds great if that's a possibility, but I don't know how to approach it. Perhaps Adam can chime in here... > > * setup a tracking bug to track the issues, so we can make a more > > informed decision before f38 beta. > > > > Thoughts? > > If the core of your proposal is > * make it happen in f38 and revert and push back to f39 only if necessary > as opposed to > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > but not f38 branched (the current proposal) > then I can't say I understand what you are trying to achieve with > that. I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just kidding, it will not take effect until next cycle. That just seems to be dishonest to our users. > IMO it makes the switch less certain, more frantic and more abrupt, > while I was trying to smoothen it out in time as far as possible. I don't think it's possible to cleanly spread out a change like this over more than 1 long fedora cycle. > > So +1 on all the accompanying activities possible, > -1 on expediting the switch. ok. I'm not sure where the rest of fesco is on this, but I guess we will see. :) Thanks for listening. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
I just copied and pasted from the OP... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Donate 1 minute of your time to test upgrades from F36 to F37
On Wed, 14 Sep 2022 05:06:29 -
"Richard Myers" wrote:
> This is for F35 -> F37 ...
>
> I sure
> would love it if anybody knows how to fix the below warning(?), which
> shows up every time I run DNF (it has persisted through at least 3 or
> 4 Fedora revisions, maybe more):
>
> Traceback (most recent call last):
> File "/usr/lib/python3.10/site-packages/dnf/plugin.py", line 104,
> in _caller getattr(plugin, method)()
> File
> "/usr/lib/python3.10/site-packages/dnf-plugins/generate_completion_cache.py",
> line 62, in sack cur.execute("delete from available")
> sqlite3.DatabaseError: database disk image is malformed
>
> I've tried (in the past) many things to try to fix it, but nothing
> worked. Can't remember everything I tried, because it has been a
> couple of years, but suffice to say, I've tried the low-hanging,
> obvious stuff, and some obscure things...
The database it is trying to access is
/var/cache/dnf/packages.db
If you delete it, it will rebuild it at the next update, and that
should take care of the error, since it shouldn't build a malformed
database from scratch. If it does, you should open an error agaist
package
python3-dnf-plugins-core
component
generate_completion_cache.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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
TLS client certificates is actually not a terrible idea. They're not very popular anymore, but they're supported by all major browsers (I think?) and they work. On Wed, Sep 14 2022 at 02:08:32 PM +0200, Vitaly Zaitsev via devel wrote: On 14/09/2022 10:01, Demi Marie Obenour wrote: Still, even a pure software FIDO2 implementation is much better than TOTP etc. I don't think so. Malware can easily steal the private key. Simple TOTP on a separate device is much better. Well they're different threats with different solutions. Installing malware on users' computers is a lot harder than phishing them, so I'd much rather see software-based FIDO2 than TOTP on a separate device. At least I'm not aware of any malware running on my computer, but I already confessed to entering a password into a phishing website, so we know you can phish me at least. If you want to protect against *both* threats, use a security key, but you've already pushed back against requiring a hardware purchase. It's impossible to enforce use of a separate device regardless of whether you're doing TOTP or FIDO2. I use my Yubikey only for my highest-security work account. Everything else uses a TOTP app running on-device, vulnerable to malware. (I don't want to buy a smartphone just to do TOTP: no way. A $25 security key sounds much more reasonable.) Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Explicit dependency on systemd-rpm-macros now required?
On Wed, Sep 14, 2022 at 10:53 AM Smith, Stewart via devel
wrote:
>
>
> > On Sep 14, 2022, at 4:17 AM, Tom Hughes via devel
> > wrote:
> >
> >> On 14/09/2022 12:11, Florian Weimer wrote:
> >> I see some new build failures in rawhide related to systemd RPM macros:
> >>
> >> Processing files: opencryptoki-3.18.0-4.fc38.s390x
> >> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
> >> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
> >> […]
> >> RPM build errors:
> >> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
> >> File must begin with "/": %{_unitdir}/pkcsslotd.service
> >> Child return code was: 1
> >> EXCEPTION: [Error()]
> >>
> >> Is this a package problem (missing dependency on systemd-rpm-macros), or
> >> is this something that should be fixed at the buildroot level?
> >
> > Guidelines say yes, you do need a BR on that:
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
>
> I think there was some change “recently” where it needed to start being
> explicit rather than being brought in by some other dependency (possibly a
> change to systemd?). I hit the same thing in a package in Amazon Linux the
> other day, read the packaging guide and wondered how the package had ever
> built.
It happened because Zbigniew changed the rich dependency from Requires
to Requires(meta):
https://src.fedoraproject.org/rpms/systemd/c/c971c5b980dff46fb9d7885f9e26b179a5a4749b
I don't think Requires(meta) works when weak dependencies are turned off.
--
真実はいつも一つ！/ 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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Remaining packages in need of a Python 3.11 rebuild
On 14. 09. 22 16:36, Casper wrote: Miro Hrončok a écrit : profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. I just made package update 1 hour ago. Cross-fire :) https://bodhi.fedoraproject.org/updates/FEDORA-2022-245be5acd2 RHBZ#2049682 is now closed. Awesome, thanks! PS I've reopened the bugzilla and marked the update as fixing it. -- 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
Re: Explicit dependency on systemd-rpm-macros now required?
> On Sep 14, 2022, at 4:17 AM, Tom Hughes via devel
> wrote:
>
>> On 14/09/2022 12:11, Florian Weimer wrote:
>> I see some new build failures in rawhide related to systemd RPM macros:
>>
>> Processing files: opencryptoki-3.18.0-4.fc38.s390x
>> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
>> […]
>> RPM build errors:
>> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> File must begin with "/": %{_unitdir}/pkcsslotd.service
>> Child return code was: 1
>> EXCEPTION: [Error()]
>>
>> Is this a package problem (missing dependency on systemd-rpm-macros), or
>> is this something that should be fixed at the buildroot level?
>
> Guidelines say yes, you do need a BR on that:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
I think there was some change “recently” where it needed to start being
explicit rather than being brought in by some other dependency (possibly a
change to systemd?). I hit the same thing in a package in Amazon Linux the
other day, read the packaging guide and wondered how the package had ever built.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 ke, 14 syys 2022, Stephen Smoogen wrote: On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy wrote: Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules. If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do. There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA' I understand all of that myself. I think what is important here is to plan to work together so that eventually we can implement this. This whole thread is about agreeing or disagreeing whether Fedora as a project would want to have better security methods to identify and authenticate its contributors when performing tasks that have large impact. If Fedora contributors would have had access to Fedora's FreeIPA web UI or IPA API directly, we wouldn't even need to have a conversation about PKINIT and certificates. We could have added instructions how to request and associate a certificate with your account. But since Fedora Accounts system is the frontend to Fedora Project's FreeIPA deployment, we cannot simply do that. However, FreeIPA-wise, smartcards are supported now for Kerberos authentication, so we as Fedora contributors could benefit from that. I hope we can plan to work together on this improvement again, similar how we did with the initial rewrite of Fedora Accounts on top of FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, perhaps CPA team could consider scheduling this effort as part of the initiatives. Let me round up methods that we have supported now or plan to add in Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to issuance of a Kerberos ticket that can be used for communicating with the rest of Fedora services: - basic password-based authentication - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an external RADIUS server for validation of a string passed as a 'password' or 'token' value - use of a certificate stored on a supported PKCS11 token (smartcard, softtoken (SoftHSMv2, NSS) or just in plain keypair files) - use of OAuth2 device authorization grant against some OAuth2 IdP (new in FreeIPA 4.9.10+) - (future) use of a FIDO2/WebAuthn token Fedora accounts system implements the management of the first two methods right now. As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs. A particular benefit of using Kerberos authentication to Fedora services is that it does not need to change the workflow for all those things. Once you've got your ticket, it works against all the services you are allowed to access. Sure, actual process of obtaining that ticket might change -- like with 2FA token one needs to get a wrap ticket first -- but the rest is the same. They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard. Do we have any statistics of how we stand now that Fedora Accounts is deployed for more than a year and people were enabled to use 2FA tokens through it? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Remaining packages in need of a Python 3.11 rebuild
Miro Hrončok a écrit : > profanity > @fantom > ASSIGNED https://bugzilla.redhat.com/2049682 > Bug status changed ~3 weeks ago without comment, > not updated since. > Fixed in rawhide recently, f37-candidate build exists. > I just made package update 1 hour ago. Cross-fire :) https://bodhi.fedoraproject.org/updates/FEDORA-2022-245be5acd2 RHBZ#2049682 is now closed. -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der Jabber/XMPP Messaging: cas...@casperlefantom.net signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Remaining packages in need of a Python 3.11 rebuild
Hello folks! We are approaching Fedora 37 Final Freeze, which will start on 2022-10-04. There are still 33 packages in Fedora 37 that will need to be rebuilt with Python 3.11 in order to be installable (most of them). I propose to retire the non-installable packages if they are not rebuilt by 2022-10-03 (1 day before the final freeze) unless they have a freeze exception request and a clear path forward to make it to Fedora 37 GA. Packages that will be fixed after GA can be reintroduced with an update. Packages by maintainer: aekoroglu python-funcy python-sendgrid amoralej python-yappi bizdelnick dlib dcavalca monkeytype fabhome-assistant-cli python-haversion python-requests-credssp fantom profanity gicmo renderdoc ibotty paternoster kevin datanommer luya dlib mcurlejmodule-build merlinmpython-calligrabot mkulik module-build ngompa kiwi-boxed-plugin python-hyperkitty python-postorius oget muse orphan python-calligrabot python-cu2qu python-evic qulogicpython-octave-kernel ralph datagrepper datanommer-commands raphgrojpype py4j python-javabridge python-jep rathannpython-Pympler python-filecheck salimmamailman3 monkeytype python-django-mailman3 python-hyperkitty python-postorius sdgathman cjdns sharkczsigil cjdns @sdgathman ASSIGNED https://bugzilla.redhat.com/2045255 2 possible ways forward but no news for ~3 weeks datagrepper @ralph ASSIGNED https://bugzilla.redhat.com/2098691 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround. Maybe persuade upstream into not doing that long-term. datanommer @kevin NEW https://bugzilla.redhat.com/2098692 Upstream (Fedora Infra) pins dependencies aggressively, needs to be relaxed downstream (also Fedora Infra) as a workaround Maybe persuade upstream into not doing that long-term. Will be retired one week before the freeze anyway barbecue it's an old NEW. datanommer-commands @ralph ASSIGNED https://bugzilla.redhat.com/2098693 Seems to have been updated in dist-git to a version with missing dependencies? dlib @bizdelnick @luya ASSIGNED https://bugzilla.redhat.com/2098694 Bundles old pybind11 which is not Python 3.11 compatible, needs to be unbundled or at least updated. home-assistant-cli @fab ASSIGNED https://bugzilla.redhat.com/2058155 Bug status changed in March without comment, not updated since. jpype @raphgro NEW https://bugzilla.redhat.com/2049705 Upstream PR exists: https://github.com/jpype-project/jpype/pull/1087 kiwi-boxed-plugin @ngompa NEW https://bugzilla.redhat.com/2098732 Already orphaned once due to non-responsivnes, took again by the same maintainer without response. Fixed in Rawhide recently, requested a Fedora 37 fix. Will be retired one week before the freeze anyway barbecue it's an old NEW. mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2098746 Bug status changed ~4 weeks ago without comment, not updated since. module-build @mcurlej @mkulik ASSIGNED https://bugzilla.redhat.com/2098750 Fixed in rawhide recently, requested a Fedora 37 fix. monkeytype @dcavalca @salimma ASSIGNED https://bugzilla.redhat.com/2098752 Maintainer "will try to fix this" ~3 weeks ago, no news since. muse @oget NEW https://bugzilla.redhat.com/2103647 Accidentally closed before, but still does not build. Only requires libpython3.10.so.1.0()(64bit) so is installable. paternoster @ibotty ASSIGNED https://bugzilla.redhat.com/2098772 Maintainer agreed to retire ~3 weeks ago, no news since. profanity @fantom ASSIGNED https://bugzilla.redhat.com/2049682 Bug status changed ~3 weeks ago without comment, not updated since. Fixed in rawhide recently, f37-candidate build exists. py4j @raphgro NEW https://bugzilla.redhat.com/2098787 Already CLOSED DEFERRED once by the maintainer, no fix. python-calligrabot @merlinm @orphan NEW https://bugzilla.redhat.com/2098856 Already orphaned once due to non-responsivnes, took again by a different maintainer, orphaned again by them. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-cu2qu @orphan NEW https://bugzilla.redhat.com/2098875 Already orphaned due to non-responsivnes. Should be retired as it is not needed any more. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-django-mailman3 @salimma ASSIGNED https://bugzilla.redhat.com/2044961 Bug status changed in March without comment, not updated since. python-evic @orphan NEW https://bugzilla.redhat.com/2098904 Already orphaned due to non-responsivnes. Will be retired one week before the freeze anyway barbecue it's an old NEW. python-filecheck @rathann ASSIGNED https://bugzilla.redhat.com/2098908 Last comment in June, no news since. python-funcy @aekoroglu NEW https://bugzilla.redhat.com/2098917 Orphaned (used to be Igor's?), taken by another maintainer, no update. Will be retired one week before the freeze anyway barbecue it's an old NEW.
Re: Donate 1 minute of your time to test upgrades from F36 to F37
# dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync Last metadata expiration check: 0:06:44 ago on Wed 14 Sep 2022 02:12:53 PM CEST. Error: Problem: problem with installed package python3-lhafile-0.3.0-6.1.x86_64 - package python3-lhafile-0.3.0-6.1.x86_64 requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) # dnf --releasever=37 --setopt=module_platform_id=platform:f37 --enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) --assumeno distro-sync --skip-broken Last metadata expiration check: 0:07:12 ago on Wed 14 Sep 2022 02:12:53 PM CEST. Error: Problem: problem with installed package python3-lhafile-0.3.0-6.1.x86_64 - package python3-lhafile-0.3.0-6.1.x86_64 requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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, 14 Sept 2022 at 05:28, Alexander Bokovoy wrote: > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > certificate authority that is trusted by the KDC as well. For example, > by FreeIPA CA which is already ran by the Fedora project infrastructure > team. An alternative is to set up certificate mapping and validating > rules. > > If someone from Fedora Accounts team wants to experiment with this, I > can guide you what to do. > There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA' As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs. They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 14/09/2022 10:01, Demi Marie Obenour wrote: Still, even a pure software FIDO2 implementation is much better than TOTP etc. I don't think so. Malware can easily steal the private key. Simple TOTP on a separate device is much better. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
* Tom Hughes via devel:
> On 14/09/2022 12:11, Florian Weimer wrote:
>> I see some new build failures in rawhide related to systemd RPM macros:
>> Processing files: opencryptoki-3.18.0-4.fc38.s390x
>> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
>> […]
>> RPM build errors:
>> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> File must begin with "/": %{_unitdir}/pkcsslotd.service
>> Child return code was: 1
>> EXCEPTION: [Error()]
>> Is this a package problem (missing dependency on
>> systemd-rpm-macros), or
>> is this something that should be fixed at the buildroot level?
>
> Guidelines say yes, you do need a BR on that:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
Ah, thanks, missed that. I'll try to fix opencryptoki then.
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Explicit dependency on systemd-rpm-macros now required?
On 14/09/2022 12:11, Florian Weimer wrote:
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Guidelines say yes, you do need a BR on that:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Explicit dependency on systemd-rpm-macros now required?
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20220914.n.0 changes
OLD: Fedora-Rawhide-20220913.n.0 NEW: Fedora-Rawhide-20220914.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:2 Upgraded packages: 174 Downgraded packages: 0 Size of added packages: 323.29 KiB Size of dropped packages:100.91 MiB Size of upgraded packages: 3.05 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -86.31 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: python-azure-eventhub-5.10.1-1.fc38 Summary: Microsoft Azure Event Hubs Client Library for Python RPMs:python3-azure-eventhub Size:249.78 KiB Package: python-azure-mgmt-fluidrelay-1.0.0-1.fc38 Summary: Microsoft Azure Fluid Relay Management Client Library for Python RPMs:python3-azure-mgmt-fluidrelay Size:73.50 KiB = DROPPED PACKAGES = Package: rust-starship-1.2.1-5.fc37 Summary: Minimal, blazing-fast, and infinitely customizable prompt for any shell RPMs:rust-starship+battery-devel rust-starship+default-devel rust-starship+notify-rust-devel rust-starship+starship-battery-devel rust-starship-devel starship Size:7.82 MiB Package: valyriatear-1.0.0-26.fc37 Summary: Valyria Tear is a free 2D J-RPG based on the Hero of Allacrost engine RPMs:valyriatear valyriatear-data Size:93.09 MiB = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.12.63-1.fc38 Old package: ImageMagick-1:6.9.12.62-1.fc38 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 33.76 MiB Size change: 6.30 KiB Changelog: * Tue Sep 13 2022 S??rgio Basto - 1:6.9.12.63-1 - Update ImageMagick to 6.9.12.63 (#2125990) Package: amiri-fonts-0.117-1.fc38 Old package: amiri-fonts-0.113-4.fc37 Summary: A classical Arabic font in Naskh style RPMs: amiri-fonts amiri-fonts-all amiri-quran-colored-fonts amiri-quran-fonts Added RPMs: amiri-fonts-all amiri-quran-colored-fonts Dropped RPMs: amiri-fonts-common Size: 723.68 KiB Size change: -13.51 KiB Changelog: * Sat Sep 03 2022 Parag Nemade - 0.117-1 - Convert spec to new fonts packaging guidelines - Update to new upstream release 0.117 Package: ansible-collection-community-general-5.6.0-1.fc38 Old package: ansible-collection-community-general-5.5.0-1.fc38 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.49 MiB Size change: 3.75 KiB Changelog: * Tue Sep 13 2022 Maxwell G - 5.6.0-1 - Update to 5.6.0. Package: ant-1.10.12-8.fc38 Old package: ant-1.10.12-8.fc37 Summary: Java build tool RPMs: ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 ant-commons-logging ant-commons-net ant-imageio ant-javadoc ant-javamail ant-jdepend ant-jmf ant-jsch ant-junit ant-junit5 ant-lib ant-manual ant-swing ant-testutil ant-xz Size: 5.28 MiB Size change: 1.42 KiB Package: apache-commons-beanutils-1.9.4-11.fc38 Old package: apache-commons-beanutils-1.9.4-11.fc37 Summary: Java utility methods for accessing and modifying the properties of arbitrary JavaBeans RPMs: apache-commons-beanutils apache-commons-beanutils-javadoc Size: 624.27 KiB Size change: 97 B Package: apache-commons-cli-1.5.0-4.fc38 Old package: apache-commons-cli-1.5.0-4.fc37 Summary: Command Line Interface Library for Java RPMs: apache-commons-cli apache-commons-cli-javadoc Size: 255.16 KiB Size change: 29 B Package: apache-commons-codec-1.15-7.fc38 Old package: apache-commons-codec-1.15-7.fc37 Summary: Implementations of common encoders and decoders RPMs: apache-commons-codec apache-commons-codec-javadoc Size: 627.70 KiB Size change: -1.15 KiB Package: apache-commons-collections-3.2.2-28.fc38 Old package: apache-commons-collections-3.2.2-28.fc37 Summary: Provides new interfaces, implementations and utilities for Java Collections RPMs: apache-commons-collections apache-commons-collections-javadoc apache-commons-collections-testframework Size: 1.46 MiB Size change: -1.15 KiB Package: apache-commons-compress-1.21-4.fc38 Old package: apache-commons-compress-1.21-4.fc37 Summary: Java API for working with compressed files and archivers RPMs: apache-commons-compress apache-commons-compress-javadoc Size: 1.31 MiB Size change: -704 B Package: apache-commons-io-1:2.11.0-2.fc38 Old package: apache-commons-io-1:2.11.0-2.fc37 Summary: Utilities to assist with developing IO functionality RPMs: apache-commons-io apache-commons-io-javadoc Size: 864.33 KiB Size change: -402 B Package
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > How about this: > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. I'm open for proposals on the wording. =) > Rework the change so it's basically planning on making this change in > f38. That makes it closer than currently, defeating the purpose of letting people prepare. > Before f38 beta freeze, change owners/fesco looks at the state of things > and decides if it can remain on in f38 and if not, it gets reverted and > moved to f39. Not sure how it's better than reverting in branched f38 but not rawhide, unless the goal is to hasten the change. > In the run up to f38 beta we could: > > * run a series of test days. perhaps one before you enable it in > rawhide, one a month or two later and one right before f38 beta > freeze? I'm for more test days. There was one held already and I'm open for holding more in the future. Plus I should attempt some side-tag mass-rebuild or equivalent, but I, unfortunately, won't get to it until October at the earliest. > * see if openqa might have some way to set TEST-FEDORA39 and re-run > tests on a compose or updates? This might be a good thing to try and do > before landing it in rawhide. Sounds great if that's a possibility, but I don't know how to approach it. > * setup a tracking bug to track the issues, so we can make a more > informed decision before f38 beta. > > Thoughts? If the core of your proposal is * make it happen in f38 and revert and push back to f39 only if necessary as opposed to * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, but not f38 branched (the current proposal) then I can't say I understand what you are trying to achieve with that. IMO it makes the switch less certain, more frantic and more abrupt, while I was trying to smoothen it out in time as far as possible. So +1 on all the accompanying activities possible, -1 on expediting the switch. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 ke, 14 syys 2022, Demi Marie Obenour wrote: On 9/14/22 03:55, Vitaly Zaitsev via devel wrote: On 14/09/2022 08:46, Demi Marie Obenour wrote: The only other non-phishable authentication method is TLS client certificates and I would be fine with those. Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos. Could Fedora turn on PKINIT or make TLS client certificate authentication an option again? I think PKINIT support is active, otherwise you would not be able to use Anonymous PKINIT for FAST channel wrapping with OTP preauthentication. All we need is a way to associate a trusted certificate with the user and have the trust between KDC cert and the client machine where you'd run kinit: [1660786] 1663147221.189471: PKINIT client verified DH reply [1660786] 1663147221.189472: PKINIT client found id-pkinit-san in KDC cert: krbtgt/fedoraproject@fedoraproject.org [1660786] 1663147221.189473: PKINIT client matched KDC principal krbtgt/fedoraproject@fedoraproject.org against id-pkinit-san; no EKU check required [1660786] 1663147221.189474: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/1D6D [1660786] 1663147221.189475: Preauth module pkinit (17) (real) returned: 0/Success The latter works fine, so we just need to have a certificate in the user account to use PKINIT, not Anonymous PKINIT. And since we have no direct access to FreeIPA server behind Fedora Accounts system, Fedora Accounts should be extended to allow adding a public certificate to the user's account. Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules. If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do. since almost every laptop has a TPM. In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited. Still, even a pure software FIDO2 implementation is much better than TOTP etc. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: small aarch64 home server
On Tue, Sep 13, 2022 at 7:51 PM Chris Adams wrote: > > I'd like to piggy-back - is there a Fedora well-supported board that can > use the Pi-targeted hats? I stayed away from the Pi for a long while, > because of the support problems, but it just seems like there's so much > that's just made for Pis. HATs are hard, there's a lot of devices that claim to be compatible with the HAT interface but there's always caveats so it would depend very much on your usecase. P ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: glibc 2.36 and DT_HASH (preserving it for F37+)
* Vitaly Zaitsev via devel: > On 14/09/2022 05:27, Neal Gompa wrote: >> Well, we just released the Beta and people have noticed that this is >> still broken. Do we have an ETA on a fix? Because this is going to be >> a major black eye for*us* if it stays broken through to GA. > > Epic Games had more than a month to fix the problem but they did nothing. Why do you say that? These multi-ISV coordination issues can be difficult to resolve. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 9/13/22 21:37, Tommy Nguyen wrote: > On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote: >> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < >> devel@lists.fedoraproject.org> wrote: >> >>> On 06/09/2022 19:49, Michael Catanzaro wrote: Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2]. > > I think most people would find it not reasonable for contributors to an > open source project to pay any amount of cash, even $25, to gain > packaging rights. That's tantamount to a membership or entrance fee. There is a huge difference between accepting contributions from someone and trusting them with access to a vast number of people’s machines. Qubes OS accepts contributions from untrusted contributors, but it can only do so because all code is reviewed by hand before merging, so a malicious contribution simply will not be accepted. Fedora, on the other hand, lacks any means to limit the blast radius of a compromised account with packaging rights. Therefore, preventing such a compromise is critical, and hardware authenticators are currently the best means of doing so. In the long term, Fedora should figure out how to avoid having to trust such a large number of people with such power. But for now, requiring **unphishable** 2FA is the best option I am aware of. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 9/14/22 03:55, Vitaly Zaitsev via devel wrote: > On 14/09/2022 08:46, Demi Marie Obenour wrote: >> The only other >> non-phishable authentication method is TLS client certificates and >> I would be fine with those. > > Fedora used to have TLS client certificate authorization (in Koji), but > this has been replaced by Kerberos. Could Fedora turn on PKINIT or make TLS client certificate authentication an option again? >> since almost every laptop has a TPM. > > In some countries (Russia, China and some other countries from the US > export banlist) hardware TPMs are prohibited. Still, even a pure software FIDO2 implementation is much better than TOTP etc. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 14/09/2022 08:46, Demi Marie Obenour wrote: The only other non-phishable authentication method is TLS client certificates and I would be fine with those. Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos. since almost every laptop has a TPM. In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 13/09/2022 23:50, Demi Marie Obenour wrote: Another option is a TPM-based authenticator. Would this be acceptable? No. TPM 2.0 chip is a *proprietary* black box. Some of them have known critical security vulnerabilities[1]. [1]: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: glibc 2.36 and DT_HASH (preserving it for F37+)
On 14/09/2022 05:27, Neal Gompa wrote: Well, we just released the Beta and people have noticed that this is still broken. Do we have an ETA on a fix? Because this is going to be a major black eye for*us* if it stays broken through to GA. Epic Games had more than a month to fix the problem but they did nothing. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
