Re: New Fedora Planet
On Пан, 20 мая 2024, Pedro Moura wrote:
How can I add more feeds? Under my account I had feeds to two Packit
blogs, one ABRT and my personal.
So far, users can only add just one feed. We didn't know the necessity of
having more than one because we didn't get too many answers in the
research about sub-planets.
If that is an issue, we need to ask for an update in noggin and
consequently fasjson.
Judging by
https://github.com/fedora-infra/freeipa-fas/blob/dev/ipaserver/plugins/baseruserfas.py#L118-L124,
the backend already supports multi-valued fasRssUrl attribute.
'fasrssurl*' is FreeIPA syntax for 'zero or many values'. Indeed,
LDAP 'fasRssUrl` attribute definition lacks SINGLE, so it will be a
multi-valued one.
Noggin has support for lists of values for an attribute and defaults to
a single value. This needs to be fixed for 'rss_url' field in Noggin's
user representation by adding an attr_types override similar to how
'sshpubkeys' and 'gpgkeys' overridden.
So the only visible change needed is probably a Noggin's attr_type
override. fasjson will need a Converter('fasRssURL', multivalued=True)
and that should be enough.
Overall, this looks like a two-line change across two projects.
--
/ 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: F41 Change Proposal: Pytest 8 (self-contained)
On Суб, 06 кра 2024, Sandro wrote: On 05-04-2024 23:45, Aoife Moloney wrote: == Summary == Update to a new upstream release of pytest that is not completely compatible with previous releases. Pytest 8 is a major upstream release removing a lot of deprecated functions and introducing breaking changes. I was wondering how this will pan out with the introduction of Python 3.13, which is also planned for F41 and comes with its own set of breaking changes. Some of those affecting tests. The current test builds are run against Python 3.12. Will all Python packages also be tested against Python 3.13 with pytest 8 later on? Does that even make sense? Anyway, it's two major updates affecting the Python ecosystem, which are both aiming at F41. Maybe letting the dust settle on Python 3.13 first and then updating pytest to the next major release will let package maintainers (and upstream) focus more. Just some food for thought. On top of that, I wonder how the packages were chosen. FreeIPA is missing in the test COPR at all (but freeipa-healthcheck is present). FreeIPA is also missing in the list of affected packages. We do use pytest and some of more complex pytest plugins (multihost, sourceorder), also add our own extensions. I filed an upstream issue to track Pytest 8: https://pagure.io/freeipa/issue/9571 -- / 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: Three steps we could take to make supply chain attacks a bit harder
On Sun, 31 Mar 2024, Neal Gompa wrote: On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote: On 31/03/2024 13:03, Kevin Kofler via devel wrote: This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for contributors for a while, starting with "important" projects, then getting stricter and stricter. It has done absolutely nothing to stop this attack. How could it, when the backdoor was apparently introduced by the authorized maintainer? (Or if not, the attacker must have had access to their 2FA secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON US! And especially DO NOT abuse this incident as an excuse to force 2FA down our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! 2FA for Fedora packagers doesn't solve this issue, but that wasn't Adam's point. What Adam is saying is that we're in danger of focusing too much on a specific issue while we should spent our time and energy on the general security aspect of Fedora. 2FA isn't nonsense, it strengthens security by a lot. A compromised (proven)packager account can do a lot of harm and can take a while to be noticed. If this would happen to us, Fedora's reputation would tank immediately. Mint is still regarded as a insecure distro (in my circles) for things that happened before I even entered the linux scene... Like it or not, this is 2024 and passwords are not as secure as they used to be. Yelling about it isn't going to solve anything. Meanwhile, enabling 2FA helps A LOT even if used incorrectly (e.g. storing it in the same keepassxc database). At this point, I'm used to MFA for stuff (and I use a password manager that handles 2FA OTPs too), but the Fedora implementation of MFA is uniquely bad because we have to do a lot in the terminal, and our MFA implementation sucks for terminal usage. If MFA is turned on: 1. The Fedora account integration in GNOME breaks 2. You need to concatenate password and OTP for getting a krb5 session ticket 3. The recovery mechanism involves GPG signed emails The experience using 2FA for Fedora accounts is sufficiently unpleasant that I really don't want to use it. We need to fix these problems anyway. For the first two I am working on a potential solution as a part of FreeIPA passwordless authentication support. As you know, FreeIPA supports more than just OTP method that Fedora Project is currently using. The way how that support is implemented through Kerberos makes it uniform for OTP, RADIUS, passkeys, and external IdP pre-authentication methods. Since internal bits of SSSD already implement support for all these methods in a proper way, we might reuse those to improve Fedora user experience. -- / 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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Срд, 20 сак 2024, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We disable support of engines in OpenSSL
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbely...@redhat.com
== Detailed Description ==
We are going to build OpenSSL without engine support. Engines are not
FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
The engine functionality we are aware of (PKCS#11, TPM) is either
covered by providers or will be covered soon.
== Feedback ==
== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to the engine. So we reduce the maintenance
burden and potentially attack surface.
Hi,
In systemd, we recently added support for engines in various tools:
- systemd-{repart,measure} have --private-key-source=file|engine|provider
(this is C code).
- ukify has --signing-engine.
This is Python code that calls sbsign or pesign to do parts of the
heavy lifting, and those binaries do not support providers. (At least
the docs are silent on this, please correct it they do.)
So it seems we'd lose support for signing with keys stored on yubikeys
and tpms and other fancy approaches if the proposed change goes through.
--
Also, what is the impact on:
- kernel module signing in the build system
scrips/sign-file.c would need to migrate from use of ENGINE_* API to
providers. This is trivial as the only use is to find pkcs11 engine and
then load a private key through it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/sign-file.c#n142
static EVP_PKEY *read_private_key(const char *private_key_name)
{
EVP_PKEY *private_key;
if (!strncmp(private_key_name, "pkcs11:", 7)) {
ENGINE *e;
ENGINE_load_builtin_engines();
drain_openssl_errors();
e = ENGINE_by_id("pkcs11");
ERR(!e, "Load PKCS#11 ENGINE");
if (ENGINE_init(e))
drain_openssl_errors();
else
ERR(1, "ENGINE_init");
if (key_pass)
ERR(!ENGINE_ctrl_cmd_string(e, "PIN", key_pass, 0),
"Set PKCS#11 PIN");
private_key = ENGINE_load_private_key(e, private_key_name,
NULL, NULL);
ERR(!private_key, "%s", private_key_name);
} else {
BIO *b;
b = BIO_new_file(private_key_name, "rb");
ERR(!b, "%s", private_key_name);
private_key = PEM_read_bio_PrivateKey(b, NULL, pem_pw_cb,
NULL);
ERR(!private_key, "%s", private_key_name);
BIO_free(b);
}
return private_key;
}
Dmitry, I think it is something your team needs to handle (submit
support for provider vs engine to Linux kernel upstream).
- signing of shim, grub2, fwupd, and the kernel in the build system
- mokutil
mokutil does not use ENGINE_* APIs at all.
--
/ 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: F40 Change Proposal: 389_Directory_Server_3.0.0 (System-Wide)
:
* Configure 389 Directory Server instances (like FreeIPA) because the
set of configuration attributes for the backend depends on the
underlying database implementation.
The unused parameters are ignored, so it should not impact the compatibility.
But there is a risk with the new parameters: the "20 GB" default value
for the LMDB database maximum size may not be large enough for the
application's needs.
* Monitor 389 Directory Server backends because the set of attributes
in the monitoring entries also depends on the underlying database
implementation.
More details about these points are described in
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
389 Directory Server FAQ - BerkeleyDB backend deprecation]
== How To Test ==
[https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-freeipa-tests/
COPR project] contains builds that can be tested (F37, F38, F39,
rawhide on x86_64 and s390x).
So you can install them by using:
sudo dnf copr enable -y @389ds/389-ds-base-freeipa-tests
sudo dnf install 389-ds-base-3.0.0
Then you can create new directory server instances and use them.
== User Experience ==
Prepare for the removal of an obsolete piece of software that is no
longer supported by the upstream community. This process aims to
provide more visibility to its replacement.
== Dependencies ==
All the dependent packages are owned by 389DS and FreeIPA teams:
`dnf repoquery --whatrequires 389-ds-base --recursive`
{| class="wikitable"
|+
|-
! Package !! Owner !! Tests
|-
| 389-ds-base-snmp|| 389DS || Tested by 389DS CI test
|-
| cockpit-389-ds || 389DS || Tested by 389DS CI test
|-
| freeipa-fas || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-healthcheck || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server-dns || FreeIPA || Tested by FreeIPA CI test
|-
| freeipa-server-trust-ad || FreeIPA || Tested by FreeIPA CI test
|-
| migrationtools || 389DS || Not impacted by the change
|-
| slapi-nis || FreeIPA || Tested by FreeIPA CI test
|}
== Contingency Plan ==
* Contingency mechanism:
* Revert the default backend implementation to Berkeley Database
* If libdb-5.3 or libdb-devel is no longer shipped in Fedora:
The plan is to build libdb static library as part of 389-ds-base build
process and link libback-ldbm statically with it
(as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_statically_linking_executables).
The risk is that we may have to generate patches in case of CVE that
impacts 389-ds or in case of build environment changes until we can
remove the support of the bdb backend. libdb-5.3.28-55.fc38.src shows
that the risk is quite limited (1 cve and one set of patches related
to c99 since 2017).
* Contingency deadline: Fedora 40 beta freeze (2024-02-20)
* Blocks release? No
== Documentation ==
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
Directory Server FAQ - BerkeleyDB backend deprecation]
== Release Notes ==
Need to write release notes for 3.0.0 in
https://www.port389.org/docs/389ds/releases/release-notes.html as
usual for 389DS.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@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: How to handle updates with large python dependency chains?
On ti, 02 touko 2023, Sandro Mani wrote: Hi I'm working on packaging pgadmin4-7.0, which bumped several python dependencies, requiring multiple updates of existing fedora packages. I started by building newer version of all direct dependencies in copr [1], and then investigating the dependencies trees of the direct dependencies. So here come the questions: - It is kinda hard to know which python dependencies are really affected. What is the best practice? Just limiting to checking those which have a version-constrained dependency which would not be satisfied by the update? - So far I've filed multiple PRs for the various dependencies, but it is fairly unrealistic to have these all processed in a timely manner. I'm assuming the best way forward is a self-contained change? This is not a self-contained change if for PostgreSQL admininstration it bumps bunch of packages like python-cryptography and python-gssapi. ;) Is there a real need to bump them? Specifically, python-cryptography does break a lot with its changes -- we got broken twice in FreeIPA in this year. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/pgadmin4-7.0/builds/ -- / 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: Orphaning despite having maintainers?
On to, 27 huhti 2023, Alexander Bokovoy wrote: On ke, 26 huhti 2023, Gary Buhrmaster wrote: On Wed, Apr 26, 2023 at 9:04 AM Alexander Bokovoy wrote: Hi, This morning I woke up to find that packages I maintain were orphaned out of blue. Nobody contacted the maintainers, nobody raised any tickets to releng, as far as I can see. Yet, releng ran the orphaning from what I saw in a few bugs. What is happening? Who and how made those decisions? Removing inactive packagers (who have not made any package updates, nor responded to direct emails, for an extended period are removed from the packagers group as part of good security hygiene per: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ It is an artifact of that fact that in Fedora, packages have only one main admin, and when that packager is removed from the packagers group, their packages get orphaned (there is no automated promotion, and nor should there be, to select one of the other maintainers, as that would also imply other responsibilities that one might not want). You (or other interested packager) can go to: https://src.fedoraproject.org and "Take" that packager to become the new main admin/owner. My concern is that for packages that have more than one maintainer, no notification that the packages will be orphaned has happened to them. This is a pretty bad situation. Take, for example, cifs-utils. It had six maintainers, including inactive admin at that point. None of the maintainers except the inactive person received any notification that the package was going to be orphaned. I understand the logic behind 'no automated promotion' but the current logic in the process is effectively not treating existing maintainers as worth anything. I see this as a problem with the policy and I am raising this issue as I believe we should fix the policy. I filed https://www.pagure.io/fesco/issue/2987 to address the policy 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: Orphaning despite having maintainers?
On to, 27 huhti 2023, Miro Hrončok wrote: On 27. 04. 23 12:19, Alexander Bokovoy wrote: The graph in the packager dashboard is showing that resteasy directly depends on java-1.8.0-openjdk which is not true. resteasy (maintained by: cfu, cipherboy, ckelley, edewata, jmagne, mfargett, mharmsen, vakwetu) pki-resteasy-client-3.0.26-23.fc38.noarch requires java-1.8.0-headless = 1:1.8.0.362.b09-2.fc38 pki-resteasy-core-3.0.26-23.fc38.noarch requires java-1.8.0-headless = 1:1.8.0.362.b09-2.fc38 pki-resteasy-jackson2-provider-3.0.26-23.fc38.noarch requires java-1.8.0-headless = 1:1.8.0.362.b09-2.fc38 That is not what is in the binary package (spec file does not even have that dependency expression directly). Binary package https://koji.fedoraproject.org/koji/rpminfo?rpmID=33490808 has the following Requires statement: (java-headless or java-17-headless or java-11-headless or java-1.8.0-headless) This library is usable with any supported JDK build. -- / 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: Orphaning despite having maintainers?
On to, 27 huhti 2023, Stephen Smoogen wrote: On Wed, 26 Apr 2023 at 22:32, Alexander Bokovoy wrote: On ke, 26 huhti 2023, Kevin Fenzi wrote: >On Wed, Apr 26, 2023 at 07:23:10PM +0100, Chris Kelley wrote: >> One thing I still don't understand is why all of our java packages are >> orphan-affected by the orphaning of java-1.8.0-openjdk. None of them >> BuildRequires a JDK, and the source/target/release values for the packages >> range from 6 to 17. Can anyone shed some light on this please? > >What do you mean by 'orphan-affected'? > >I only see java-1.8.0-openjdk orphaned... what are the other packages >you see and how are they affected? Packager dashboard shows that resteasy is depending on java-1.8.0-openjdk but it is not. When I don't have java-1.8.0-openjdk installed and attempt to install build dependencies for resteasy package, I don't see it pulling in java-1.8.0-openjdk: Doesn't that also need to cover all of the build requires for those components also? It isn't just that a package may need it in an install, it may also need it to be rebuilt. The graph in the packager dashboard is showing that resteasy directly depends on java-1.8.0-openjdk which is not true. It may be a bug in the original data gathering script as well. Right now dogtag-pki is off the hook, nothing shows that it is 'orphan-impacted'. However, for ecj I still get that and it shows explicit dependency on java-1.8.0-openjdk as well while ecj has following list of dependencies: Build dependencies: - ant - java-11-openjdk-devel - javapackages-local Binary dependencies: - (java-headless or java-11-headless or java-1.8.0-headless) - /usr/bin/bash - javapackages-filesystem Perhaps, the generator takes an explicit mentioning of java-1.8.0-headless as the required dependency? -- / 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: Orphaning despite having maintainers?
16 k javapackages-local noarch 6.1.0-7.fc38 fedora 9.0 k jdeparser noarch 2.0.3-13.fc38 fedora 219 k python3-javapackagesnoarch 6.1.0-7.fc38 fedora 109 k xmvn-core noarch 4.0.0-12.fc38 fedora 122 k xmvn-minimalnoarch 4.0.0-12.fc38 fedora 45 k xmvn-mojo noarch 4.0.0-12.fc38 fedora 63 k xmvn-tools noarch 4.0.0-12.fc38 fedora 115 k Transaction Summary === Install 19 Packages Total download size: 1.6 M Installed size: 2.4 M Is this ok [y/N]: -- / 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: Orphaning despite having maintainers?
On ke, 26 huhti 2023, Gary Buhrmaster wrote: On Wed, Apr 26, 2023 at 9:04 AM Alexander Bokovoy wrote: Hi, This morning I woke up to find that packages I maintain were orphaned out of blue. Nobody contacted the maintainers, nobody raised any tickets to releng, as far as I can see. Yet, releng ran the orphaning from what I saw in a few bugs. What is happening? Who and how made those decisions? Removing inactive packagers (who have not made any package updates, nor responded to direct emails, for an extended period are removed from the packagers group as part of good security hygiene per: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ It is an artifact of that fact that in Fedora, packages have only one main admin, and when that packager is removed from the packagers group, their packages get orphaned (there is no automated promotion, and nor should there be, to select one of the other maintainers, as that would also imply other responsibilities that one might not want). You (or other interested packager) can go to: https://src.fedoraproject.org and "Take" that packager to become the new main admin/owner. My concern is that for packages that have more than one maintainer, no notification that the packages will be orphaned has happened to them. This is a pretty bad situation. Take, for example, cifs-utils. It had six maintainers, including inactive admin at that point. None of the maintainers except the inactive person received any notification that the package was going to be orphaned. I understand the logic behind 'no automated promotion' but the current logic in the process is effectively not treating existing maintainers as worth anything. I see this as a problem with the policy and I am raising this issue as I believe we should fix the policy. -- / 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
Orphaning despite having maintainers?
Hi, This morning I woke up to find that packages I maintain were orphaned out of blue. Nobody contacted the maintainers, nobody raised any tickets to releng, as far as I can see. Yet, releng ran the orphaning from what I saw in a few bugs. What is happening? Who and how made those decisions? I raised the issue https://pagure.io/releng/issue/11406 -- if you also experienced a similar orphaning, please add your data. -- / 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: It’s time to transform the Fedora devel list into something new
On to, 20 huhti 2023, Stephen Smoogen wrote: On Thu, 20 Apr 2023 at 18:47, Matthew Miller wrote: On Thu, Apr 20, 2023 at 05:39:51PM -0400, Stephen Smoogen wrote: > I hate to ask this but could you give a more summarized version of this > email? I realize you had a lot of reasoning you wanted to cover on the > why's but I frankly got lost several times. That makes it really hard not > to respond in ways which are overly emotional and not helpful. Anything I > wrote would start with me trying to summarize what was written but failing > to do so, or I would end up trying to pick apart different paragraphs in > non-helpful ways. Sure. I realize it is quite long. I am proposing that over the course of 2023, starting with the Changes process, we move Fedora development conversations from this mailing list to the Discourse-based Fedora Discussion. Many Fedora folks, new and old, can't keep with this list. The number of participants is down over time (even as the number of threads has risen). Many teams are moving away from devel list anyway -- using various scattered bug trackers as their effective "forum". Discourse gives us better tools for the conversations we need to have as a project. I know it takes some getting used to, but I strongly believe it will be worth it. Devel list actually covers a lot of different topics. Discourse lets us categorize those better while still keeping it all together. The first thing I suggest moving is discussion around proposed Changes. This is a FESCo decision. The rest I won't duplicate here. Thank you. I have a better understanding of where you are coming from, and what this meant to do. I don't like the solution, but I know all too well that the current mailman3 solution works on a wing and a prayer. It has been running an EOL version of the software for a long time and there are not enough infrastructure resources to do all the things that are needed for an upgrade AND keep builds going. I also understand that the general community of the lists has shrunk over the last 10 years with it becoming more and more 'the same old people complaining about the same old things'. That said, I don't think I will be greatly active after the move. I have tried Discourse for a year, but have found it to be like every forum and BBS I have tried for the last 30 years.. frustrating and needy. I get tired and angry after 30 minutes and my replies start becoming the problem you don't want. [I realize this is how many people feel about email which causes them to drop out there.] If that lack of engagement requires me to orphan packages or other items, I completely understand. My main trouble with Discourse and other places where I try to help people with answers to their questions is that forums promote a drive-by questions without further engagement. This experience is opposite to what forum proponents are claiming but I see it pretty consistently on Discourse, on Stackoverflow sites, on Reddit and in many other places. In my area, identity management and authentication, the topics are complex enough to want to help others but lack of further engagement simply kills any interest to use a particular discussion board. If people asking questions aren't interested in getting the answers or even tying in the ends for their own questions, it comes hard to keep an interest in helping those people again and again. I can point you to one specific topic on Fedora Discourse as an example: https://discussion.fedoraproject.org/t/fedora-login-bug-having-a-128-character-password-breaks-otp-and-will-lock-users-out-of-account/78960 I would have supposed that someone would follow-up, right? As a FreeIPA maintainer in Fedora, as an upstream FreeIPA contributor and a contact for security issues, I have never been contacted with either details for what the thread claims to happen or never got any follow-up on the thread to my comments. This is an experience I want to avoid. If this is what Matthew is proposing a Fedora development discussions to be, then sorry, this is not an improvement. -- / 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: Certbot 2.2.0 Update
On ti, 21 maalis 2023, Jonathan Wright via devel wrote: Hi, I've updated Certbot to 2.2.0 in rawhide, f38, f37, and epel9. I wanted to email devel and seek more testing than usual for this release as I've also converted the 10-15 packages to be built from a single spec instead of all broken up as they were prior (ref https://bugzilla.redhat.com/show_bug.cgi?id=2132123) If people could please update their certbot-related packages from epel-testing and provide feedback here and/or karma or comments on the updates in bodhi I'd be extremely grateful. Thanks. We have certbot tests in FreeIPA upstream. We run them against Rawhide weekly. Here is the one that was run on March 18th: http://freeipa-org-pr-ci.s3-website.eu-central-1.amazonaws.com/jobs/47908126-c5d5-11ed-84b2-fa163e02831a/report.html This one ran against certbot 2.1.0, but we'll see this Saturday how the tests will behave against 2.2.0. -- / 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: Regular crash of the internal DirectoryServer389 replication
On pe, 18 marras 2022, Dip Barua wrote: Hello all, I hope you are doing well. I would like to have your help because I have a Replication crash problem on 389DS. Here is the below some Frequent Error : Please open a bug for 389-ds-base package in Fedora's bugzilla. [25/Oct/2022:02:03:15.698645866 +0200] - ERR - slapi_ldap_bind - Could not send bind request for id [cn=Directory Manager] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 107 (Transport endpoint is not connected, host "wam2p.lefoyer.lu:389") [25/Oct/2022:02:06:27.558971677 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=lpfroot12" (wam2p:389): Replication bind with SIMPLE auth resumed [25/Oct/2022:07:25:15.490236609 +0200] - ERR - log_ber_too_big_error - conn=36614 fd=78 Incoming BER Element may be misformed. This may indicate an attempt to use TLS on a plaintext port, IE ldaps://localhost:389. Check your client's LDAP_URI settings. [25/Oct/2022:12:10:07.709047940 +0200] - ERR - NSMMReplicationPlugin - repl5_inc_waitfor_async_results - Timed out waiting for responses: 330754 330879 Thanks in advance for your help. Best Regards, Dipankar Barua ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: FontAwesome 6
On pe, 04 marras 2022, Jerry James wrote: On Tue, Nov 1, 2022 at 1:37 AM Matthias Runge wrote: As a former contributor to those packages, your assumption is correct. python-XStatic-Font-Awesome can go away; I'll sync with Radomir on that note. Great! One less package for me to worry about. :-) If someone relies on fontawesome-fonts, they should step up. The question is, how to get out of this, since there were incompatible changes between major package releases. Three options: I'm working on option 4: migrate all users to version 6. I have to admit that the packages that consume fontawesome through a web interface (I'm looking at you, freeipa and ipsilon) are proving somewhat troublesome. I am not a web developer, nor do I play one on TV. I'll muddle through it eventually, but would welcome help from any actual web developers with (cough, cough) free time. For FreeIPA I looked at the changes and it looks like we can upgrade it more or less easily. Please open a ticket at https://pagure.io/freeipa/ and point to your COPR. We would need to add a variant of our patternfly adaptation (install/ui/less/patternfly.less) that would use new *.less definitions for the v6 version. There are few things to handle there because we are still using patternfly v3 in the current web UI code. There is also another package you need to look at: while FreeIPA reuses system fonts, Dogtag PKI embeds fontawesome (and few more) several times: # rpm -qf /usr/share/pki/acme/webapps/acme/css/assets/fonts/webfonts/fa-solid-900.woff dogtag-pki-acme-11.1.0-1.fc36.noarch # rpm -qf /usr/share/pki/common-ui/fonts/fontawesome-webfont.woff dogtag-pki-theme-11.1.0-1.fc36.noarch -- / 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: Inactive packagers to be removed after the F37 release
Hi, On to, 15 syys 2022, Kevin Fenzi wrote: > 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... I am open to it too, may be in couple weeks or so, to allow interested parties to prepare. Sure. Can you schedule something when you are ready/available and we can go from there. It took me more than couple weeks... I have been working on an article to describe what we are doing in FreeIPA and SSSD world with authentication against various identity providers and how that could help the Fedora Infrastructure. Long story short, there are now two articles: Part 1, where I am talking about Fedora infrastructure aspects: https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra/ Part 2, where FreeIPA-specific improvements and details discussed: https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra-2/ -- / 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: Inactive packagers to be removed after the F37 release
On to, 15 syys 2022, Kevin Fenzi wrote: On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote: Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers? Well, as others noted in this thread, any packager has a lot of power. They can add a weak dep on something everyone has installed and pull their package in. Of course they likely only get to do that once. 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. As far as I know, it's not possible to enforce otp per group is it? That would be a nice enhancement. It is on my radar. Additionally, right now, packagers commit with ssh keys or oidc tokens, in order for a 2fa setup to be effective, we would need to switch that to kerberos or the like. One thing I want to get properly implemented in SSSD in upcoming FIDO2 support is to allow admins to filter out certain types of public SSH keys associated with the user account. E.g. get a way for administrator to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk, ed25519-sk) allowed for these users' and let SSSD's sss_ssh_authorized_keys to filter all other types. Then your git server could be able to deny non-FIDO2 SSH keys on per-user base. FreeIPA Kerberos already gives you this feature for various authentication methods[1] but it is not integrated in OpenSSH's GSSAPI support. [1] https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html 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. Yeah, it will still be hard to require 100% of packagers, but it might be doable. Solving this is a social problem. I'd like to remove technical roadblocks so that we can better focus on the solutions to social problems. Right now we aren't there on both sides. 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 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... I am open to it too, may be in couple weeks or so, to allow interested parties to prepare. Sure. Can you schedule something when you are ready/available and we can go from there. Sure. I guess we can aim last week of October. I'll write up a call for participation next week. > > 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? > > I could try and gather some. What stats would be helpfull? A particular argument by smooge and others was arount 'passwords or tokens being lost frequently'. I'd like to see how widespread is this problem. Can we collect stats on amount of requests to reset passwords, reset tokens, etc. for a period of a year or so? We currently have 1560 tokens enrolled. (Of course some users have more than one, but most seem to have one) In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to reset otp. Some of these were people who were confused and didn't actually even have a otp enabled, but it's hard to count those without going through each request. So, it's less than 5% a year it seems like, or a request every 4days if they were evenly spaced. Thank you. This is actually better than I expected to see. Improving technical measures and UX should help but there always will be something that is harder to deal with, anyway. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org T
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 Acc
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: 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: Inactive packagers to be removed after the F37 release
On ti, 06 syys 2022, Adam Williamson wrote: On Tue, 2022-09-06 at 16:47 +, Tommy Nguyen wrote: On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote: > On 06/09/2022 17:00, Gary Buhrmaster wrote: > > mobile device > > Requires proprietary Google services. > > > computer > > Requires proprietary TPM 2.0 chip. Hi, Neither of this is true. For example, I use Raivo on my iOS device which isn't proprietary. It seems that your concerns regarding 2FA are based on a number of misconceptions. 1. That it will cost money You can generate TOTP codes using password generators, desktop apps, or even by hand in the command line. It's a simple algorithm that doesn't even require an Internet connection. However, in order for it to truly be 2FA, it should be on a separate device (i.e, your phone) though generating it on the desktop is what people do if they have no external device. 2. That the algorithm will pose problems in other countries I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and HMAC poses as much of a problem as you say it does, even in Russia/China. 3. That it requires specialized hardware Again, not true. See part 1. TOTP should work on any device regardless of the underlying hardware so long as it supports basic cryptographic primitives. This section of the thread seems to be moving rather at cross-purposes. This was mcatanzaro's original proposal: "In the long run, we should be moving to require WebAuthn for all Fedora authentication-related purposes, since it's unphishable. Last year I entered my GitHub password into a phishing page that was proxying the real GitHub... if the evil page had gone to just slightly more effort, it could have easily intercepted a simple TOTP/HOTP challenge. This is not possible with WebAuthn, which I would say actually is pretty much equivalent to a security magic bullet." i.e. it was specifically about moving away from allowing "simple TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which Vitaly's points are I believe accurate. Yep. We are not there yet with regards to this use case being implemented in Fedora AAA but our goal is to provide an infrastructure in Fedora 38 for Kerberos and local system integration, hopefully. Looking at hardware products, a cheapest FIDO2 authenticator I know about is a Token2 T2F2 FIDO2 and U2F Security Key (10.00 EUR per key plus shipping costs)[1]. I am in contact with Token2 to see if we can test this hardware in our SSSD/FreeIPA development. Google's OpenSK platform is something people already tried to turn into a FIDO2 virtual authenticator -- see [2] for example of integrating with QEMU. This is far from being complete and user-friendly. [1] https://www.token2.eu/shop/product/token2-t2f2-fido2-and-u2f-security-key [2] https://github.com/google/OpenSK/issues/485 -- / 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 17:05, Alexander Bokovoy wrote: The site blocks access from outside of Russia. Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English. Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-notification-for-encryption-or-notification-for-encrypted-pr/ There are solutions by Russian companies which use WebAuthn and were certified by Russian state (FSTEK). For example, Avanpost Web SSO and Avanpost FAM were certified in 2021. They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia. I happen to know as they support FreeIPA integration officially. The issue right now is not a non-certified usage but a basic unavailability of these tokens inside the country. However, this is a completely different store. Avanpost's press-releases (in Russian): https://avanpost.ru/news/928/ https://avanpost.ru/news/944/, and https://avanpost.ru/news/973/ -- / 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote: Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Sure (in Russian, use Google Translate): - http://clsz.fsb.ru/clsz/in-out.htm - http://clsz.fsb.ru/clsz/notif.htm The site blocks access from outside of Russia. -- / 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: Inactive packagers to be removed after the F37 release
On su, 04 syys 2022, Gary Buhrmaster wrote: On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson wrote: Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely. Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)). However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*). FreeIPA 4.9.10+ supports integration with an external OAuth2 identity provider (IdP). It needs OAuth2 device authorization grant flow support from IdP which Ipsilon does not support but Keycloak or any of major public IdPs aside from Gitlab do support. Keycloak does support FIDO2/WebAuthn too, so FreeIPA in Fedora 36 or later can be set up to operate with WebAuthn and no passwords in your own deployments. Fedora AAA uses RHEL IdM as a backend and there this feature is coming in next minor RHEL releases. It is not fully functional yet but for Fedora AAA use-case things are there with FreeIPA side. For Fedora users it would look like similar to the current Kerberos flow: (1) obtain an anonymous PKINIT ticket to use as a FAST channel, and (2) attempt to authenticate to Fedora KDC. If sssd-idp subpackage is installed and your Fedora AAA account is configured to use external IdP for your access authorization, then you'd be asked to visit a URL where you'd authenticate and then grant that authorization to Fedora AAA system. This IdP can be something that Ipsilon could federate to purely for the user authentication purposes. This is not implemented in Fedora AAA yet. You might want to watch our Nest with Fedora 2022 talk. More features are coming too, we are working on a direct FIDO2 integration in SSSD and FreeIPA, but a lot of help is needed from desktop folks as well to make it usable for login to graphical environments. GDM login is ugly right now as a message we push through PAM prompts is simply not fitting into GDM input boxes and you don't know where to go for your IdP access. See https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html for practical workshop details on how to set and use this in FreeIPA. Nest With Fedora's talk replay is available here: https://app.hopin.com/events/nest-with-fedora-2022/replay/Um91bmR0YWJsZVJlY29yZGluZ0FyY2hpdmU6MTM2OTQ3 (skip to 8:55 or so to the talk's start). Slides can be found here but the talk also has several demos: https://vda.li/talks/2022/2022-Nest-With-Fedora-FreeIPA-and-OAuth2.pdf (*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point. Ipsilon is orphaned in Fedora. If not picked up, it will disappear. It would be sad but a practical issue is that upstream seem to be less active too. Not sure how it goes but given that Fedora AAA is deployed or going to be eventually deployed in a containerized way, then probably focusing on another feature rich open source IdP could be a better option. -- / 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: Thoughts welcome: interface between automated test gating and the "critical path"
On ti, 30 elo 2022, Adam Williamson wrote: On Tue, 2022-08-30 at 09:39 +0300, Alexander Bokovoy wrote: On ma, 29 elo 2022, Adam Williamson wrote: > On Tue, 2022-08-30 at 00:32 -0400, DJ Delorie wrote: > > It sounds to me like the problem is "how do we best use the available > > automated test resources?" so I'll answer accordingly. Ignore me if I > > misunderstood ;-) > > No, not really, sorry if I didn't explain clearly enough :D It's more > just a 'what's the best way to work what I want to do around the > existing definitions' question. What I want to do is have updates of > FreeIPA-related packages gated. The awkwardness is that right now the > definition of what gets gated is "critical path packages", and those > clearly don't meet the current definition of "critical path". Not all of them meet the current definition of 'critical path' but many do. In fact, almost all crypto-implementing packages should be on that list, if not already. Sure, but freeipa itself, for instance, can't really be as things stand. Nor could bind, I don't think. And several others. Ideally, use of gating tests should be defined in the component itself. Do we have a mechanism to trigger OpenQA runs from the gating.yaml in the specific component? If we do, then we really should move it there. No. I don't think this is in-scope for gating.yaml. I *could* extend the openQA scheduler to check some kind of per-repo config for every package in the update, but there is nothing like this at present. In any case, triggering the *tests* isn't the problem here; we already do that, with the allowlist. It's doing the *gating* that's the problem. As I said, we could add *that* to gating.yaml for each repo, but I don't really love that idea, because you have to provide a full list of what tests to gate on, and doing that for each repo and keeping it updated seems like kind of a drag. I guess in a sense it's appropriate for these packages, though, as you could say we'd "really" want to gate on the FreeIPA-specific tests, or at least just the server tests. But honestly, if an update to a freeipa-related package causes GNOME to start crashing or something, that's something I want to look into before the update goes stable, even if it seems very weird. From FreeIPA side I'd split this into two parts: - turn allowedlist into critpath list and treat all these tests as gating ones properly, run them for all cases - finally make FreeIPA CI tests to run on Fedora updates and make them gating too. There are hundreds of tests we run in RHEL and in FreeIPA CI upstream that Fedora would benefit from because they excercise more unlit corners than OpenQA does. I agree with your arguments below, we need to turn gating for all use cases, especially Branched before Beta freeze, and Rawhide. Resource wise it may be excessive but early detection of complex issues FreeIPA testing tends to uncover is worth it. Practically speaking, the way we do things in Fedora, there is very little difference between "gating" and "consulting"; because of the waiver mechanism they're effectively identical. You can always issue waivers to override the gating. So really, gating is consulting. You can look at the failures, decide they're bogus, and hit the waiver button, which will immediately make the update 'pass' gating. I do encourage people not to abuse the waiver function - if the failure seems like a flake please use the 're-run tests' button, if you really think it's bogus please poke me or Lukas or someone as I'm probably working right then on dealing with it - but it is right there. Do you have measured data for waivers? How often the waiver process is used at all? In Branched before beta freeze? This would be lovely, sure, but at this point we're quite far away from the fairly concrete initial scope of my mail. I don't want to get sidetracked into sky castle building where we file tickets and wait two years for people to build stuff. I would like to gate updates to FreeIPA-related packages *now*. I was all set to submit a pull request to comps to add them to the server critpath definition, but then I checked the official definition of "critical path" and noticed this problem. That's where I'm coming from here: I want to make a concrete change now, not design awesome speculative improvements on paper. So your real issue at the moment is that 'critical path' definition is not helping to QE. I guess, it is a worth submission to FESCO then, right? -- / 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 Gu
Re: Thoughts welcome: interface between automated test gating and the "critical path"
On ma, 29 elo 2022, Adam Williamson wrote: On Tue, 2022-08-30 at 00:32 -0400, DJ Delorie wrote: It sounds to me like the problem is "how do we best use the available automated test resources?" so I'll answer accordingly. Ignore me if I misunderstood ;-) No, not really, sorry if I didn't explain clearly enough :D It's more just a 'what's the best way to work what I want to do around the existing definitions' question. What I want to do is have updates of FreeIPA-related packages gated. The awkwardness is that right now the definition of what gets gated is "critical path packages", and those clearly don't meet the current definition of "critical path". Not all of them meet the current definition of 'critical path' but many do. In fact, almost all crypto-implementing packages should be on that list, if not already. Ideally, use of gating tests should be defined in the component itself. Do we have a mechanism to trigger OpenQA runs from the gating.yaml in the specific component? If we do, then we really should move it there. Another part of the problem is that most of these runs should probably be consulting, not gating in the sense that failing them should give you a clue that things might be wrong but there needs to be a human overview of the failures. It is what we have right now with OpenQA-reported failures for Bodhi updates in most cases, the test results aren't really preventing the submissions from the going forward unless a maintainer defined the update configuration to be so. Ideally, we should have reverse dependency updates to trigger FreeIPA tests and give their results a visibility but don't block on failures. This would give an opportunnity to notice a failurer earlier but don't discourage maintainers from participating in a joint development. Perhaps, The Fedora Packager Dashboard could be extended to pick up results of tests relevant to your packages and display them together? This way FreeIPA maintainers can see an overview of all tests related to FreeIPA in one place and see if any help is needed to resolve failures. -- / 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: Users with commit rights in src.fp.o but no more in packager group
On to, 25 elo 2022, Miro Hrončok wrote: On 24. 08. 22 22:53, Alasdair G Kergon wrote: On Wed, Aug 24, 2022 at 09:50:59PM +0200, Fabio Valentini wrote: I think some of those *-team / *-sig / *-maint pseudo-group users are outdated. Most of them probably pre-date the existence of actual groups, so they are probably all ancient. For example, we removed the xgl-maint pseudo-group a while ago, because it was actually unused, and its associated bugzilla account was disabled. I wonder for how many of these groups the same is true, and whether we should actually remove them from all packages where that's the case. lvm-team is still in use as a package owner and default bugzilla assignee. To do anything of any significance using the account, we were instructed to open a ticket to ask for the change to be made for us. It has never been a member of the packager group because it was decided that accounts that are not individuals cannot sign the legal agreement that is a pre-requisite to being able to join that group. We use the python-maint pseudo-account to be the default Bugzilla assignee for Pythons, e.g. https://src.fedoraproject.org/rpms/python3.11 Note that it does *not* require the account to be listed in maintainers or to have commit rights. Same for ipa-maint account. -- / 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: liburing update
of 'unsigned int pad[3]' changed: array element type 'unsigned int' changed: entity changed from 'unsigned int' to compatible type 'typedef __u8' at int-ll64.h:21:1 type name changed from 'unsigned int' to 'unsigned char' type size changed from 32 to 8 (in bits) type name changed from 'unsigned int[3]' to '__u8[3]' array type size changed from 96 to 24 and offset changed from 1632 to 1672 (in bits) (by +40 bits) parameter 2 of type 'io_uring_cqe**' has sub-type changes: in pointed to type 'io_uring_cqe*': in pointed to type 'struct io_uring_cqe' at io_uring.h:258:1: type size hasn't changed 1 data member insertion: '__u64 big_cqe[]', at offset 128 (in bits) at io_uring.h:267:1 end of changes of 'liburing.so.2.0.0'=== I guess we can ignore the added functions as those should always be safe. The changed function __io_uring_get_cqe is documented in the header as: /* * Helper for the peek/wait single cqe functions. Exported because of that, * but probably shouldn't be used directly in an application. */ I looked at the source of qemu & ceph and neither call this function. Samba does not call __io_uring_get_cqe() either. -- / 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
slapi-nis license change
Hi, I was intending to do this change for several years but never been able to complete it. With slapi-nis 0.60.0 release today I finally finished relicensing of slapi-nis to GPLv3-or-later and builds in Fedora reflect it now. Previous version was GPLv2. slapi-nis is a plugin to 389-ds LDAP server which moved to GPLv3-or-later already for some years. The relicensing was agreed with Red Hat legal for quite some time already, since Red Hat is the only copyright owner. -- / 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: F37 proposal: BIND 9.18 (Self-Contained Change proposal)
We tested this extensively in FreeIPA upstream CI using a separate COPR repo. Current FreeIPA versions in Fedora are ready and rawhide version of bind-dyndb-ldap only needs a rebuild. I'm currently on a sick leave but Peter should be able to handle it with his bind/bind-dyndb-ldap maintainer rights. On Saturday, July 16, 2022, Adam Williamson wrote: > On Fri, 2022-07-15 at 17:30 -0400, Ben Cotton wrote: >> >> == Scope == >> * Proposal owners: The update required update of bind-dyndb-ldap >> package (part of Freeipa suite), but otherwise it is isolated change. > > That's a big 'but'. FreeIPA is a release-blocking part of Server, one > of our Editions. We've seen issues before between bind upgrades and > FreeIPA. I would like to see assurances that this is being planned > together with FreeIPA folks and resources will be in place to ensure > FreeIPA is fully tested and working when this is deployed. > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > -- -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On ke, 09 maalis 2022, Daniel P. Berrangé wrote: On Wed, Mar 09, 2022 at 02:32:48PM +0200, Alexander Bokovoy wrote: On ke, 09 maalis 2022, Daniel P. Berrangé wrote: > On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote: > > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote: > > > > > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > > > We've been disabling it in TLS, but its usage is much wider than TLS. > > > > The next agonizing step is to restrict its usage for signatures > > > > on the cryptographic libraries level, with openssl being the scariest one. > > > > > > > > Good news is, RHEL-9 is gonna lead the way > > > > and thus will take a lot of the hits first. > > > > Fedora doesn't have to pioneer it. > > > > Bad news is, Fedora has to follow suit someday anyway, > > > > and this brings me to how does one land such a change. > > > > > > > > --- > > > > > > > > Fedora is a large distribution with short release cycles, and > > > > the only realistic way to weed out its reliance on SHA-1 signatures > > > > from all of its numerous dark corners is to break them. > > > > Make creation and verification fail in default configuration. > > > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > > > and break it in Rawhide for Fedora 38. > > > > The fallout will just be too big. > > > > > > If RHEL-9 has lead the way, what are the stats for real world > > > RHEL impact ? > > > > We'll know when the real world starts using RHEL-9 en masse? > > > > > What is/was the absolute number of packages and % number of > > > packages from the RHEL distro that saw breakage ? > > > > Does preventing the distro from installing altogether count as 100%? > > If yes, 100%. =) > > Jokes aside, I can't give you an accurate estimate yet. > > Perhaps a useful first step is to just modify the three main > crypto libs (gnutls, openssl, and nss) to send a scary warnihg > message to stderr/syslog any time they get use of SHA1 in a > signature. Leave that active for a release cycle and see how > many bug reports we get. > > > > Such figures can give us a better idea of impact on Fedora > > > beyond "too big". > > > > > > Assuming RHEL-9 has dealt with the problems, Fedora should > > > inherit those fixes, which gives us a good base for the most > > > commonly used / important packages in Fedora. > > > > Yeah, that's what I meant by the good news. > > But that won't solve all Fedora problems. > > > > > If the breakage % from RHEL was single digits, and those > > > were the most important packages to fix from Fedora's POV > > > too, then maybe the fall is not in fact "too big". It might > > > be sufficient to identify a few important remaining packages > > > to validate, and just accept the fallout for the remaining > > > less important packages in Fedora can be fixed after the > > > fact ? > > > > At a quick glance, > > I eyeball RHEL at ~2k packages and Fedora at ~22k packages. > > I think that limited analysis 's enough to safely claim > > that leaving the 90% of the packages you've labelled "less important" > > to be "fixed after the fact" is gonna be a disaster. > > One cycle doesn't sound enough. > > That 90% of packages are not all going to be using cryptographic > signatures though. Only a relatively small subset will do anything > crypto related, and most of that just be HTTPS and completely > outsourced to a crypto library. > > IOW of that 90% of packages not in RHEL, it could conceivably be > single digits that will be using cryptographic signatures with > SHA-1. An even smaller percentage of those will be considered > important enough to be blockers for this change. Specifically, Kerberos is one of those protocols and MIT Kerberos is one of those implementations which currently forced to use SHA-1 due to interoperability issues and also due to compliance with RFCs. In the context of Fedora development, for example, use of Anonymous PKINIT requires usage of SHA-1 in PKINIT pre-authentication module in MIT Kerberos. We have to support that or Fedora developers would not be able to obtain their Kerberos tickets. For more details see https://bugzilla.redhat.com/show_bug.cgi?id=2060798 I assume RHEL is going to have to solve that problem with Krb because it wouldn't be viable to break Krb in RHEL, any more than it would in Fedora. Yes, the
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On ke, 09 maalis 2022, Daniel P. Berrangé wrote: On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote: On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote: > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > We've been disabling it in TLS, but its usage is much wider than TLS. > > The next agonizing step is to restrict its usage for signatures > > on the cryptographic libraries level, with openssl being the scariest one. > > > > Good news is, RHEL-9 is gonna lead the way > > and thus will take a lot of the hits first. > > Fedora doesn't have to pioneer it. > > Bad news is, Fedora has to follow suit someday anyway, > > and this brings me to how does one land such a change. > > > > --- > > > > Fedora is a large distribution with short release cycles, and > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > and break it in Rawhide for Fedora 38. > > The fallout will just be too big. > > If RHEL-9 has lead the way, what are the stats for real world > RHEL impact ? We'll know when the real world starts using RHEL-9 en masse? > What is/was the absolute number of packages and % number of > packages from the RHEL distro that saw breakage ? Does preventing the distro from installing altogether count as 100%? If yes, 100%. =) Jokes aside, I can't give you an accurate estimate yet. Perhaps a useful first step is to just modify the three main crypto libs (gnutls, openssl, and nss) to send a scary warnihg message to stderr/syslog any time they get use of SHA1 in a signature. Leave that active for a release cycle and see how many bug reports we get. > Such figures can give us a better idea of impact on Fedora > beyond "too big". > > Assuming RHEL-9 has dealt with the problems, Fedora should > inherit those fixes, which gives us a good base for the most > commonly used / important packages in Fedora. Yeah, that's what I meant by the good news. But that won't solve all Fedora problems. > If the breakage % from RHEL was single digits, and those > were the most important packages to fix from Fedora's POV > too, then maybe the fall is not in fact "too big". It might > be sufficient to identify a few important remaining packages > to validate, and just accept the fallout for the remaining > less important packages in Fedora can be fixed after the > fact ? At a quick glance, I eyeball RHEL at ~2k packages and Fedora at ~22k packages. I think that limited analysis 's enough to safely claim that leaving the 90% of the packages you've labelled "less important" to be "fixed after the fact" is gonna be a disaster. One cycle doesn't sound enough. That 90% of packages are not all going to be using cryptographic signatures though. Only a relatively small subset will do anything crypto related, and most of that just be HTTPS and completely outsourced to a crypto library. IOW of that 90% of packages not in RHEL, it could conceivably be single digits that will be using cryptographic signatures with SHA-1. An even smaller percentage of those will be considered important enough to be blockers for this change. Specifically, Kerberos is one of those protocols and MIT Kerberos is one of those implementations which currently forced to use SHA-1 due to interoperability issues and also due to compliance with RFCs. In the context of Fedora development, for example, use of Anonymous PKINIT requires usage of SHA-1 in PKINIT pre-authentication module in MIT Kerberos. We have to support that or Fedora developers would not be able to obtain their Kerberos tickets. For more details see https://bugzilla.redhat.com/show_bug.cgi?id=2060798 -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On su, 20 helmi 2022, Kevin Fenzi wrote: On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote: On Sun, Feb 20, 2022, 16:09 Adam Williamson wrote: > It used to support these, but the support was lost with the recent > rewrite. However, it supports Google Authenticator-style OTPs. Folks > with infra privileges on their accounts (like me) are already required > to use these. It works fine. I preferred being able to use a yubikey so > I don't always have to open an app on my phone and retype a six digit > code when I need to log in to something, but that's just a minor > annoyance. The old account system (fas2) used to support yubikeys, but it did not support U2F. It only supported them in HOTP mode, not U2f. The new account system is a frontend to IPA, and IPA does not currently support U2F. There's a RFE ( https://github.com/SSSD/sssd/issues/4322 ) but I don't know where it is on their roadmap. Not only does IPA need to add support, but then we would need to add support to noggin to enroll/etc. We (FreeIPA and SSSD teams) are working on a bit different approach right now since support of U2F in Kerberos is complicated with a need to first get a specification agreed between multiple industry participants and currently there is no one driving that work. Instead, we are working on an ability to authenticate against OIDC when acquiring a Kerberos ticket granting ticket. This would turn the need to choose authentication method to the IdP configured and most IdPs support use of U2F tokens (as well as other mechanisms). With this approach, id.fedoraproject.org would be able to handle authentication on its own way, not Fedora Project's KDC alone like now. After authenticated, a user would be issued with a 'normal' Kerberos TGT which then can be used to obtain service tickets to other services and authenticate to them with GSSAPI. Including, if needed, to authenticate to id.fedoraproject.org again, this time with GSSAPI. This is not ready for general consumption but we plan to have something to submit to Rawhide in a month or so. Enrolling IPA users into this would be similar to already existing RADIUS proxy authentication path in FreeIPA. TOTP (what the authenticator app does), is, indeed, better than nothing, but U2F (FIDO), is considered to be stronger. Yeah. So, as to the topic of this thread... I agree it's a possible attack vector, but it seems... like a lot more work than just coming in through the new maintainer workflow, but I do suppose there might be more scrutiny there. When someone makes an account, basically we are saying "This person is the person who controls that email address". So, if we don't have the email address, we have to fall back on other data that was added to the account, like ssh pub key, gnupg key, etc. Or real world information, like "I know them and met them at the pub", they work for Red Hat and we can verify them, etc. In fas2 we also had a 'challenge/response' thing that someone could fill in, but not many folks did (and the new system doesn't have that anyhow). I think some kind of keep alive ping could be worthwhile, although we have always rejected them in the past for bothering mataintainers too much. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package notes issues with python wheel building
On ke, 02 helmi 2022, Simo Sorce wrote: So I got this bug about FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2049643 These are bindings to C libs and use gcc to build .so files. Upon investigation the issue is that the default linker flags seem to point to non existing package note files, so the build fails. It was suggest to disable notes for this package via: %undefine _package_note_file However this just changed the error from a linker script named against the python package to a linker script named against the krb5 dependency. This is what I get in a scratch build: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note-krb5-1.19.2-4.fc36.1.x86_64.ld: No such file or directory How do I solve this? I need to update to a new version of python-gssapi but I cvan't build it right now. There is a similar bug against krb5: https://bugzilla.redhat.com/show_bug.cgi?id=2048909 I guess we need to fix krb5 this way too. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On ke, 22 joulu 2021, Alexander Bokovoy wrote: On ke, 22 joulu 2021, Mat Booth wrote: On Tue, 21 Dec 2021 at 14:35, Alexander Bokovoy wrote: I picked up wsdl4j to prevent actions which would lead to tomcat, Dogtag, and FreeIPA being orphaned over Christmas break. Have you tried building tomcat without wsdl? I can't see where in the tomcat source it is used. Is it really a build dep? I haven't tried that yet. Looking at the spec, ant is called with -Dwsdl4j-lib.jar="$(build-classpath wsdl4j)" \ Looking at the tomcat source code, there are plenty of references to WSDL code, so it is definitely needed at runtime because WSDL definitions for servlets are parsed and used. Build environment insists on having WSDL jars in the class path (in build.xml): I did a quick test in mock for rawhide by removing BuildRequires for wsdl4j and the build succeeded with only one warning that wsdl4j jar was not found: $ grep wsdl results_tomcat/9.0.56/1.fc36/build.log ++ build-classpath wsdl4j /usr/bin/build-classpath: Could not find wsdl4j Java extension for this JVM + ant -Dbase.path=. -Dbuild.compiler=modern -Dcommons-daemon.jar=HACK -Dcommons-daemon.native.src.tgz=HACK -Djdt.jar=/usr/share/java/ecj/ecj.jar -Dtomcat-native.tar.gz=HACK -Dtomcat-native.home=. -Dcommons-daemon.native.win.mgr.exe=HACK -Dnsis.exe=HACK -Djaxrpc-lib.jar=HACK -Dwsdl4j-lib.jar= -Dbnd.jar=/usr/share/java/aqute-bnd/biz.aQute.bnd.jar -Dbndlib.jar=/usr/share/java/aqute-bnd/biz.aQute.bndlib.jar -Dbndlibg.jar=/usr/share/java/aqute-bnd/aQute.libg.jar -Dbndannotation.jar=/usr/share/java/aqute-bnd/biz.aQute.bnd.annotation.jar -Dosgi-annotations.jar=/usr/share/java/aqute-bnd/biz.aQute.bnd.annotation.jar -Dslf4j-api.jar=/usr/share/java/slf4j/slf4j-api.jar -Dosgi-cmpn.jar=/usr/share/java/osgi-compendium/osgi.cmpn.jar -Dversion=9.0.56 -Dversion.build=56 deploy I haven't run the resulting package with a real life workload, though. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On ke, 22 joulu 2021, Mat Booth wrote: On Tue, 21 Dec 2021 at 14:35, Alexander Bokovoy wrote: I picked up wsdl4j to prevent actions which would lead to tomcat, Dogtag, and FreeIPA being orphaned over Christmas break. Have you tried building tomcat without wsdl? I can't see where in the tomcat source it is used. Is it really a build dep? I haven't tried that yet. Looking at the spec, ant is called with -Dwsdl4j-lib.jar="$(build-classpath wsdl4j)" \ Looking at the tomcat source code, there are plenty of references to WSDL code, so it is definitely needed at runtime because WSDL definitions for servlets are parsed and used. Build environment insists on having WSDL jars in the class path (in build.xml): -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On ti, 21 joulu 2021, Miro Hrončok wrote: On 21. 12. 21 15:33, Alexander Bokovoy wrote: wsdl4j akurtakov, mizdebsk, orphan 2 weeks ago I picked up wsdl4j to prevent actions which would lead to tomcat, Dogtag, and FreeIPA being orphaned over Christmas break. There was no orphaning going to happen over the Christmas break: The next action that could impact any of the dependents of wsdl4j would be in 4 weeks, in the second half of January, when wsdl4j would be retired. That would lead to new bugzillas being opened and another 8 weeks of no response before any of the dependent would be orphaned -- that is mid-March. I will be on PTO until January 10th, so for me January 13th when it would have been retired is dangerously close to have any action organized from Tomcat and Dogtag teams. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
: libgda mharmsen: wsdl4j mizdebsk: wsdl4j moezroy: libgda music: libgda nacho: libgda omajid: wsdl4j, icedtea-web pabelanger: python-jenkins-job-builder rakesh: libgda spike: wsdl4j spot: libgda tmraz: PyPAM vakwetu: wsdl4j van: wsdl4j volter: e00compr -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On ke, 08 joulu 2021, Matthew Miller wrote: On Wed, Dec 08, 2021 at 01:50:47PM +0100, Lennart Poettering wrote: So here's what I'd suggest: let's define a group (my suggestion: let's repurpose "wheel" for that) that has the effect that the passwords of any user in it are also accepted as password for the root user, My working real-world security knowledge is dangerously out of date so I will defer to others on the proposal itself, but: yes, we already treat wheel membership as "able to escalate to root", and it seems sane to reuse. Since we have group merging in effect in glibc, please do not treat a user present in wheel group but missing in /etc/shadow as something extra-ordinary. It is a normal situation when you have users in the centralized identity store like FreeIPA or Samba AD. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Retire the NIS(+) user-space utility programs (System-Wide Change proposal)
://pagure.io/fedora-infrastructure -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [RFC] Remove supoort for NIS(+) from PAM
On pe, 01 loka 2021, Neal Gompa wrote: On Fri, Oct 1, 2021 at 12:41 PM Frank Ch. Eigler wrote: Stephen John Smoogen writes: >> > The places I have seen it still being used are in Universities run by >> > people who learned sysadmin in the 1990's and early 2000's. It is a >> > light weight system which is simple to set up [...] >> >> For those people who like simple to set up and working systems but are >> willing to consider upgrading if it's also simple and will keep working, >> is there a NIS->$whatever migration document in fedora someplace? > > I don't think anyone has come up with an agreed upon $whatever that a > majority of people like. There is LDAP but that isn't light. There are > kerberos but that isn't easy. "light" in terms of CPU/network, who cares. "light" in terms of simplicity and maintenance, you have my attention. If there is no such gadget available, then please let's keep NIS around. > And honestly the cool kids only want web logins these days as servers > are a pain and why not just login into Google/Facebook/Microsoft and > let them deal with all that setup. (OK but seriously that's not a fedora matter. Well, or rather, I'd love to have a passwd/nss backed openid gadget. Is that ipsilon?) We're currently missing a way to do OpenID or OIDC based login in Linux like what Windows and macOS has. Ipsilon would be the server-side aspect of it, we don't have any client-side integration (sssd, gdm/sddm, etc.) We are working on that part for SSSD and FreeIPA. Not production ready yet but aim to have something testable later this year. In a prototype we have it is possible to authenticate against a thing like Github or Keycloak. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [RFC] Remove supoort for NIS(+) from PAM
On la, 02 loka 2021, James Szinger wrote: On Sat, 2 Oct 2021 08:42:02 -0400 Demi Marie Obenour wrote: How many of these can be solved by tunneling everything in a WireGuard mesh network, and using nftables rules to prevent spoofing? Sounds harder than setting up NIS+, which was supposed to solve many of these issues 30 years ago, but still has not displaced NIS. Even if one can secure NIS on the network, that still leaves the issue of `ypcat passwd`. These days, I think FreeIPA or Active Directory are the best choices, but both are complicated and possibly too much for a SO/HO, workgroup, or departmental sysadmin. AD has the advantage of supporting Windows, MacOS, and Samba; the last time I looked FreeIPA was not good at this. FreeIPA has integration with Samba (to run Samba file server on IPA clients) for quite some time, around two years now. You need to run 'ipa-client-samba' tool on IPA client to set it up, that's all. This will make Kerberos authentication work against smbd and partially password authentication too. See man page for ipa-client-samba(1) for more details and https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html for even more technical details. Samba upstream is planning to eventually remove support for a standalone domain controller without Kerberos (e.g. not Samba AD or IPA DC). Given that NTLM authentication will eventually be disabled everywhere, until we get something better for a standalone use case, Kerberos is there to handle such cases. Both Samba AD and FreeIPA in Fedora are good to cover them. Critique of complexity of a general 'domain controller' setup is warrant, of course. It is something that FreeIPA really tries to address and for simple use cases we are almost there if you are using an integrated approach where FreeIPA runs and configures all the pieces it needs (DNS, CA, ...). At least a basic understanding of DNS and Kerberos is still preferrable, of course. We need to improve in this area in Fedora Server documentation... NIS+ as a tooling for such configurations is even less secure than relying on NTLM in SMB protocol. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [RFC] Remove supoort for NIS(+) from PAM
On ke, 06 loka 2021, Björn 'besser82' Esser wrote: Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John Smoogen: On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser wrote: > > Hello, > > I'm currently doing some experiments with replacing the - upstream > mostly unmaintained - pam_unix module (authentication with user > passwd) > with something using less bloated and cleaner code. This topic is > currently also discussed with the upstream maintainer of pam_unix. > > Replacing parts of a software for the sake of less complexity > usually > comes with a cut-down of features; in this particular case it would > be > dropping support for NIS(+), which has already been abandoned by its > initial developer SUN / Oracle for about 10 years [1]. > > Before starting some more concrete plans, I'd like to get some > feedback > from the Fedora community how they feel about removing NIS(+) > support in > PAM. Is it even still actively used anywhere and/or by anyone in > the > Fedora universe? > The places I have seen it still being used are in Universities run by people who learned sysadmin in the 1990's and early 2000's. It is a light weight system which is simple to set up and tends to be the goto-stick for a lot of 'we put this together in 1999 with RHL6 and upgraded ever since' places. That said, NIS in most setups causes all kinds of security problems and audit failures that those areas are probably rapidly going away. [And the ones I know have been moving to Debian because it keeps various other technologies we jettisoned long ago.] If we drop this from pam_unix, should we look to dropping ypbind and similar tools? Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to make sense in this context, as from my understanding they won't be of any practical use anymore. Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be dropped also. slapi-nis implements two separate plugins, one of which provides NIS support. It is going to be supported in RHEL 9 and I'd like to keep NIS part supported in Fedora as well for some time. This only requires existence of libnsl2. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora-Rawhide-20211001.n.0 compose check report
On pe, 01 loka 2021, Fedora compose checker wrote: Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 4 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud Failed openQA tests: 15/206 (x86_64), 23/132 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210930.n.0): ID: 1008518 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1008518 ID: 1008528 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1008528 ID: 1008531 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1008531 ID: 1008535 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1008535 All FreeIPA tests fail because resteasy-jaxb-provider is removed but it is still required by dogtag. My understanding is that this is an intermediate step which should have better be done in a sidetag. So we can expect broken FreeIPA in Rawhide until this issue is solved by Dogtag team. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [RFC] Remove supoort for NIS(+) from PAM
Hi, On pe, 01 loka 2021, Björn 'besser82' Esser wrote: Hello, I'm currently doing some experiments with replacing the - upstream mostly unmaintained - pam_unix module (authentication with user passwd) with something using less bloated and cleaner code. This topic is currently also discussed with the upstream maintainer of pam_unix. Replacing parts of a software for the sake of less complexity usually comes with a cut-down of features; in this particular case it would be dropping support for NIS(+), which has already been abandoned by its initial developer SUN / Oracle for about 10 years [1]. Before starting some more concrete plans, I'd like to get some feedback from the Fedora community how they feel about removing NIS(+) support in PAM. Is it even still actively used anywhere and/or by anyone in the Fedora universe? I am maintaining slapi-nis, the server side of NIS implementation on top of FreeIPA. I also maintain libnsl2 in RHEL 9. In RHEL 9 we removed client side of NIS(+) support from the distribution. Server side emulation in FreeIPA is still available because we have to be able to provide interoperability with non-Linux clients. The only reasonable use of NIS(+) beyond that is within computing farms. NIS is very lightweight in terms of network traffic and an overhead for a single request compared to LDAP-based solutions (SSSD). This is the only reason we kept NIS support available for quite some time in FreeIPA. But we are considering to remove it completely in future as well. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Python libraries problem with F34
On ma, 05 heinä 2021, Frederic Muller wrote: On 7/5/21 4:01 PM, Felix Schwarz wrote: Hi Fred, your code works for me without printing any warnings. Am 05.07.21 um 10:01 schrieb Frederic Muller:> I install all my libraries using pip. The important thing is that you never use pip to install anything into Fedora's site-packages /usr/lib64/python3.9/site-packages/ . That can (and will) cause a lot of trouble. Use "dnf" only to install stuff into your system site-packages directory. Use virtualenvs (or similar mechanisms) to install your own libraries with pip. Ok I didn't know that. I however install them for my user. So the (full) error message is actually: Warning (from warnings module): File "/home/fred/.local/lib/python3.9/site-packages/requests/__init__.py", line 89 I guess it's the same as /usr/lib64/ then? If you want to use pip, make sure you are doing so within a virtual environment, e.g. with venv or similar constructs. This ensures whatever was installed is self-consistent with regards to the source where it came from. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)
On ti, 15 kesä 2021, Petr Viktorin wrote:
On 14. 06. 21 20:09, Alexander Bokovoy wrote:
On ma, 14 kesä 2021, Ben Cotton wrote:
[...]
PyPI Parity
Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).
This solves a ''namespace'' issue. Python packaging tools use a
flat namespace,
and PyPI is ''the'' place where open-source Python packages are generally
published, so users and tools assume a package called
requests
is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes sense
for Fedora to align with the PyPI namespace.
Note that Fedora package names are not affected – just the Python
packaging
metadata on disk and virtual RPM Provides generated from it.
The new guidelines cover what to do for packages that cannot be
registered
on PyPI. The Change owner is prepared to help with PyPI registration.
Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been
reserved on PyPI]
to avoid being taken by unrelated projects.
samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.
In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.
Then I'd recommend that the project name in dist-info metadata would
be, for example "samba-bindings".
Samba Python bindings have no dist-info metadata. Does it need to? The
bindings are consumed by few projects around Samba but none of them has
anything related on PyPI. What exists on PyPI is either an outdated
stuff without upstream sources or a reference to a similar outdated
stuff, none of which is using Samba Python bindings.
This matters in cases like a pip-installable package declaring a
dependency on Samba bindings: it now can't use `samba` because that
means something else on PyPI.
There are already unrelated projects with Samba name on PyPI. This
change in Fedora guidelines cannot affect those. It cannot also affect
actual use of Samba Python bindings. It looks like there is no real use
of PyPI for our use case either, so why the fuss for this particular
package?
I suspect at best we'd submit a request for exception, if pressed.
I fully agree about not installing Samba itself via pip.
(Also, this is one of the cases that might take a decade -- I'm not
putting pressure on you to implement this, but pointing out a
direction for the future.)
Frankly, I do not see a real use case for what you might see in other
projects. We had a similar issue with FreeIPA and what we provide on
PyPI is a crippled subset of FreeIPA Python modules that mostly does not
use real FreeIPA features. To date, I am not sure it is really bringing
any benefit to us (upstream).
This does not mean the whole effort is useless, not at all. It means, in
my opinion, that proposed guidelines are failing to address real world
use cases present in Fedora. Invalidating these use cases is as bad as
dropping the guidelines' changes in one go. ;)
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag
On ma, 14 kesä 2021, Adam Williamson wrote: On Mon, 2021-06-14 at 15:40 +0300, Alexander Bokovoy wrote: > > The fact that this blocks FreeIPA was indeed only discovered by chance > while the side tag rebuild was already in progress (and about to be > merged). I wonder haw can we improve the process to ensure problems > like this are known to FreeIPA maintainers since the beginning and > prioritized accordingly. (Ideally, the process would not only be > improved for FreeIPA but the entire distro.) Well, this is a dependency problem in the first place. When an ABI change happens, like a Python ABI change with 3.10 mass-rebuild, it should be assumed and expected that until all previously successfully built packages were to be rebuilt, there will be broken dependencies. Perhaps, we could extend our existing checks for a broken compose to be done on a side-tag on demand? This way mass-rebuilders could ask for such a run one they consider to be ready to merge and see how that side-tag merge would affect the distribution. I don't think we have a better way to detect it before the merge. Note, we did do a limited version of this; I built a Rawhide installer image with Python 3.10 and ran a subset of openQA tests on it. We did not include the FreeIPA tests in that, which was a bit of an oversight; however, FreeIPA tests failed for an unrelated reason in the compose before the merge, so it wouldn't necessarily have turned up the issue anyway. I think in this particular case even getting a compose closure would have been enough to get us on track to mod_wsgi problem. We do have the ODCS - https://pagure.io/odcs , https://odcs.fedoraproject.org/composes/ - which we might be able to use to do this in a more comprehensive and organized way, but I haven't checked in on exactly what its capabilities are lately. I don't know if it's possible to request a compose "like Rawhide, but with this side tag" from it. We might also be able to get releng to hand-roll one, I guess. Thanks, this would be a great contribution to side-tag rebuilds. We are using a similar tooling in RHEL *a lot* (in fact, for IDM CI testing we do it with every package update). -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)
ns to handle, but we expect there won't be enough requests to make
automation worth it.)
=== Conditioning names on PyPI ===
Neal also
[https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/IYBF5GX6HVQYPC5EJ6HVK7GJHAIKHVBK/
fundamentally disagrees]
“on conditioning those names on PyPI, because frankly no other ecosystem
in Fedora works that way. Not Rust, not Go, not Perl, not OCaml, not anything.”
It's true that no other ecosystem in Fedora does this, but the author
of this change believes that they should:
if the ecosystem uses a flat namespace of dependencies,
its Fedora packages ''should'' use the ecosystem-wide namespace
rather than a Fedora-specific one.
RPM predates global per-ecosystem directories of free/open software,
but they are here and users (at least those affected by these issues)
are used to them.
For Python specifically, PyPI is already a de-facto standard:
if you see a name in install_requires in setup.py
of some random upstream project you want to package,
you can assume that it's the PyPI name.
It is in the best interest of Fedora's users to use PyPI names
for dependency resolution.
== Benefit to Fedora ==
The new packaging guidelines should encourage sharing packaging work
with upstream developers (and through them, with other distros).
Hopefully, they'll also free up some packagers' time.
PyPI parity will hopefully enable automated ways of mixing Fedora packages
with upstream ones.
The updated examples and notes will be more useful to today's packagers.
The older (a.k.a. "201x-era") Python Packaging guidelines only cover
projects that use `setup.py`-based installation (via `setuptools` or
`distutils`). The new guidelines and macros support more "build
backends" (such as `setup.py`-less `setuptools`, `poetry`, `flit` or
others) transparently via [https://www.python.org/dev/peps/pep-0517/
PEP 517] (and they continue to work with projects that use `setup.py`
to install).
== Scope ==
* Policies and guidelines:
https://pagure.io/packaging-committee/pull-request/1072
* Proposal owners:
** Make {{package|python3-devel}} require {{package|pyproject-rpm-macros}}
** Remove ''provisional'' status from
{{package|pyproject-rpm-macros}}; release & package version 1.0.
** Handle PyPI name registration/reservation requests from other packagers.
* Other developers: Maintainers of packages that use Python should
gradually switch to the new guidelines
* Release engineering: https://pagure.io/releng/issue/10164
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
None expected.
Any compatibility impact on individual packages would be a bug.
== How To Test ==
If you maintain a package that uses Python, try to follow the new guidelines.
Any major omission or ambiguity is a bug.
(Minor/unique cases should be discussed on the
[mailto:python-de...@lists.fedoraproject.org Pytohn SIG list] instead;
the document is already quite long.)
Until this change proposal is approved and enabled, you'll need to
BuildRequire `pyproject-rpm-macros` to have the new macros available.
Updated packages should be tested normally, as with any other package update.
== User Experience ==
No direct impact on end users.
== Dependencies ==
PyPI maintainers [https://github.com/pypa/pypi-support/issues/355 are aware] of
the general direction the Guidelines, and have been supportive.
== Contingency Plan ==
* Contingency mechanism: Revert to the older guidelines
* Contingency deadline: N/A (Any time until old guidelines are
retired, in a separate Change)
* Blocks release? No
== Documentation ==
The new guidelines are the documentation.
See ''Detailed Description'' above for links.
== Release Notes ==
Fedora's Python Packaging guidelines have been rewritten
to align with modern Python packaging practices
and better integrate with the wider Python ecosystem
(specifically, the Python Package Index).
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
/ 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/
Lis
Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)
On ma, 14 kesä 2021, Neal Gompa wrote: On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: > On 14.06.2021 15:32, Ben Cotton wrote: >> Running upstream tests is mandatory. > > What about tests that require network access? From the proposed guidelines: > If a test suite exists upstream, it MUST be run in the %check section and/or > in Fedora CI. You MAY exclude specific failing tests. > > You MUST NOT disable the entire testsuite or ignore the result to solve a > build failure. > > As an exception, you MAY disable tests with an appropriate %if conditional > (e.g. bcond) when bootstrapping. Assuming that *all the tests* require network access, you should run them on Fedora CI instead. Assuming only some of the tests require network access, you should exclude them in %check (and possibly run them on Fedora CI instead). This is unreasonable, since Fedora CI isn't usable across all architectures. Unless Fedora CI is at platform parity, then we have to have an allowance for not running tests. More to that, for packages like FreeIPA, running a FreeIPA installation -- which is what required to have a reasonable test run -- is simply not possible in %check. We could run a subset of unit tests but that is not going to produce a meaningful result. Current Fedora CI capabilities also pretty limited with regards to multi-server deployments. We rely on OpenQA testing at the Bodhi update time for a reason. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag
On ma, 14 kesä 2021, Miro Hrončok wrote: On 14. 06. 21 13:40, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeIPA) is mod_wsgi which relied on Python C API which was removed in Python 3.10. The same API was used by uWSGI as well, so it would really be great if Python core developers and Python maintainers team could have helped mod_wsgi/uWSGI upstreams to migrate from the old API. Sadly, this was only found after the fact when a side-tag was already merged, so FreeIPA right now is broken in Fedora Rawhide. The problem in mod_wsgi was actually found and reported in November 2020 [1], which is exactly why we test with each pre-release of Python: To report problems *early* and give maintainers time to fix them, so we can land the new version with limited negative impact. Unfortunately, the mod_wsgi maintainer did not respond to the problem :( While we try really hard, we cannot report each failure to upstreams directly. The fact that this blocks FreeIPA was indeed only discovered by chance while the side tag rebuild was already in progress (and about to be merged). I wonder haw can we improve the process to ensure problems like this are known to FreeIPA maintainers since the beginning and prioritized accordingly. (Ideally, the process would not only be improved for FreeIPA but the entire distro.) Well, this is a dependency problem in the first place. When an ABI change happens, like a Python ABI change with 3.10 mass-rebuild, it should be assumed and expected that until all previously successfully built packages were to be rebuilt, there will be broken dependencies. Perhaps, we could extend our existing checks for a broken compose to be done on a side-tag on demand? This way mass-rebuilders could ask for such a run one they consider to be ready to merge and see how that side-tag merge would affect the distribution. I don't think we have a better way to detect it before the merge. What I do not see as acceptable is what Python core team did in November 2020 when this issue was made clear in the original PR to remove the 'old' parser that broke mod_wsgi/uWSGI/unbound and some more packages. Instead of following up in providing a supported API function, the comment[1] from Victor was practically ignored. I assume that opening bugzillas for all the dependent packages for each failure would be considered as spam by many. It depends on what that bug opening would mean. If you are doing it early together with an upstream that breaks its ABI/API, helping them to see the issues early is one of your goals -- as you stated above. Realizing through reverse dependencies a damage such breakage could cause is something you (as Python maintainers in Fedora) could definitely do and raise the issue earlier also with the package maintainers/upstreams. In this case FreeIPA is affected but we missed it completely in November 2020 as nobody told us mod_wsgi would not work anymore. In the meantime, I've marked mod_wsgi as "blocker" for the Python 3.11 rebuild next year, but that is not a systematic solution. I saw that there is some discussion and an effort to help mod_wsgi upstream already, thank you! There is a proposed fix [2] but we don't know enough about Apache to say if it is ideal. In case this blocks you very much, I suggest you work with the Fedora's mod_wsgi maintainer and backport this patch to rawhide, keeping an eye on it in case it breaks your use cases, and report problems to us, so we can adapt it. At this point of the Fedora 35 development schedule, I think this patch should be good enough for it. I already nominated mod_wsgi bug as Fedora 35 beta release blocker because it violates Fedora Server release criteria[2]. I am not a maintainer for mod_wsgi myself and have no rights to that package. [1] https://bugs.python.org/issue40939#msg381227 [2] https://fedoraproject.org/wiki/Basic_Release_Criteria#FreeIPA_server_requirements -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag
On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeIPA) is mod_wsgi which relied on Python C API which was removed in Python 3.10. The same API was used by uWSGI as well, so it would really be great if Python core developers and Python maintainers team could have helped mod_wsgi/uWSGI upstreams to migrate from the old API. Sadly, this was only found after the fact when a side-tag was already merged, so FreeIPA right now is broken in Fedora Rawhide. I saw that there is some discussion and an effort to help mod_wsgi upstream already, thank you! Victor On Sun, Jun 13, 2021 at 9:52 PM Miro Hrončok wrote: On 08. 06. 21 1:01, Miro Hrončok wrote: > On 02. 06. 21 10:02, Tomas Hrnciar wrote: >> Hello, in order to deliver Python 3.10, we are running a coordinated rebuild >> in a side tag. >> >> https://fedoraproject.org/wiki/Changes/Python3.10 >> <https://fedoraproject.org/wiki/Changes/Python3.10> >> >> If you see a "Rebuilt for Python 3.10" (or similar) commit in your package, >> please don't rebuild it in regular rawhide. >> If you need to, please let usknow, so we can coordinate. >> >> If you'd like to build the package, you should be able to build it in the >> side tag via: >> >> on branch rawhide: >> $ fedpkg build --target=f35-python >> $ koji wait-repo f35-python --build >> >> Note that it will take a while before all the essential packages are rebuilt, >> so don't expect all your dependencies to be available right away. When in >> trouble, ask here or on IRC (#fedora-python on Libera.Chat). >> >> Builds: >> https://koji.fedoraproject.org/koji/builds?latest=0=f35-python=-build_id=0 >> <https://koji.fedoraproject.org/koji/builds?latest=0=f35-python=-build_id=0> >> >> >> Please avoid any potentially disturbing changes in Python packages until the >> rebuild is over. >> >> Thanks. Let us know if you have any questions. > > The side tag has been merged into Rawhide. And we have a successful compose, so Python 3.10 is now the main Python on Rawhide. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-de...@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Tomcat Package Changes in Rawhide
On pe, 04 kesä 2021, Coty Sutherland wrote: On Fri, Jun 4, 2021 at 11:21 AM Fabio Valentini wrote: > That is the worst news I've gotten in a while :/ How many maven artifacts are being used? Could I get away with only providing poms/artifacts for the servlet/jsp/el implementations or do they need all 30+ artifacts? It wouldn't have been news if you checked if anything depends on those "mvn(foo:bar)" virtual Provides before dropping them ;) According to koschei, resteasy only depends on one maven pom though: No package found for: mvn(org.apache.tomcat:tomcat-servlet-api) See: https://koschei.fedoraproject.org/package/resteasy Not sure if just adding that one back will make it work again, though. That is true :) I didn't even think about virtual deps to be honest...shame on me for that. Anyway, it looks like pki-core and dogtag-pki depend on the servlet-api via resteasy, so adding it back should be fine. Now I just have to make that happen :) For consistency sake I guess I'll add the other spec impls too, in case anyone needs them. Just to report that one can track an installation issue like this with dnf -y groupinstall freeipa-server like it is done in OpenQA tests: https://openqa.fedoraproject.org/tests/902432#step/role_deploy_domain_controller/25 Once the build https://koji.fedoraproject.org/koji/buildinfo?buildID=1762794 with https://src.fedoraproject.org/rpms/tomcat/c/de863ffa6657ae4fb789d2ece41abe9f2413ea12?branch=rawhide would be in Rawhide compose, that test should succeed. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Javapocalypse is Monday
On pe, 04 kesä 2021, Fabio Valentini wrote: On Thu, Jun 3, 2021 at 11:31 PM Jerry James wrote: I've just been looking through my packager-dashboard page. A depressingly large chunk of my packages are going to become unbuildable on Monday when a bunch of orphaned Java packages are retired. I think a lot of us are going to be affected. In my case, there are quite a few non-Java packages involved (due to the parser generators antlr3 and antlr4-project), primarily OCaml and python packages. Mikolaj has a huge pile of work on his shoulders, so don't take this as criticism of him. Here are some of the pain points: - log4j will be retired, which will break ant. - hamcrest2 will be retired, which will break apache-commons-lang3, which will break bcel, which will also break ant. - google-gson and javassist will be retired, which will break reflections, which will break jna, which is used by about a dozen packages, including bcel. - maven-install-plugin will be retired, which will break tycho, which will break eclipse. - args4j will be retired, which will break jacoco and jgit. - maven-invoker-plugin and several of its dependencies (maven-doxia-sitetools, plexus-velocity, maven-reporting-api, maven-script-interpreter, and maven-reporting-impl) will be retired, which will break xml-maven-plugin, which is used by eclipse. - jakarta-el and jakarta-server-pages will be retired, which will break eclipse. - aopalliance will be retired, which will break maven-native. - jdependency will be retired, which will break maven-shade-plugin, which is used by openjfx8, a dependency of java-1.8.0-openjdk. - apache-ivy will be retired, which will break javapackages-tools. There's even more problems. Some of those packages are also transitive dependencies of PKI and FreeIPA (core component of Fedora Server etc.). I knew two of the guys who worked on the Fedora packages for this stack, but both have since left Red Hat, so I have no idea what's going on there. Dogtag team includes few more people than those who left the team. They were working past month with other Java teams at Red Hat to figure out how to support these dependencies in a longer term. The issue of dropped dependencies is taken seriously but since it involved internal teams' responsibilities, the discussiuon is not happening on a public mailing list. With the help of Mikalaj and Coty, hopefully, most of the issues would be solved, though at a cost of most of the depdendencies not used by Dogtag trimmed down. In addition, Dogtag is dropping some of own internal dependencies to switch its API from XML to JSON[1]. XML support in Dogtag's REST API is what forces it to require so many orphaned dependencies in Fedora. In general, despite Red Hat's generally big involvement in the Java world (with OpenJDK, JBoss, WildFly, Quarkus, etc.), their interest in actually maintaining packages for those projects (except the JDKs) is ... non-existent, which I find baffling. In my discussion with some Java application developers, their primary point of view is that Maven infrastructure provides them with the required content. There are point of view clashes with the needs of distributions like Fedora or RHEL. While for RHEL purposes there are infrastructure pipelines that allow to rebuild curated Maven content and then package it automatically in a RHEL-friendly way, Fedora project didn't accept this concept in past[2] -- I am sharing most of the arguments in [3] myself. Red Hat's Java-based product deployments are wider than targetting RHEL or Fedora, that makes a need for unified delivery approach prioritized and any deviations are much harder to handle. [1] https://github.com/dogtagpki/pki/issues/3553 [2] https://fedoraproject.org/wiki/KojiMavenSupport [3] https://fedoraproject.org/wiki/Talk:KojiMavenSupport -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Kerberos and Fedora's 2FA UX
On la, 24 huhti 2021, Kevin Fenzi wrote: On Sat, Apr 24, 2021 at 12:12:19PM +0300, Alexander Bokovoy wrote: On Пт, 23 апр 2021, Kevin Fenzi wrote: > On Fri, Apr 23, 2021 at 07:40:14AM +0200, Miroslav Suchý wrote: > > I have been using 2FA with the new Fedora Account system and the UX is ... can be improved. The question is how? > ...snip... > > I am pretty sure the IPA folks are aware that this can be improved and > are working on it. Hopefully one of them will chime in here. :) Aside from completing work on the 2FA SPAKE pre-authentication mechanism for Kerberos, right now we can do the following, all in hands of Fedora Accounts development team: - (easy) supply a script/wrapper like Miroslav is showing as a part of the fedora-packager rpm package Yeah, we talked about this a while back, I am not sure why it wasn't implemented. ;( Would someone care to submit a PR to fedora-packager for it? Otherwise hopefully we can get to it... - add PKINIT certificate management to Fedora Accounts application so that users can ask for and issue a personal PKINIT certificate from IPA CA used by Fedora and CentOS, which they then can use with their PIV smart cards Sure, we could look at doing that. Note however that we don't support smart cards at all currently, it's just TOTP. FreeIPA does support it, even if you don't provide an interface to it in Fedora Accounts. You are already using PKINIT to generate an anonymous PKINIT ticket for use as a FAST channel wrapper, so Fedora IPA instance is already configured for PKINIT. When a smart card pre-authentication is used, there is no need for two-step kinit use, PKINIT is a separate pre-authentication method and can be done at once. There are two ways of accepting certificates for PKINIT in FreeIPA: - add a public key to the user entry and make sure both KDCs and the client side trust the issuer chain - add certificate mapping rules that identify a user (Kerberos principal) from the certificate's properties. In this case only a client needs to know the issuer chain. In both cases it is possible to accept certificates that do not need to be issued by IPA CA itself, which makes possible to use something like your government-issued ID card, for example. See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_smart_card_authentication/index for more details. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Kerberos and Fedora's 2FA UX
On Пт, 23 апр 2021, Kevin Fenzi wrote: On Fri, Apr 23, 2021 at 07:40:14AM +0200, Miroslav Suchý wrote: I have been using 2FA with the new Fedora Account system and the UX is ... can be improved. The question is how? ...snip... I am pretty sure the IPA folks are aware that this can be improved and are working on it. Hopefully one of them will chime in here. :) Aside from completing work on the 2FA SPAKE pre-authentication mechanism for Kerberos, right now we can do the following, all in hands of Fedora Accounts development team: - (easy) supply a script/wrapper like Miroslav is showing as a part of the fedora-packager rpm package - add PKINIT certificate management to Fedora Accounts application so that users can ask for and issue a personal PKINIT certificate from IPA CA used by Fedora and CentOS, which they then can use with their PIV smart cards We know that U2F support would be the best approach here but right now it is not possible to support it without some heavy work MIT Kerberos upstream and FreeIPA upstream and that hinges on an RFC that is not yet written. Kerberos tickets can be issued for a longer time and can be refreshed. For example, I am typically issuing Fedora tickets for a week-long period, so I only need to run the kinit sequence once a week and then SSSD/GNOME Accounts tools are refreshing it every 8 hours automatically. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On to, 01 huhti 2021, Kevin Fenzi wrote: On Thu, Apr 01, 2021 at 01:50:40PM +0300, Alexander Bokovoy wrote: This split of fields in FreeIPA Web UI exists since FreeIPA 4.0 which was part of early RHEL 7 deliveries (the code for separate OTP field was added in 2014). There is nothing specific about it -- Noggin developers simply missed this part, as well as they missed OTP token sycnhronization functionality. Odd. I am looking at our "RED HAT IDENTITY MANAGEMENT" web interface and it has a Username and a Password field and the Password field has "Password or Password + One Time Password" in it. Sorry, I mixed these things myself. Main password login screen has only a password login field, not two. I mixed it up with the password reset form where there is a separate OTP field. Noggin can have a separate OTP field on the login screen, though. This would be a UX optimization as currently you'd still need to pass both values concatenated as a 'password' to the server in the login POST request. Once we add prompting support to kinit, though, we would be able to pass the OTP token value separately and could add a separate OTP value field to the server login form. library. SSSD does use them, so it is possible to change password through SSSD with separate prompts. Improving 'kpasswd' and 'kinit' utilities in on my todo list as I'll need this for other use cases as well. Cool. I'll investigate if we want to make this case easier. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On ti, 30 maalis 2021, Kevin Fenzi wrote:
On Tue, Mar 30, 2021 at 09:30:33AM +0300, Alexander Bokovoy wrote:
Could you please explain where you want to do it? Noggin (Fedora
Accounts app) does handle the login itself, not FreeIPA. In the context
of what Fedora contributors interact with, FreeIPA is only directly
exposed via Kerberos authentication flow.
Well, I don't know. I am not implementing anything myself.
I should leave that to the people who would be implemnting things (the
noggin team).
Noggin can be modified to accept separate password and token values. In
fact, FreeIPA Web UI does have password-based login implemented in this
way -- there are separate password and token value login fields if user
has OTP associated.
Yeah, note that we are using IPA / RHEL8. It does not have seperate
password and token fields, so I assume this is something coming to IPA
soon. :)
This split of fields in FreeIPA Web UI exists since FreeIPA 4.0 which
was part of early RHEL 7 deliveries (the code for separate OTP field was
added in 2014).
There is nothing specific about it -- Noggin developers simply missed
this part, as well as they missed OTP token sycnhronization
functionality.
Security query/response pairs are something that Noggin would need to
manage on top of FreeIPA as well and thus would handle login with them.
We do not have any mechanism in FreeIPA to allow you to handle this on
behalf of Noggin.
ok
For security query/response pairs to be useful in FreeIPA context,
they'd need to be plugged into the main password change flows. There are
currently two major ones and the rest just piggy-backs on either of
them:
- a password change via LDAP protocol
- a password change via Kerberos protocol
Our current scheme for resetting forgotten or unknown passwords in
FreeIPA requires administrators to initiate a reset with a temporary
password, pre-set or randomly generated. Then a user changes the
password via one of the two methods above -- either directly or with the
help of one of applications that utilize those, by specifying the
temporary password first and providing a new one afterwards.
Kerberos password change protocol implements a single request and a
single reply message where the request is initiated by a client and the
server replies with a success or an error, after which the password is
either updated or not. The request sent by the client includes a single
user-data component (part of generic Kerberos KRB_PRIV message as per
RFC4120 section 5.7.1).
I don't think this is supported via KDCproxy is it?
It is supported. We don't expose DNS URI record for
_kpasswd.fedoraproject.org but if you'd add 'kpasswd_server' to
/etc/krb5.conf.d/fedoraproject_org with the same value as 'kdc', it will
allow you to change the password:
[934873] 1617273694.628547: Sending DNS URI query for
_kpasswd.FEDORAPROJECT.ORG.
[934873] 1617273694.628548: No URI records found
...
[modify fedoraproject_org snippet]
...
$ cat /etc/krb5.conf.d/fedoraproject_org
[realms]
FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy
pkinit_anchors = FILE:/etc/pki/ipa/fedoraproject_ipa_ca.crt
kpasswd_server = https://id.fedoraproject.org/KdcProxy
}
[domain_realm]
.fedoraproject.org = FEDORAPROJECT.ORG
fedoraproject.org = FEDORAPROJECT.ORG
$ KRB5_TRACE=/dev/stderr kpasswd ab...@fedoraproject.org
...
Enter OTP Token Value:
...
Enter new password:
Enter it again:
[935146] 1617273825.195267: Creating authenticator for ab...@fedoraproject.org -> kadmin/chang...@fedoraproject.org, seqnum 0, subkey aes256-cts/9584, session key aes256-cts/4F2B
[935146] 1617273825.195269: Resolving hostname id.fedoraproject.org
[935146] 1617273825.195270: TLS certificate name matched "id.fedoraproject.org"
[935146] 1617273825.195271: Sending HTTPS request to https 8.43.85.67:443
[935146] 1617273825.195272: Received answer (236 bytes) from https
8.43.85.67:443
[935146] 1617273825.195273: Terminating TCP connection to https 8.43.85.67:443
[935146] 1617273825.195274: Read AP-REP, time 1617273825.195268, subkey
aes256-cts/9584, seqnum 834862168
Password changed.
Note that in 'kpasswd' and 'kinit' utilities you have to concatenate
password and OTP token value in the same string, unfortunately, because
these utilities don't use prompting facilities available in MIT Kerberos
library. SSSD does use them, so it is possible to change password
through SSSD with separate prompts.
Improving 'kpasswd' and 'kinit' utilities in on my todo list as I'll
need this for other use cases as well.
If we'd want to add security query/response pairs to allow users to
'securely' reset their passwords initiated by themselves, this would be
possible with an appropriate extension of an LDAP control and changes to
FreeIPA Web UI and Noggin to support that. The bigger problem is to find
a way to securely store these pairs encrypted per user. Right now the
only per-user secret we have is something generated
Re: Disable bodhi auto-update creation on rawhide?
On ti, 30 maalis 2021, Ian McInerney wrote: Is there a way I can disable the creation of updates automatically in Bodhi for builds I submit to rawhide? I find it very inconvenient because it means I can't add the appropriate bugzilla references/description to the update when I submit package updates that need them. I would prefer the behavior of branched releases where I have to make the update myself. One way to get around that right now is by using side-tags. If you created a side-tag for rawhide and built packages in it, then they would not be submitted automatically. Instead, you'd need to create a bodhi update yourself for this side-tag. This gives you back all the control but with an overhead of a side-tag. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On ma, 29 maalis 2021, Kevin Fenzi wrote: On Sat, Mar 27, 2021 at 11:02:58PM +0100, Björn Persson wrote: Kevin Fenzi wrote: > I'd like us to add security query/respond pairs. Those can very easily weaken security, as the answers are often public and easy for an attacker to look up, especially when there are only a few predefined questions to choose from. I was not advocating predefined questions. :) If I can enter my own question, then I can come up with some things that only I and my family know. That requires careful and security- conscious consideration. Many people would come up with insecure questions. Well, I always use randomly generated words for mine. But I agree, some people would make poor choices there. There's a limited supply of such personal secrets that I can be sure I'll remember, so I can't do that for too many sites. It also requires a not too public life. People who publish their entire lives on Facebook will have trouble coming up with a question that an attacker can't find the answer to. Another reason to randomly generate. Otherwise I'll make up a nonsensical phrase to enter as the answer, and store it securely. That turns the "security question" into a backup passphrase. If you want people to do this, then it's better to ask them to make up a passphrase. Sure, that might be better, although I still like that it's a manual process. ie, they have to tell it to an admin and the admin has to make sure everything looks right, etc. But in the end there's lots of ways to do all this, but one good reason we wanted to get off running our own account system was to not have to deal with this so much. So, really I think we should work to improve / land any changes we want here in IPA itself. Then everyone can benifit from it, and the IPA team that has a lot more security experence than I can do the right thing implementing it. :) Of course IPA has focused on the corp setting and this is kind of an expansion of their area, so we will need to discuss things with them I think. Could you please explain where you want to do it? Noggin (Fedora Accounts app) does handle the login itself, not FreeIPA. In the context of what Fedora contributors interact with, FreeIPA is only directly exposed via Kerberos authentication flow. Noggin can be modified to accept separate password and token values. In fact, FreeIPA Web UI does have password-based login implemented in this way -- there are separate password and token value login fields if user has OTP associated. Security query/response pairs are something that Noggin would need to manage on top of FreeIPA as well and thus would handle login with them. We do not have any mechanism in FreeIPA to allow you to handle this on behalf of Noggin. For security query/response pairs to be useful in FreeIPA context, they'd need to be plugged into the main password change flows. There are currently two major ones and the rest just piggy-backs on either of them: - a password change via LDAP protocol - a password change via Kerberos protocol Our current scheme for resetting forgotten or unknown passwords in FreeIPA requires administrators to initiate a reset with a temporary password, pre-set or randomly generated. Then a user changes the password via one of the two methods above -- either directly or with the help of one of applications that utilize those, by specifying the temporary password first and providing a new one afterwards. Kerberos password change protocol implements a single request and a single reply message where the request is initiated by a client and the server replies with a success or an error, after which the password is either updated or not. The request sent by the client includes a single user-data component (part of generic Kerberos KRB_PRIV message as per RFC4120 section 5.7.1). LDAP password change may include and return a control that could be used to pass through some additional information in both directions with a bit more flexibility than on the Kerberos side. It still requires that an LDAP client implements this exchange so Noggin would need to implement the logic for this too. If we'd want to add security query/response pairs to allow users to 'securely' reset their passwords initiated by themselves, this would be possible with an appropriate extension of an LDAP control and changes to FreeIPA Web UI and Noggin to support that. The bigger problem is to find a way to securely store these pairs encrypted per user. Right now the only per-user secret we have is something generated with the help of its password but since this is all about being able to reset that password without knowing its content, we need somewhat different method that would still be secure against others. In FreeIPA nobody, including administrators, is able to discover the user's password from a hashed form. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Lim
Re: Proposal to fail builds if RPATH is found in Fedora 35
isen condor ttomecek scipy ueno libkkc valtri condor volter qwtpolar vpolasek openscap vstinner python2.7 wsato openscap scap-workbench wzzrd pam_yubico zeenix gupnp-dlna -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is Pagure openid login broken?
On to, 25 maalis 2021, Richard W.M. Jones wrote: On Thu, Mar 25, 2021 at 01:30:56PM -0400, Matthew Miller wrote: On Thu, Mar 25, 2021 at 05:10:47PM +, Richard W.M. Jones wrote: > https://pagure.io/login/?next=https://pagure.io/ > > It says: > > "No email address was returned by your OpenID provider, this > information is mandatory for pagure" Yeah. I'm seeing this too when testing in a private window. Since I am logged in, I'll file the issue. Just now (a few seconds ago) it "fixed itself" and worked. I don't know why and I suppose it's still a bug so thanks for filing one. If I understand it correctly, you caught a state in the middle of upgrades. Ipsilon IdP was actually reconfigured to use FreeIPA-provided data and some of attribute mappings did change which required modifications. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer: kir
On ti, 16 maalis 2021, Pierre-Yves Chibon wrote: Good Morning Everyone, Since February 24th the packager kir has been receiving a daily email asking them to either adjust their bugzilla or their FAS account so the email address in FAS matches an existing bugzilla account. Having a bugzilla account is mandatory per: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account kir is maintainer of rpms/runc Does anyone know how to contact kir? Yes, I asked Kir to respond. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ti, 02 maalis 2021, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:
On ma, 01 maalis 2021, Lennart Poettering wrote:
>On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
>
>>> 1. Dots (".") for separating IPV4 address bytes
>>> 2. Colons (":") for separating IPv6 address parts, as well as separating
>>> port numbers from the IP addres
>>> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
>>> construct
>>> 4. Percent ("%") characters to separate interface info from the rest
>>> 5. Hash ("#") characters to separate SNI host name specifications
>>>
>>> Now, we currently don't use "," and ";" for separators here, but as
>>> these things keep growing we might need them for something soon too.
>>
>>I understand your willingness to apply the same rules for multiple
>>options in the config files owned by systemd codebase. This, however, is
>>a content pushed out by external parties, not a part of systemd
>>proper.
>
>It's a configuration file *owned* by resolved. it's its private
>property, with defined and documented syntax. if other tools make
>changes to that config files, but they better follow the documented
>syntax then.
>
>I'd be a lot more open to a more relaxed parser if this was some
>"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
>owned by glibc and is maybe even more generic than that. There it's
>our duty to to accept even the worst formatted files.
>
>But resolved.conf is inherently only ours, we define the contents and
>are the sole consumer of it. Hence I think we don't have to be and
>shouldn't be so lenient, so that the variances remain smaller.
>
>I mean, I#d consider the original issue here a simple bug. The
>question is simply where to fix it: in cloud-init or in systemd. Given
>that cloud-init is responsible for it, and given that either way
>there's exactly one project to fix I think it should be cloud-init
>that is fixed.
Clearly, what happened in the cases described in this thread, is that
some other configuration file was imported into resolved state and
parsing the content that came from that import was failing.
This is what I think an issue on systemd-resolved side. See below for
cloud-init part.
>
>>Digital Ocean updates pushed with cloud-init use. Cloud-init does not
>>have any native support for systemd-resolved. It means it writes
>>something that systemd-resolved imports into own state. I would argue
>>that your arguments for systemd-wide configuration rules do not apply
>>here. Either you'd need to fix cloud-init or allow for a variance in
>>input data that comes to systemd-resolved from third parties.
>
>Hmm, cloud-init has no direct support for resolved.conf? But how is it
>then that that file is modified? I don't get it?
https://github.com/canonical/cloud-init/search?q=resolved.conf --
nothing handles resolved.conf.
It is done by something else after parsing cloud-init provided content.
For example, on my Digital Ocean's node which is not affected by this
bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by
cloud-init.
The network scripts update is done by
cloudinit/net/sysconfig.py:Renderer._render_subnets() method.
Additionally, render_network_state() writes down NetworkManager
configuration snippet.
Does systemd-resolved parse any of those?
No.
It seems DigitalOcean added *custom code* [1] to write
/etc/systemd/resolved.conf,
and in *that new code* they messed up the syntax. Considering that it's
new code, it seems most reasonable to just fix that.
Yes, I agree with that. How can we ensure they'd fix it? :)
[1]
https://www.digitalocean.com/community/questions/fedora-33-how-to-persist-dns-settings-via-etc-resolv-conf?comment=96290
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ti, 02 maalis 2021, Ed Greshko wrote: On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. This can be said about pretty much every public cloud provider with 'cheap' systems that easy to deploy and remove. I see 'ssh' attacks everywhere to any just created machine. -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ma, 01 maalis 2021, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> 1. Dots (".") for separating IPV4 address bytes
> 2. Colons (":") for separating IPv6 address parts, as well as separating
> port numbers from the IP addres
> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
> construct
> 4. Percent ("%") characters to separate interface info from the rest
> 5. Hash ("#") characters to separate SNI host name specifications
>
> Now, we currently don't use "," and ";" for separators here, but as
> these things keep growing we might need them for something soon too.
I understand your willingness to apply the same rules for multiple
options in the config files owned by systemd codebase. This, however, is
a content pushed out by external parties, not a part of systemd
proper.
It's a configuration file *owned* by resolved. it's its private
property, with defined and documented syntax. if other tools make
changes to that config files, but they better follow the documented
syntax then.
I'd be a lot more open to a more relaxed parser if this was some
"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
owned by glibc and is maybe even more generic than that. There it's
our duty to to accept even the worst formatted files.
But resolved.conf is inherently only ours, we define the contents and
are the sole consumer of it. Hence I think we don't have to be and
shouldn't be so lenient, so that the variances remain smaller.
I mean, I#d consider the original issue here a simple bug. The
question is simply where to fix it: in cloud-init or in systemd. Given
that cloud-init is responsible for it, and given that either way
there's exactly one project to fix I think it should be cloud-init
that is fixed.
Clearly, what happened in the cases described in this thread, is that
some other configuration file was imported into resolved state and
parsing the content that came from that import was failing.
This is what I think an issue on systemd-resolved side. See below for
cloud-init part.
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.
Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?
https://github.com/canonical/cloud-init/search?q=resolved.conf --
nothing handles resolved.conf.
It is done by something else after parsing cloud-init provided content.
For example, on my Digital Ocean's node which is not affected by this
bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by
cloud-init.
The network scripts update is done by
cloudinit/net/sysconfig.py:Renderer._render_subnets() method.
Additionally, render_network_state() writes down NetworkManager
configuration snippet.
Does systemd-resolved parse any of those?
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On pe, 26 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:
I think one of the issues reported in the discussion you mention was
that systemd-resolved considered invalid a DNS= line where addresses
were separated by a comma rather than space. Can systemd-resolved be
improved to allow common separators like both space and comma?
I am not a fan of such needless ambiguity, and it's not going to
retroactively fix the original reporter's configuration that has now
been fixed anyway... Moreover, across the systemd codebase in
configuration files we so far stuck to using mostly whitespace for
separating multiple values on the same config option line.
The thing is: separator characters end up being used for various other
purposes sooner or later. For example the DNS= lines in resolved.conf
already uses:
1. Dots (".") for separating IPV4 address bytes
2. Colons (":") for separating IPv6 address parts, as well as separating
port numbers from the IP addres
3. Brackets ("[]") for separating ipv6 addresses from the rest of the
construct
4. Percent ("%") characters to separate interface info from the rest
5. Hash ("#") characters to separate SNI host name specifications
Now, we currently don't use "," and ";" for separators here, but as
these things keep growing we might need them for something soon too.
I understand your willingness to apply the same rules for multiple
options in the config files owned by systemd codebase. This, however, is
a content pushed out by external parties, not a part of systemd proper.
As pointed out by Michael in this discussion, Digital Ocean uses ',' to
separate DNS servers pushed out by cloud-init. I don't think they are
alone in this.
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ke, 24 helmi 2021, Lennart Poettering wrote: On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote: The scenario of roaming laptops/phones is completely different from this. Which is why I have argued for a long time now that systemd-resolved should not be installed by default on servers or containers. It adds complexity without any real gain in these deployments and makes DNS issues harder to troubleshoot. There are two kinds of containers: docker-style containers that only have a single process (more or less) in them, or nspawn-style containers that have a full init system in them, that may run their own network management solution and maybe sshd or so, that basically behave like a VM (except they don't do any hw/storage management themselves, but leave that to the host). I think for nspawn-style containers the difference to the host should be kept at a minimum, and thus whatever a host running the same OS would run should also run inside the container. For docker-style containers the same obviously doesn't apply: if there's no init system inside the container it doesn't really make sense to run arbitrary services (and resolved is one) in them either. We run FreeIPA in a nspawn-style containers (podman rootless containers since Fedora 33) and we actually would benefit from the ability to disable systemd-resolved for the cases when IPA is deployed with integrated DNS server. Right now we are configuring systemd-resolved during IPA installation with integrated DNS to pass-through requests for IPA-hosted primary DNS zone to the local IPA DNS server but this is not enough as users can (and probably would) add multiple DNS zones. Setting a routing domain '~.' is probably a too much of an overhead here. I think the caching and DoT stuff that resolved provides is useful on any system, and that includes servers, and I think it would be good to minimize the difference in the APIs (and that includes D-Bus APIs) when we can. So I'd recommend doing resolved on server images too. This seems contradicting? The last resort method only sends all DNS queries to google as a last resort? It still means that in 100% of the cases that the last resort is activated, it sends all traffic to google? Furthermore, since it hides that this is happening, once the network is broken, it never gets fixed, and thus leads to the fallback always kicking in. We do log on invalid configuration (such as the invalid DNS= lines discussed earlier on this ML), as mentioned. And then proceed without it, so that the fallback paths might apply (unless we can acquire DNS info from elsewhere, e.g. DHCP). I think one of the issues reported in the discussion you mention was that systemd-resolved considered invalid a DNS= line where addresses were separated by a comma rather than space. Can systemd-resolved be improved to allow common separators like both space and comma? -- / 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On ma, 22 helmi 2021, Miro Hrončok wrote:
tomcat-taglibs-parent orphan 5 weeks ago
I've taken tomcat-taglibs-{parent,standard} as they are required for
tomcat which is needed for Dogtag which is needed for FreeIPA.
I rebuilt tomcat-taglibs-parent in Rawhide already by syncing it with
upstream POM spec (mostly update to require JDK8+, should be noop for
Fedora).
tomcat-taglibs-standard is only required by tomcat-webapps which is not
required by anything in Fedora, so we can discuss what to do with it but
since this version of JSP Standard Tag Library implementation is rather
solid, I don't think it would need any changes, just timely rebuilds
until it is retired upstream.
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Chris Murphy wrote: >> > ram + zram + in-memory-zwap in the check. >> >> For bare metal IPA uses the python3-psutil call: >> psutil.virtual_memory.available() >> >> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that >> matter). > > psutil (in general) reports data from /proc/meminfo; available come > from MemAvailable: in that file. This is defined in kernel as: > >MemAvailable: An estimate of how much memory is available for starting new > applications, without swapping. Calculated from MemFree, > SReclaimable, the size of the file LRU lists, and the low > watermarks in each zone. > The estimate takes into account that the system needs some > page cache to function well, and that not all reclaimable > slab will be reclaimable, due to items being in use. The > impact of those factors will vary from system to system. > >Notice "without swapping" in second line. Next question, how zram impacts >reporting of MemAvailable by kernel? This is a good note. If zram breaks kernel API promise to user space (/proc/meminfo is one such API), how can it be enabled by default. I also would question enabling zram by default if it does not play along with cgroups. We do depend on cgroups being properly managed by systemd, including resource allocation. In my opinion, zram enablement in Fedora is quite premature. It's the default Fedora wide since Fedora 33. It's been used by default in Fedora IoT since the beginning, and in openQA Anaconda tests for even longer than that. What's premature about it? I tried to point to my line of thought in the sentence above you quoted. You might think that is irrelevant which thought I'd accept as an argument and we can agree to disagree. Back to this subthread's topic. Looks like Adam found that something did reduce a memory available to the system after standard install process between Jan 24th and Jan 27th. Something did allocate ~120MB of RAM more than it did previously on Fedora Server but also the kernel reports ~600MB less RAM available even though in both cases QEMU was configured with 2048MB RAM. -- / 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Chris Murphy wrote:
On Thu, Jan 28, 2021, 6:21 AM Alexander Bokovoy <[1]aboko...@redhat.com>
wrote:
With today's OpenQA tests I can point out that using zram on 2048MB RAM
VMs actually breaks FreeIPA deployment:
[2]https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
FreeIPA deployment with integrated CA and DNS server. Not anymore with
zram activated:
Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
dev-zram0.swap (/dev/zram0 with 1384MB)
Swap on zram isn't recently enabled in Fedora, so why are the tests
recently failing?
Also, the default fraction is 0.5 so the zram device size should be
1024MB. Why is it 1384MB?
I have no idea why. This is Rawhide of today, automatically provisioned
in OpenQA. All logs are available in 'Logs and Artifacts' tab on the
OpenQA page referenced above.
Tests started to fail because we raised the low memory limit in FreeIPA
from 0.7GB to 1.2GB after seeing real world issues with lower memory
pressures.
which ends up eating 2/3rds of the whole memory budget and FreeIPA
installer fails:
That's not possible with default settings. The device size is not the
amount of memory used. The device size is virtual. The real amount used
depends on what's paged out to swap divided by the commission ratio.
If swap is being used at all it means the workload already used ~95% of
memory.
In the OpenQA test there is nothing running on the system yet. This
literally happens when a test runs 'ipa-server-install' and we haven't
yet gone to configure *anything*. This check is one of the earliest in
the installer.
2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
[] and options: {'unattended': True, 'ip_addresses': None,
'domain_name': '[3]test.openqa.fedoraproject.org', 'realm_name':
'[4]TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
2021-01-28T02:18:31Z DEBUG IPA platform fedora
2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
Prerelease)
2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
...
2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
0.77GB available.
We need more info. Something is consuming more memory than the
provisioning expects. If there was no swap, the problem would be worse.
Please look into OpenQA logs. There is a tarball with /var/log/* content
there (and few more things), including a full systemd journal which
might have some additional information.
--
/ 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Tomasz Torcz wrote:
On Thu, Jan 28, 2021 at 11:04:34AM -0500, Rob Crittenden wrote:
Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
>> With today's OpenQA tests I can point out that using zram on 2048MB RAM
>> VMs actually breaks FreeIPA deployment:
>>
https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
>>
>> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
>> FreeIPA deployment with integrated CA and DNS server. Not anymore with
>> zram activated:
>>
>> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
dev-zram0.swap (/dev/zram0 with 1384MB)
>>
>> which ends up eating 2/3rds of the whole memory budget and FreeIPA
>> installer fails:
>>
>> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
'test.openqa.fedoraproject.org', 'realm_name': 'TEST.OPENQA.FEDORAPROJECT.ORG',
'host_name': None, 'ca_cert
>> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
>> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
>> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
Prerelease)
>> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
>> ...
>> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed, exception:
ScriptError: Less than the minimum 1.2GB of RAM is available, 0.77GB available
>> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
0.77GB available
>> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
>
> Enabling zram doesn't really "take away memory", because no pre-allocation
happens.
> If there is no physical swap, then adding zram0 should just shown additional
> swap space, so I don't think it could cause the check to fail.
> But if there is physical swap, the zram device is used with higher preference
> than the physical swap. So I think the explanation could be that the VM has
> a swap partition. Before, some pages would be swapped out to zram, and some
would
> be swapped out to the "real" swap. The fraction of RAM used for compressed
zram
> would be on the order of 25% (zram-fraction=0.5 multiplied by typical
compression 2:1).
>
> But now the kernel sees more zram swap, so it inserts pages there, taking away
> more of RAM, instead of saving pages to disk. So more memory (maybe 50% RAM)
is
> used for the unswappable compressed pages. But this shouldn't break things:
> if there is enough pressure, pages would be swapped out to the physical swap
device
> too.
>
> Assuming that this guess is correct, the check that ipa-server-install is
> doing should be adjusted. It should use the total available memory (ram + all
kinds
> of swap) in the check, and not just available uncompressed pages.
> Or if it wants to ignore disk-based swap for some reason, it should use
> ram + zram + in-memory-zwap in the check.
For bare metal IPA uses the python3-psutil call:
psutil.virtual_memory.available()
I don't know how/if psutil reports zram (or cgroup v1 and v2 for that
matter).
psutil (in general) reports data from /proc/meminfo; available come
from MemAvailable: in that file. This is defined in kernel as:
MemAvailable: An estimate of how much memory is available for starting new
applications, without swapping. Calculated from MemFree,
SReclaimable, the size of the file LRU lists, and the low
watermarks in each zone.
The estimate takes into account that the system needs some
page cache to function well, and that not all reclaimable
slab will be reclaimable, due to items being in use. The
impact of those factors will vary from system to system.
Notice "without swapping" in second line. Next question, how zram impacts
reporting of MemAvailable by kernel?
This is a good note. If zram breaks kernel API promise to user space
(/proc/meminfo is one such API), how can it be enabled by default. I
also would question enabling zram by default if it does not play along
with cgroups. We do depend on cgroups being properly managed by systemd,
including resource allocation.
In my opinion, zram enablement in Fedora is quite premature.
--
/ 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
a case of us moving back to disk-based swap soon. There still is no cgroups support in device-mapper, and right now the only way to secure swap is to put it on dm-crypt. One of the benefits of zram-based swap is, it's volatile, so any leaks of personal information can be ignored (at least if the system is powered off). Another issue is dynamically creating/removing swapfiles. We kinda want to avoid partitions because that preallocation siphons away a possibly limited resource that may not get used at all; and also related is still pending work (not yet happening) on Secure Boot and hibernation images which would necessarily need disk based swap. Anyway there's quite a lot of work happening, and even though it isn't ready to be used by default in Fedora, it is a good time for early adopters to do performance testing as this work continues. I anticipate the server and desktop will eventually move away from zram-based swap, but I can't give a time frame for it. [1] For the early adopters who want to experiment with their swap dependent workloads and different configurations: https://github.com/facebookexperimental/resctl-demo [2] One thing not discussed much is where to put the swapfile on Btrfs. This is my current suggestion: btrfs sub create /var/swap chattr +C /var/swap fallocate -l 4G /var/swap/swapfile1 mkswap /var/swap/swapfile1 swapon /var/swap/swapfile1 Be sure to read the limitations in 'man 5 btrfs' - the above takes care of most concerns, the other one is it needs to be a single device Btrfs. Other arrangements are possible. Ping me on irc (cmurf) if you have questions about alternatives. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- / 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
Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On to, 03 joulu 2020, Matthew Miller wrote: On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote: I suppose we could look into this, but it seems kind of complementary to me: Server: a install dvd, pxe/netboot Cloud: a runnable image Are folks wanting to drop the dvd and netinstall? Or just market the Cloud image more to server admins that want a ready to run image? Mostly the latter. I don't even really care if they end up keeping the distinct os-release and etc. I do care about being able to deploy from DVD or pxe/netboot. For home environments cloud images are not everything you need, especially for home infrastructure. FreeIPA on Fedora is one of practical home infrastructure deployment targets. The linux-system-roles is it's own project... so I am not sure what the working group would do here? Help them? Help them, and help make it feel like a primary feature of Fedora Server. Right now, our marketing materials at https://getfedora.org/en/server/ highlight: * modularity * cockpit * FreeIPA -- / 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On to, 26 marras 2020, Alexander Bokovoy wrote: On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote: On ke, 25 marras 2020, Tomáš Popela wrote: On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy wrote: Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi. Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium? Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work. It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect. I get the same behavior in Chrome but in Firefox it shows proper dialogs and still fails to send anything out. With the help of Tomas and Jan, we've got this sorted out. Upgrade to pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to share the screen. It doesn't help with UX of pipewire portal dialogs but this is something I can live with for time being. -- / 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote: On ke, 25 marras 2020, Tomáš Popela wrote: >On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy >wrote: > >>Screencasting still does not work in Fedora 33. It pretends to work as >>in claiming through the applications and GNOME indicators that the >>screen / application window / browser tabs are shared but nothing gets >>actually shared. Tested today with Firefox and Chrome on Wayland for >>Google Meet, BlueJeans, Jitsi. >> > >Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you >have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in >Chrome/Chromium? Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work. It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect. I get the same behavior in Chrome but in Firefox it shows proper dialogs and still fails to send anything out. -- / 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On ke, 25 marras 2020, Tomáš Popela wrote: On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy wrote: Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi. Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium? Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work. What I also see on this F33 instance is that mic input often disappears from Chrome -- Firefox continues to see it but Chrome doesn't. And it is even for a built-in mic on the laptop. In fact, I have now three mics connected (one in Logitech's camera, one USB mic, one built-in) and regularly get Chrome to not see any of the mics while GNOME Settings can see them. Restart of Chrome helps for the first meeting done, then I need to restart it again. But even in Firefox no actual screen sharing happens. It doesn't complain -- simply nothing gets out while everything is saying it should. -- / 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
. It ultimately depends on how confident people feel after using it for a while. I've tried it and it doesn't work You have not tried what we propose for rawhide and f34 because there is no easy way to install this yet, please stay tuned. We're going to be fixing the dependencies and upgrading to the latest versions to make this easy. Also please tell us what is wrong and please try again after a fix landed. Much of the instability with browsers and music players got fixed after the pulseaudio replacement server was implemented. but I don't want to test all this This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey. but this and that is broken, it's all pointless, why bother, you'll never get this fixed in time Maybe so. Please let us know what's broken. It might be an easy fix and we can retest an updated version. Or not, and then it's a blocker and we roll back. But you have to let us know. So my proposal still is: * Make it easy to swap, hopefully get that working smoothly next week. stay tuned. * Enable by default in rawhide * fix bugs, repeat, retest.. * collect final experiences at beta freeze, re-evaluate rollback or not Is this something we can agree on? Wim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- / 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
Re: Fedora 34, faccessat, and containers (was: Re: Fedora 34 Change: GNU Toolchain update (gcc 11, glibc 2.33) (System-Wide Change))
On ti, 24 marras 2020, Florian Weimer wrote: * Fabio Valentini: Are there plans to fix the glibc faccessat2 issues with older systemd-nspawn and docker? It would be a shame if fedora 34 containers wouldn't be able to run correctly in most circumstances. I've brought the discussion to what I think are the appropriate forums: <https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/> <https://groups.google.com/a/opencontainers.org/g/dev/c/8Phfq3VBxtw> I've also posted a glibc upstream patch to show what it would look like: <https://sourceware.org/pipermail/libc-alpha/2020-November/119955.html> Personally, I find it difficult to support such an approach technically, and I would like to see some reassurance from kernel developers that this is okay. Feedback so far is in the opposite direction, though. Thanks, Florian. For those who need this working now rather when Docker is fixed (as promised by Aleksa in the linux-api@ thread), I ended up taking libseccomp 2.5 from Debian Sid and making a PPA with it for Ubuntu 20.04. It seems to help now, so if others have the same need, installing libseccomp2 from the https://launchpad.net/~abbra/+archive/ubuntu/freeipa-libseccomp should help -- you also need to add 'faccessat2' to the Docker profile. Example use in FreeIPA is https://pagure.io/freeipa/c/1bf0d628281f33693a1f6c6e156b0c258eee929e?branch=master -- / 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
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On Sat, 21 Nov 2020, Neal Gompa wrote: On Sat, Nov 21, 2020 at 3:53 PM James Szinger wrote: On Sat, 21 Nov 2020 19:47:30 - "Tom Seewald" wrote: > Things like bluetooth support, audio for flatpak applications, and > the new pulse server were just added in the last month or so and > there are issues with stability and audio playback (look at the issue > tracker [1]), for example HSP is still marked as WIP [2]. It seems > premature to commit to this change before the core features have been > stabilized and more testing has been done. Audio is an area where > users really have no tolerance for it misbehaving. Pushing a change > like this too early can create a negative perception of the project > which is something we should try to avoid (within reason). According to the FAQ `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ` Is PipeWire ready yet? It is getting ready for broader testing. There’s also `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3` Upstream says it is not ready! Linux has had a large number of audio systems (OSS, ALSA, ESD, pulseaudio, and probably some I’ve forgotten), and almost as many painful transitions from one to the next. Since then audio has become a vital part of the computer desktop experience. Please make this less painful and don’t make this the default until it is ready and tested. The upstream developer of PipeWire is the one who submitted this Change proposal. Before this proposal was submitted, he talked to us in the Workstation WG about it and stated that he's confident that PipeWire is in good shape for Fedora 34 and provides a straightforward way to fall back to legacy PulseAudio as needed. I spent about three weeks trying to live with pipewire in October/November and encountered a lot of issues, most of them were already reported. The most important one is instability of conference calls with Google Meet in both Firefox and Chrome and inability to share more than a single browser page window on Wayland. The pipewire and its portal are stating everything is ok but the content is simply not streaming out. Also, constant change of the audio inputs and outputs, like arbitrarily switching the defaults for mic between USB devices, thunderbolt-based dock and the built-in one on Thinkpad attached to the dock, is making it very hard to accept it is a stable and predictable software. These are the ones that really turned me away from using pipewire on F33. I tried twice: first with F32, then F33 and it is simply not ready for even basic office use case with a laptop in dock and multiple monitors with audio outputs. This is just one evidence point, of course, and highly personal, but I do not see how pipewire could become a default with the current quality. Shipped in parallel, with easy to switch ways, sure. -- / 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
Re: systemd-resolved in a container
On to, 19 marras 2020, Nikos Mavrogiannopoulos wrote: On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy wrote: On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote: >Hi, > I realized my fedora-based containers have an /etc/resolv.conf which >claims it is managed by resolved, and nsswitch.conf has "resolve" in >hosts. However, doing something like ># systemd-resolve --status > >results to: >sd_bus_open_system: No such file or directory > >Trying to start dbus claims that systemd is not the init: ># systemctl start dbus >System has not been booted with systemd as init system (PID 1). Can't operate. >Failed to connect to bus: Host is down > > >Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. Is that on the "default" fedora container, or do you use something else? On fedora33 I get the same message about dbus and systemd not being pid 1. We build our own Fedora container with systemd based on the 'default' one. I haven't tried 'fedora-init' variant as Dan suggested. -- / 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
Re: systemd-resolved in a container
On ke, 18 marras 2020, Paul Wouters wrote: On Wed, 18 Nov 2020, Alexander Bokovoy wrote: Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. What is the advantage of running systemd-resolved in a container? Is that container doing mDNS or LLMNR or a split-dns VPN ? The whole point of containers is isolation and minimal setups. Pulling in Base OS components into each container seems a waste of resources? It is part of systemd packaging and gets pulled in with that if you need systemd -- like we need for FreeIPA CIs or FreeIPA container deployments. # rpm -qf /usr/lib/systemd/systemd-resolved systemd-246.6-3.fc34.x86_64 -- / 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
Re: systemd-resolved in a container
On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote: Hi, I realized my fedora-based containers have an /etc/resolv.conf which claims it is managed by resolved, and nsswitch.conf has "resolve" in hosts. However, doing something like # systemd-resolve --status results to: sd_bus_open_system: No such file or directory Trying to start dbus claims that systemd is not the init: # systemctl start dbus System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. -- / 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
Re: Non-responsive maintainer johnp for python-ldap package request
On la, 24 loka 2020, Miro Hrončok wrote: On 10/24/20 5:48 AM, John Palmieri wrote: On Fri, Oct 23, 2020 at 5:43 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 10/23/20 6:13 PM, Alexander Bokovoy wrote: > On pe, 23 loka 2020, John Palmieri wrote: >> I haven’t been a Linux dev for some time now. I can’t even figure out how >> to log into Fas anymore otherwise I would help out. > > Thank you for the response, John. > > Does it mean that I should proceed with the non-responsive process right > away so that FESCO would be able to switch the maintainership to me? If you agree John, I'll remove your assignment from Fedora packages right away. Please do. Done. I gave python-ldap to cheimes and removed johnp from all other packages. Christian, please consider adding @python-sig. John and Miro, thank you for prompt response! -- / 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
Re: Non-responsive maintainer johnp for python-ldap package request
On pe, 23 loka 2020, John Palmieri wrote: I haven’t been a Linux dev for some time now. I can’t even figure out how to log into Fas anymore otherwise I would help out. Thank you for the response, John. Does it mean that I should proceed with the non-responsive process right away so that FESCO would be able to switch the maintainership to me? On Fri, Oct 23, 2020 at 9:24 AM Alexander Bokovoy wrote: Hi, I am trying to initiate a non-responsive maintainer process for johnp for package python-ldap. Following the process defined at[1], I filed the following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1890982 Prior to that, I tried to communicate with maintainers of python-ldap package (there are 9 of them) with no response to my request sent to the package maintainers alias at fedoraproject.org (reproduced below as it explains my request). Prior to that, I opened a pull request[2]. As can be seen in Koji[3], none of the current package maintainers worked on python-ldap package since 2016 when Petr Spacek was a member of my team at Red Hat. While Petr is still marked as a maintainer of the python-ldap package, he is not working on it or any other Fedora packages for quite some time. He also has no rights to give maintainership to the package to us. Date: Wed, 21 Oct 2020 10:34:54 +0300 From: Alexander Bokovoy To: python-ldap-maintain...@fedoraproject.org Cc: chei...@redhat.com Subject: Please give abbra and cheimes rights to python-ldap Hi, I am a maintainer of FreeIPA -- upstream, in Fedora, and in RHEL. FreeIPA depends on python-ldap package heavily and we would like to take over its maintainership in Fedora. My colleague Christian Heimes is already maintaining it in RHEL 8 and also is one of python-ldap upstream developers. It looks like the current set of maintainers of Fedora python-ldap package are not active -- all the commits in past two years were either mass rebuild ones or fixing build requires/mass changes to the spec files. We would like to acquire maintenance of python-ldap package in Fedora (and EPEL, if required), to allow us to make sure it is in functioning state in those distributions. Thank you in advance. For the procedure of giving rights of the package please see here: https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_give_a_user_commit_access_to_a_dist-git_repo.3F [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [2] https://src.fedoraproject.org/rpms/python-ldap/pull-request/7 [3] https://koji.fedoraproject.org/koji/packageinfo?packageID=942 -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- / 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
Non-responsive maintainer johnp for python-ldap package request
Hi, I am trying to initiate a non-responsive maintainer process for johnp for package python-ldap. Following the process defined at[1], I filed the following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1890982 Prior to that, I tried to communicate with maintainers of python-ldap package (there are 9 of them) with no response to my request sent to the package maintainers alias at fedoraproject.org (reproduced below as it explains my request). Prior to that, I opened a pull request[2]. As can be seen in Koji[3], none of the current package maintainers worked on python-ldap package since 2016 when Petr Spacek was a member of my team at Red Hat. While Petr is still marked as a maintainer of the python-ldap package, he is not working on it or any other Fedora packages for quite some time. He also has no rights to give maintainership to the package to us. Date: Wed, 21 Oct 2020 10:34:54 +0300 From: Alexander Bokovoy To: python-ldap-maintain...@fedoraproject.org Cc: chei...@redhat.com Subject: Please give abbra and cheimes rights to python-ldap Hi, I am a maintainer of FreeIPA -- upstream, in Fedora, and in RHEL. FreeIPA depends on python-ldap package heavily and we would like to take over its maintainership in Fedora. My colleague Christian Heimes is already maintaining it in RHEL 8 and also is one of python-ldap upstream developers. It looks like the current set of maintainers of Fedora python-ldap package are not active -- all the commits in past two years were either mass rebuild ones or fixing build requires/mass changes to the spec files. We would like to acquire maintenance of python-ldap package in Fedora (and EPEL, if required), to allow us to make sure it is in functioning state in those distributions. Thank you in advance. For the procedure of giving rights of the package please see here: https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_give_a_user_commit_access_to_a_dist-git_repo.3F [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [2] https://src.fedoraproject.org/rpms/python-ldap/pull-request/7 [3] https://koji.fedoraproject.org/koji/packageinfo?packageID=942 -- / 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
On to, 01 loka 2020, Michael Catanzaro wrote: On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz wrote: I think, he meant the systemd-resolved fiallback to Cloudflare and Google. Is that in the fedora build? If so, i suggest to patch it out. That will fix the issue for me in perspective of the GDPR. Unless you explain this *very* clearly, I'm going to ignore it, because it seems farfetched. Fedora is not operating its own DNS server or collecting any sort of DNS-related data from you. We are not going to patch out fallback to Cloudflare or Google because it is a non-issue. Fallback only happens when you have zero other DNS servers configured. When was the last time you connected to a network and there's no DHCP, no nothing? The number of users without some other working DNS is probably under 0.1%. Even then, I think you also have to disable NetworkManager for systemd-resolved to ever use its fallback DNS, because NetworkManager will configure a ~. DNS domain, causing systemd-resolved to never use its global DNS settings. (I think. That's my reading of the manpage. Testing welcome from anyone who wants to confirm that.) We use the drop-in snippet configuration file in /etc/systemd/resolved.conf.d/zzz-ipa.conf to configure this behavior on IPA servers which deploy integrated DNS server. It works, so there is a confirmation. So (if I'm right) we are talking about the exceeding rare combination of (a) no DNS set by DHCP, and also (b) user manually disabled NetworkManager. If you're really going to do (b) you will probably also disable systemd-resolved, right? Or make the one-line config file change to remove the fallback DNS? Or just manually set some DNS server? Seriously, this is a silly thing to worry about. You can also drop a configuration snippet in /etc/systemd/resolved.conf.d/ to contain FallbackDNS= This will disable global DNS servers for any case. -- / 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
Re: Lenovo P1G2 and P53 web sales updates
On to, 24 syys 2020, Mark Pearson wrote: Hi Fedora community, Just wanted to drop a note to the community as I'm sure you're wondering where the P1G2 and P53 are with the web sales. It's been a frustrating experience and we've been working past issue after issue for weeks but it looks like we hit the wall today. One of the major issues we've been fighting with the web sales is the lack of inventory. Covid (whilst also adding delays to the whole project) hit our supply chains and whilst I don't understand all the details the summary is we don't have enough components left to put these systems up on the web. You may have noticed the Windows systems have been pulled - this is not Linux specific. We have looked at instead of doing full configuration as planned if we could put up a few fixed configurations instead and at least get something up for the short term but it seems that even that is not possible with the stock we have. I know John Trapasso (who joined me at Nest) is still looking into other options. We believe we can make it so systems can be ordered by calling the phone support line - there they line are able to identify exactly which components are available and build the system with the Linux option. But it's not the same as having them up online and generally available as we'd planned for and wanted which is massively disappointing. My sincere and complete apologies to the community. From my point of view it sucks as so much work and effort went into getting these platforms ready. Whilst I've learnt a lot about Lenovo process for the future platforms the key lesson (which with hindsight should have been obvious) is that trying to release something new towards the end of its lifecycle is a bad idea.I just wish someone had told me that back in February (there are so many things I wish I knew about in February but that's another story). We have prioritized getting the P1G3 and the P15 (successor to the P53) done with Fedora - those are entering test very shortly and fingers, legs and eyes are crossed for a smooth passage. I've been using the P1G3 with Fedora33 preview and it's looking good. I can't give a date yet but we're moving as fast as we can on them. I've seen some really positive reviews for the Fedora experience on the X1 Carbon 8 - I'm so glad that is up successfully and seems to be doing well. We are working on getting that out to the worldwide sites. Do let me know any questions. Once again I apologise to all those who helped us on the way - the next round will go smoother. Thank you for the update. Any news when the global availability of the Linux login portal would actually happen? So far, the Linux portal is only on US website... -- / 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
Re: Fedora 32: samba 4.12.2: Problem with access from win10b to win10a via remote desktop
name of the WIN10A$ machine account, so they share the same key and are seen at the same principal for the check that is being done here. For MIT Kerberos, it doesn't see them as aliases as it does explicit compare of the principals and requested service principal does not match the principal in the evidence (2nd) ticket. -- / 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
Re: Many packages unnecessarily link to libpython
On pe, 15 touko 2020, Charalampos Stratakis wrote: Hello everyone, As of Python 3.8, python C extensions modules should not link to libpython, unless they embed the interpreter in their code. Relevant upstream PR: https://github.com/python/cpython/pull/12946 If your package links to libpython without requiring it, it won't be possible to use the python3-debug binary with your python C extension, unless you recompile the extension against it. On Fedora Rawhide, there are at this point 144 packages linking to libpython, many of those possibly without any need for it. If your package links to libpython but it does not embed the interpreter, I would like to ask you to unlink it. Usually the fix needs to be done at the package's build system. If you are not sure if your package links to libpython, a way to figure this out is to inspect the code for the Py_Initialize and the Py_Finalize calls [0]. If the code includes those calls, no action is required from your side. If it does not, linking to libpython is not required. I might mass file bugzillas at a later date, but I wanted to provide you the heads up before that. [0] https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter List of possibly affected packages, provided through $ repoquery --repo=rawhide --source --whatrequires 'libpython3.8.so.1.0()(64bit)' Samba does use Py_Initialize and thus link correctly. -- / 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
Re: Orphaned uglify-js
On ke, 29 huhti 2020, Alexander Bokovoy wrote: On ke, 29 huhti 2020, Jun Aruga wrote: Hi, I orphaned the package. https://src.fedoraproject.org/rpms/uglify-js because * I removed the uglify-js dependency from rubygem-uglifier. * When I asked the co-maintainers, there was no response. * The difficulty of the management. uglify-js requires nodejs-acorn, which requires nodejs-rollup, which requires nodejs-source-map-support, which is orphaned now. https://src.fedoraproject.org/rpms/nodejs-source-map-support FreeIPA depends on uglify-js to minimize its JS code. Do we have any other alternative that doesn't change meaning of the code? I quickly hacked on to use python3-rjsmin, seems to work fine for our use case. -- / 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
Re: Orphaned uglify-js
On ke, 29 huhti 2020, Jun Aruga wrote: Hi, I orphaned the package. https://src.fedoraproject.org/rpms/uglify-js because * I removed the uglify-js dependency from rubygem-uglifier. * When I asked the co-maintainers, there was no response. * The difficulty of the management. uglify-js requires nodejs-acorn, which requires nodejs-rollup, which requires nodejs-source-map-support, which is orphaned now. https://src.fedoraproject.org/rpms/nodejs-source-map-support FreeIPA depends on uglify-js to minimize its JS code. Do we have any other alternative that doesn't change meaning of the code? -- / 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
Re: python2-dns without DNSSEC support in rawhide
On ke, 29 huhti 2020, Lumir Balhar wrote: On 4/29/20 10:31 AM, Paul Howarth wrote: Hi Lumir, On Wed, 29 Apr 2020 07:35:43 +0200 Lumir Balhar wrote: Hello. I'd like to switch python-dns crypto backend from pycryptodomex and ecdsa to python-cryptography. Upstream already did the same in master branch: https://github.com/rthalley/dnspython/pull/449 But, because python2-cryptography is not available in Fedora anymore, this change will disable DNSSEC functionality in python2-dns. There are only two packages depending on python2-dns: mailman and trac-spamfilter-plugin. I did a check and rebuild of both of them and it seems that they both work with the new version and there is no usage of DNSSEC in their codebases. COPR: https://copr.fedorainfracloud.org/coprs/lbalhar/dns/ PR: https://src.fedoraproject.org/rpms/python-dns/pull-request/5 If you think we should not merge the PR, let us know rather sooner than later. No objections from me (trac-spamfilter-plugin maintainer); it uses python-dns for IP blacklist lookups and I wouldn't be surprised if mailman did the same. Great! On the other hand, maybe the crypto backend could be changed for Python 3 and not for the Python 2 version? I would hope that the Python 2 version wouldn't need to be maintained for too much longer anyway. That would mean either ship two different codebases from one SRPM (python-dns) or create a new SRPM just for python2-dns and use old codebase there. The first one is (in my opinion) a bad idea and would make the spec file ugly. Second solution is kinda lot of work for nothing. So I hope nobody will be affected by missing DNSSEC in python2-dns :) Could you please add a sentence like 'Note this library has no DNSSEC support' to python2-dns subpackage description? -- / 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
Re: How to fix a dependency to the version at build time?
On ti, 17 maalis 2020, Vít Ondruch wrote: Dne 16. 03. 20 v 18:15 Kevin Fenzi napsal(a): On Mon, Mar 16, 2020 at 10:38:07AM +, Paul Howarth wrote: On Mon, 16 Mar 2020 11:22:40 +0100 Vít Ondruch wrote: I always thought that one should not call `rpm` during rpmbuild. Nevertheless I am not sure what was the reason? Probably locking of RPM db? Can somebody elaborate? It couldn't be guaranteed to work in the case that the buildroot was populated using a different version of rpm that used a different version of libdb. That's not an issue that crops up much these days as libdb hasn't been version-updated for years (due to licensing issues Except that now we are going to move to sqlite... :) (See rpm 4.16 change posted today) Good point. I have proposed this guideline to FPC: https://pagure.io/packaging-committee/pull-request/954 Also, I'll ask removal of `%requires_eq`. This seems to be used just by samba, so it should not cause too much breakage. Please do not remove it. We need it critically in Samba case. Anyway, it is strange that the autogenerated requires in samba would not be enough. There are already quite a lot of them in samba-dc: It is a long story but cutting it short, libldb is tightly coupled to Samba upstream and should not be deviated between the build and the install: # Force using libldb version to be the same as build version # Otherwise LDB modules will not be loaded and samba-tool will fail # See bug 1507420 %requires_eq libldb Auto-generated requires are not enough for that. For some of the history see the thread at https://lists.samba.org/archive/samba-technical/2019-April/133281.html -- / 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
Re: Intent to request a FESCo exception for python2 for ardour5
On su, 15 maalis 2020, Guido Aulisi wrote: Hi, I’m going to ask a FESCo exception for python2 for package ardour5. Python2 is only needed to build the package using the WAF build system. Ardour has been undergoing a complete rewriting for 2 years, no stable versions have been released in the last 2 years, so we are stuck with ardour 5.12, which still uses python2 to build. What do you think about that? Just package git master in Rawhide. It has been migrated to waf 2.0.19 two months ago and builds just fine in Fedora 32 environments with Python 3 only. -- / 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
Re: RFC: entering luks password on grub level for devices without keyboards
On la, 14 maalis 2020, Marius Schwarz wrote: Hi all, bevor we start, it is a VERY VERY SPECIAL situation i will talk about now. It could get fixed by a UNUSUAL approach. The device we talk about as an example is the SURFACE PRO Tablet Series from Microsoft WITH a LUKS encrypted installation on the drive. Situation: If you encrypt the fedora ( or any ) installation with luks, as security of a mobile device indicates, you end up without the possibility to enter the password, when you do not have an in/external keyboard at hand. As tablets do not come with a keypad ( called TypoCover by MS ) by default, it's not possible to enter the password when Plymouth asks for it. There is simply no keyboard available, AND additionally since surface pro 4+, touch does not work with upstream kernel, so adding an OSK isn't helping. Solution until now: TypeCover or external Keyboard OR no encryption for the device. You can set up clevis to use any automated policy you want. For example, clevis supports TPM2 pin which would allow you to bind your LUKS keys to a TPM2 chip in Surface devices. All Windows 10-capable hardware has internal TPM chip, this is true for my Surface Pro 2017. Please see https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/ https://discussion.fedoraproject.org/t/automatic-decrypt-with-tpm2-on-silverblue/8424/2 and https://github.com/latchset/clevis/issues/34#issuecomment-369560587 for more details. With this setup you wouldn't need to use any keyboard to enter your passkey as TPM2 is always present. -- / 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
Re: Samba 4.12.0 on Fedora32: bind DNS say "named: client @...: update 'fedora.loc/IN' denied"
On ma, 09 maalis 2020, Dario Lesca wrote:
Il giorno lun, 09/03/2020 alle 13.17 +0200, Alexander Bokovoy ha
scritto:
It is independent of Kerberos implementation, so affects both types
of
deployment.
Ok, it's a generic samba problem.
It's right if I fill a bug on samba bugzilla?
Yes.
I tried to create a configuration where named.conf is used to supply an
update ACL to a zone hosted by Samba DLZ module and it didn't work
because for a master zone specified explicitly in named.conf Bind
expects a full definition, including 'file ..' statemenet. Since the
zone is stored in DLZ database plugin, it directly overlaps with that.
As result, it looks like it is impossible to specify ACL to DLZ-provided
DNS zone other than through DLZ itself.
You can add rules in the named.conf but they would be static,
effectively. They are typically static anyway, so this is not a big
loss.
Ok, thanks, but what kind of rule and where I must add in named.conf?
In options session or zone session?
Note that there is not a zone called "fedora.loc" in my named.conf, but
only a include "/var/lib/samba/bind-dns/named.conf", witch contain.
dlz "AD DNS Zone" {
database "dlopen /usr/lib64/samba/bind9/dlz_bind9_11.so";
};
See above, it is not going to work, as I found out.
--
/ 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
Re: Samba 4.12.0 on Fedora32: bind DNS say "named: client @...: update 'fedora.loc/IN' denied"
On ma, 09 maalis 2020, Dario Lesca wrote: Thank for reply Alexander I think it is a missing feature in samba_dl Is this feature missin only into samba+MIT or this lack is present also in samba +Heimdal? It is independent of Kerberos implementation, so affects both types of deployment. You can add rules in the named.conf but they would be static, effectively. They are typically static anyway, so this is not a big loss. -- / 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
