Re: OpenVPN 2.6 Beta released
On 07/12/2022 16:02, Alexander Ploumistos wrote: Hello David, Thanks for the heads up. Is there a tool that can test server and client configurations for compatibility before upgrading? If not, how can one verify that certificates, TLS version etc. comply with the minimum requirements? There exists no tools to check compatibility. I would recommend you to just try your configuration files on a VM with the distribution version of your choice. Just run the openvpn binary manually with the --config argument on the command line. It should complain about issues reasonably quickly. Otherwise, as long as OpenSSL permits it, OpenVPN tries to be considerate to older clients. In general, it the cryptographic and MTU related options which can cause the biggest issues. If your clients are at least v2.4 or newer, then the cryptographic settings should usually work well, as long as the certificates and private keys are accepted by recent OpenSSL versions . The DCO support is opportunistic. If the configuration contains settings which makes it unsuitable for DCO, it will warn about that and continue with the classic tun setup. Otherwise, it is the OpenSSL library setting the limitations of what is supported in regards to TLS protocols and algorithms in use. The same goes for certificates and private keys. Since Fedora 27 and EPEL-7, the openvpn-server@.service unit file has added a few changes which should mostly upgrade the default ciphers to AES-GCM, while keeping the older clients supported via the NCP (Negotiable Crypto Parameters) feature in OpenVPN. I suggest reading the "DATA CHANNEL CIPHER NEGOTIATION" section in the man page. Also notice that OpenVPN clients older than v2.4 are no longer supported upstream [1]. And from March 2023, OpenVPN 2.4 will also become unsupported. So I would strongly recommend starting to migrate clients and configurations to be more up to recent standards. Default ciphers should be an AEAD based cipher (AES-GCM, ChaCha20-Poly1305). And certificates should be at least RSA-2048 with SHA256, preferably ECC based certificates. You should also ensure you use --tls-crypt or --tls-crypt-v2. TLSv1.3 is preferred, but TLSv1.2 will be accepted if the OpenSSL library accepts it. The --auth option is of less relevance unless you require AES-CBC, other non AEAD ciphers or --tls-auth. In these case SHA1 (default) and SHA256 is more than reasonable enough; it is only used in HMAC contexts. If you use an AEAD, --auth should only be used with --tls-auth. You can run the openvpn command with --show-ciphers and --show-tls to see available ciphers and which algorithms are deprecated. [1] <https://community.openvpn.net/openvpn/wiki/SupportedVersions> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenVPN 2.6 Beta released
Hi, This is just a heads-up that the OpenVPN community has released OpenVPN 2.6 beta 1. While this release includes several nice new features, one important one requires more attention - Kernel based Data Channel Offload (DCO). The DCO support has already been available in the OpenVPN 3 Linux project for quite some time already, but with OpenVPN 2.6 the performance boost can now be more noticeable as this also includes full server support. You can read more about the release here: <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25613.html> There is now a Fedora Copr repository available too, which contains all the needed pieces: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-beta/> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Copr - EPEL-9 buildroot
Hi, I've been trying to complete the OpenVPN 3 Linux v18_beta release in my Fedora Copr repository for EPEL-9. But there seems to be something odd going on here. I tried to reach out on IRC earlier today but didn't get much further. The issue, how I see it, is that the buildroot for EPEL-9 seems to use CentOS 9 Stream (centos-stream+epel-9-x86_64) instead of RHEL-9. The end result is that the openvpn3-selinux package depends on a newer selinux-policy package than what is available in RHEL-9. My latest attempt is available here: <https://download.copr.fedorainfracloud.org/results/dsommers/openvpn3/epel-9-x86_64/04507658-openvpn3/> And the paradox is that trying 'yum copr enable dsommers/openvpn3' on a CentOS 9 Stream also doesn't work. But manually downloading and installing the .repo file, installing 'openvpn3-client' works smooth on CentOS 9 Stream. Is this a known issue? Shouldn't EPEL-9 repository builds happen on proper RHEL-9? And buildi ng on CentOS 9 Stream sounds wrong as well. Doing the EPEL-9 build on Fedora Koji works fine and installs fine. <https://koji.fedoraproject.org/koji/taskinfo?taskID=88073281> In addition, trying to do a build with the proper CentOS 9 Stream repository also fails - as the moce config used there is the plain centos-stream-9-x86_64, not the '+epel' variant used in EPEL-9. I do understand this last issue (CentOS 9 Stream build) is different from the EPEL-9 build issue. Any advice would be appreciated. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenVPN 2.x with kernel acceleration
[bouncing this msg, as Antonio is not subscribed to this devel list] Hi, On 04/02/2022 15:35, David Sommerseth wrote: On 04/02/2022 15:09, Neal Becker wrote: Does this modified openvpn support all the same features/options as the stable release version? Almost. I recommend to have a look at the README.dco.md [0] documentation for details, as that lists the limitations quite nicely. [0] <https://github.com/OpenVPN/openvpn/blob/dco/README.dco.md#limitations-by-design> I would like to add that if you use an unsupported option, openvpn will tell you about that with a warning and will fallback to non-DCO mode (i.e. will just use tun as usual). Cheers, -- Antonio Quartulli OpenVPN Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenVPN 2.x with kernel acceleration
On 04/02/2022 15:53, Vitaly Zaitsev via devel wrote: On 04/02/2022 11:03, David Sommerseth wrote: We plan to release OpenVPN 2.6 later this year, which will be DCO capable. This will be available in the existing Fedora repositories, as well as Fedora Copr for releases (like EPEL 7 and 8) where we cannot upgrade easily. You should submit your Linux kernel patches upstream by this date, as Fedora doesn't allow packaging of kernel modules. We are going to do that. But we want more broader *testing* to iron out bugs and annoying issues first. We know that the module works pretty well in our own environments (I'm using it on a daily basis with OpenVPN 3 Linux on the client side, running on RHEL-8.5). But there are always some corner cases we might have overlooked which should be fixed first. Once we have performed more testing and gotten more feedback from users, we will off course start the job of getting the ovpn-dco module into an upstream kernel. That is the main goal for us. But we take it step by step, to avoid wasting too much of kernel maintainers time on nonsense issues. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenVPN 2.x with kernel acceleration
On 04/02/2022 15:55, Fabio Valentini wrote: On Fri, Feb 4, 2022 at 11:04 AM David Sommerseth wrote: OpenVPN 2.6 and the openvpn-dco Copr builds should also work even if kmod-ovpn-dco is not available. And we will provide and support the kmod-ovpn-dco via the openvpn3 Copr repository until we can get it into the far more common Fedora repositories. Just FYI, packages for out-of-tree kernel modules are not allowed in the main Fedora repositories: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules We are well aware of that. Currently, the ovpn-dco kernel module is available via the dsommers/openvpn3 Fedora Copr repository, as indicated in the initial mail (it is provided as a dkms enabled module). For testing purposes. If the ovpn-dco kernel module is unavailable on a system, this DCO enabled OpenVPN build will _fallback_ to tun automatically. Once we have p erformed more testing and gotten more feedback from users, we will off course start the job of getting the ovpn-dco module into the upstream kernel. That is the main goal. -- kind regards, David Sommerseth OpenVPN Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenVPN 2.x with kernel acceleration
On 04/02/2022 15:09, Neal Becker wrote: Does this modified openvpn support all the same features/options as the stable release version? Almost. I recommend to have a look at the README.dco.md [0] documentation for details, as that lists the limitations quite nicely. [0] <https://github.com/OpenVPN/openvpn/blob/dco/README.dco.md#limitations-by-design> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenVPN 2.x with kernel acceleration
On 03/02/2022 05:52, Demi Marie Obenour wrote: On 2/2/22 13:34, David Sommerseth wrote: Hi, An OpenVPN colleague of me, Antonio Quartulli (on Cc), has been working on a kernel acceleration module for OpenVPN for quite some time. We call this OpenVPN Data Channel Offload (DCO). This moves the tunnelled network traffic to a new kernel module (ovpn-dco) and keep only the control channel (authentication, VPN IP configuration, etc) in user-space. This is gives a noticeable improved performance. Do you plan to submit this kernel module to upstream Linux? Fedora does not ship out-of-tree kernel modules last I checked. Yes, we do plan for that. But before we're ready to do so, we'd like to see more broader testing of this module. This comes in addition to have OpenVPN packages available with DCO support. We use Fedora Copr for the time being to make the availability of both kmod-ovpn-dco and OpenVPN builds with DCO support more easily available for more testers. These builds and repository is currently fully supported by the OpenVPN community, with the standard clause that this is development builds which may contain bugs and not necessarily be as stable as ordinary releases. Going forward ... We plan to release OpenVPN 2.6 later this year, which will be DCO capable. This will be available in the existing Fedora repositories, as well as Fedora Copr for releases (like EPEL 7 and 8) where we cannot upgrade easily. As long as RHEL-9 is in Beta, we are considering to move to OpenVPN 2.6 in the EPEL-9 repositories. Depending on the community testing of the Copr repos announced now, we might also provide similar snapshots in default EPEL-9 repos instead of OpenVPN 2.5.z until OpenVPN 2.6 is officially released. Basically: If you want to see OpenVPN 2.6 in EPEL-9, please test our EPEL-9 builds in the openvpn-dco Copr repo and provide feedback ASAP. If we get confidence t his works well, we will start preparing for pre-releases in EPEL-9 sooner than later. OpenVPN 2.6 and the openvpn-dco Copr builds should also work even if kmod-ovpn-dco is not available. And we will provide and support the kmod-ovpn-dco via the openvpn3 Copr repository until we can get it into the far more common Fedora repositories. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OpenVPN 2.x with kernel acceleration
Hi, An OpenVPN colleague of me, Antonio Quartulli (on Cc), has been working on a kernel acceleration module for OpenVPN for quite some time. We call this OpenVPN Data Channel Offload (DCO). This moves the tunnelled network traffic to a new kernel module (ovpn-dco) and keep only the control channel (authentication, VPN IP configuration, etc) in user-space. This is gives a noticeable improved performance. We have had that support available in the OpenVPN 3 Linux for quite some time. But that is currently only a client-mode only implementation. So the real benefit of DCO has been limited when connecting to OpenVPN 2.x servers. In parallel with that, we have now reached a point where we also have code ready for OpenVPN 2.x which can make use of DCO - also for the server side. This code is currently going through review in among the developers in the OpenVPN community. But! We have now a dedicated Fedora Copr repository available for those willin g to test this out. # yum copr enable dsommers/openvpn-dco # yum copr enable dsommers/openvpn3 # yum install openvpn kmod-ovpn-dco The ovpn-dco kernel module is tried first, and if that succeeds OpenVPN 2.x will now use that instead of tun.ko. There is a new --disable-dco option which will force not using DCO, which is useful when testing performance. One performance tip ... Ensure your tun-mtu is 1420 or slightly lower, this is to avoid packet fragmentation which will reduce ability for ovpn-dco to work optimally. We are looking into ways to make the MTU settings better by default, but we're not there yet. This is the only configuration change which might be needed. Even though, I've mentioned OpenVPN 2.x server mode explicitly here ... It will also work with OpenVPN 2.x in client mode too. If you also try the OpenVPN 3 Linux to compare the performance, you should not really notice much difference - as it's the same kernel module doing th e heavy lifting. If you test this out, feel free to reach out on our OpenVPN developers mailing list [0], on IRC [0] or to Antonio (Cc) who is overseeing the DCO development. [0] <https://community.openvpn.net/openvpn/wiki/GettingHelp#Developersupport> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Copr - and building Fedora + Stream with EPEL
On 27/01/2022 15:50, Neal Gompa wrote: pkcs11-helper doesn't exist in RHEL/CentOS itself, and it's probably being filtered out in ELN to mimic RHEL. It's shipped in EPEL, so you need an EPEL repository. Alright, sounds reasonable. ELN won't be very useful for you because it's a stripped compose, unless you rebuild pkcs11-helper for ELN in your Copr. That's an option, I'll consider that. I'm also saying that having both the epel-* chroots enabled and the centos-* chroots enabled is a bit redundant. If you need stuff from EPEL, just use the EPEL chroots, which are built on CentOS/RHEL. My understanding is that CentOS Stream is more bleeding edge than the standard CentOS/RHEL releases, so dependencies might not be correct for Stream users. Or maybe I'm overthinking this and I don't need to have special builds for CentOS Stream? To be clear, to me there is a difference between EPEL builds (targetting the traditional CentOS/RHEL distros) and CentOS Stream. But again, I might have misunderstood these concepts. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Copr - and building Fedora + Stream with EPEL
On 27/01/2022 15:35, Neal Gompa wrote: On Thu, Jan 27, 2022 at 9:33 AM David Sommerseth wrote: Hi, I've hit a challenge I've not been able to figure out properly. I'm putting together a Fedora Copr repo which should cover most the various distros supported via Copr- CentOS Stream, EPEL, Fedora and Fedora ELN. The challenge is that for CentOS Stream, the EPEL repository is required - as the pkcs11-helper-devel package is a build requirement. I've not yet figured out the solution for ELN yet, but I suspect it will be somewhat similar. For the EPEL builds, everything works just as expected - which is not surprising, as it seems to have the EPEL repo already enabled. One thing I've tried, is to put a URL to a Fedora EPEL repository in the "Extra repos" under "Settings". This makes the CentOS Stream build work. But it breaks everything else, as the URL for the Fedora builds does not ha ve a valid URL. So my question is simply, what is the best approach to resolve this? epel-* chroots are sufficient for CentOS systems. What we're missing are epel-next chroots in COPR for Stream for when you need rebuilt/updated stuff that's in Stream but not out yet for RHEL. Hmm ... Maybe we are talking about different things now? So everything builds fine on the EPEL repos (which CentOS can use) as well as the ordinary Fedora releases. What does not work is CentOS Stream and Fedora ELN. When I add a URL to an EPEL repository in the "Extra repositories" field under Copr repo settings, CentOS Stream builds fine. But everything else breaks due to the URL returns a 404 when fetching the epodata/repomd.xml file. Fedora ELN might require some other repo (EPEL.Next?) to fetch the pkcs11-helper. I might be doing something stupid and unsupported ... but I don't quite understand how to resolve this, except of creating separate Copr repos for Fedora/EPEL, CentOS Stream and a third one for Fedora ELN. But that sounds complicated, as they should all be able to build from the exact same .spec file. It is only the access to pkcs11-helper-devel package which is causing this issue. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora Copr - and building Fedora + Stream with EPEL
Hi, I've hit a challenge I've not been able to figure out properly. I'm putting together a Fedora Copr repo which should cover most the various distros supported via Copr- CentOS Stream, EPEL, Fedora and Fedora ELN. The challenge is that for CentOS Stream, the EPEL repository is required - as the pkcs11-helper-devel package is a build requirement. I've not yet figured out the solution for ELN yet, but I suspect it will be somewhat similar. For the EPEL builds, everything works just as expected - which is not surprising, as it seems to have the EPEL repo already enabled. One thing I've tried, is to put a URL to a Fedora EPEL repository in the "Extra repos" under "Settings". This makes the CentOS Stream build work. But it breaks everything else, as the URL for the Fedora builds does not have a valid URL. So my question is simply, what is the best approach to resolve this? -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora EPEL 7 and enabling devtoolset
On 25/11/2021 15:11, Ben Beasley wrote: I’d like to point to https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec as a working example of a package that is built with a devtoolset in EPEL7. While I maintain the sleef package, the EPEL7 backport was contributed by Dave Love. – Ben Beasley Thanks a lot! I adopted a few tricks from there, and seems to build great. Will run more testing on the binaries, but hopefully nothing unexpected will be found. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora EPEL 7 and enabling devtoolset
Hi, I'm starting to hit more and more challenges in the OpenVPN 3 Linux project with the RHEL-7 GCC version (which is 4.8.5), especially when it comes to C++ building. I've tried to keep the project compatible with RHEL-7 as the oldest supported distro, but it is getting harder and harder. In addition to newer C++ standards making the development of the project easier. I do see that RHEL/CentOS 7 has the needed compiler versions in the devtoolset. I also stumbled across this blog post: <https://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html> But ... a) Is that blog post still relevant? I couldn't find anything in the Fedora packaging guidelines giving any further advice. b) By adding the devtoolset as a build dependency, is that enough? Will the final .rpm need anything else installed to function? Like a newer libstdc++? c) Which other traps may I be facing using a devtoolset for EPEL-7 builds? -- kin d regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [RFC] Remove supoort for NIS(+) from PAM
On 02/10/2021 15:27, James Szinger wrote: 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. While a FreeIPA server certainly doesn't come for free in regards to system resource consumption. And you need to relate to at least the webadmin at times. Under the hood it also surely is complicated, but from an every-day use is it that complicated? I'm running an IPA server at home on a VM which should have been given more memory, but it is functional and responsive enough. And I don't really think much about it. Adding new users is easy enough. And enrolling a new host and get it setup is also fairly straight forward (run `ipa-client-install` and optionally `ipa-client-automount`). Once the IPA client install has completed, logins usually work instantly with sudo access and whatever else you've configured in the domain. But it must be said ... I don't have any other hosts than Linux hosts at home. A more heterogeneous environment might bring in bigger challenges. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 it me, or is it autotools being silly?
On 14/07/2021 11:55, Miro Hrončok wrote: On 14. 07. 21 11:49, David Sommerseth wrote: Hi, So I'm running some builds for the openvpn3-linux project on Fedora Rawhide ... And we have this little line in configure.ac: AM_PATH_PYTHON([3.5],, [:]) When ./configure runs, it reports: checking for python3 version... 3.1 As a colleague said, mathematically this is correct. But that doesn't really help. Who/what is truncating Python 3.10 to 3.1? And how can that be fixed? Is someone already looking into this? Is the configure script regenerated during build? Old consifure scripts tend to do this. No, the tarball is pre-generated - on an Ubuntu 20.04 box, iirc. This was fixed e.g. in automake: https://bugzilla.redhat.com/show_bug.cgi?id=1889732 But depending on how is the configure script created, might require fix in the project itself. Thanks! This was the pointer I needed and didn't find myself. I'll dig into this. I suggest to grep the configure script for 'sys.version' and see what it does with that value (e.g. sys.version[:3] is usually the problem). Yupp, the configure script does contain sys.version[:3]. Thanks for quick and good feedback! I'll probably just add a re-run of autoreconf before %configure in the .spec file to circumvent this for now until we get automake upgraded. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Is it me, or is it autotools being silly?
Hi, So I'm running some builds for the openvpn3-linux project on Fedora Rawhide ... And we have this little line in configure.ac: AM_PATH_PYTHON([3.5],, [:]) When ./configure runs, it reports: checking for python3 version... 3.1 As a colleague said, mathematically this is correct. But that doesn't really help. Who/what is truncating Python 3.10 to 3.1? And how can that be fixed? Is someone already looking into this? Complete build logs can be seen here: <https://download.copr.fedorainfracloud.org/results/dsommers/openvpn3/fedora-rawhide-x86_64/02329646-openvpn3/> -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Security] Critical OpenVPN update (CVE-2020-15078)
Hi, Just a quick update on an OpenVPN update which was released this week. Fedora packages are in the release pipe, but needs to get some karma to move on quicker. Since this issue is critical, I'm adding an additional notice here. The TL;DR version: OpenVPN 2.5.1 and earlier versions allows a remote attackers to bypass authentication and access control channel data on servers configured with deferred authentication, which can be used to potentially trigger further information leaks. Details on the issue can be found here: <https://community.openvpn.net/openvpn/wiki/CVE-2020-15078> Please test and update as soon as possible. Updated packages Fedora 33: <https://bodhi.fedoraproject.org/updates/FEDORA-2021-242ef81244> Fedora 34: <https://bodhi.fedoraproject.org/updates/FEDORA-2021-b805c26afa> Fedora Rawhide: <https://bodhi.fedoraproject.org/updates/FEDORA-2021-268c06b2cf> EPEL-7: <https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ec6398823b> EPEL-8: <https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0754fdd085> In addition, we have Fedora Copr builds with the latest OpenVPN 2.5 release for distros shipping OpenVPN 2.4 in the main repos: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/build/2143551/> -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: split-DNS, resolvconf on Fedora (OpenVPN related issues)
On 25/02/2021 16:02, Dan Williams wrote: On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote: [...snip...] * NetworkManger and OpenVPN Outside of that, OpenVPN via NetworkManager will be a different beast to tackle which we have not yet dug into from the OpenVPN project side. From the OpenVPN side, we are not too happy about the current NetworkManager plug-in from a general point of view. It is good with the graphical interface, but NetworkManager does not too much in several areas (like killing the OpenVPN process if the main link disappears; OpenVPN is capable of recovering quite nicely when network recovers). And we have more OpenVPN specific features planned as well, where the NetworkManager can cause more damage - as it does not (and should not) understand how OpenVPN operates. I'm pretty sure the NM team would be receptive to improvements especially given new OpenVPN capabilities. We do have on our todo-list to provide a nm-openvpn3 plugin; I hope we will be able to allocate resources to work on that in the next 4-6 months. We cannot re-use the existing nm-openvpn implementation as it is a completely different client. OpenVPN 3 Linux is fully managed via D-Bus. Hopefully the new architecture will make it easier to add NM integration, as OpenVPN 3 Linux already takes care of the privilege separations and OpenVPN configuration management. There are APIs to import and retrieve available configurations, start/stop/pause/resume VPN sessions and as well as retrieving VPN session statistics and log/status updates. So an nm-openvpn3 plug-in just needs to behave like a user interface towards the user. That said, if there are other aspects where NM would like to integrate more tightly with OpenVPN 3 on the networking integration, we are equally open to look into improvements here. We have briefly started to investigate NM online status tracking - to hold back starting of VPN connections until the host is fully online, and equally pause sessions when the connection disappears. Mostly to put the network silent when a connection is impossible but being able to recover quickly when the network is back. But NM has supported a feature that allows VPN connections to persist across link changes (the VPN service returns the "can-persist" key in its IP config response if it knows the underlying service can handle it). I don't see that exposed/utilized by nm-openvpn, but perhaps it should be if the connection properties will allow it (eg, if -- keepalive/ping*/whatever is enabled?). I'm sure they'd accept patches to that effect... This is great news and a considerable improvement. Last time I was in contact with the NM developers, this was being discussed but got the impression it had not materialized yet. But this is something which would be great to explore further. Another challenge, which is more a bureaucratic/management one, is the collaboration platform between the nm-openvpn project/development and the upstream OpenVPN project. Currently OpenVPN Inc people working in the community focuses on OpenVPN 3 and, server side aspects of OpenVPN 2 and the OpenVPN kernel module under development. While the community itself mostly focuses on the whole breath OpenVPN 2. But it is hard to motivate people to work on the NM integrations from our side. And to be honest, it's not too easy to get people involved in the Windows GUI either - but we do have at least some progress there with a very dedicated upstream maintainer. Somehow it seems the GUI aspects are not that intriguing to work on. That said, if there are people wanting to dive into the NM-OpenVPN integration, OpenVPN will be supportive to such efforts and will help as much as possible. Just keep me in the loop and I will ensure that the right people gets in touch. -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: split-DNS, resolvconf on Fedora (OpenVPN related issues)
pv4.dns-search and ipv4.dns, with ipv6 having this too. My ethernet nmcli shows values from DHCP as IP4.DNS[*] and IP4.DOMAIN[*]. I think that is almost all we need. Set of DNS IPs and list of domains handled by them. Then just a signal of preference, whether to forward all unspecific queries to this connection by default. NM has also ipv4.dns-priority number, I guess it is for similar thing. Problem is as you already noted, NM limits some feature uses. I think NM can store only values per connection only when it manages such connection. I doubt it can store dns properties on connections or devices not managed by it. resolvconf should make possible even pure openvpn connections having list of dns servers and list of domains. Can or should we ignore connections not managed by NM? How rare are they? That's essentially the crux of the issue with NetworkManager. VPNs and devices are kind of same-same-but-very-different. I have spoken with NetworkManager developers about these challenges a while back, and we kinda agreed that NetworkManager was not the perfect fit given the current design and architecture. OpenVPN 3 Linux and OpenVPN 2.x can be extended and taught to integrate with various DNS management approaches. systemd-resolved is already on the way, but does not need to be restricted here. But we are very much interested in being involved in such discussions. Of course! Providers of VPN are a primary target to split-DNS support. There should be unified interface for them, without having to implement any specific cache details. Implementation-specific mapping to cache implementation should be provided by dns cache maintainers IMHO. If resolvconf is problematic in any way, what features are missing? What requirements are important for OpenVPN? Is OpenVPN 3 even packaged on Fedora? There are pointers to our Fedora Copr repository in [0] ;-) <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> Once we're getting ready with a stable release, I want to submit the Copr packaging to mainline Fedora. But do read the quick-start part in [0], as OpenVPN 3 Linux is designed very differently from OpenVPN 2.x ... and it tries to have a user interface which is more end-user friendly than OpenVPN 2.x. [0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: split-DNS, resolvconf on Fedora (OpenVPN related issues)
On 22/02/2021 16:29, Petr Menšík wrote: Why? I thought about common interface to various DNS cache implementations for workstations and different VPN providers available. While I think the best place to direct, which interface resolvers should handle given domains. resolvconf handles conflicting requests from different interfaces, when multiple DNS resolver providers are configured by connection. Just providing some input from the OpenVPN perspective. * OpenVPN 3 Linux OpenVPN 3 Linux [0] since the v10 release provides native systemd-resolved support. It is not optimal yet, but we plan to provide full support for split-DNS (only pushed domains will be resolved via the DNS server requested by the VPN server) and exclusive DNS (use only the DNS server pushed by VPN server). The current implementation will query all DNS servers on all interfaces. This hybrid mode will also be supported. At the moment I'm not yet decided what should be the default mode, but I'm leaning towards split-DNS - as that provides the least risk for DNS leakage either way. But for some any DNS lookups to the main link is considered a DNS leak as well, so this is highly usage dependent. We are also considering how far the server can go to push for a certain profile - as the use cases for VPN provider side are also very diverse with different requirements. For the v10+ releases you need to do a little configuration step [1] to enable this support, but we are planning to enable this by default on Fedora 33+. Ubuntu 20.04 will probably also be updated to use it by default. This will most likely happen from the v14 release. * OpenVPN 2.x We are also considering to fully embrace the update-systemd-resolved [2] script for the OpenVPN 2.x versions. And will work together with this project to ensure OpenVPN 3 Linux and OpenVPN 2.x will behave a similar as possible. * NetworkManger and OpenVPN Outside of that, OpenVPN via NetworkManager will be a different beast to tackle which we have not yet dug into from the OpenVPN project side. From the OpenVPN side, we are not too happy about the current NetworkManager plug-in from a general point of view. It is good with the graphical interface, but NetworkManager does not fully consider what OpenVPN is capable and restricts its capabilities too much in several areas (like killing the OpenVPN process if the main link disappears; OpenVPN is capable of recovering quite nicely when network recovers). And we have more OpenVPN specific features planned as well, where the NetworkManager can cause more damage - as it does not (and should not) understand how OpenVPN operates. * DNS updates If NetworkManager is capable of fully integrating with a unified DNS resolver management which OpenVPN and other updateresolve alternatives could work with would definitely be the best for all of this. OpenVPN 3 Linux and OpenVPN 2.x can be extended and taught to integrate with various DNS management approaches. systemd-resolved is already on the way, but does not need to be restricted here. But we are very much interested in being involved in such discussions. [0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> [1] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20607.html> [2] <https://github.com/jonathanio/update-systemd-resolved> -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal to deprecated `fedpkg local`
On 28/01/2021 10:39, Vít Ondruch wrote: 2) I would really love you to stop using VMs for your build/testing. With exception of Kernel and Kernel related issues, the argument of "mock being slow" can't stand. Every VM will be more resources hungry then mock, slowing every your task. I'd love to. But then we need to ensure that it is possible to mock build future Fedora 45+ packages from a RHEL-8 installation without issues; due to yum/dnf/rpm being too old, not able to parse the .rpm or .spec files due to new features in use, etc, etc. And add some simple approaches so you can easily access the source code failing to build, so you can add some tweaks and test out manually before diffing and patching up the .spec file for another run. With "simple approaches", I mean to not needing to add additional arguments to mock build so the buildroot doesn't get wiped on errors and that you don't have to dig deep into the /var/lib/mock directories to find the source location For me, this is where fedpkg local excels over mock build -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On 27/01/2021 21:47, Zbigniew Jędrzejewski-Szmek wrote: +1 to everything that Gwyn said. 'fedpkg local' is just so immensely useful for initial package developement. I also use it a lot for systemd & friends: I *want* to build packages against the local environment and install them locally without pulling in any other package updates, and I want to be able to debug build or test failures in the host environment. (I also use mock in various configurations, and copr, and scratch builds, etc. I find mock immensely useful too, but in a later phase of package development. Different tools have different tradeoffs.) All of this +1. I don't do this for systemd, but for OpenVPN related packaging. Also, mock against newer Fedora distros gets more and more complicated as time flies, as I usually do all of this on RHEL [*]. I've recently upgraded to RHEL-8 (from RHEL-7), so I'm not sure how that changes in this aspect, but looking forward to test it out properly. But doing OpenVPN related packaging for quite some years has taught me to not fully trust mock to be capable to builds on more recent Fedora releases (from a RHEL host). The rescue has always been to use fedpkg local (on RHEL) to iron out the build issues before spinning of a VM and run a fedpkg mockbuild in the VM (with a recent Fedora), and then koji build in the end for the broader platform builds. [*] I always try to do main development on an older distribution, as forward porting fixes for issues are always more convenient than backwards porting them. Especially when writing new code and features for a project. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 29/09/2020 17:21, Paul Wouters wrote: > > For the VPN scenario, it is just a little bit more complicated. > > For those with proper standards, such as "Cisco IPsec", L2TP/IPsec", > the VPN confiuration is dictated by the server to either send all or > some traffic to the VPN server. If it is not "everything", then these > VPNs convey 1 domain name and one or more IP's of DNS servers to use > to resolve that domain. > > For IKEv2 IPsec based VPNs, any number of domain names can be specified > by the server to be used by the client. When doing split-DNS with DNSSEC > trust anchors, these can be conveyed and there are strict rules on when > to allow these to override public DNSSEC trust anchors as per RFC 8598. > > For VPN protocols with no real standard, things are more complicated. > > OpenVPN can do custom things. It all depends on the provisioning. As an OpenVPN developer, I can't resist giving a few details here :) OpenVPN 2.x using the openvpn-client@.service unit files depends entirely on the OpenVPN configuration. So you are right here. OpenVPN 2.x using NetworkManager, will let NetworkManager pick up changes and apply them accordingly to the abilities of the NetworkManager-openvpn plugin. OpenVPN 3 Linux can be enabled with systemd-resolved support [0], but out-of-the-box it will modify /etc/resolv.conf directly. Enabling systemd-resolved support, you will get fairly close to a split-DNS setup but not completely - but this integration is still considered tech-preview and we're using the v10_beta release to gain more experience with systemd-resolved across various distributions. Ubuntu 20.04 has also enabled systemd-resolved by default, but it seems it has not gone as far as Fedora 33. Common to all of these alternatives, the VPN server must push DNS options or the client configuration file must include the appropriate --dhcp-options. [0] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20607.html> -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
OpenVPN 2.5 beta released
Hi, Just wanting to raise awareness that the OpenVPN 2.5 Beta was released last week. I have prepared a Fedora Copr repository for those wanting to test this version. <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-beta/> OpenVPN 2.5 will drop EPEL-6 support; it goes EOL in November anyhow and will require a more recent OpenSSL library than 1.0.1e. The final OpenVPN 2.5 release will hit Rawhide and will be part of the next Fedora release. I am pondering on adding an openvpn25 package for EPEL-7 and EPEL-8, as this release does have some nice security enhancements. I will not consider this for Fedora 31/32. If you have a possibility to test OpenVPN 2.5, or if you want to review the spec file and packaging - we can ensure this will be a more painless upgrade than the 2.4 upgrade was. Packaging/.spec file issues can be taken here on this mailing list; otherwise OpenVPN 2.5 specific issues can be discussed on the OpenVPN developers mailing list [1] or the upstream Trac ticketing system [2]. [1] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/> subscribe: <https://sourceforge.net/projects/openvpn/lists/openvpn-devel> [2] <https://community.openvpn.net/openvpn/newticket> (Need a Trac account to file tickets) -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
pkcs11-helper and Fedora
Hi, We're having some discussions in the OpenVPN community in regards to the pkcs11-helper library and which version to bundle in our Windows builds. We pull the pkcs11-helper-rfc7512.patch from the Fedora builds, as we need that functionality it provides. During these discussions we see that Fedora is still using the 1.22 version while upstream OpenSC/pkcs11-helper has released 1.26. We have been told that 1.23 adds improved support for EC and 1.26 includes a PSS padding fix might be interested in. Is there a reason Fedora has not updated to a newer version than 1.22? -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Preparing for OpenVPN 3 package review
Hi, We released the OpenVPN 3 Linux v8 beta release early last week [0], with the Fedora Copr repository [1] updated as well. Now things are working so well it is about time to get this package into the mainline Fedora repositories. I'm fairly rusty on the Fedora packaging, but I have opened a discussion on the Fedora security ML related to an rpmlint complaint (which I believe is more or less a false-positive, from a Fedora perspective). But if someone got some time to help out doing some initial review, I would appreciate it. Everything used for the Fedora Copr builds are available here: <https://gitlab.com/dazo/copr-openvpn3> If there are any questions, I'm always available on IRC (dazo) or on e-mail. I will also file the official package review bugzilla once we've sorted out the worst glaring issues. [0] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19394.html> [1] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: new maintainer for tmuxinator
On 06/02/2020 09:19, Miro Hrončok wrote: > On 06. 02. 20 4:21, Dusty Mabe wrote: >> It was orphaned recently. Anybody care to pick it up? :) >> >> https://src.fedoraproject.org/rpms/tmuxinator > > To clarify: It was retired recently. > > (I've noticed people confuse the terms all the time and was wondering what to > do about it without changing them.) Looking at the URL above, seeing "Maintained by orphan" ... that certainly does not help clear up any confusion ;-) -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Encrypted DNS in Fedora
On 06/11/2019 18:56, Michael Catanzaro wrote: > On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth wrote: >> Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP >> addresses you connect to will still provide meta data which can be used to >> profile you and give an indication of what kind of sites you visit. > > Well that's the whole point right there. In combination with ESNI, it's no > longer possible to tell which domain you are visiting on a particular vhost. > It's not perfect, but that's still tremendously better than nothing. It is why > Mozilla and EFF are strongly promoting DoH. > Please just watch the talk by Paul Vixie (who is one of the really big DNS gurus these days, even ISC BIND maintainer for quite some years). And you will see that DoH is pointless when you have DoT. But DoT can also go much further than DoH will, when you consider the bigger part of the DNS query chain. Plus, ignoring the local networks DNS also has its own set of challenges when being added directly to browsers. Like hostnames only available inside a local network will no longer be available. But again, watch the talk, these points are well covered there. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Encrypted DNS in Fedora
On 05/11/2019 22:00, Nicolas Mailhot via devel wrote: > Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit : [] > > The day DoH actually gets decentralized the nowheristan state and its > ISPs will run DoH servers like everyone else and influence their > results exactly like today, and the nowheristan population will use the > result by default just like they use the state and ISP servers by > default. DoH won't even really work here. Yes, the DNS request is encrypted and you knock-a-whole through their firewall, you can be fairly confident the response has not been modified (as long as the TLS connection is validated, etc, etc). Except of the "knock-a-whole" aspect, DoT resolves exactly the same issues. But what is even more important to realize is what happens *after* the DNS query has been returned. You connect to the IP address provided in the response. And if that server is encrypted but uses TLSv1.2 or older, the hostname you are connecting to is "leaked" via the TLS negotiation (SNI hostname is not encrypted). The result is, you do not have any kind of privacy in regards to what services you connect to. A DPI capable firewall will still be able to block this access. Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP addresses you connect to will still provide meta data which can be used to profile you and give an indication of what kind of sites you visit. So claiming DoH or DoT helps privacy is in best case ignorant to privacy. In worst case, it puts people needing privacy at risk. If you want privacy, you need to connect to a VPN server you choose to trust. And that VPN provider needs to find ways to circumvent any firewall blocks as needed. Now DoT on the other hand can have a purpose, when used between DNS servers. For more details about DoH challenges ... please have a look at this talk: <https://www.youtube.com/watch?v=8SJorQ9Ufm8> -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 packages to be retired (~400 during this week)
On 09/09/2019 23:49, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life [...snip...] > dsommers: python-which This surprises me quite a lot. I have never been a package maintainer for this package. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop lz4-static
On 14/08/2019 23:08, Jason L Tibbitts III wrote: >>>>>> "DS" == David Sommerseth writes: > > DS> As I can see it, there is little benefit of removing lz4-static. > > Isn't that entirely the decision of those maintaining the package? It's > still completely reasonable if they want to remove it for no other > reason than it eliminates ten lines from the specfile. The question was > whether there is any pressing reason to refrain from removing it. Sure is! Byt I still don't think there's any benefit caring much about an additional sub-package in such a tiny package. In this case the changelog is actually 2/3 of the complete spec file. And these 10-11 lines (including blank lines) related to the -static subpackage are roughly 14% of the "non-changelog" section of the .spec file. But as I said earlier, for static libraries, it is harder to get some kind of usage statistics who uses them or not, as you only need that library during the compile time. So combine that with the effort of reducing the spec file with 10-11 lines, I'm not sure it's such a big difference in maintainability or the efforts required to keep them around. Just my 2 cents. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Drop lz4-static
On 14/08/2019 07:49, Igor Gnatenko wrote: > Hello, > > I found out that nothing in Fedora depends on lz4-static (neither > runtime nor buildtime). Is anybody using it or I'm free to drop it? > > Any thoughts? Ehm ... This is a _static_ library. Which means you can build against it, uninstall the lz4-static RPM and the built application still runs. What I'm trying to say that, even though no Fedora packages does not have a build dependency on this package, there might be other users of this library which does static builds of some binaries. That said, static builds have their own challenges (mostly security related) - but also use some real cases (like running code during early boot phase before file systems with shared libraries are available). So there been performed a good enough check that "nothing in Fedora depends on [it]"? Also consider that this is the static library is built by default, it is a tiny library which is really fast to build and the built binaries are less than a few megabytes all together. As I can see it, there is little benefit of removing lz4-static. But I might overlook something. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?
On 14/08/2019 15:01, Kevin Kofler wrote: > David Sommerseth wrote: >> Like it or not, Python 2 is going to die: >> <https://www.python.org/dev/peps/pep-0373/> >> >> Python 2 will not be maintained by upstream after January 1, 2020. Python >> 2 will go EOL during the lifetime of Fedora 31. > > So what? Qt 3 had its last release (3.3.8b) in 2008 (and that was basically > just a relicensing of the final 2007 release 3.3.8). Yet, we (mostly me) > still maintain qt3 and backport security fixes where issues are reported to > us, and Qt 3 applications still work fine. I have KSensors (a qt3/kdelibs3 > application) sitting in my system tray all the time. It still works (thanks > also to Plasma 5's xembedsniproxy). I also use Quanta Plus to edit HTML. It > also works as expected. So what? You chose to do this work to keep this alive. In my personal opinion, that's wasting of precious time and I would never have done that. You chose differently, and I respect that. > Just because upstream no longer releases something does not mean it has to > disappear from distributions instantly. I see no other distribution being as > aggressive about removing Python 2 as Fedora is. I honestly don't care much what other distros do. I care about the road forward for Fedora. In my point of view, putting legacy software which has reached EOL from upstream behind is really sane. If you want/need it, then port it forward to the future. Secondly, this isn't "disappearing instantly", as you say. Fedora started this migration almost 4 years ago. If this feels "instantly", someone has not paid attention. > There is also a fork trying to keep Python 2 alive: > https://github.com/naftaliharris/tauthon > though it is unfortunately unclear whether the most important point > (backporting security issues) will be taken care of reliably: > https://github.com/naftaliharris/tauthon/issues/109 And this is why we should let Python 2 rest in peace once it reaches EOL. Python 3 contains a lot of improvements over Python 2. The world need to move forward and not linger in the past. > But it is always possible to do the backports downstream, as we are doing > for the Qt 3 and 4 stacks. Who will do this job? And which guarantees do we have it will be done in a way providing the same quality work the Python community has done so far? If the result is less secure Python 2 updates, nothing really improves at all ... except keeping code which should be ported forward to Python 3 alive longer than really needed. Instead of spending time and resources keeping old stuff alive longer than needed, rather spend that energy on porting the old Python 2 over to Python 3. In the long run, this will result in far less work over time. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?
On 11/08/2019 01:45, Kevin Kofler wrote: >> My opinion at least postpone this decision one or two releases to >> Fedors 33/34 , many things still just work with python 2 . > > I second that wholeheartedly. Like it or not, Python 2 is going to die: <https://www.python.org/dev/peps/pep-0373/> Python 2 will not be maintained by upstream after January 1, 2020. Python 2 will go EOL during the lifetime of Fedora 31. So why are we here? Because Python maintainers have ignored this, or have hoped this will not be a reality or it will be postponed. But the PEP-373 defining and documenting the EOL of Python 2 was created in November 2008(!). That is 11 years ago(!). Life must move on, like or not. Python must move on, like it or not. And since so many Python package maintainers have ignored this fact, we are having this discussion now. By not enforcing Python 2 to really die in Fedora, we will have exactly the same discussion in the coming decade as well. There has been plenty of time to get ready for the Python 3 move: <https://fedoraproject.org/wiki/Changes/Python_3_as_Default> ... This happened in Fedora 23 - which was released in November 2015. That is close to 4 years ago. So why are we here? Because Python 2 package maintainers in the Fedora community have ignored this fact, for almost 4 years. Yes, I know it's not necessarily an easy task. But 4 years in Fedora land is quite a long time; it is 8 Fedora releases. If we want to do a move, it is possible to do such a change in 4 years. Time has run up. It is time to move on and accept the fate of Python 2 packages not being ready. Those caring so much for unported Python 2 packages now got a brilliant chance to help moving them forward to Python 3 too. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
OpenVPN 3 Linux client - v5 beta release
Hi,
Just a shameless update again from the OpenVPN 3 Linux project.
We published the v5 beta release earlier yesterday (Monday). This release is
taking a good step forward in regards to reach a release candidate quality
level.
There are several changes since the last announcement we did in end of January
with the v3 beta release. But most importantly, OpenVPN 3 Linux is now built
against OpenSSL by default. Currently only OpenSSL 1.0 is supported (so we
depend on compat-openssl10 for now), but there are work in the pipes to enable
OpenSSL 1.1.1 as well.
For more details, please see our release announcements to the OpenVPN community:
<https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04738.html>
<https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04818.html>
We are trying to get a new release out approx. once per month.
Quick start
===
- Install openvpn3-client according to the Fedora Copr page:
<https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/>
- To start a VPN tunnel, run this command:
$ openvpn2 --config my-config.conf --verb 6
If this configuration contains the --daemon option, you will need to manage
this session via the 'openvpn3' command line utility:
It is also possible to do it like this:
$ openvpn3 session-start --config my-config.conf
In this case, the VPN session must be managed by 'openvpn3' commands.
- Managing VPN sessions:
$ openvpn3 sessions-list
$ openvpn3 session-stats --config my-config.conf
$ openvpn3 session-manage --config my-config.conf \
{--pause,--resume,--disconnect}
$ openvpn3 log --config my-config.conf --verb 6
(this will only provide a real-time view of log events, not a "historical"
view)
Please see the man page for 'openvpn3', 'openvpn2' and 'openvpn3-linux' for
more details.
This project is now ready to get better integration within desktop
environments (GNOME, KDE, XFCE, etc), NetworkManager, Cockpit Project, etc.
This shouldn't be too daunting, as you can get a long way by using all the
various D-Bus interfaces being exposed by the OpenVPN 3 Linux services.
Please get in touch if you want to get involved and I can ensure you get
started in the right direction instantly.
--
kind regards,
David Sommerseth
OpenVPN Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: OpenVPN 3 Linux client - v3 beta release
On 01/02/2019 00:01, Tom Hughes wrote: > On 31/01/2019 22:44, David Sommerseth wrote: > >> This new client shares the same code base the OpenVPN Connect (proprietary) >> clients uses as well as the OpenVPN for Android when switching to use the >> OpenVPN 3 backend. The OpenVPN 3 code base is a rewrite in C++ and makes use >> of the more modern features of C++11. > > So what does this mean for the server? Currently client and server > are the same program but it sounds like this is a pure client so does > that mean client support will be removed from the current program to > make it server only? or that there will be a new server? Yes, this is a pure client. But it is mostly backwards compatible with OpenVPN 2.x servers. The most noticeable missing features are support for TAP devices and the lack of --fragment. TAP support is not planned, as all VPN APIs on mobile devices and even the Unified Windows Platform (UWP) API does only support TUN mode. Users depending on TAP may continue to use OpenVPN 2.x for a long time forward, but should start considering to switch to routed TUN in the future. The --fragment features is troublesome. It is unfortunately needed in some networks, but it is a quite heavy feature to implement - especially when this is not too often needed. This feature basically needs to do a lot of a similar task you'll find in the TCP stack, and in particular packet reassembly and keep track of packets received - and then the chunking of packets into new sizes. We are investigating better solutions to --fragment, both in the company and within the community. Our ideal goal would be that --fragment would no longer needed and the OpenVPN protocol itself would figure out how to solve this issue when it occurs. There are more options which are unsupported (if you test your configuration with the openvpn2 front-end provided in the openvpn3 package, you'll notice soon enough). We will backport those options which makes sense and has a real use case (like --verify-x509-name). But the overall idea is to try to reduce the quite enormous amount of options available in OpenVPN 2.x. -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
OpenVPN 3 Linux client - v3 beta release
Hi, As some of you know, I've been involved with the OpenVPN packages for some time as well as being an upstream OpenVPN developer and maintainer. Now we have released the third beta release of OpenVPN 3 Linux. This new client shares the same code base the OpenVPN Connect (proprietary) clients uses as well as the OpenVPN for Android when switching to use the OpenVPN 3 backend. The OpenVPN 3 code base is a rewrite in C++ and makes use of the more modern features of C++11. The Linux version is also very different from the OpenVPN 2.x generation, as it is now D-Bus based. We have done this to allow easier integration with other users and front-ends on Linux as well as having a better privilege separation. Once all the backend pieces of OpenVPN 3 Linux has settled non of them runs with more privileges than absolutely needed and there are several services running which is responsible for only a subset of the features. This is probably the least privileged OpenVPN implementation available today. On top of that, we have also tried to make DNS configuration work out-of-the-box as well (but here we need much more work to be really complete). Part of this project we're also trying to get some kind of equivalent of the Android VPN API in place on Linux. We have our own D-Bus service which provides the needed functionality and can hopefully work as a stepping stone towards something which can also be used outside OpenVPN alone too. The current implementation should already provide all the needed features to create and configure TUN devices (including IP addresses, routing and DNS) for unprivileged users. I'm announcing this here now as we also have Fedora Copr builds available for EPEL-7, Fedora 28, Fedora 29 and Rawhide. In not too far future I would like to get the process running to get the openvpn3 package into the mainline Fedora repositories as well. <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> Our main source repositories can be found here: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> We would be very much interested to get more users to try this out and to move this project forward. The current codebase is in a reasonably good shape. It is a bit rough around the edges when it comes to the DNS configuration and /etc/resolv.conf handling, but otherwise it is fairly production ready. This project aims to have good and reasonable documentation. I'm not saying we're perfect in this regards, and we're open to improve here too. All D-Bus services should be fairly well documented and we should have man pages for most of the binaries we provide. * D-Bus details <https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/dbus> * man pages: <https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/man/> Feel free to reach out if you have some questions or good ideas. -- kind regards, David Sommerseth OpenVPN Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: IBM buying RedHat
age or control the community itself regardless of Red Hat being acquired or not. It can only manage the people on their payroll in regards to what they work on in their working hours. But the best way to kill passion is to tell people what not to do. And this would go completely against the statement of the Senior Vice President Arvind Krishna at IBM said: "Red Hat must, and will, remain independent". What would IBM in the end benefit from by killing passion and risking reducing the impact Fedora has in a bigger scale - which is what drives RHEL - and provides the knowledge and experience needed in the future cloud solutions? I do believe Fedora, as a whole, plays a fundamental role in the bigger ecosystem for RHEL and towards the hybrid cloud everyone works towards. Fedora plays a role providing a good experience and platform, all from the developers and the sys-admins perspective to the end users, leading the way towards the future enterprise solutions. Which is why IBM wanted Red Hat. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: IBM buying RedHat
On 31/10/18 06:21, John Coughlan wrote: > Yea - Does IBM have any plans on keeping, or discarding any of RH’s open > source > efforts…like this one? Can we as a community still expect the same sort of, > and level of > involvement post sale as we have enjoyed before hand from RH/IBM employees? Even though this is not an official source of any kind, I think the analysis done here pretty well covers these questions for now: <https://www.zdnet.com/article/red-hat-an-independent-barony-in-the-kingdom-of-ibm/> -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Set firefox default home page
On 13/09/18 22:16, Danishka Navin wrote:
> Hi,
>
> I am working on a project that require a fedora spin with firefox which point
> to specific web url as the default home page.
> This will be applicable to all users and I could not find anything on skell
> directory against mozilla.
>
> I have manually altered (just for testing) vim
> /home/liveuser/.mozilla/firefox/ogkcrque.default/prefs.js and it worked.
> user_pref("browser.startup.homepage", "")
>
> But my requirement is to make this change system wide.
I don't recall the details, but I believe this is what /etc/firefox/pref is for.
There is also /usr/lib64/firefox/defaults/preferences, but this is owned by
the firefox package and can be overwritten.
At least a few places to look further.
--
kind regards,
David Sommerseth
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Idea: let's use Pagure to track Changes
On 23/08/18 22:43, Ben Cotton wrote:
> Hi community,
>
> We've traditionally used the wiki for Change proposals because it's
> the tool we had. But, it's not necessarily well-suited to the purpose.
> But now we have Pagure, which can help address some of the
> shortcomings of using the wiki: poor scriptability, no reporting, and
> a lot of copy/paste.
>
> So I've come up with a plan that would use Pagure instead:
> https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
>
> You can read the full details on the wiki page above, but the general
> idea is that we won't change the policy for Changes, just how we store
> and manipulate them. My intent is to make it nearly seamless for the
> community while giving us a platform for building on the process in
> the future. Note that this would run parallel to Bugzilla for a
> release or two and then replace Bugzilla for Changes tracking.
Even though I'm not as active here as I would like to be, I generally like
this idea.
A few things which would be good to sort out are:
* Still requires changes be represented in three different Pagure repos
* We lose edit history if a change proposal is updated based on feedback
From my point of view, those are the most critical ones. The history is good
when you want to see if/how things changed - to learn from specific changes
which went well or really bad. Not having a history to base it on makes this
learning somewhat more difficult - as you don't know exactly how a change
proposal did develop, just the final result.
Also having changes represented in three different repos sounds a bit too
bureaucratic to me. Processes are good to have, but in the moment they get
too complicated people will generally try to avoid them. If it is really
needed to involve three repos, then a decent tooling on top of it is needed at
launch time; to hide this bureaucratic process a bit.
Other than that, I think this idea makes perfect sense. The first time I did
a change proposal (not even system-wide), it felt like an odd process ("Is
this the right template? In a wiki? Have I filled out all the proper fields
correctly? How is this proposal picked up and distributed properly?" are some
of the thousands questions which popped up).
--
kind regards,
David Sommerseth
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
Re: Hiding the grub menu by default on single OS installs
On 31/05/18 12:23, Hans de Goede wrote: > Hi All, > > I'm working on improving the Fedora boot experience, with the > end goal being a user pressing the on button and then going > to the graphical login manager without him seeing any > text messages / menus filled with technical jargon. Making the boot process less "magical" by not presenting "text messages / menus filled with technical jargon" sounds like a nice user experience - when everything works. But we need to account for all the times things do not work too well. Diving into a menu by pressing a button or key within a reasonable time window is challenging for many non-techs. So this would be a worse user experience if they struggle to enter this "hidden menu". I'd rather consider a different approach. Rather have a closer look at this "technical jargon" being presented. Just a quick example from one of my Fedora VMs: 'Fedora (4.15.8-300.fc27.x86_64) 27 (Cloud Edition)' Why not just say: "Fedora 27" Or even just "Fedora", as it's not possible to boot into, say, "Fedora 26" unless lots of tweaks at the install/upgrade time has been done. Then have a sub-menu called "Recovery options", where you can list older kernels specifying kernel versions - but make that simpler too. Instead of "4.15.8-300.fc27.x86_64" just say: "4.15.8-300" So the menu could look something like - Fedora Recovery options |`- Fedora (older kernel, 4.13.0-103) |`- Fedora (older kernel, 4.14.5-300) |`- Fedora (older kernel, 4.15.3-304) \-- System recover mode (expert) - Just my 2cents. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PMI6UPESGWUFWA5HPCFVW6M6H6TAQ4J2/
Re: Status of OwnCloud/NextCloud
On 03/04/18 21:00, Christian Glombek wrote: > I should probably add that the actual updater program has not been shipped in > the rpms thus far. Although I'm not sure how this affects major updates, it > is leading to problems elsewhere (i.e. people have to uninstall some apps on > v13 and re-install them on v13.0.1 for them to work again). > > And how many people actually still run NC v10? I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned. I've even started considering moving those servers over to a stable Debian release, as that environment is closer to EPEL stability than Fedora but with newer dependencies. But I'm not too happy about manually installing NC. NC is great in so many ways, but the poor packaging means I'll have to rethink how much longer I'm willing to accept the current situation. Time is scarce for everyone. I don't mean to shoot any of the NC package maintainers in Fedora, I have the impression they have and are doing what they can, as this is a community project. But I think Nextcloud as a company should take this matter far more serious. It might even be considered a business model for a subscription service. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 03/04/18 15:13, Peter Robinson wrote: > On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow > <bowlofe...@fedoraproject.org> wrote: >> Greetings! >> >> It seems that OwnCloud and NextCloud might be unmaintained in Fedora. I >> found that upgrading my F27 box to F28 causes it to be unable to login: > > I think the old maintainer did a blog post about this some time ago, > can't seem to find it with a quick search, but I think it was on the > planet. Here's some traces ... <https://twitter.com/hogarthj/status/961300659931926528> Not sure what happened after this. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removal of BuildRoot
On 16/02/18 19:48, Tom Hughes wrote: > On 16/02/18 18:26, David Sommerseth wrote: > >> But my "worst" example was probably the openvpn package I'm now in charge for >> (and I am a core upstream developer for that project as well). But it didn't >> take that much efforts to iron out most of those issues. False positives are >> also easily filtered out by adding .rpmlint to the dist-git repository. > > I suspect approximately nobody knows that you can create such a file > because as far as I can tell it's not well documented. > > Even now having googled a bit I haven't managed to find anything telling > me what I can put in it. Have a look here: /usr/share/doc/rpmlint*/config.example -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Remove GCC from BuildRoot
On 16/02/18 15:53, Daniel P. Berrangé wrote: > On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: [...snip...] >> There is no simple way of doing this. Also as other thread mentioned, people >> hate automated changes... So for this one we need every single packager to >> fix >> their packaging and not to fix it in automatic way. > > For the few people who complain about the automated changes, there's a largely > silent group would just welcome it. +1 ... the negative noise of a few with is not a representative measure for the whole group. And the negative noise is always more visible and noticeable. I've been mostly silent whether it is good or bad. But I generally think it is good that things which are wrong or bad gets fixed. It means I can focus on more real issues than fixing which could (read: should) be be automated. I am very much thankful for all automation being done. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removal of BuildRoot
On 16/02/18 17:21, Martin Kolman wrote: > On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote: [...snip...] >> As upstream for rpmlint, I do not believe anyone cares at all about >> rpmlint in Fedora. One more warning or error won't mean anything. From >> time to time, I have considered making a proper rpmlint policy for >> Fedora, but I always decide not to because it's clear that that people >> don't care about it and ignore it. > > I think this is more or less a chicken and egg problem - rpmlint output is > currently so insanely bad and useless that > most people indeed ignore it. So arguably if the output was better more > people would likely use it. I certainly might be a weird guy with odd perspectives or I'm haven't touched packages which has had so enormous issues with rpmlint it didn't make sense to fix it. Or I'm lacking good enough experience (I've not been maintaining that many Fedora packages). But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily filtered out by adding .rpmlint to the dist-git repository. If anyone have examples of those really nasty rpmlint reports ... that would be far more valuable to this discussion than just claiming it is "insanely bad and useless". And since we have the attention of the rpmlint maintainer, perhaps there would be a better chance to figure out how to report those issues in a better way - or remove what isn't truly an issue. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removal of BuildRoot
On 16/02/18 09:14, Nico Kadel-Garcia wrote: > On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III <ti...@math.uh.edu> > wrote: [...snip...] > While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are > there any EPEL tools that are identical to the upstream Fedora > releases, that might still use any of htese for legacy environments? Perhaps a silly and ignorant question but is it still possible to send builds to EPEL 5 repositories? I thought that option got closed long ago, together with RHEL 5 reaching EOL. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Escaping macros in %changelog
On 10/02/18 12:54, Kevin Kofler wrote:
> David Sommerseth wrote:
>> I doubt Koji was primarily built for "does this work?"-builds. It exists
>> to build proper packages targeting Fedora repositories.
>
> But that is the point, to build a proper package:
>
> do {
> try build;
> } while (!build succeeded);
>
> and the output is a working package.
We agree on the goal. But we have different views on the path to the goal.
I personally find it abusing shared resources throwing builds at it which has
not been tested first. So I prefer to do local mockbuilds first, simply to
lessen the load on shared resources. I'm not saying I haven't tossed failing
builds at koji, that has happened too. But I generally try to avoid that as
much as I can.
>> To me this is backwards and is lacking some logic. If you push things
>> which does not build properly, you also waste a build.
>
> That is a build attempt that would have had to happen anyway. Otherwise, how
> do I know that it doesn't build.
>
> The point is, the above optimized loop needs n build attempts. What you
> propose doing needs n+1 build attempts to get the exact same package.
True. But my n+1 approach also wouldn't add litter to the git commit history
with noise. I use the same approach when doing development too; I always try
to avoid committing anything which hasn't been tested first, as I simply find
it nasty to have commits not building (which again makes bisecting harder) ...
But I'll agree that development and package maintenance are not the same thing
- even though they carry similarities
--
kind regards,
David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Escaping macros in %changelog
On 09/02/18 23:46, Kevin Kofler wrote: > David Sommerseth wrote: >> Doesn't 'fedpkg mockbuild' resolve those test builds? To my knowledge, >> this is fairly close to what koji does under the hood. Then you'll have >> everything tested locally, git tree can be cleaned up and be in a >> reasonable shape before being pushed out. > > I'm surely not going to build those packages on my computer, that's what we > have Koji for! I doubt Koji was primarily built for "does this work?"-builds. It exists to build proper packages targeting Fedora repositories. >> If you want to make koji run the build, you can also use 'fedpkg build >> --scratch' and provide an SRPM (generated by 'fedpkg srpm'). This >> shouldn't need to be git pushed either to work. > > Then I have to waste a build (which wastes my time and Koji's resources) > because I'll have to build the last attempt (the one that ends up > succeeding) again as an official build later. It also takes extra time to > build and upload the SRPM compared to letting Koji compose it from dist-git, > which for a large package like qt5-qtwebengine is not negligible either. (I > have only so much upload speed on this asymmetric cable broadband > connection.) To me this is backwards and is lacking some logic. If you push things which does not build properly, you also waste a build. And if your build works but there are other non-critical typos, you still waste a build when you correct that. Testing builds is critical to ensure your .spec file is properly setup. If it happens locally or in a pre-built SRPM sent to koji, is not really that important. Here people use what is most convenient to them. To avoid bandwidth issues I know people (including myself) uses external hosts with a decent Internet link (you might even get access to some free resources, especially if targeting special platforms - like the Open Power Hub if doing POWER8 related stuff [1]). Use sshfs or similar approaches to a remote server which is used to update a .spec file from your local host and then use ssh on that host and do the heavy-lifting there directly. The bandwidth for a ssh connection is negligible compared to uploading large srpm packages. Plus the koji upload goes fairly fast. Or you could get a more reasonable and decent Internet connection at home/work with a better bandwidth. To me these complaints sounds more like insisting on not adopting to the reality. Getting all your expectations covered and expect the Fedora tooling around to adopt to your expectations just sounds backwards to me. [1] <https://research.redhat.com/powerlinux-openpower-development-hosting/> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Escaping macros in %changelog
On 09/02/18 23:09, Kevin Kofler wrote: > Kamil Dudka wrote: >> Would not it be then better to work on this in a staging branch and rework >> those commits before they are pushed to a production branch? I am myself >> not interested in going through commits like "fix a typo", "forgot to bump >> release", "add missing BR", "revert the previous revert", etc. > > I have to push them to the right branch so I can build them. Then if it > builds, it's fine, but if it's broken, I fix it and try again. Hi Kevin, Doesn't 'fedpkg mockbuild' resolve those test builds? To my knowledge, this is fairly close to what koji does under the hood. Then you'll have everything tested locally, git tree can be cleaned up and be in a reasonable shape before being pushed out. If you want to make koji run the build, you can also use 'fedpkg build --scratch' and provide an SRPM (generated by 'fedpkg srpm'). This shouldn't need to be git pushed either to work. Just my 2 cents. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Package review - test builds for OpenVPN 3 Client
Hi, This week I've started poking at packaging pre-release builds of the new OpenVPN 3 based client for Linux (sorry, no server support yet). I've started a Copr build/repo for it and I'd appreciate some help reviewing the packaging and otherwise hints (or pathces) how to improve things. You'll find everything here: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> Now, beware that this client is still under heavy development and is not ready for a full release yet. Once lacking features and the most critical or annoying bugs are sorted out, we'll tag the first beta release. Since it is under heavy development ... it is not ready for production yet. But I have enabled it on a server, to test the long-term stability of it. And a final warning ... This client is _very_ _different_ from the far more common openvpn-2.x series. It is different in almost every aspect. The only thing they have in common is that the OpenVPN wire protocol is essentially the same and compatible (it can connect to OpenVPN 2.x servers) and the configuration files will in most cases work just fine (as long as unsupported options in OpenVPN 3 is not used). If you have any questions or comments, feel free to reach out! -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Remove old GPG keys?
On 31/10/17 18:46, Simo Sorce wrote: > On Tue, 2017-10-31 at 17:34 +0200, Panu Matilainen wrote: >> On 10/31/2017 04:57 PM, Stephen Gallagher wrote: [...snip...] >>> Correct me if I'm wrong, but we only check keys at installation >>> time, so >>> they'd be able to continue running just fine, but they'd be denied >>> if >>> they tried to reinstall it after F21 is EOL. Which seems perfectly >>> reasonable to me; if you're using an EOL operating system, forcing >>> people to have to pass --no-gpgcheck is a great way to get them to >>> pause >>> and reconsider their situation. >> >> Actually rpm by default checks signatures on queries and >> verification >> too, so there is some value in keeping the keys there, at least for >> keys >> that are actually in use. >> > > Is it possible to mark keys so they can be used for verification but > not for installation of new packages ? Can't key revocation status be used for this? IIRC, it is possible to verify existing signatures with revoked keys, so yum/dnf just need reject doing verification during install if the key is revoked. > My personal worry is that old keys may get compromised over time, so it > is a very good practice to regularly "disable" old keys. +1 -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN and its user/group
On 02/10/17 19:33, Colin Walters wrote: > On Mon, Oct 2, 2017, at 10:56 AM, David Sommerseth wrote: > >>"diag" : "Invocation of useradd without specifying a >> UID; this may be OK, because /usr/share/doc/setup/uidgid defines no UID for >> openvpn" > > https://github.com/default-to-open/rpmgrill/pull/22 Thanks! This makes a lot of sense. I'll leave things as it is and just ignore this particular error in the report. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
OpenVPN and its user/group
Hi,
I just looked more carefully through some issues reported when pushing
out the openvpn-2.4.4 release.
--
{
"module" : "RpmScripts",
"order" : 90,
"results" : [
{
"arch" : "src",
"code" : "UseraddNoUid",
"context" : {
"excerpt" : [
"useradd -r -g openvpn -s /sbin/nologin -c OpenVPN -d
/etc/openvpn openvpn"
],
"lineno" : 149,
"path" : "openvpn.spec",
"sub" : "%pre"
},
"diag" : "Invocation of useradd without specifying a
UID; this may be OK, because /usr/share/doc/setup/uidgid defines no UID for
openvpn"
}
],
"run_time" : 0,
"status" : "completed"
},
--
This made me wonder if it would be beneficial to allocate a fixed
UID/GID value for the openvpn user and group account? Is that
advisable? And what would be the process for doing so?
It is highly recommended by upstream to let OpenVPN change uid/gid
to a unprivileged account after the initial setup have completed;
OpenVPN does that in the correct order when applying --user/--group
to the configuration.
And as we are also working towards a brand new Linux client based on
the OpenVPN 3 Core library, that will also run several helper processes
unprivileged; only to have the core tunnel instance starting with root
privileges for tunnel setup. All the session management and user
front-ends will run completely unprivileged.
But if these scenarios are reasonable arguments for having a fixed
uid/gid, I do not currently know. The OpenVPN source code itself
is not tied to any specific uid/gid values. All it uses is the
openvpn user/group name; and currently the openvpn.spec file
calls `useradd` directly as part of the installation process.
--
kind regards,
David Sommerseth
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
On 07/09/17 14:25, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 03 September 2017 at 13:45, Igor Gnatenko wrote: >> GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat symlink >> from /usr/bin/gpg to /usr/bin/gpg2.. >> >> Is it time to retire gnupg (v1) ? > > hplip still requires gnupg. I won't raise the banner on the barricades over this one, but I have been able (by tweaking the hplip.spec file somewhat) to build hplip-3.17.4-1 on RHEL7. Had to revert Python3 -> Python2 and ditched the GUI tools. And RHEL7 ships only gnupg2. That said, I don't know how broken my build is (all I know is that it works well enough for my printer, including network scan). But for all I know, it might be it is the GUI tools which depends on the gnupg stuff. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BTRFS dropped by RedHat
On 04/08/17 18:06, Neal Gompa wrote: > On Fri, Aug 4, 2017 at 11:23 AM, Fernando Nasser <fnas...@redhat.com> wrote: >> On 2017-08-04 11:12 AM, Przemek Klosowski wrote: >> >> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs: >> >> >> Is it only RHEL? >> >> What are other distros doing? >> > > It is only RHEL, but unfortunately that has a *huge* knock on effect > across hundreds of derivative distribution projects and products. > > It's an enormous problem that they're doing this... Hmmm, that sounds backwards to me. I would say it is more a problem that Btrfs haven't reached a stability/trust level over so many years which makes Enterprise Linux considering to use it. To me this more indicates the overall state of Btrfs. I certainly do hope that Btrfs development doesn't slow down by this, rather that the pace gets improved and it will come back again in stronger and more solid during a future RHEL 8 release. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFD Unifying graphviz.spec with upstream
On 20/07/17 12:47, Michael Schwendt wrote: > On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote: >> >> This works well for me, upstream, for building and testing across all >> distributions, but perhaps the .spec file is less optimal when you >> separately maintain versions for each distribution? >> > > Doubtful. It's a maintenance nightmare. Tons of defines and conditionals, > which toggle almost everything (BR, features and subpkgs) using highly > cryptic macro names, sections that don't adhere to the packaging > guidelines, dangerous violations of the guidelines, workarounds for RHEL > 7. You may be familiar with the spec file, or you may believe you are, but > in my point of view, the spec file is filled with pitfalls. That will > backfire eventually. Not even the %changelog has been maintained since > 2009. And probably the biggest mistake related to conditional subpackage > builds is that you cannot simply flip a #define and disable a subpackage > build without inserting an Obsoletes/Provides pair. So, what may be of > some limited use while testing builds, is of no use in packages released > into a public distribution. I second this opinion. We've had a similar discussion within the upstream OpenVPN team as well. Most distributions have their own tracking of the .spec files, with their own set of packaging guidelines and preferences how things should do. Yes, it is possible to use %if to get around all that. But the end result in the .spec file is much harder to read and follow. I recommend to let distributions be distributions, and let each distribution carry their own .spec file - especially targeting their needs and processes. The benefit of carrying a unified .spec file is really not worth the efforts in the long run IMO. Once the RPM build tools and packaging guidelines is unified across all RPM based distributions you will find it reasonable to unify the .spec files. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 20/07/17 13:55, Alexander Ploumistos wrote: > On Thu, Jul 20, 2017 at 2:21 PM, David Sommerseth <d...@eurephia.org> wrote: >> I rather prefer to have this change in Fedora _now_ in a _planned_ >> release where this can be tested out before the final F27 is released. > > I modified the unit file on a F26 VPS and I didn't have any problems > connecting with F24, F25, F26, a gentoo installation that hasn't been > updated in almost a year, OpenWrt (CC) and Android (Lineage OS 14.1). > Not that this is exhaustive testing, but I think this change is a lot > less pervasive than it is made out to be. Thank you very much for this testing! This is truly a valuable feedback. And you are right, this shouldn't be such a risky or invasive change at all - as it should provide the needed fallback to not break existing configurations; which you seem to have confirmed as well. But I wanted to make this change visible in Fedora, both due to there were complaints when updating to OpenVPN v2.4 which broke some configurations (several reasons, I won't dive into that now) - and to highlight that there is now a way to seamlessly update client configurations one-by-one to a far better cipher for those still using BF-CBC. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 20/07/17 09:46, Farkas Levente wrote:
> On 07/20/2017 02:09 AM, David Sommerseth wrote:
>> On 18/07/17 22:55, Farkas Levente wrote:
>>> On 07/18/2017 10:03 PM, David Sommerseth wrote:
>>>> On 18/07/17 17:50, Farkas Levente wrote:
>>>>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>>>>>> This will result in the following:
>>>>>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
>>>>>> regardless if they have --cipher in their configuration file or not.
>>>>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>>>>>> client configuration needs to deploy --ncp-disable.
>>>>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>>>>>> --ncp-disable in the client configuration) can connect to the server
>>>>>> using any of the --ncp-ciphers list; this is what is called "poor
>>>>>> man's cipher negotiation" by the upstream OpenVPN developers.
>>>>>> * Any client not providing --cipher defaults to BF-CBC. These clients
>>>>>> should still be able to connect to the server as the server allows
>>>>>> BF-CBC through --ncp-ciphers.
>>>>>
>>>>> unfortunately it's not working:-(
>>>>> it takes me long time to debug it on my own server and a long discussion
>>>>> in this ticket:
>>>>> https://community.openvpn.net/openvpn/ticket/886
>>>>> it's not possible to set
>>>>> cipherAES-256-GCM
>>>>> since in this case old clients eg android client which not updated to
>>>>> 2.4.x are not able to connect.
>>>>
>>>> The issue I believe you refer to ("unreliable NCP") should be fixed in
>>>> OpenVPN v2.4.3.
>>>> <https://community.openvpn.net/openvpn/ticket/887#comment:13>
>>>
>>> this means only a few weeks ago...
>>> imho openvpn is _very_ widely used and if it's break anything it's break
>>> a lots of thing...
>>> i'd rather postpone it to f28 when it's fully tested and stabilized.
>>
>> What is the benefit of postponing based on a bug which have been fixed?
>> And have been tested? And where the test process should reasonably
>> thoroughly documented and can be verified by others?
>>
>> Also considering that we're just in the very early planning phase of
>> F-27 and F-26 have just been released. So F-27 is at least 6 months
>> ahead of us. Which means the NCP feature will be at least 1 year old,
>> with the last fix making this work will be 6 months - which should be
>> plenty of time to test this out. Plus considering that OpenVPN is
>> deployed elsewhere in much grander scales than Fedora alone where also
>> NCP is getting more and more used and rolled out in similar ways as this
>> proposal. So this is also being tested outside the Fedora universe as well.
>
> if this is so obvious and has only benefits and at the same time you
> also upstream developer why the upstream openvpn not change it's
> default? since it'll exactly has the same effect as it's changed in
> fedora and in this case fedora don't have to do anything.
You never seem to really answer any questions, you just shoot new ones.
This makes it really makes it hard to take your feedback serious.
Especially when you even base your claims that this won't work on false
premises, completely disregards issues have been fixed upstream already
and it is reasonably easy to verify my claims it works. You have not
provided any feedback that there are any flaws in neither the example
configurations nor the test script described in the change proposal.
With this argumentation tactic, Fedora would still be arguing when to
include systemd in an official release. And this OpenVPN change is a
far less invasive change. And even only hitting OpenVPN server
configurations.
But to answer your yet new question: A far more invasive change is being
discussed upstream, which will enforce this change also on non-systemd
based OSes (that change will be happen in the OpenVPN executable). The
experienced functionality will be most likely be pretty much the same.
But as this is a very simple change for Fedora - by changing the unit
file, so I didn't really see any reason to postpone it. This also helps
preparing Fedora users once it hits a future upstream OpenVPN release
(something I got lots complaints about when moving towards OpenVPN 2.4
in Fedora).
So if the consensus is that we should just silently wait until upstream
OpenVPN forces this change upon us, then I don't want to he hear a lot
of noise and
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 18/07/17 22:55, Farkas Levente wrote:
> On 07/18/2017 10:03 PM, David Sommerseth wrote:
>> On 18/07/17 17:50, Farkas Levente wrote:
>>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>>>> This will result in the following:
>>>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
>>>> regardless if they have --cipher in their configuration file or not.
>>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>>>> client configuration needs to deploy --ncp-disable.
>>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>>>> --ncp-disable in the client configuration) can connect to the server
>>>> using any of the --ncp-ciphers list; this is what is called "poor
>>>> man's cipher negotiation" by the upstream OpenVPN developers.
>>>> * Any client not providing --cipher defaults to BF-CBC. These clients
>>>> should still be able to connect to the server as the server allows
>>>> BF-CBC through --ncp-ciphers.
>>>
>>> unfortunately it's not working:-(
>>> it takes me long time to debug it on my own server and a long discussion
>>> in this ticket:
>>> https://community.openvpn.net/openvpn/ticket/886
>>> it's not possible to set
>>> cipher AES-256-GCM
>>> since in this case old clients eg android client which not updated to
>>> 2.4.x are not able to connect.
>>
>> The issue I believe you refer to ("unreliable NCP") should be fixed in
>> OpenVPN v2.4.3.
>> <https://community.openvpn.net/openvpn/ticket/887#comment:13>
>
> this means only a few weeks ago...
> imho openvpn is _very_ widely used and if it's break anything it's break
> a lots of thing...
> i'd rather postpone it to f28 when it's fully tested and stabilized.
What is the benefit of postponing based on a bug which have been fixed?
And have been tested? And where the test process should reasonably
thoroughly documented and can be verified by others?
Also considering that we're just in the very early planning phase of
F-27 and F-26 have just been released. So F-27 is at least 6 months
ahead of us. Which means the NCP feature will be at least 1 year old,
with the last fix making this work will be 6 months - which should be
plenty of time to test this out. Plus considering that OpenVPN is
deployed elsewhere in much grander scales than Fedora alone where also
NCP is getting more and more used and rolled out in similar ways as this
proposal. So this is also being tested outside the Fedora universe as well.
In addition, the scope of this proposal *only* targets the server side
configurations. I would expect the vast majority of Fedora users run
OpenVPN as a client, and then I'd expect it to be more likely used via
the NetworkManager plug-in for OpenVPN. In both these scenarios,
nothing will change.
I know I am somewhat blinded to other potential issues, as I am also an
upstream OpenVPN developer. But if others see flaws in the proposed
test script [1], feel free to help improve it! And do report back
unexpected results ASAP.
[1]
<https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN#How_To_Test>
Bottom line is, from my perspective: This feature currently works as
expected - at least to my knowledge. If there are issues we do have
time to fix them before the final F-27 release. And if not, then we'll
roll it back - which is more than fair enough.
The change itself isn't big, but the security improvements are
considerably much more important for end users and system administrators
to help them easily move away from BF-CBC.
--
kind regards,
David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 18/07/17 17:50, Farkas Levente wrote:
> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>> This will result in the following:
>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
>> regardless if they have --cipher in their configuration file or not.
>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>> client configuration needs to deploy --ncp-disable.
>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>> --ncp-disable in the client configuration) can connect to the server
>> using any of the --ncp-ciphers list; this is what is called "poor
>> man's cipher negotiation" by the upstream OpenVPN developers.
>> * Any client not providing --cipher defaults to BF-CBC. These clients
>> should still be able to connect to the server as the server allows
>> BF-CBC through --ncp-ciphers.
>
> unfortunately it's not working:-(
> it takes me long time to debug it on my own server and a long discussion
> in this ticket:
> https://community.openvpn.net/openvpn/ticket/886
> it's not possible to set
> cipherAES-256-GCM
> since in this case old clients eg android client which not updated to
> 2.4.x are not able to connect.
The issue I believe you refer to ("unreliable NCP") should be fixed in
OpenVPN v2.4.3.
<https://community.openvpn.net/openvpn/ticket/887#comment:13>
I just ran a few tests manually now.
server.conf --
dev tun
persist-tun
server 10.35.8.32 255.255.255.224
topology subnet
user openvpn
group openvpn
chroot /var/lib/openvpn
client-config-dir clients
proto udp
port 1194
verb 4
keepalive 20 45
persist-key
remote-cert-tls client
dh dh2048.pem
pkcs12 server-ec.p12
ecdh-curve secp521r1
cipher AES-256-GCM
auth SHA256
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC
key-direction 1
tls-auth vpn.ta
client.conf ---
dev tun
pkcs12 client-ec.p12
remote testserver.example.com 65441 udp
tls-auth vpn.ta
key-direction 0
verb 4
client
auth SHA256
explicit-exit-notify 2
I tested this client config on both OpenVPN v2.3.12 and v2.4.3. All
connects with BF-CBC, AES-256-CBC, AES-128-CBC and for v2.4.3 I also
tested AES-256-GCM (I didn't test AES-128-GCM).
So I would recommend to re-test your own setup with the latest v2.4.3 on
the server side; which is what we ship in F25 and newer.
--
kind regards,
David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Rsyslog log format change proposal
On 29/05/17 23:18, Björn Persson wrote: > Björn 'besser82' Esser wrote: >> Does this qualify to be a system-wide change? To me this looks like >> a self-contained change, since I don't see any other packages or >> processes in need for adjustment, but rsyslog itself. > > I'll be surprised if there aren't any programs that parse the system > log and will need to understand the standard timestamp format. One can > hope that they all understand it already, but the review that's needed > to determine that is in my opinion reason enough to treat it as > system-wide. One such program which strikes my mind instantly is logwatch ... how will that cope this change?That said, this change does make a lot of sense; as long as log parses won't choke and die. And those tools should be fixed in these cases, don't revert this needed log format change. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wild changes in nsswitch.conf
On 16/05/17 14:20, Stephen Gallagher wrote: >> apparently *designed* with philosophy much like that of systemd. It's >> supposed to be a unified set of tools replacing a lot of already >> existing functionality, and adding some useful features. >> Unfortunately, its unifying multiple service and multiple host >> authentication doesn't seem to have become popular: Most folks I've >> seen using Kerberos and LDAP, which sssd was designed to integrate, >> have simply ignored sssd and gone straight to the more multi-platform >> supported Samba. > > Just a reminder: anecdotes do not equal rigorous data :) > > SSSD is in extremely wide use around the world and is the preferred > LDAP/Kerberos client option in all of the major Linux distributions. Just to backup this a bit further. Those integrating with AD, will also most likely take advantage of LDAP/Kerberos as well. Kerberos is the only authentication scheme I know of which also enables a truly working SSO solution, which tackles the full stack from localhost login to various network services. In addition, SSSD provides a possibility to cache authentication details so you can have laptops fully integrated with an LDAP/Kerberos environment, provide a centralized password policy and yet be able to do local authentication if the LDAP/Kerberos backends are unavailable. And then there is the support for OTP based authentication, which it also seems to be handled quite well regardless if you are online or not. From my perspective, SSSD solves more issues than what nscd is capable of, at least to how I've learnt to know nscd. And my experience with computers enrolled into a FreeIPA managed network have overall just been a wonderful and easy experience. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN v2.4.2 with two important fixes
On 12/05/17 13:59, Jonathan Wakely wrote: > On 11/05/17 16:59 +0200, David Sommerseth wrote: >> >> Hi, >> >> Just making a little noise here, as the upstream OpenVPN community have >> released v2.4.2 which fixes to critical authenticated remote DoS >> vulnerabilities. >> >> <http://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits> >> >> (the site is being hammered right now, so patience is needed ;-)) >> >> I have already sent the updates to EPEL 6, EPEL7 and F-25. >> >> Next in the pipe is F-26 and Rawhide, but that have the challenges >> around OpenSSL 1.1 vs mbedtls - and I plan to test out compat-openssl >> with compat-pkcs11-helper. > > Will F24 get an update to 2.3.15? > > The current 2.3.14 version seems to have the same issues as 2.4.1 in > F25 does. Just prepared this update: <https://bodhi.fedoraproject.org/updates/FEDORA-2017-f426acf49d> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN v2.4.2 with two important fixes
On 12/05/17 13:59, Jonathan Wakely wrote: > On 11/05/17 16:59 +0200, David Sommerseth wrote: >> >> Hi, >> >> Just making a little noise here, as the upstream OpenVPN community have >> released v2.4.2 which fixes to critical authenticated remote DoS >> vulnerabilities. >> >> <http://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits> >> >> (the site is being hammered right now, so patience is needed ;-)) >> >> I have already sent the updates to EPEL 6, EPEL7 and F-25. >> >> Next in the pipe is F-26 and Rawhide, but that have the challenges >> around OpenSSL 1.1 vs mbedtls - and I plan to test out compat-openssl >> with compat-pkcs11-helper. > > Will F24 get an update to 2.3.15? > > The current 2.3.14 version seems to have the same issues as 2.4.1 in > F25 does. > > (I'm not asking for an F24 update, just curious if you plan one). To be honest, I haven't spent much time thinking of F24. I've focused on F25 or newer. But it makes sense to at least update to 2.3.15. I'll give that a look soonish. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
OpenVPN v2.4.2 with two important fixes
Hi, Just making a little noise here, as the upstream OpenVPN community have released v2.4.2 which fixes to critical authenticated remote DoS vulnerabilities. <http://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits> (the site is being hammered right now, so patience is needed ;-)) I have already sent the updates to EPEL 6, EPEL7 and F-25. Next in the pipe is F-26 and Rawhide, but that have the challenges around OpenSSL 1.1 vs mbedtls - and I plan to test out compat-openssl with compat-pkcs11-helper. As always, I appreciate comments, feedback and help with testing these releases. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
> On 2 May 2017 at 11:14, David Sommerseth <d...@eurephia.org> wrote: >> Show us a dist-git repos we can clone and run 'fedpkg mockbuild' and see >> how this works for _Fedora_. >> >> How things are done in various other distributions doesn't mean it can >> be re-used directly in Fedora. And that tweaking is something we need >> to have sorted out long before we can even consider doing something >> similar in Fedora. Without that we have no idea how to adopt this to a >> full scale on all packages and how much work it will be. > > Nice try > Seems you are posting from one of the email addresses blocked by > fedora devel because there is no any traces of this email on > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2017/5/. Wrong. <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SD77K6KFRINX3RANRP5ITJ44KU6HO5IS/> > I'm adding you to my spam filter so please do not bother reply to my > public emails next time. Just thought the list should beware of this attitude. Oh and by the way, kloczek, thank you very much! Now at least I know you are not that serious about contributing to Fedora. Which, by the way, is quite confirmed here: <https://badges.fedoraproject.org/user/kloczek> And I'm not going to spend more energy on this mail thread any more. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On 02/05/17 08:18, Tomasz Kłoczko wrote: > On 1 May 2017 at 14:42, Matthew Miller <mat...@fedoraproject.org> wrote: >> Tomasz, as I'm sure you know, our entire OS-creation infrastructure is >> built around RPM. Suggesting we switch to another system is an ENORMOUS > > Seems you did not read what I wrote careful. > *I'm not suggesting switching to IPS.* > I've pointed on IPS as software with tested and implemented some ideas > about PM which can be *imported* to the RPM. > > Please read one more time whole thread. No. Matthew understood me 100% correct. Show us a dist-git repos we can clone and run 'fedpkg mockbuild' and see how this works for _Fedora_. How things are done in various other distributions doesn't mean it can be re-used directly in Fedora. And that tweaking is something we need to have sorted out long before we can even consider doing something similar in Fedora. Without that we have no idea how to adopt this to a full scale on all packages and how much work it will be. The bottom line is: Show us a proof-of-concept which can be deployed and tested directly in Fedora. And the POC *MUST* work in a Fedora environment out-of-the-box you provide. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On 29/04/17 20:31, Tomasz Kłoczko wrote: > >> As the saying goes: Talk is cheap! > And this is what exactly I'm doing .. And it is incredibly tiring with all your words. Lets try another idiom: Don't talk the walk; walk the walk Point us at some patches, git repos, .spec files, *whatever* which uses your approach so we can see and get experience on how to resolve it. If you're not coming up with anything concrete by now, you'll just be ignored and mail threads of such types just gets silently ignored by the mailing list recipients. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN, OpenSSL and Fedora 26+
On 27/04/17 23:15, Pete Travis wrote: > > > On Apr 27, 2017 3:13 PM, "David Sommerseth" <d...@eurephia.org > <mailto:d...@eurephia.org>> wrote: > > On 27/04/17 01:20, Dominik 'Rathann' Mierzejewski wrote: > > Thanks a lot for the write-up, David. Can you make sure this ends up > > in the release notes? > > Sure ... I've never done that before, any pointers to how I can make > that happen? > > > -- > kind regards, > > David Sommerseth > > > File a PR or issue at https://pagure.io/release-notes and I'll follow up > on it. An issue would be best at the moment, there's a bit of prep work > to do for the F26 branch. Thanks a lot, Pete! An issue have been created: https://pagure.io/release-notes/issue/36 -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN, OpenSSL and Fedora 26+
On 27/04/17 01:20, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 26 April 2017 at 21:18, David Sommerseth wrote: >> On 26/04/17 17:08, Lee Howard wrote: >>> On 04/25/2017 01:39 PM, David Sommerseth wrote: >>>> This is actually just a very late heads-up about challenges with OpenVPN >>>> in Fedora 26. >>>> >>>> Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and >>>> good step forward. Unfortunately, that gives OpenVPN a real challenge. >>>> The OpenSSL v1.1 support is not completed. Patches have been sent to >>>> the upstream devel mailing list for review, but only half of them have >>>> been processed and applied so far. >>>> >>>> So, to be able to provide OpenVPN in Fedora 26 it was decided to switch >>>> to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have >>>> revealed several issues: > > Thanks a lot for the write-up, David. Can you make sure this ends up > in the release notes? Sure ... I've never done that before, any pointers to how I can make that happen? -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenVPN, OpenSSL and Fedora 26+
On 26/04/17 17:08, Lee Howard wrote: > On 04/25/2017 01:39 PM, David Sommerseth wrote: >> This is actually just a very late heads-up about challenges with OpenVPN >> in Fedora 26. >> >> Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and >> good step forward. Unfortunately, that gives OpenVPN a real challenge. >> The OpenSSL v1.1 support is not completed. Patches have been sent to >> the upstream devel mailing list for review, but only half of them have >> been processed and applied so far. >> >> So, to be able to provide OpenVPN in Fedora 26 it was decided to switch >> to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have >> revealed several issues: >> >>- mbed TLS 2.3+ does by default not support certificates hashes >> "older" than SHA1. And RSA keys must be 2048 bits or more. >> This have been fixed by a couple of additional patches on top >> of the upstream OpenVPN code base. > > Why is switching to mbed TLS and patching that preferred over just > patching OpenVPN? Basically, security - as VPNs are by default security sensitive. The patches on the OpenVPN mailing list which enables OpenSSL 1.1 support need to be reviewed properly before we can fully trust them. And considering that the mbed TLS support have been in OpenVPN for several years and have also been used by OpenVPN-NL [1] for a long time, I consider that approach more secure. In addition I don't want to maintain what would in effect be a fork of OpenVPN (even though only for a while). So I follow the common Red Hat mantra of "upstream first". One upstream have officially blessed OpenVPN with OpenSSL 1.1, we will pull in the these patches unless a new v2.4 release is coming. This makes it easier to get upstream bugs fixed; we don't need to consider if a potential bug is a result of the un-reviewed OpenSSL patches or not. Those two patches I have added are basically based upon other patches under review [2] (I have been involved in that review too). In addition a similar approach have been implemented in the OpenVPN 3 core library [2] (which is being used by the OpenVPN Connect product range) which uses the same concept. So I consider those patches less security sensitive. [1] <https://openvpn.fox-it.com/> [2] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14452.html> [3] <https://github.com/OpenVPN/openvpn3/commit/88ae6eba36e91aa04ad95252456129ffcf544bd9> -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
OpenVPN, OpenSSL and Fedora 26+
Hi, This is actually just a very late heads-up about challenges with OpenVPN in Fedora 26. Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and good step forward. Unfortunately, that gives OpenVPN a real challenge. The OpenSSL v1.1 support is not completed. Patches have been sent to the upstream devel mailing list for review, but only half of them have been processed and applied so far. So, to be able to provide OpenVPN in Fedora 26 it was decided to switch to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have revealed several issues: - mbed TLS 2.3+ does by default not support certificates hashes "older" than SHA1. And RSA keys must be 2048 bits or more. This have been fixed by a couple of additional patches on top of the upstream OpenVPN code base. It supports now RSA keys of 1024 bits or more. In addition for OpenSSL support of the OPENSSL_ENABLE_MD5_VERIFY, a quirk have been added to also enable MD5 support if that environment variable have been set. - mbed TLS build in Fedora lacked PKCS#11 support. This have been resolved. But there are concerns how well this plays along with another dependency OpenVPN have, pkcs11-helper. This is being investigated and tested. Feel free to help out on bz #1432152 if you depend on PKCS#11/Smart Card functionality. Your feedback is valuable! - mbed TLS completely lacks support for PKCS#12 files. Now, there is kind of an alternative by using compat-openssl-10. But that does not play well with pkcs11-helper; which is compiled against OpenSSL v1.1. Currently the plan is to stay with mbed TLS support until PKCS#11 support is fully confirmed working or not working at all. If not working, we can at least move to compat-openssl10 without PKCS#11 support, which enables PKCS#12 support again. If PKCS#11 support works with mbed TLS, then we will stay on mbed TLS for now as I value that support more important than PKCS#12. Once OpenVPN have released a version with full OpenSSL v1.1 support (or at least have all the needed patches reviewed and applied to their upstream git repos), then I will switch back to the default openssl package again. This is far from ideal. But I do consider this the best compromise than not having an OpenVPN package in Fedora 26 at all. For those of you having PKCS#12 files, there is a kind of workaround where you can split up that file into CA, Certificate and Private Key PEM files - which OpenVPN can use directly. $ openssl pkcs12 -nokeys -cacerts -in $PKCS12FILE > ca-cert.pem $ openssl pkcs12 -nokeys -clcerts -in $PKCS12FILE > cert.pem $ openssl pkcs12 -nocerts -nodes -in $PKCS12FILE > private-key.pem If switching from '-nodes' with for example '-aes256' on the last line, the private key will be encrypted and password protected; similar to what your PKCS#12 files may already use today. I am sorry for not having sent this heads-up earlier. I took over package maintenance mid-March, and I've taken this package through a very much needed overhaul to align the packaging with improvements in the upstream packaging. The previous maintainers have done a good job keeping this package alive, but the gap against upstream began to be a bit too big. There are still a few things which needs to be ironed out. But once the mbed TLS/OpenSSL issue and a few other more minor issues gets resolved, I'd say we're pretty much in a reasonable shape. If you have questions, issues or comments ... feel free to reach out! -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
OpenVPN, OpenSSL and Fedora 26+
Hi, This is actually just a very late heads-up about challenges with OpenVPN in Fedora 26. Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and good step forward. Unfortunately, that gives OpenVPN a real challenge. The OpenSSL v1.1 support is not completed. Patches have been sent to the upstream devel mailing list for review, but only half of them have been processed and applied so far. So, to be able to provide OpenVPN in Fedora 26 it was decided to switch to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have revealed several issues: - mbed TLS 2.3+ does by default not support certificates hashes "older" than SHA1. And RSA keys must be 2048 bits or more. This have been fixed by a couple of additional patches on top of the upstream OpenVPN code base. It supports now RSA keys of 1024 bits or more. In addition for OpenSSL support of the OPENSSL_ENABLE_MD5_VERIFY, a quirk have been added to also enable MD5 support if that environment variable have been set. - mbed TLS build in Fedora lacked PKCS#11 support. This have been resolved. But there are concerns how well this plays along with another dependency OpenVPN have, pkcs11-helper. This is being investigated and tested. Feel free to help out on bz #1432152 if you depend on PKCS#11/Smart Card functionality. Your feedback is valuable! - mbed TLS completely lacks support for PKCS#12 files. Now, there is kind of an alternative by using compat-openssl-10. But that does not play well with pkcs11-helper; which is compiled against OpenSSL v1.1. Currently the plan is to stay with mbed TLS support until PKCS#11 support is fully confirmed working or not working at all. If not working, we can at least move to compat-openssl10 without PKCS#11 support, which enables PKCS#12 support again. If PKCS#11 support works with mbed TLS, then we will stay on mbed TLS for now as I value that support more important than PKCS#12. Once OpenVPN have released a version with full OpenSSL v1.1 support (or at least have all the needed patches reviewed and applied to their upstream git repos), then I will switch back to the default openssl package again. This is far from ideal. But I do consider this the best compromise than not having an OpenVPN package in Fedora 26 at all. For those of you having PKCS#12 files, there is a kind of workaround where you can split up that file into CA, Certificate and Private Key PEM files - which OpenVPN can use directly. $ openssl pkcs12 -nokeys -cacerts -in $PKCS12FILE > ca-cert.pem $ openssl pkcs12 -nokeys -clcerts -in $PKCS12FILE > cert.pem $ openssl pkcs12 -nocerts -nodes -in $PKCS12FILE > private-key.pem If switching from '-nodes' with for example '-aes256' on the last line, the private key will be encrypted and password protected; similar to what your PKCS#12 files may already use today. I am sorry for not having sent this heads-up earlier. I took over package maintenance mid-March, and I've taken this package through a very much needed overhaul to align the packaging with improvements in the upstream packaging. The previous maintainers have done a good job keeping this package alive, but the gap against upstream began to be a bit too big. There are still a few things which needs to be ironed out. But once the mbed TLS/OpenSSL issue and a few other more minor issues gets resolved, I'd say we're pretty much in a reasonable shape. If you have questions, issues or comments ... feel free to reach out! -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Re: /var/log/dnf.log
On 10/09/15 15:31, Reindl Harald wrote: > what in the world is that garbage instead a clear and simple log as > /var/log/yum.log just listing installed, removed and updated packages? > > frankly it's impossible to write worksheets as admin what happened in > the last few weeks with such needless verbose logging Did you take a look at /var/log/dnf.rpm.log? -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /var/log/dnf.log
On 10/09/15 17:46, Reindl Harald wrote: > > Am 10.09.2015 um 17:38 schrieb David Sommerseth: >> On 10/09/15 15:31, Reindl Harald wrote: >>> what in the world is that garbage instead a clear and simple log as >>> /var/log/yum.log just listing installed, removed and updated packages? >>> >>> frankly it's impossible to write worksheets as admin what happened in >>> the last few weeks with such needless verbose logging >> >> Did you take a look at /var/log/dnf.rpm.log? > > no, because i did not assume it's existence Presumptions never reveals the truth. Honestly, it took me 5 seconds to figure out this. This rant takes me minutes. > one example of a not well thought change That's an opinion - without much food for thought. > yum -> dnf > yum.log -> dnf.log > > that would be logical (given that it's still not understandable change > the name) but that new log should be called "dnf.debug.log" and frankly > *not* exist in a enduser *default* install That is how you would solve it. Just bite the bitter apple, that not everybody thinks in the same ways as you do. For me looking for /var/log/dnf* actually made the dnf.rpm.log file the obvious place to look for where rpm operations was involved. But hey, that's me! Life usually moves forward and things evolve - embrace it! Disgruntlement mostly makes just you unhappy. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 28/05/15 23:03, David Smith wrote: On 05/28/2015 10:26 AM, David Sommerseth wrote: ... stuff deleted ... Any thoughts or comments to this approach? Anyone got a better idea? Your process looks reasonable. Thanks! Yes, I do know it is not good to have the keying material for the signing too easily available. So I'm also keen to hear ideas how to protect the key better. With that said, I'm planning on only providing access to the key file to the root user only. And I'll look into if I can restrict the accesss even further with some SELinux rules (so only the ExecStartPre= script can access it together with the preparation script. Systemtap has a similar problem. By definition, we compile kernel modules and still need to work on a secure boot system. To solve it, we automated the process you outlined above and added it to our existing compile server functionality. On a client machine you ask for a systemtap script to run, and behind the scenes the script gets shipped off to a compile server that has a matching kernel devel environment and matching MOKs. The signed module gets shipped back to the client system and run. The advantage we have here is that if you have lots of client systems, none of them have the private MOK key installed on them - only the server has the private key(s). We only pass around public key fingerprints. Right, that sounds like a good approach when you have a compile server. For the mhvtl project, having a compile server isn't really the right solution. Another thought ... Are there other packages who could benefit of such a solution if it was made more generic? I'm willing to investigate into this too, if there are more users out there ... Or if someone has already done that - no need to reinvent the wheel! Systemtap's solution is probably pretty specific to ourselves, but the general idea (and perhaps some code) could certainly be borrowed. Cool! Thanks for the pointer! I'll have a look at systemtap. But really the best solution here is to get the mhvtl kernel module upstream. Agreed, but I'm not sure how keen upstream kernel developers are to carry a driver for virtual tape devices. I've asked mhvtl upstream if that has been considered, but currently I'm not convinced that will happen any time soon. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: Hi, I've started poking into packaging the mhvtl project for Fedora and EPEL. This package also contains a kernel module, which normally works fine - until you hit Secure Boot. So I was wondering how to handle this the best way. AFAIK, there are currently no plans to get the mhvtl.ko kernel module into the upstream kernel. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? [...snip...] My current idea to solve this is to: * Have a preparation script which the admin is required to run on a new system. This scripts generates the needed key material and runs mokutil which installs the key. It will then provide enough information so that the admin can reboot the system and get the MOK key installed. * Have a unit file which runs a ExecStartPre= script. This script will check if the key material exists. If it does, it will check if the mhvtl.ko module for the currently running kernel exists. If the module is missing, it will compile it, sign it and load it. Failures along the way will cause the unit file to fail all together. When the ExecStartPre= script has completed successfully, it will start the needed processes it normally would do. Any thoughts or comments to this approach? Anyone got a better idea? The above approach seems mostly sane. It does seem like a lot of hassle, but it's what is required if you want to leave SB validation enabled. Otherwise, you could have your preparation script disable mokutil validation at the risk of no longer leveraging the SB protections for grub, the kernel, or the kernel modules. Shim is still validated by UEFI itself as SB is still enabled in the firmware. I generally prefer the most strict approaches, I don't want users to feel that a package I introduce may lower the overall security in any way - unless that is the only working alternative. I do see it doesn't makes it easy to implement, but that's how it is. Yes, I do know it is not good to have the keying material for the signing too easily available. So I'm also keen to hear ideas how to protect the key better. With that said, I'm planning on only providing access to the key file to the root user only. And I'll look into if I can restrict the accesss even further with some SELinux rules (so only the ExecStartPre= script can access it together with the preparation script. Another thought ... Are there other packages who could benefit of such a solution if it was made more generic? I'm willing to investigate into this too, if there are more users out there ... Or if someone has already done that - no need to reinvent the wheel! I'm not aware of any. The one place that might be worth looking is rpmfusion, as I would expect they need to do something similar for the kernel module packages they build if they care about running with SB enabled. Thanks! -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
On 29/05/15 14:54, Josh Boyer wrote: On Fri, May 29, 2015 at 8:40 AM, David Sommerseth dav...@redhat.com wrote: On 28/05/15 17:45, Josh Boyer wrote: On Thu, May 28, 2015 at 11:26 AM, David Sommerseth dav...@redhat.com wrote: Hi, I've started poking into packaging the mhvtl project for Fedora and EPEL. This package also contains a kernel module, which normally works fine - until you hit Secure Boot. So I was wondering how to handle this the best way. AFAIK, there are currently no plans to get the mhvtl.ko kernel module into the upstream kernel. Where can I read more information on this project, and why that might be? Duh! I'm so into this I forget to add better project info ... https://sites.google.com/site/linuxvtl2/ Sorry, I should have been more explicit in my question. I found the site by googling of course, but I was curious if you had pointers to reasoning/discussion around why the kernel module won't be pushed upstream. I have asked the mhvtl developer about this, still awaiting an answer. I would generally prefer seeing it upstream kernel, but until then I'd like to have a solution in place as well. It is worth noting that Fedora does not allow packages other than the kernel to ship kernel modules. Oh, I was not aware of that. But compiling a kernel module on-the-fly is acceptable for Fedora? Kinda. Packages that do that exist. We know they exist. We assume the people maintaining them are going to be polite and deal with issues. Fair enough! -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Secure boot and packaging third-party kernel modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/05/15 17:04, Simon Farnsworth wrote: On Friday 29 May 2015 15:24:24 David Sommerseth wrote: On 28/05/15 23:03, David Smith wrote: snip But really the best solution here is to get the mhvtl kernel module upstream. Agreed, but I'm not sure how keen upstream kernel developers are to carry a driver for virtual tape devices. I've asked mhvtl upstream if that has been considered, but currently I'm not convinced that will happen any time soon. As a different route, if upstream are still active, have they considered using LIO's TCMU interface[1]? Combine this with tcm_loop to provide local access to the LIO SCSI targets, and it looks to provide the same featureset as mhvtl's kernel module, using existing kernel infrastructure. Note that I've not dived in deep enough to confirm that LIO is a competent solution here, but it looks like it provides the features mhvtl needs. [1] https://www.kernel.org/doc/Documentation/target/tcmu-design.txt Thanks, Simon! I'll check up on that! I've not yet dug deep enough into how the tape library is fully managed on the lower levels (I'm still learning about how to make use of it). But if this can replace the mhvtl kernel module, that could perhaps simplify some of the work. Very simply explained: mhvtl generates /dev/mhvtl device nodes which is acting like tape robots. And the user space tools mhvtl provides is to link virtual tape drives/robots (via specific device nodes) to files on a file system. Then you can use ordinary tape tools (mt, mtx, backup tools understanding tape drives, etc) to store data in these files ... so the clue here is virtual tapes. If LIO/TCM can provide such support, then this might be a better solution. But thanks a lot for the heads up! - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVogsgACgkQIIWEatLf4Hc9FgCdEqyZ7gf0/sHFtQh2VzP/ujQF cfUAoIn9xKetfbvHAtxOe31l8dZ5g44P =ruwp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Secure boot and packaging third-party kernel modules
Hi, I've started poking into packaging the mhvtl project for Fedora and EPEL. This package also contains a kernel module, which normally works fine - until you hit Secure Boot. So I was wondering how to handle this the best way. AFAIK, there are currently no plans to get the mhvtl.ko kernel module into the upstream kernel. Some packages (VirtualBox, IIRC) can compile the kernel module on-the-fly if it is missing during boot. That's an easy thing to implement. But for secure boot, things gets complicated as the kernel module needs to be signed. I've played with mokutil and the sign-file script which is in kernel-devel, based on this article [1]. This all works fine. I could easily install my own key, compile the mhvtl.ko module and sign it. And then it was possible to load the module. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html It's also important to remember that kernels do get updated. So when a new kernel is installed, it is (to my knowledge) required to recompile the module. If I'm mistaken, please educate me! My current idea to solve this is to: * Have a preparation script which the admin is required to run on a new system. This scripts generates the needed key material and runs mokutil which installs the key. It will then provide enough information so that the admin can reboot the system and get the MOK key installed. * Have a unit file which runs a ExecStartPre= script. This script will check if the key material exists. If it does, it will check if the mhvtl.ko module for the currently running kernel exists. If the module is missing, it will compile it, sign it and load it. Failures along the way will cause the unit file to fail all together. When the ExecStartPre= script has completed successfully, it will start the needed processes it normally would do. Any thoughts or comments to this approach? Anyone got a better idea? Yes, I do know it is not good to have the keying material for the signing too easily available. So I'm also keen to hear ideas how to protect the key better. With that said, I'm planning on only providing access to the key file to the root user only. And I'll look into if I can restrict the accesss even further with some SELinux rules (so only the ExecStartPre= script can access it together with the preparation script. Another thought ... Are there other packages who could benefit of such a solution if it was made more generic? I'm willing to investigate into this too, if there are more users out there ... Or if someone has already done that - no need to reinvent the wheel! -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Including tlp in Fedora Workstation by default
On 28/05/15 12:57, Richard Hughes wrote: On 28 May 2015 at 11:21, Nadim Kobeissi nadim@nadim.computer wrote: 1: My understanding is that tlp ships with a default configuration that, without any modification, will enable reasonable settings for power saving. I think what the kernel is providing is reasonable, from a regression / feature point of view. I agree some of the kconfig options could be modified in a few cases, although this is the pain when we have a single kernel for all the different products. then the Fedora package can modify these defaults accordingly while keeping the things we like and consider safe. Do you think that the average user with a clicking sound card or disk corruption when suspending would be able to make the link to this new package? Even better ... the integrated mouse pointer on my external ThinkPad USB keyboard stops working if USB suspend is enabled for this device. We shouldn't inhibit progressively better Fedora user experience until the kernel is perfect; this would mean years of waiting for regular users. We shouldn't paper over the cracks. I've seen that again and again and it just stops being maintainable after a few years. +1 ... If the kernel isn't perfect, lets make the kernel perfect instead. Just my 2 cents. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On 20/03/14 20:05, Lennart Poettering wrote: On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... Actually they are used quite a bit in various service worlds. Mainly for ssh and email for dealing with scanners. [DenyHosts is a boon in this area.] The reason for using a secondary tool is that depth of security. Well, all mails servers as well as sshd have much better ways to do such filtering. sshd has Match, Postfix for example has smtpd_client_restrictions=, and so on. Again, I have no doubt that some people still use tcpwrappers. But I'd argue that is clearly the excpetion, not the rule, and they'd better use something different, and that we should be creating an excellent distro, instead of a one that features horrible software... Over the years I have found that there are multiple of attacks which will nullify one layer of protection at one point or another. Having a second level or third level of protection is a boon when this happens. Well, it certainly makes sense to combine a firewall with let's say selinux with maybe postfix/ssh acls. Then you already have three layers of protection, of very good protection. But of all possible options tcpwrap is the absolute worst choice. And we should be able to deprecate and remove stuff from our core OS if we think it is crap. I mean, there are two sides of the medal: sure multiple layers of protection might be a good thing, but you also make things a lot more complex with each one, and you involve more possibly exploitable code -- and tcpwrap is simply bad code, that's a fact. So you have to balance things out: is something a layer that is worth the trouble? Or does having it around make things worse? I am of the opinion that tcpwrap indeed does make things worse. I happen to share Stephens concerns. I think tcpwrappers is a good additional security layer. And I honestly don't buy the idea that code which is 11 years old is crap by default. If it has gone 11 years, being widely used by several services (including high-profile services such as SSH), that tells me something about the quality of the *performing* code. New code is better just because it's new. That we have a firewall layer which resides in the application level is a plus. Netfilter/iptables and SELinux are in kernel space, tcpwrapper is in the user-space. Yes, more layers adds complexity. But adding more security layers usually doesn't make any setups less complicated. Managing security properly is a complicated task. I would further like to hear *how* you mean tcpwrappers make things worse. You just state it, you don't provide any arguments supporting it. And comparing code and condoms is just as clever as comparing age and wisdom. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 21:19, Dan Williams wrote: On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 [...snip...] Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. NM only uses bluez via the D-Bus interface, so if you force install bluez4, NM will still work and should even handle the change at runtime. And then you'll get DUN back too :) Clarification: I actually don't mean runtime. NM must be restarted to notice the change from bluez4 - bluez5, but it does not need to be recompiled. The DBus interface with bluez5 have changed too. http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Does NM support both bluez NM APIs? -- kind regards, David SOmmerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 23:59, Dan Williams wrote: On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: Nope, several packages depends on the bluez-5.13-1 package. Indeed. However I could probably live without gnome-bluetooth if blueman were still available. pulseaudio-module-bluetooth though. Would it work with Bluez4? Would it need a compile to do so? I wonder how you make that a functional downgrade that users can select if they still need Bluez4. --- -- Finished Dependency Resolution Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64 (@updates/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. Indeed. I suspect the same. Perhaps gnome-bluetooth could be uninstalled and replace with blueman without too much heartburn. It's the other packages that get troublesome. A pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA? Something similar for NM? It's starting to get ugly and perhaps the effort spent doing that would be better put towards: https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5 But either way, it does seem a pretty serious regression. Although maybe you and me, David, are the only F20 users using HSP bluetooth headsets. :-/ Out of curiosity, what do people use Blueman for? I used it in far earlier versions of Fedora, because gnome-bluetooth was just lacking basic features. I used it to setup GPRS/3G connections using PAN and not rfcomm (as that was the only thing working with my cell phones at that time), browsing files via OBEX over bluetooth plus it gave more informative information on signal strengths of connected devices - useful for some debugging. But as GNOME got far better Bluetooth support (F14 and F19 were quite good, even though file browsing seemed somewhat cripled in F19), I used what was there instead of using blueman additionally. I actually think Cinnamon used blueman in F19 for Bluetooth management, iirc. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 23:16, Chris Murphy wrote: On Jan 23, 2014, at 2:56 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote: As a side note, it also needs to be discussed how such a key feature of the bluetooth stack could go unnoticed through QA, and how to avoid this from happening again. Indeed. I wondered the same myself. As far as I know there isn't an explicit test case or release criteria that covers this functionality, or it would have been discovered. Why it's not a test case is a valid question, but simply put there are only so many QA people, much of it is voluntary so not everything important gets tested. Fair enough. However, in this case it seems this was even noticed. Why that was never looked into more thoroughly is a mystery for me. By all means, software does and needs to evolve, and it can break. I have full understanding for this. But not alerting that basic functionality of things you would expect breaks, that's the key point here. That puts users into a difficult situation, especially when the dependencies are so tricky. Seemingly critical features that shouldn't have major regressions are exactly where testing should be done in advance of release. People who care about such functionality need to alpha and beta test, and review feature proposals that affect things they care about. You don't have to test for a week or month or the whole cycle. But had there been more discovery, and criticism of the loss of features at the right time, then it seems plausible the change would have been pushed back to F21. https://fedoraproject.org/wiki/Changes/Bluez5 I'll admit I noticed the Bluez5 threads on this list, and thought this was fairly straight forward. Packages needed to be adopted to a new API is kind of normal. And I took it for granted that the HSP/HFP functionality would be tested. I cannot understand this functionality is not considered an important feature. I mean, does people only use bluetooth for the A2DP profile? Major functionality should keep working without regressions, compared to BlueZ 4 in Fedora 19. And… If the release blocking desktops have major bluetooth related regressions by the time of the Fedora 20 Beta Change Deadline, then FESCo and the proposal owners may enact a contingency plan to revert the BlueZ 5 related changes and go back to BlueZ 4. This thread is suggesting a major regression, and if that's the case then the contingency should have been employed. But the first red flag for that should have been at the latest prior to beta freeze. During the F20 beta, I was soaked into other work to be able to test this. But knowing we have a Fedora QA group and a plan for rolling things back, I had a trust that the Fedora community wouldn't allow this to happen. But trust me, I will check things far more closely in the coming releases ... unless I simply switch to RHEL instead to have some better predictability. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 24/01/14 08:31, Bastien Nocera wrote: FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20. Can you please shed some more light on this. From what I could grasp out of the freedesktop bug, it was a bluez bug. And PulseAudio says bluez4 is needed to get the handsfree profile working. Anyhow, I'm past this discussion and have started to figure out how to recompile the needed packages. So anything which can simplify this job is appreciated. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 24/01/14 18:30, Dan Williams wrote: On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote: On 23/01/14 21:19, Dan Williams wrote: On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 [...snip...] Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. NM only uses bluez via the D-Bus interface, so if you force install bluez4, NM will still work and should even handle the change at runtime. And then you'll get DUN back too :) Clarification: I actually don't mean runtime. NM must be restarted to notice the change from bluez4 - bluez5, but it does not need to be recompiled. The DBus interface with bluez5 have changed too. http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Does NM support both bluez NM APIs? Correct. It determines which one to use when it starts up, based on what version of bluez is running at that time. Perfect! However, because of a significant change in how DUN works with Bluez5, NetworkManager does not (yet!) support DUN when Bluez5 is running. We are working on that. Thanks a lot! It makes more sense after having poked at this today. I've been doing some local mockbuilds today, and noticed I could enable bluez4 in the NM spec file (it was set to --enable-bluez4=no, afaics), and I seems to produce some nm-bluez4 files. Now I just need to get the proper version built, I built the fedpkg NM master by mistake. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 David Sommerseth dav...@redhat.com wrote: Hi all, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. It's already tracked in this BZ: is just downgrading bluez any help? yum downgrade bluez* --releasever=19 Nope, several packages depends on the bluez-5.13-1 package. --- -- Finished Dependency Resolution Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64 (@updates/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/12 19:42, Brian Wheeler wrote: On 06/01/2012 12:21 PM, Lennart Poettering wrote: I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future... Lennart I understand how memory management works...which is why this seems like a terrible idea. Can you provide numbers that show that there is a speed increase with this scheme which offsets the amount of change required to do this? I haven't seen anything other than its faster. This is change is troublesome for multiple reasons: * It switches the semantics of what /tmp is. Its now apparently for small and short-lived files. Where small and short-lived are defined based on the RAM usage at the time a file is created. Hooray for heisenbugs! * everything that did use /tmp now should use /var/tmp which means patching a ton of programs and hoping that third party applications do the same thing. So the problem this fixes with /tmp now exists in /var/tmp. * there are no numbers which back up the purported benefits * file data gets moved out of RAM (in this case, to swap) not when it is convenient for the kernel at a potentially idle time but when the kernel is experiencing memory pressure. * changing the amount of space available in /tmp means screwing with swap files How is this change a win? I sense a long term strategy ... a) Move /tmp to tmpfs b) all programs using /tmp uses /var/tmp c) all failing programs enforces $TMPDIR to be set to /var/tmp d) Somebody discovers that /tmp is no longer in use - and propose to remove /tmp all in all But we're just at the beginning... Having that said ... I really see some benefits of /tmp on tmpfs, but for large workloads which depends on /tmp or $TMPDIR it will be a pain, no matter what, IMO. And it strikes me as interesting that Solaris have been doing a similar tmpfs approach for years; yet still the thumb-rule seems to be get rid of that ram-fs-stuff and put /tmp on a real drive. And I wonder why A couple of times (several years ago now), I've experienced /tmp being filled up with junk - and at that time /tmp was a part of /. And that caused even more fun challenges. So I started deploying /tmp on a separate LVM logical volume, with a restricted space. Since that time, all systems have been running quite stable - despite /tmp getting filled up from time to time. But that's usually not a problem, as in worst case that misbehaving program just dies. But I'm really curious to see what happens if this happens on a tmpfs based /tmp. If you have 4GB RAM server and a 4GB swap ... and then a program hits the system creating 8-9GB of trash in /tmp ... how will that impact the performance and responsiveness of the overall system? How will applications reading data from these memory pages being swapped out behave (in a performance, point of view) Will OOM killer at some point kick in? And if OOM killer starts, I'm curious which processes it will pick to kill ... I imagine this to be particular funny if you're running something RAM intensive, like something Java based (JBoss anyone?). I've been seeing a tendency for quite some that these new features in Fedora only benefits a smaller restricted set of laptop (and to some degree workstation) configurations ... while Fedora is the base for something far bigger and real servers might have completely different needs. But as they say ... ignorance is a bliss ... Yes, /tmp on tmpfs might make a lot of sense on many laptops/netbooks/ultrabooks, SSD based systems and other places where I/O load and energy consumption is crucial - and especially if you have plenty of RAM. But (spinning) disk space is still fairly cheap, and /tmp on a real disk behaves in a predictable manner - even with misbehaving programs. And RAM is far more expensive per GB than spinning disks. I'm sorry to say, I still haven't really seen any good arguments why this move is a clever idea on *all* installations. Some installations, yes, but default for not all. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+/qkACgkQIIWEatLf4HfORQCfT2fkdb0150xoFYNP6w4h8Bve LPMAn38F/0IJERoTy759UfykGWc406lv =+v6l -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 21:56, Chris Murphy wrote: Performance: dd if=/dev/zero ~56MB/s CPU 10% dd if=/dev/urandom ~12MB/s CPU 99% haveged ~54MB/s CPU 25% The dd relative values are consistent with kernels in Fedora 16. However these tests were done with 3.3.0-1. The questions are: Is the urandom performance expected? That sounds reasonable. Unless I mix /dev/random and /dev/urandom, the latter blocks until it has filled up the entropy pool again. What is the quality of pseudo-random data produced by urandom vs haveged? PolarSSL used havege in v1.0 and below. It used RDTSC as a source for seeding the randomisation. However, it turned out that in some virtualised environment, the RDTSC values was quite easy to predict. I'm not sure if I mix it with another issue, but I believe I remember some reporting it to constantly be seeded with 0. Havege is in otherwords something to play carefully with. If used together with other randomisation sources or on bare metal, it's okay. Kind of interesting, as LWN had an article pointing at this blog post today http://rusty.ozlabs.org/?p=265 ... and yesterday the havege implementation in OpenVPN when using PolarSSL was discussed in the developers meeting. As a side note, OpenVPN decided to deprecate PolarSSL versions below v1.1, thus enforcing DRBG as a replacement for havege, due to the mentioned reasons. (Using OpenSSL, nothing changes btw.) If the qualities are similar, or haveged's is better, is there anything that can be done to improve urandom's performance? It really takes quite a bit longer to prepare a disk/volume for encryption. The reason /dev/urandom is experienced as slow is because it tries to ensure a certain level of randomness. That's also a device provided by the kernel. While havege and other rngd's are probably faster as they can use more sources for entropy generation and prepare bigger entropy pools than what's default in the kernel space. But as mentioned, be careful with havege. It might not be as random as you'd expect. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk915wcACgkQIIWEatLf4HerZQCglA4QOSgRoIR8FwSMBBfR52Su PNgAoKzFupvU2MwuFHty+3cDiUJJPGnv =JN6G -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/03/12 21:01, Przemek Klosowski wrote: On 03/30/2012 01:02 PM, David Sommerseth wrote: That sounds reasonable. Unless I mix /dev/random and /dev/urandom, the latter blocks until it has filled up the entropy pool again. Eh, the FORMER (/dev/random) blocks until it has filled up the entropy pool again. I seem to remember that urandom is a PRNG seeded with data from /dev/random; it never blocks. Right! I too often mix those two. Thanks for the correction. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk92GqEACgkQIIWEatLf4Hc1ewCgxoOLNEvXjKvIw9zr2/UjsrYL UecAn3Ssyfvmo1JTfBA3nVv9cDjv67M5 =qVJL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/07/11 16:24, Miloslav Trmač wrote: On Wed, Jul 27, 2011 at 4:13 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 27.07.11 16:05, Miloslav Trmač (m...@volny.cz) wrote: On Wed, Jul 27, 2011 at 4:01 PM, Lennart Poettering [...snip...] d) there is point in having a standardized dir for this *shrug* Anyone knowledgeable enough to install software in $HOME is able to configure $PATH, and with some probability has strong opinions on where the $prefix should be. Agreed that having standards is great. Unfortunately, it so often seems that everyone wants their own standards. hence: let's just change the xdg basedir spec to standardize it. IMHO the ~/.local/bin place is a mistake, and it's still not too late to stop making this mistake irreversible. I'm torn. I've been using ~/bin for over a decade already, which is probably why I don't like ~/.local/bin. I also don't like the fact that an application can easily install scripts/binaries into a directory I will most likely forget to check - and have this in my path. I do know exactly which files I have in ~/bin - I know so because I placed them there. However, my workaround will most likely be: mv ~/bin/* ~/.local/bin ln -fs ~/.local/bin ~/bin restorecon ~/.local/bin But I'm far from convinced ~/.local/bin is clever. So far I've only seen oh this is nice to have! arguments. I haven't seen anything which brings the strong need to have argument. However, I find ~/.local an odd name. To whom or what is it 'local'? If you have home directories mounted via NFS and log into two different remote hosts via SSH - the only base is local to, is the user. But if you start a program which is installed on server but lacks global libraries on the other server, then this program is suddenly local to a particular server in addition. My point is that local is very ambiguous and its name is poorly chosen. But I realise it's way too late to change ~/.local to anything now. And this leads to why I'd like to see a much broader discussion on the topic about ~/.local/bin, also bringing it outside of Fedora's core. Lets rather move forward with more caution. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xNxkACgkQIIWEatLf4HeK/wCfcM2koOSYuAD5E+OPNzLnjzGM KTgAoIm/+qZPqIQWaVgzN5pfo6v9c1+7 =uNOh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/07/11 15:54, Lennart Poettering wrote: [..snip..] If you don't hide ~/.local and ~/.config then users who are less savvy than us might wonder what thzat stuff is and delete it and nothing will stop them and then all their configuration is lost. If a user lists out (even via Nautilus) hidden files and folders. What would stop that user from seeing .local and then wonder what thzat stuff is and delete it? We cannot stop any users from doing stupid things, no matter what the name of a file or directory is, if it is hidden or not. Sure hidden dirs is more difficult to find for new rookies, but sooner or later people will find such hidden stuff. But they will most likely only delete such a directory once, regret bitterly and never touch it again. We must stop thinking that the users are plain drop-dead-stupid and will never become as clever as you, me or any other claiming to be a computer guru. Users can be taught to do things the right way. Sometimes through experience, sometimes by others telling them what to do or not to do, other times we can have software popping up an alert saying: What you're about to do now is most likely crazy, silly and stupid. Are you sure you really want to do this? You might regret bitterly if you proceed! Just like what Firefox has done with the about:config warning. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xO5EACgkQIIWEatLf4HctOwCghw0BfvSnyWDefyg8I65TTnTP 2aoAn3ekLsoFaCTgk3CzNM89M1xydaM7 =Bj6j -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/07/11 17:40, Roman Rakus wrote: Hi all, from the discussion here, I'm tempted to revert the change. Any objections? +1 ... at least the there is some common consensus, also across distributions. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xPNQACgkQIIWEatLf4Hfr3wCfVybYeo7M7eGXWrDqPnceiY4W h8kAnj4zOUQ5egtXmA6KOYGOU5z4vgcu =swRS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/07/11 15:46, Genes MailLists wrote:
On 07/28/2011 09:09 AM, Bryn M. Reeves wrote:
On 07/28/2011 01:41 PM, Genes MailLists wrote:
On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
On 07/28/2011 12:46 PM, Genes MailLists wrote:
This is a good point. Especially when you start on a 64 bit box and
login to a 32 bit (or other arch) - bin now makes now sense at all. You
need arch specific bins (bin, bin64 etc).
Currently Fedora only separates out the /lib* directories in multilib
installations - you'll find a mix of 32 and 64 bit binaries in the system
binary
paths on these systems.
which is fine for a 'system' which is 64 bit and may support 32 bit as
well - its not fine for a 'user' who logs in to a 32 bit machine from a
64 bit machine and now his binaries wont work.
Separating bin paths like this would not solve the problem; anything that's
only
present in one path or the other would still fail in the scenario you
suggest.
You could equally install foo/foo64 or vice versa into the same directory.
I don't follow your thought here - if you have a bin64/ and a bin/
etc and you have your shell initscripts decide (e.g. using uname -m)
which of those to include in your PATH I think it does work ... provided
you have (obviously) both (all) populated with whats needed...
But that is still going to be a convoluted mess. For those poor users who
then have access to arm, ia32, ppc64, s390x and x86_64, you suddenly need 5
different ~/.local/bin directories ... And I've probably forgotten some arches.
~/.local/bin (or even ~/bin for that matter) as default in $PATH is going
to be a mess, no matter how you twist it. Because of the architecture
issues. For scripts it will of course work fine in most cases, but in the
moment programs begins to get installed in ~/.local/bin (or ~/bin), then
we're definitely on the wrong track.
Binaries are related to the hardware it's running on, and should not be
related to $HOME at all. In my opinion, $HOME must be arch agnostic.
I begin to fear that not being stricter on the pure original purpose of the
directory separation from the original Unix days is going to bite us hard
soon. /home is for *user data*, and not binaries to start with. Advanced
users understands this, and understands what will happen when their
binaries are attempted started on a different arch via NFS mounts. They
most likely also know what they're doing when creating ~/bin or similar
directories and updating their .*shrc. Average user John Doe, doesn't
really need know this, and shouldn't really be bothered to care about
binaries in his $HOME directory.
So often the road to hell is paved with good intentions. To have
~{/.local,}/bin in default $PATH is indeed a good intention at first
glance. However, it might not be the best solution for everybody.
kind regards,
David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4xj/oACgkQIIWEatLf4Hem+QCgqEuDYWw2G+BMxNYuFxHoRnY7
6SUAn33zcXqwudsrVJEv4iQu0vQ0Kurm
=B1HH
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
