Re: google-re2 pacakge update and facebook vs google python bindings ?
On Mon, 4 Mar 2024, Fabio Valentini wrote: Since this update was stuck and obviously broken, with no response from Paul in over a week (either here or on the bodhi update), I've used my provenpackager rights to revert the commits in dist-git and unpush the stuck update (it failed gating tests, so it never made it to rawhide repos). This should prevent the broken update from accidentally getting pushed to Rawhide again, and it gives an opportunity to re-do the conversion to rpmautospec correctly (i.e. "rpmautospec convert" to preserve the old changelog) if that is desirable. Thanks and sorry for dropping the ball. Last week there were issues getting the sidetag and this week it got lost in IETF deadline work. I'll try to pick this up ASAP via the sidetag. Paul -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: google-re2 pacakge update and facebook vs google python bindings ?
On Wed, 7 Feb 2024, Ben Beasley wrote: Subject: Re: google-re2 pacakge update and facebook vs google python bindings I haven't heard back from any of the maintainers. I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the first step towards getting python-google-re2 working. https://src.fedoraproject.org/rpms/re2/pull-request/6 Paul -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
google-re2 pacakge update and facebook vs google python bindings ?
Hi, At $dayjob we are running into issues with re2 and python bindings. Fedora has a fairly old version of re2 with so.9 while upstream is at so.11. Is there a reason for this? If it is just time, I'd like to help bumping the package in rawhide. Originally, facebook creating python bindings for this, which are packaged in python-fb-re2, but this package is no longer updated as google're2 now has native python bindings (I think the fb one was pulled in and maintained and so the fb one is abandoned upsteam) I'd like to see: - google-re2 updated to version 2024-02-04 - python3-google-re2 python bindings shipped, providing the fb-re2 package. - python2-fb-re2 retired Currently, the google-re2 python bindings do not compile against the older google-re2 we ship (but that might be a fairly trivial fix, that would need to be done for the branches anyway) Added package maintainers to the CC: for additional input. Again, happy to help if time/effort is the only thing holding this back. If there are other reasons for this, I'd very much like to know more. I know there were soname issues in the past. Packages that would be affected by the soname bump: loaty dnsdist frr grpc libarrow mtxclient onnxruntime perl-re-engine-RE2 python3-fb-re2 python3-grpcio python3-onnxruntime qt5-qtwebengine syslog-ng syslog-ng-opentelemetry Thanks, Paul -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
proposal to orphan tcpcrypt
Hi, After talking to the debian maintainer of tcpcrypt, we both decided the best thing is to remove tcpcrypt from the distributions. - The protocol at the IETF seems have stalled for many years - The main proponent and implementer sadly passed away years ago - The website tcpcrypt.org has died a while ago - The package interferes badly with firewalling tools If anyone is really objecting, please let me know and be prepared to become the maintainer in that case. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packager check for F38
On Wed, 15 Feb 2023, Ben Cotton wrote: For the curious, here are the stats from today's run: ### Found 2129 users in the packager group. ### ### Found 914 users with no activity in pagure/src.fp.org over the last year. ### ### Found 845 users which also show no activity in Bodhi over the last year. ### How many packages depend _only_ on people from this list? Eg are likely to be unmaintained ? Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: OpenSSL update
On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote: I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. I will also push to f38 and rawhide later today. Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done in the reverse order? In fact all the updates landed simultaneously. Ahh okay, no worries then :) Thanks for the updates! Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: OpenSSL update
On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote: I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. I will also push to f38 and rawhide later today. Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done in the reverse order? This is a security release, it fixes 8 MODERATE CVEs (https://www.openssl.org/news/secadv/20230207.txt) I kindly ask you to test the version so it could be rolled up earlier. I really would hope that testing happens in rawhide before it is pushed into f36/f37 :( Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F36 to F37
On Mon, 12 Sep 2022, Miroslav Suchý wrote: Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run: In case you hit dependency issues, please report it against the appropriate package. Seemed fine. I saw two issues related to python azure packages but since I maintain some that might be self inflected. will double check though on a stock install. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
On Fri, 2 Sep 2022, Neal H. Walfield wrote: Note: Sequoia currently uses Nettle on Fedora, but there is ongoing work to port it to Sequoia to OpenSSL: I think this should be considered a blocker for changing gpg backends. https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 Note2: There are lots of reasons to use Sequoia, but one user-visible reason is improved usability. When a user imports a certificate, Sequoia lints it and displays potential issues, or reasons why it can't be imported: https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 $ rpm --import peter-expired-backsig.pgp Certificate 251C20A67D942D45: Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z Certificate does not have any usable signing keys Whereas before rpm would just say: error: peter-expired-backsig.pgp: key 1 import failed. That seems like a fairly minor point to change backends and crypto library for and could be something that can be fixed in the current backend as well? Of course if upstream rpm is moving, I think fedora should do so as well to keep in line with upstream, but to me that really does imply not using nettle but using openssl. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: percona-xtrabackup bundling the kitchen sink in static libs
On Tue, 23 Aug 2022, Otto Liljalaakso wrote: The relevant policy is Bundled software policy [1]. Unlike in the past, a package does not need a FESCo exception to bundle dependencies. However, the requirements of that policy are not being met here: The reason for bundling should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should be included. [1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ Thanks for the link. Sadly, the justification would be "because upstream hardcoded this an errors on any other version", which in itself is pretty weak. And since it includes boost, which can't easilly be upgraded between fedora releases, all the older stuff lingers forever. If the maintainer is not responding, you should invoke the Non-responsive maintainer policy [2]. This package has CVE bugs open [3], so most probably it should eith be retired, or somebody should start caring for it. Miro started the non-responsive maintainer process and woke up the maintainer, but they themselves are also thinking it might be better to kick it out of fedora. https://bugzilla.redhat.com/show_bug.cgi?id=1989019 Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
percona-xtrabackup bundling the kitchen sink in static libs
Hi, I looked at fixing percona-xtrabackup and noticed it is staticly linking to a bunch of libraries. These .a files are then removed in %install so they are not shipped. It bundles a bunch of this stuff from its extra/ dir: duktape googletest icu libcbor libedit libevent libfido2 libkmip lz4 protobuf rapidjson robin-hood-hashing zlib zstd On top of that, it pins boost to a specific (older!) version and bundles boost seperate via dist-git / sources :( I've just fixed it up in the same bad way, making it link to the old openssl just to get it past F35FailsToInstall for rhbz#1989019. It is going through rawhide and the branches now. But I think perhaps this package should be removed from rawhide. This package clearly breaks a lot of packaging rules, so I was wondering if there was ever any exception of some kind given to this package? I will definitely look at $dayjob migrating away from this, eg see if myhoard or mariabackup can be used instead. Any feedback would be appreciated, as it seems the maintainer is MIA. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
dnf makecache memory usage increase
Looks like dnf makecache is uses a lot more memory, causing issues on smaller systems/containers. F34: Metadata cache created. 1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata 162440maxresident)k 144inputs+56outputs (0major+46906minor)pagefaults 0swaps F35: Metadata cache created. 29.28user 2.15system 0:49.94elapsed 62%CPU (0avgtext+0avgdata 841704maxresident)k 184160inputs+497320outputs (181major+425900minor)pagefaults 0swaps Is this a known issue? Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.
On Fri, 8 Jul 2022, Kevin Kofler via devel wrote: But upstream is now under a hostile corporation's control? Can we trust the most privileged userspace program when it is effectively controlled by a hostile corporation? Yes we can, by reading and evaluating the code like we always do. If it starts to deviate from our needs and requirements, we can change things. If Fedora was too depending on one person, this change would be good as in that case we should have diversified these things already before and now we would be forced to do so if that is problem. Lennart might not be the easiest person to work with, and I have had my personal disagreements with him, but he has never been a malicious person and I don't expect him to suddenly become one. I wish him luck on his new adventures. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Self Introduction: Roman Inflianskas
On Tue, 26 Oct 2021, Roman Inflianskas via devel wrote: Subject: Self Introduction: Roman Inflianskas Dear Fedora Community,My name is Roman Inflianskas.I work at aiven.io (DBaaS based on Open-Source technologies) as a Python Backend Developer, and my motivation for becoming a Fedora maintainer is to package software that is used by Aiven so that my effort had more impact. I contributed to SaltStack, KDE, Taskwarrior, aiogram, Vim plugins, LaTeX/LyX style of Russian standard for research work; packaged some software for openSUSE for myself, etc. My personal website is http://roman.inflianskas.ru. In spare time I like to walk in a beautiful Central Park of Helsinki.I've prepared `python-cs` and `python-requests-exoscale-auth` on my PC. Here is the first ticket: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2017419The person, who recommended people in our company to become Fedora maintainers is Paul Wouters. I'm grateful to him for this.Best Regards, Roman Welcome Roman! I'm happy to see more Aiven people join our Fedora efforts :) Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Mon, 12 Jul 2021, Simo Sorce wrote: SQLite is a general-purpose tool. Not every use of SHA-1 is cryptographically relevant. Most uses in the context of SQLite probably aren't, so the removal just annoys users for no good reason. Note that this is a Sqlite decision, from RHEL engineering we only requested the removal in digital signatures and where integrity protection is required for security. Also note that we do not require full removal, just that SHA-1 is not used unless users intentionally change configuration. How does this affect users of NSS who have created "default" databases, eg using certutil -N ? Do these use SHA1? If so, can they be migrated to SHA2? Automatically ? Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)
On Mon, 28 Jun 2021, Ben Cotton wrote: https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec == Detailed Description == OpenDNSSec changed the default behavior to not include SHA1 DS by default, and added the -sha1 knob as an immediately-deprecated compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By default ‘ods-enforcer key export –ds’ included the SHA1 version of the DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS use the –sha1 flag. This flag is immediately deprecated and will be removed from future versions of OpenDNSSEC." (see ChangeLog: https://www.opendnssec.org/archive/releases/ ). The proposal is to disable the -sha1 knob in Fedora. I will also open an issue upstream to remove all the sha1-related code. This change makes me a bit nervous, and I'm the author of RFC 8624 that recommennds not using SHA-1 for DS/CDS records anymore. https://datatracker.ietf.org/doc/html/rfc8624#section-3.3 Supporting statement [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en [from ICANN] (2020-1-24): "Now is the time for administrators of zones at all levels of the DNS to stop using SHA-1 and change to algorithms using stronger hashes." While this is true, the order of where things need to change are: 1 Discourage, but not block, the use of SHA-1. Eg remove it from the default set. 2 Ensure the migration of SHA-1 based records to SHA-256 is taking place 3 remove support for SHA-1 This plan assumes we are in phase3. I would say we are in phase2. Remember, any domain that depends on SHA-1 is going to be more secure than being marked as insecure because SHA-1 is rejected. This is somewhat different from like SHA-1 support for authentication where the rejection of a weaker algorithm forces the use of a stronger algorithm. The DNSSEC fallback when an algorithm is not supported is to go insecure, not insist on a more secure SHA-2 that is not there. With DNSSEC, there is not client-server exchange like with TLS or IPsec. There is a producer on one end, and a consumer on the other end. The two do not negotiate crypto parameters. == Benefit to Fedora == * This change makes sure OpenDNSSec in Fedora follows ICANN's guidelines and does not propose SHA1 DS. This is is needed given the [https://sha-mbles.github.io/ latest attacks against SHA-1]. More in-depth articles are available [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/ I know that a few people believe that shambles can in theory be abused with DNSSEC, but a lot of people also believe the constrains of DNS RRsets make this impossible. But even _if_ it is possible, it would only affect multiple domains that share the same private key that made the SHA-1 signature. And then we are talking about RRSIG records and not, as in this proposal, the DS/CDS RDATA content. Patch the enforcer so that bsha1 is not honored anymore: I don't think fedora should move faster than upstream opendnssec. I believe the people at the IETF and the software developers of the DNS software are more aware of where we are in the migration path than individual Fedora developers. == Upgrade/compatibility impact == Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone. The RRSIG signature is not related to the DS signature. Zone resigning is something completely different from the DS/CDS records. Those records are signed by the parent zone, and use whatever algorithm the parent zone uses, which the child zone cannot dictate. This change might break (very old) clients that only recognize SHA-1 but these should already be broken (on the Internet at least) because the root zone is signed with SHA-256 only. The root zone has no DS record, so this statement does not make sense. The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata that contains a hash of the child's public key, where the hash is created with SHA-1 or SHA-2. == User Experience == OpenDNSSec in Fedora can currently be used to sign zones with SHA1. With this change, this will no longer be possible. The migration from SHA1 is underway anyway. So there are two things that really need to be clarified for this proposal. Is it talking about DS/CDS signature algorithm as per IANA registry http://www.iana.org/assignments/ds-rr-types, or are we talking about DNSKEY signature algorithm, that is responsble for signing all the zone data, that uses a hash algorithm or SHA-1 or better. Based on the description, I am a bit worried that it is not entirely clear what the proposed change actually is. Please feel free to reach out to me directly to talk about this feature request. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedora
Re: Offering strongswan for (co)maintaining
On Wed, 31 Mar 2021, Petr Menšík wrote: strongswan and NetworkManager-strongswan packages were passed to me from previous maintainer. I admit I have little experience with them and do not run any service based on them. Because IPSsec is quite complex technology, I am looking for help with its maintenance. I was always using OpenVPN based solutions myself, so I guess I am not the best person as main admin. I would like to transfer main admin to anyone doing a good job, not not immediately. That is why I haven't orphaned it already. I would like to keep commit access for a while, but I would share at least commit access with anyone willing to improve those packages. Especially someone using they (almost) everyday would be ideal maintainer. I have been maintaining strongswan for the last couple of years now. I use it regularly at upstream libreswan to run interop testing. I am actively maintaing strongswan for this. I am also an admin on this package. Pavel is also an admin but he has not worked on the package in many years. But orphaning seems a bit dramatic when there is an active maintainer ? :) As for NetworkManager-strongswan, I am not an actie user of this, but I could just pick it up for the community. I see it is two versions behind, so I'll go and update it. For some reason, src.fp.org does not want to show me this package, so I cannot see who else has admin/commit rights (or request admin/commit for it) Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Wed, 24 Feb 2021, Colin Walters wrote: It's trickier than that because local caching nameservers can provide real benefits in various server scenarios, and also the IoT/edge case (as usual) blurs the traditional datacenter/mobile boundary. (IoT can be servers with WiFi) We ended up enabling resolved in FCOS, although it took a bit because it broke OpenShift, see: https://github.com/openshift/okd-machine-os/pull/15 https://github.com/openshift/machine-config-operator/pull/2377 https://github.com/openshift/okd-machine-os/pull/47 etc. It's hard to read through those. It's a big nest of issues, fixes and reverts on adding/removing systemd-resolved. I couldn't figure out the DNS setup based on these reports. (It's really complex for OpenShift because we have a split between the host DNS and pod DNS which is served by CoreDNS, yet some cases span those, plus some on-premise installs differ from cloud/Iaas in this) I'm confused here too, since AFAIK NM does not support tying queries for certain domains to certain nameservers, and I was told that NM configures DNS, not systemd-resolved, so how is that done in this case then? For VPN, to support split-DNS you ran a full resolver like unbound that has this support, and does not get configured through NM. I guess I can't say more unless someone can point me to some documentation on the DNS deployment details there. However, this all changes nothing that different systems want to use different DNS solutions, and making systemd-resolved part of the init package so it is mandatory to install is not appropriate. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 23 Feb 2021, Lennart Poettering wrote: And yeah, call me a hypocrite, but if I have the choice between having no Internet at all or using some public DNS servers for DNS, and leaking a tiny bit of information to those DNS server providers then I am definitely preferring to have Internet, thank you very much. In practise, this is not often the case. Almost always, the network will provide working DNS via DHCP. If not, then the network is severely broken and hacking up a DNS workaround is likely to fail anyway. Like, you can't get past hotspot/captive portal. Newly installed and booted server/cloud images should _really_ use the DHCP obtained DNS servers. It is very likely their correct functioning depends on local DNS zones and local resources pointed to by DNS not available when bypassing the local DNS for public DNS services. It is also likely that those networks even restrict DNS to only allow their own DNS servers to be used for security and compliance reasons, and using public DNS would be a violation of network policy. The scenario of roaming laptops/phones is completely different from this. Which is why I have argued for a long time now that systemd-resolved should not be installed by default on servers or containers. It adds complexity without any real gain in these deployments and makes DNS issues harder to troubleshoot. One could even go further: the privacy level using those public DNS servers might actually be higher than using the DHCP-provided ones in many cases, simple because we can use DoT on the former (admittedly not yet the default in resolved though, but hopefully soon), but almost never can on the latter, and what's worse the latter are usually provided by crappy edge networks like Internet Cafés and such where the fact we send stuff unencrypted is just awful. I agree with this, but the caveat here is that the solution should take into account isolating the hotspot/signon network from the OS, and not mix that into your caches when you later bring up more private/trustworthy DNS servers. But as I said, I'm fine with the default of systemd-resolved here, although I would strongly prefer to be able to not install or remove the package for advanced users like me with specific DNS and DNSSEC requirements that cannot have systemd-resolved interfering with the system. Now, Fedora made its choice here, and I'll accept that, but I still think it's a bad one, that trades a misunderstood concept of privacy against a major step forward in userfriendliness. i.e. I am not sure it's a good choice to limit Fedora's userspace needlessly to people who can fix their DNS configuration. It's a pretty tiny elite group of people to be in after all... It seems to have a price of network administrators having their DNS broken in a string of different ways resulting in filed bugs at systemd upstream that takes years to get addressed. It can be argued that this price is too high for the feature of helping nontechnical laptop users that stumbled into a broken network. Meanwhile, applications like firefox are absorbing DNS anyway, adding another layer in the fight over who gets to configure and process DNS: DHCP, systemd-resolved, NetworkManager, Gnome, or applications. (Oh, and I don't appreciate those people at all, who claim that "resolved sends all DNS lookups" to Google because it's a lie, we never did that, we only did that in case no better DNS configuration was available, i.e. as *last* *resort*, one step before giving up entirely). This seems contradicting? The last resort method only sends all DNS queries to google as a last resort? It still means that in 100% of the cases that the last resort is activated, it sends all traffic to google? Furthermore, since it hides that this is happening, once the network is broken, it never gets fixed, and thus leads to the fallback always kicking in. If anything, these recurring discussions, and long turnover of systemd-resolverd bugs show that systemd-resolved should be a choice and not being pushed as mandatory. And I am fine with saying that for Workstation or Desktop installs, we lean to the side of userfriendly and give them systemd-resolved. But it has no place as a default binary or service on servers, containers or cloud images launched within actively managed networks. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: [dns-sig] Re: split-DNS, resolvconf on Fedora
On Mon, 22 Feb 2021, Petr Menšík wrote: Wouldn't it be much simpler, if I could just dnf remove systemd-resolved in case I don't want it? In the past I also mentioned this. The overwhelming majority of installs do not gain any benefit from te systemd-resolved service. Most servers, containers and even workstations are installed and given DNS configurations via DHCP, manager by a network administrator. systemd-resolved addresses a problem with finding printers and resolving a .box domain for router reconfiguration. And it provides partial solutions for split-DNS views when VPN's are deployed on laptops. There is no technical reason why this is not in its own package. There has been some focussing on reducing minimal installs, and this is a prime candidate for that. I'm fine with the workstation or desktop installs bringing this package in by default. But I see only potential harm from installing it on servers, containers and most virtual machines. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: f33: systemd-resolved hang on ip query
On Wed, 9 Dec 2020, Dridi Boukelmoune wrote: So it looks like my initial intuition that there could be a mitigation of sorts is starting to hold water. The problem now is that clients on my system using getaddrinfo in a way that was legit until now are now being DoS'd by systemd-resolved, waiting forever for a reply that is not coming. This again leads to a required architecture change. We really need to have a captive portal namespace, that handles all of this while the applications still consider the network is down. Once the captive portal has passed and our internet link is "clean", should this be bridged into the regular network namespace so applications see the network as "active". Any state of DNS/browser that was used inside the captive portal namespace is then destroyed (it is untrusted and unverifiable data) That is, only the cpative portal handling code sees these bogus DNS messages, and no regular applications see this. This would also avoid any applications from throwing SSL certificate errors because they are connecting to the network too quickly when the network is still being in captive mode, and your SSL cert is replaced with the portal SSL cert. Pidgin is specificaly bad with this, firefox has builtin logic to prevent all its tabs from reloading in captive portal page clones. Instead, we have gnome, NM, systemd-resolved, firefox et all fighting over who and how to handle captive portal authentication. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-resolved in a container
On Wed, 18 Nov 2020, Alexander Bokovoy wrote: Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. What is the advantage of running systemd-resolved in a container? Is that container doing mDNS or LLMNR or a split-dns VPN ? The whole point of containers is isolation and minimal setups. Pulling in Base OS components into each container seems a waste of resources? Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Deprecating SCP
On Mon, 2 Nov 2020, Jakub Jelen wrote: Some months ago, I wrote a patch [2] for scp to use SFTP internally (with possibility to change it back using -M scp) and ran it through some successful testing. The general feedback from upstream was also quite positive so I would like to hear also opinions from our users. I am looking for any kind of feedback from the idea through the usability, implementation. Is this something you would like to see in Fedora soon? Do you have something against this? Is your use case missing? This is excellent! Indeed, most users don't care about the underlying SSH protocol flavour other than expecting it to be secure. They just want "scp" to work. Your solution does both. It is a very good example of listening to what users want and supported users without requiring them to learn a new command like sftp. I wish more developers had this focus! I will try it out over the next few days. My personal usecases would be that it still keeps working with rsync's method of invoking scp and that we would have sftp enable by default for sshd by default. Thanks! Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Thu, 8 Oct 2020, Michael Catanzaro wrote: On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote: I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. Well it's too late, since we are now in final freeze. FESCo reaffirmed the systemd-resolved change just last week I was not aware of this. I've left a comment in the FESCO issue. It is unfortunately that the issue provides no information why FESCO made this decision, other than vote tally about why it rejected it. I would appreciate it if FESCO would clarify their argumentation for this decision. Clearly it is very disappointing to me that we are accepting such a security and standards compliance degradation, especially without a plan to address that for f34. , so it's clearly not going to be postponed. I agree that this DNSSEC problem with systemd-resolved is unfortunate, and I'm sure the systemd developers would appreciate help fixing it. This assumes the issues reported are seen as bugs and not features by the systemd developers. I have no seen such agreement on the security and privacy issues I have reported. Anyway, the best time to deal with this would have been six months ago, when the change was proposed This was reported 5 years ago in a physical meeting. Scolding me now for not reporting this 6 months ago is not a proper justification, and in fact sounds more like victim blaming. Here is my counter proposal for this f34 feature. It is clearly now 6 months in advance of f34 that some of us reported a number of systemd-resolved related problems. Let's get these fixed before adding new systemd-resolved features in f34. That is, it is far more appropriate to have a f34 feature of "fix security and RFC standards comforming bugs in systemd-resolved" than it is to just add more new features without addressing the previous feature that has significant security bugs. Even if the main goal of such a feature is to force the systemd-resolved developers to focus on a security and privacy commitment before adding new features. That's why we did this in two parts. F33: systemd-resolved. F34: DoT. We could have done them both at once. It looks like the f33 feature did not get done properly at once, so I am glad we did not do both features as once. If we do this feature for f34 while there were serious issues reporting in the f33 feature, then basically we would _still_ be doing these two features at the same time. So in your own words, you are agreeing with me that the f33 feature should be cleaned up before doing this f34 scheduled feature. So yes, put this feature in f35 and create a f34 feature to cleanup the f33 feature. That would show that the issues we have been reported are taken seriously and address my concern that moving forward with this feature will cause my issues to never get addressed. Second, we really need any DNS-over-TLS to not break DNSSEC. If we are going to outsource validation to a remote endpoint via DNS-over-TLS, instead of using the local resolver or the local ISP resolver, then data authenticity becomes eveb more important. And DNS-over-TLS only provides transport security, not data origin authenticity. Look, I really don't understand, sorry. How is this in any way related to DNSSEC? I think this has zero relation to DNSSEC. The main use case of DNS-over-TLS is to bypass untrustworthy DNS, which often means the local DHCP provided DNS of the coffeeshop/hotel. The importance of doing DNS-over-TLS to your local ISP is pretty minor compare to the security and privacy conerns raised of the current systemd-resolved implementation and default configuration. What Fedora needs is for the DNS resolution to re-stabilize, and to not add more features while there are several security issues at play. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Thu, 8 Oct 2020, Petr Menšík wrote: I would like to request pausing any new systemd-resolved features system-wide, until its current bugs and deficiencies are resolved sufficiently. I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. I am still trying to use this setup on my f33 with DNSSEC enabled for systemd-resolved, and do still seem to have issues that I'm going through to see if these are related to DNS or not. I feel we should have this working solidly first, before we are adding more options and features into the mix. Second, we really need any DNS-over-TLS to not break DNSSEC. If we are going to outsource validation to a remote endpoint via DNS-over-TLS, instead of using the local resolver or the local ISP resolver, then data authenticity becomes eveb more important. And DNS-over-TLS only provides transport security, not data origin authenticity. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F33 upgrade: dnssec-trigger and Strong Crypto Settings, phase 2
On Wed, 7 Oct 2020, Dominik 'Rathann' Mierzejewski wrote: Today, I upgraded one of my machines to F33. Upon first F33 boot I noticed that the dnssec-triggerd service failed to start. It turns out I had very old dnssec-trigger keys and certificates ("only" 1536-bit RSA) generated back in 2014 which no longer passed as acceptable per the default crypto policy change [1], which requires at least 2048-bit keys. The work-around is to move away or delete the existing keys and certificates in /etc/dnssec-trigger and let dnssec-triggerd-keygen.service generate new ones. After that, the dnssec-triggerd.service starts successfully. I filed a bug[2] against dnssec-trigger. Can dnssec-trigger not work now via a unix domain socket instead of TLS for its command channel? I know NLnetlabs added that for its other servers like unbound and nsd that only supported TLS before. The man page suggests it does not support this yet, but I'm pretty sure upsteam would accept a patch. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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:??^M^J systemd-resolved
On Fri, 2 Oct 2020, Michael Catanzaro wrote: Hm, thanks for the explanation. I guess the DNS request would indeed be the *first* way you lose, because you have to do DNS before you do anything else. But you are going to lose immediately after anyway: * Immediately after you connect to the network, Fedora connects to http://fedoraproject.org/static/hotspot.txt to see if you're behind a captive portal * Next, GNOME Software starts checking for updates in the background. You've leaked "personal data" to fedoraproject.org again, and also fwupd. If the locally configured DNS server supports Query Minimalization as per RFC 7816, at this point you would have only revealed "." or ".org" If it further supports DNS-over-TLS, and more TLDs will start to support this, then nothing would be leaked. The world is steadilly moving towards this. Add encrypted SNI, and you see this improves even more. That is why governments are actually afraid of the opposite of GDPR right now. The fear of missing out of seeing DNS/SNI data. * You open Firefox, it downloads Safe Browsing data from Google. (Admittedly this one is probably only behind a European CDN, but maybe Google is having a bad day, or maybe IP address logs are sent to the US.) This argument is that any browsing is a GDPR violation of every browser and OS. It is not a helpfull discussion, and if worth discussing, it should be discussed by laywers, not software engineers. I'm sure my list is missing quite a lot. If your interpretation is correct, then I suppose German companies should immediately discontinue use of Fedora, and also most other computer operating systems The goal should always be to do the least amount of personal information gathering or leaking. Stating "but it leaks over there too" is not a very strong argument to leak data yourself. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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:^M^J systemd-resolved
On Thu, 1 Oct 2020, Michael Catanzaro wrote: We are not going to patch out fallback to Cloudflare or Google because it is a non-issue. Fallback only happens when you have zero other DNS servers configured. When was the last time you connected to a network and there's no DHCP, no nothing? The number of users without some other working DNS is probably under 0.1%. DNS discovery is currrently a hot topic at the IETF and there are various proposals circulating on how a client should behave to find its best DNS resolver. Please see the ADD and DPRIVE working groups and their documents. I posted a few direct links in the last few days already. I think a mechanism that has been architectured by a wider group of engineers from a large number of different backgrounds and use cases would be a more appropriate venue to address this complex policy issue. Personally, I prefer to prompt the user for permission before deciding to send their personal data to (mostly US based) entities. And while the majorit of desktop users _might_ be okay with this implicit decision, it is always better to confirm that explicitely. You might think that UI is as bad as the COOKIE popups we now get, but lawyers disagree with us - whether we like or not that is a universe we live in. Fruthermore it seems the servers running this will almost always never want this to happen, as most enterprises these days, especially in light of TLS 1.3 and encrypted SNI, are more and more reliant on using the DNS stream as an active firewall. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Thu, 1 Oct 2020, Neal Gompa wrote: Essentially, split-horizon DNS setups on Fedora systems become possible with this change. As reported by libreswan and openvpn developers already in the last two days, these are already possible without systemd-resolved and people have relied on that for years. We have also seen reports like one where servers in an Active Directory domain with systemd-resolved have broken DNS due to load issues. Clearly, there is a case for making systemd-resolved "default with an option to opt-out". It makes no sense that these deployments must install and ensure to then disable and keep disabled, the systemd-resolved daemon. The argument against this so far has been "it makes things more complicated". I have asked for specific details on this so we can talk about potentially addressing those complications and make everybody happy. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Neal Gompa wrote: since it's only a couple of binaries averaging 2MB with a few unit files. My reply was aimed at Peter saying he'd like to not ship resolved, and I'm saying that we should *not* do that, because it makes things even harder and more complicated. These two statements cannot both we true. And as I indicated earlier, most server installs have no use for systemd-resolved. Yes it can be disabled, but we didn't go all the way to virtual servers and containers to have to install things we will never use. So I would like to know more about how this would "make things even harder and more complicated". The ask I have is very small. When I install a server via kickstart, I want to be able to do a minimum install, and that it should be possible that this does not include systemd-resolved". I have explained my use case, and I believe it is _very_ common use case. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: the systemd package is getting a systemd-networkd subpackage split out that will contain systemd-networkd, networkctl, and the associated data files. This was requested by coreos maintainers: NetworkManager is used and skipping systemd-networkd allows the installation footprint and potential user confusion to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) The main systemd systemd package Obsoletes the -standalone- packages, so it should smoothly replace them whenever it is pulled in. In which package will systemd-resolved be? With enterprise server deployments, DNS will be managed by the network via resolve.conf to enterprise DNS servers. These servers tend to have "bind views" for different category of deployments. These deployments will have no VPN, no mDNS requirements etc. They also do not need (and most likely do not want) DNS caching. I believe it would be useful for kickstart installs to not install systemd-resolved for these kind of typical server deployments. I think this is an important use case to support. For Desktop systems, it could default to installing systemd-resolved. It could even default to it for all installs including Server, as long as the administrator has the option to not install it via a kickstart file. It also allows those Destop users that want to use their own validating resolvers on the end node to uninstall systemd-resolved. If there are strong reasons not to split systemd-resolved in its own package, I would like to better understand these reasons. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tue, 29 Sep 2020, Lennart Poettering wrote: "Custom" is in the eye of the beholder. It appears to me you mean that in a derogatory way. I went out of my way to compare the systemd-resolved team to te DNS teams consisting of dozens of full time senior people working 20+ years on DNS with annual budgets of millions of dollars. I even pointed out these dedicated people spend weeks per year at dedicated DNS conferences and the IETF. I did this to specifically show that purely from a resource based point of view, the systemd-resolved team cannot ever match these resources. I did this specifically to prevent being seen as derogatory. As we share the same employer, I encourage you to escalate my "derogatory behaviour" to our magenement. I did not read the rest of your email. I will not read or respond to further emails from you on mailing lists. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tue, 29 Sep 2020, Petr Menšík wrote: is there any generic protocol exchanging what (sub)domains should be targetted to specific DNS server? The search domains are usually the only signal available and used for this. RFC 7296 (IKEv2) and split-DNS (RFC 8598) defines the sent domain name list as having a meaning of INTERNAL_DNS_DOMAIN. So it is no longer a 'search domain' but officially a "name to resolve via the nameserver's specified by the VPN". Whether to accept these or not is a local policy, but usually there is a trust relationship that trusts the VPN server. I know dnssec-trigger/unbound is able to send queries only to specified search domains received by DHCP server. Yes, dnssec-trigger tests the nameservers and when they pass, it calls calls "unbound-control forward_add". This is similar to what systemd-resolved has adopted via resolvectl. Are you aware of any implementation independent way to store domains for each interface? There is none that I know of. I think there should be just single way for connection provider to specify, which domains should go to its DNS server. Then any split-DNS capable software (unbound, dnsmasq, systemd-resolved) should just implement its layer to execute such redirection in runtime. Without special hooks in connection provider to running DNS stub. I think using the 'search domain' from DHCP is fine. And the VPN use cases are clear too. As long as "public network" connections never target specific domains (eg avoid reconfiguring paypal.com) I doubt there is already generic interface, but it seems it SHOULD be created. These discussions are now happening at the IETF ADD and DPRIVE working groups. While focused on DoT and DoH, the problem is identical. We might see a "list of domains to resolve via XXX nameserver" in the near future. Once that happens, it should be trivial to use that with things like resolvectl or unbound-control. Can you point me to your support for unbound? The support for unbound in libreswan is also really easy, as all the lifting is done by the unbound daemon/library code. We just relay the domain list and nameserver IPs to forward_add/delete and flush the related zone names: https://github.com/libreswan/libreswan/blob/main/programs/_updown.xfrm/_updown.xfrm.in If we find a running unbound, we reconfigure it. If we don't find it, we rewrite resolv.conf and send all queries over the VPN. As I said, I'll work on adding systemd-resolved support here for the next version of libreswan. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tue, 29 Sep 2020, Lennart Poettering wrote: Well, but how do you determine "local resources"? This is not the proper question. The proper question is "what are you trying to do". The .local domain discovery clearly is something meant to be local. I assume the real question is: How to convey my custom local network domain to my local infrastructure. In the old days, it was what DHCP gave you as domain. If you do that with your own network, then it is pretty obvious. If you do it differently, you will have to coney this somehow via configuration. This is why 20 years ago Microsoft added "zones" to their network configuration. Is this a "home zone" or a "work zone" or a "public wifi". So I expect the information of "what is local" to live in NetworkManager or systemd-networkd via configuration. No further magic should be needed. The user selects this once when joining a new network. Corporate networks tend to define local zones. Home wifi routers all do, too. There's no clear way to know what can go directly to well-known good DNS servers and what needs to be resolved locally. Generally, resolve the names from the DHCP obtained domain name with the DHCP obtained name servers. Yes, this is limited to one domain name, which might not be ideal, but in general when you connect to a home or corporate network directly (no VPN) then you should use their DNS servers regardless. Enterprise is likely blocking port 53 (or DoT or trying to block DoH) for security reasons. And your home network you trust? Most home routers these days allow configuration of a guest network along with the native home network. For those not requiring services on the home network, and who just need internet. It is the same as using a public wifi in a coffeeshop or guest network at an enterprise network. You might need to authenticate a captive portal and then you should not trust the network for anything else and ideally only give it encrypted packets (TLS, DoT to trusted DNS servers, VPN). If no trusted DNS servers are configured on your device, you have no choice but to trust their DNS servers. For what the user deems is a "public wifi", there are simply never any "local resources" other than an internet uplink to your own remote resources. In all the above scenario's, I see no ambiguity on which DNS servers to use, except when multiple domain names exist within only the LAN, which is rarely the case. 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. WireGuard has nothing related to DNS, it is all hidden in the per-vendor proprietary provisioning code. Perhaps the "wg-dynamic" userland protocol will address this. Let's hope they read RFC 8598 for inspiration to avoid the mistakes of IPsec 20 years ago. What is important with all of the VPN cases is that you properly flush the cache when the VPN estalishes and terminates, so avoid having unreachable IP's in your DNS cache. It's important not to flush other DNS data to avoid DNS fingerprinting users across different networks. It seems resolvectl is the API to support this with systemd-resolved. In short, I don't understand the issue raised here of "How do you determine local resources". For each and every domain name in the above scenario it is obvious what nameserver to send it to. There is never a need to broadcast this over a mix of public / private DNS servers. Also, people would react very allergic if we'd start sending all DNS traffic to google or so. So this feature has no purpose as far as I can see and is never ever a good idea, unless the user is specifically told their choice is to disconnect from a broken network or try to use the broken network with well known public DNS servers as a last resort. Yes, resolved implements DNSSEC. But from my experience I can tell you it's very hard to do in a way resonably compatible with DNS servers deployed out there in particular edge ones. Things mostly work, but DNS servers are all broken in different ways, and we can't possibly test things on all possible cheap wifi hw... Which is why the DNSSEC validation code should have been left to the large DNS teams at ISC, NLnetlabs, nic.cz, powerdns, IETF/ICANN communities etc. For any of the problems that systemd-resolved claims to have b
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Mon, 28 Sep 2020, Lennart Poettering wrote: stuff that doesn't come from classic Internet DNS cannot possibly be DNSSEC validated. This statement is incorrect. Please read RFC 8598 and perhaps read up on the handling of Special Use Domain Names and DNSSEC validation. No one expects .local to be signed. This is not an actual problem. You are not unique. Participate at the IETF, write and implement new RFCs that fix your current issues. If you expect a full blown DNS server on port 53 then it's not what systemd-resolved is or strives to be. For non-local queries, that is exactly what applications expect and depend on. So far we side-step the DO issue by returning a clean error when clients set DO: "not implemented" That is not what I see: paul@thinkpad:~)$ dig +dnssec nohats.ca @127.0.0.53 ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec nohats.ca @127.0.0.53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6543 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 I get NOERROR, so you should file another systemd-resolved bug report if the expected behaviour was NOTIMP. But even so, DNS libraries getting NOTIMP will just try to go to the next server listed in resolv.conf but there is only 127.0.0.53, so it fails. So you do not "side step" this issue at all. Implementing NOTIMP will change nothing. , plus a log message in syslog with more info. I'd argue that for the vast majority of users this is perfectly enough. This is again redefining the use cases and pre-selecting the type of users you wish to support and punting everything not in your use case to the "you are the advanced user, you know how to work around this". I was an enduser with a laptop dead in the water. It did not matter how advanced I am or not. It should not happen, and the fix is not for me to read syslog messages, google for documentation and then manually fix my system. My system should not break. Because IRL client-side DNSSEC doesn't really exist outside of some very specific circles of DNS nerds, I guess. Yes, I dare to suggest that for your typical GNOME/Fedora Workstation it really doesn't matter. This is a very outdated view. I understand that some people want DNSSEC/DO stuff work client side just like that, and as mentioned we'll add that, but let's not pretend this was "obvious" and without pitfalls of its own. I told you five years ago in Brno at a meeting organized to specifically talk about DNSSEC at the client side these exact same things. Let's not pretend I and others did not raise these issues then already. I understand some loud people here consider Internet DNS the true gospel, and mDNS and LLMNR and all kinds of other forms of popular name resolution, local and remote heresy As I suggested in previous emails, stop inventing your personal wheel and go get informed at the IETF about work being done in this space by the main vendors. I've listed the working groups, the drafts and the vendors. Raise any issues you think you have with respect to mDNS, LLMNR and what not. Work with others to define a functional protocol and implementation. Then push it first in fedora and I will happilly be dead in the water and report bugs and submit patches. Until we implement the DO-bypass stuff It is not acceptable to break all f33+ and rhel9/centos9 servers "until you implement" whatever it is you need to implement to violate 15+ year old DNS RFCs at the low priority you assign this bug baesd on your selective use cases. This will be my last email in this thread. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Marius Schwarz wrote: It's always a bad idea for a programm to do the dns itself, instead of using the dns anyone on the host does. You get a inconsistent behaviour at best, and a security nightmare at worse. DOx in a browser or any other programm is wrong anyhow. The software that decided that DNS answers are too security sensitive to not be validated is now blamed for not trusting the system resolver after it found said system resolver was untrustworthy. As John Gilmore used to say, if you can't not trust your friends, who can you not trust? :) Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Michael Catanzaro wrote: Well, let's amend that to "first when it's smart to be first." We can't ever *require* DNSSEC validation, because Windows and macOS are not going to do so. https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-01.html That draft has a Microsoft and Apple co-author on it. It states for example: There are several methods that can be used to discover and validate a resolver designation: * Discovery using SVCB DNS records (Section 3.1), and validation using DNSSEC This document is precisely to discover DNSSEC (and DNS encryption) services reliably so that DNSSEC validation can be turned on by default. Can you cite the documentation for your statement that these two vendors are not working on enabling DNSSEC validation? They have to be first. I could just as well counter with "How can Fedora be first if it refuses to implement split DNS behavior by default that breaks user expectations and leaks queries to unexpected networks?" How about systemd-resolved people join the IETF draft process, so that they can still influence the protocols while they are being designed, so that it can be made to work with systemd-resolved properly? There are a dozens of long time seasonsed DNS architects and programmers at the IETF working on this problem now. Join their effort. As for just passing along records, see Zbigniew's responses; it's possible to do by default, just not a priority. This is really only interesting for specialized applications like mail servers that live on controlled networks where you know that DNSSEC is not broken, i.e. not relevant for 99% of users. Please stop filtering out the use cases you don't like. Besides that, what percentage of desktops / laptops uses Linux versus what percentage of servers use Linux? I would strongly argue the case is quite the reverse. Linux desktop uses are 0.00% and Linux on servers is like 99.99% If you're running such applications, it's a one-line change in resolved.conf to enable DNSSEC, not really a big deal. It's annoying to have to edit an extra config file, yes, and we should do better, but I don't think that should derail this change. If systemd-resolved was only installed on Linux desktops, you would have a much stronger argument. But right now it is part of the same package as /sbin/init. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Michael Catanzaro wrote: Anyway, if you don't like this heuristic, we could decide to always delete /etc/resolv.conf. You will break all software linked against libunbound that uses the ub_ctx_resolvconf() function. Most users of libunbound will use this, because firewalls might prevent UDP 53 packets going out from anything but the configured system resolver. It also then uses and gets use of the system's DNS cache. The only other alternative I can think of would be to leave it unchanged, such that upgraded systems don't get fully migrated to systemd-resolved, but that's not a good option. I do not think systemd-resolved is ready for prime time, even unrelated to the specific split DNS and DNSSEC case. A number of bugs have been closed that affect DNS resolving despite DNS experts reporting this as violating RFC standards and breaking things. For example: https://github.com/systemd/systemd/issues/8967 Not migrating everything to systemd-resolved per default would not be the worst solution. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Michael Catanzaro wrote: I don't think it would be smart for employees to voluntarily opt-in to sending all DNS to their employer anyway... there's little benefit to the employee, and a lot of downside. Again, it is not up to systemd to limit valid use cases. Perhaps Listen or read to Paul Vixie, father of many Bind software releases: https://www.youtube.com/watch?v=ZxTdEEuyxHU https://www.theregister.com/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_feature_becomes_a_standard/ There are use cases for and against routing all DNS over your VPN. If systemd wants to play system resolver, it needs to be able to be configured for either use case. You don't get to limit our use cases. network settings and you see a checkbox that says "Use this connection only for resources on its network," a reasonable user *expects* that the connection will *really* only be used for resources on its network, not that it will be used for everything except DNS, which randomly goes to who knows where depending on what else you're connected to. Our design must try to avoid this failure case: "Sadly for Distrustful Denise, her employer discovers that she has been making some embarrassing DNS requests that she had expected to go through public-vpn.example.com instead." See my previous email with respect to RFC 8598. There is a standard for this. We supported this in libreswan with unbound before we even forked from openswan, 10 years ago. I had also patched openvpn when Red Hat swithced VPN service type but it seems that patch got lost along the way. Of course, it's still possible to get the old behavior if you really want to, but it will now require custom configuration not available via GUI Again, this mentality of "power users can fend for themselves" and "only our own use cases matter". , and nobody really wants to opt-in to that behavior Some people like using a "DNS firewall", or have their VPN admins require it. Don't map use cases only on your own desired use cases. I can't really stress this enough, as it is constantly coming up within systemd projects. * There is no real protocol for sharing internal domains, so systemd-resolved cannot know all of them, and resolving some of them will fail or receive unexpected resolution results (probably observable for some jboss.org subdomains for Red Hatters, but I don't work in that area, so I don't have a good example at hand). Yes, that's true. And there's not currently any good solution to that without resorting to the command line. See above. libreswan IPsec VPNs has supported this for 10+ years. No commandline required. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Tom Hughes via devel wrote: On 28/09/2020 15:57, Marius Schwarz wrote: Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek: DNSSEC support in resolved can be enabled through resolved.conf. Why isn't that the default, if this resolver can do it? Because DNSSEC is a disaster area and if you try and use it on random networks you're going to get failed lookups on a reasonable number - it's fine if you're on a known network with decent upstream servers but once you start going out and using random WiFi hotspots and things it's a very different story. And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now being deployed. And why browsers are, contrary to Michael Catanzaro's wrong claim, overriding the system DNS already. See Mozilla's TRR program https://wiki.mozilla.org/Trusted_Recursive_Resolver and Google's chrome https://www.chromium.org/developers/dns-over-https There have been very vocal discussion at the IETF of browsers vendors vs enterprise vendors on how good/bad DNS reconfigurations are. Some discovery methods, and a protocol for Adaptive DNS by Apple have been discussed at the IETF ADD working https://datatracker.ietf.org/wg/add/documents/ The real solution to the requirement for following spoofed DNS answers to login to captive portals is to have a container with the "uplink" and a sandboxed browser inside it handling the captive portal. Once the captive portal part is done, you either use the network's DNS server, or the user provided one. And maybe change it based on testing the given DNS server in some way, using one of the ADD IETF protocols. And only then mark the network as "up" to all other applications. Or if the user prefers, only use the local DNS for portal authentication and once there is a clean internet link, use DoH or DoT to a known truted (non-coffeeshop) DNS server. What we do not need is systemd-resolved making up its own incompatible and unsuspected protocols. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Michael Catanzaro wrote: If you're running mail servers or VPN servers, you can probably configure the DNS to your liking, right? Either enable DNSSEC support in systemd-resolved, or disable systemd-resolved. I'm not too concerned about this You should be concerned about this. The bar should never be "breaking the system is fine for advanced users" The signal you are sending me (and others) right now is the wrong signal. systemd should works for me, the user. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries, misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well. You're mixing a few different things here. We decided to not enable DNSSEC in resolved with this change, at least initially. For most users, DNSSEC is problematic because various intermediary DNS servers found in hotspots and routers don't support DNSSEC properly, leading to hard-to-debug validation failures. DNSSEC support in resolved can be enabled through resolved.conf. This may be a reasonable thing to do in an environment where the configured dns servers are known to support dnssec properly. If you want to do innovate new things with hotspot detection, the place to do the protocol work is at the IETF Captive Portal Working Group: https://datatracker.ietf.org/wg/capport/charter/ Work done there include an architecture docoument: https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ Captive Portal API: https://tools.ietf.org/html/rfc8908 DHCP and RA options: https://tools.ietf.org/html/rfc8910 These are efforts with big vendor signon. These will be compatible with new hotspots and work similar to other network devices. This is preferred over homegrown solutions. leaks private queries for VPN/internal domains to the open internet It's a complicated subject, but that statement is not true in general. It was true when we had a DNSSEC systemd meeting in Brno about five years ago when I raised it as a privacy issue and was told my use case was "not valid". And it still seems to be true. With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw a major discusison in the security area of IETF (specifically SAAG and TLS) to ensure every one (including browser vendors) were okay with the resulting DNS reconfiguration requirements of VPN servers. This is especially important now that we are storing certificates as TLSA records in DNS, storing encrypted SNI in DNS, and the current draft SVCB and HTTPS service binding DNS records that are used in Apple's IOS14. These records contain information that must not be vulnerale to spoofing or rogue DNS server redirection and should be DNSSEC signed. The designers of systemd-resolved will find it a useful read: https://tools.ietf.org/html/rfc8598 systemd-resolved uses the servers it is told to use. Sometimes we're not sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041 for a long discussion. If that worked, I wouldn't have even found out that my system got upgraded to systemd-resolved. Clearly this is broken. Furthermore, I doubt the rhbz will take into account the various risks of reconfiguring DNS and DNSSEC trust anchors or how to limit certain forwarders to certain domains. We are not talking about bugs that need fixing. We are talking about design decisions that I objected to five years ago that are now starting to cause damage. and prefers faster non-dnssec answers over dnssec validated answers Not exactly. It uses a single server, unless the server is deemed non-responsive and then it switches to the next one one, round-robin. Whether the server does dnssec or not does not directly factor into this. (Except that if resolved is configured to require dnssec, it won't want to talk to non-dnssec servers.) If dnssec is enabled, it shall only accept validated answers. This is better thant it was five years ago. I'm glad some things were at least successfully conveyed in the Brno meeting. However, this still leaks queries meant for the LAN or VPN onto the wide internet and is still a privacy and security concern. Some of these issues might look like minor unimportant bugs, but could be life changing for some people. I recommend the systemd-resolved people look into the Human Rights Protocol Considerations Research Group (https://irtf.org/hrpc) and its draft documents. Please file bugs if something is not working as it should. But please be detailed, because there are a lot of unstated expectations based on how things worked in the past that don't necessarily makes sense now. My servers had functional DNSSEC. After an upgrade they don't. No more detailed reports are needed. You know what you need to do to address this bug. I see Florian had already filed a rhbz a few days ago: https://bugzilla.redhat.com/show_bug.cgi?id=1879028 systemd-resolved should not be a required base system package. You know what you need to do to fix this as well. If you want to make it part of the graphical desktop install that is okay. But it must not be included in server installs. (Like with the name servers accessible over vpn: some people think a se
This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved I was just hit by the first bug in systemd-resolved 4 days after I upgraded to fedora33. I will file a bug report for that, but I wanted to discuss something more fundamental. systemd-resolved has a number of architectural flaws. When these were pointed out, bugs are not accepted and closed or ignored. Worse, I was told that systemd-resolved would not become the system DNS resolver, so I could just choose to not use it. Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded to systemd-resolved. I want to remove it from my system, but I cannot because it is not even a sub-package of systemd, it is part of the core systemd package. This goes against promises made in the past. Not only that, this change apparently "obsoletes" /etc/resolv.conf, which is just not acceptable. It is my opinion as a long time DNS RFC author and package maintainer that systemd-resolved is not a suitable DNS resolver. Downgrading DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I read on: https://fedoraproject.org/wiki/Changes/systemd-resolved that DNSSEC is now completely disabled. Again, this is completely unacceptable. DNSSEC is part of the core of DNS protocols. My fedora mail server uses DNSSEC based TLSA records to prevent MITM attacks on the STARTTLS layer, which is now completely broken. My IPsec VPN server uses dnssec validation using the specified nameserves in /etc/resolve.conf that now point to systemd-resolvd that does not return DNSSEC records and is completely broken: paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53 ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @127.0.0.53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65494 ; OPT=5: 05 07 08 0a 0d 0e 0f ("...") ; OPT=6: 01 02 04 ("...") ; OPT=7: 01 (".") ;; QUESTION SECTION: ;vpn.nohats.ca. IN A ;; ANSWER SECTION: vpn.nohats.ca. 10 IN A 193.110.157.148 ;; Query time: 143 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Sep 28 00:18:32 EDT 2020 ;; MSG SIZE rcvd: 81 libreswan will see this result as an attack, and fail to resolve DNS names in its configuration. My postfix daemon will hold on to mail because it cannot get a DNSSEC proof of denial of existence of TLSA records if all DNSSEC records are filtered - even for domains that don't use DNSSEC because the denial of existence of DNSSEC for a specific domain requires the return of DNSSEC records that systemd now does not return. I am sorry that I did not follow the fedora list carefully enough to notice this feature when it was proposed. This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries, misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well. The first mandatory step is to not disable DNSSEC. If I put on my security hat, I would actually have to look into filing a CVE for Fedora 33. A further discussion should happen on the future of systemd-resolved as the default Fedora (and later RHEL/CentOS) system resolver. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?
Or just a new option to rpmbuild that skips %check ? Sent from my iPhone > On Jun 5, 2020, at 10:11, Tomas Orsava wrote: > > Hi, > I think it would be useful to have a standard way of disabling the running of > tests during RPM build (in the %check section of a spec file). > > I see a lot of packages already having %bcond's or other macro definitions to > archieve this, but each package has their own way, there's no real standard. > Thus you have to first look into the spec, locate the appropriate %bcond or > macro name and only then you can disable the tests. > > I would like to propose two approaches: > > (a) Add a *SHOULD* rule to the guidelines that specifies what is the > preferred way to conditionalize the tests. > > (b) Or, if that's too strong, mention in the guidelines the common methods > that are being used (e.g. %bcond tests and %bcond check) so that new > packagers have something to use. > > What do you think? > Tomas > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to packaging-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Does anybody care about gettext?
On Fri, 9 Aug 2019, Daniel P. Berrangé wrote: We can't carry on postponing things indefinitely though - at some point we have to say enough, and expect a maintainer to actually do some maintaining. That is an argument to orphan, not an argument to remove the package. Had gettext been orphaned, people would have noticed without the entire OS breakage. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [HEADS UP] Unannounced soname bump of qrencode
This was a mistake on my end. I thought I was the owner of the package, but I think I was only the owner of it back in el6. I assume systemd then wasn't depending on it. I saw a PR the other day, assumed it was to me as package owner, and saw no reason to not upgrade since it was long over due. I didn't realise this would break systemd. Note, it is a bit worrying that systemd depends on this package, which wasn't updated in 5 years, and for which the upstream changelog mostly states "bug fixes". nirik untagged the package for me. I pinged Zbyszek to coordinate things. I've reverted the commits for f29 and f30 (no updates were issued for these branches yet) Ironically, this seems to not be the first time this happened either. I see someone else made the exact same mistake in January 2018 and reverted their changes to the package. So let's see if we can fix this now in rawhide so it does not happen again in another year. Paul On Tue, Jun 25, 2019 at 4:33 PM Miro Hrončok wrote: > qrencode was bumped from 3.4.4 to 4.0.2. > > It has a bumped soname from libqrencode.so.3 to libqrencode.so.4. > > systemd once again cannot be installed and all my packages fail to resolve > build > dependencies. > > Please, announce those changes and coordinate! > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F29 System Wide Change: Strong crypto settings: phase 2
On Thu, 14 Jun 2018, Tomas Mraz wrote: On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote: I don't think TLS 1.3 will see a wide deployment immediately. Sure, the famous top websites and top browsers will, but enterprises will not. And especially those with any kind of loggin/auditing requirements cannot even allow TLS 1.3 with ephemeral DH on their network. I would personally first try and disable TLS 1.0 in f29 and see how much problems that generates. Then in f30 or f31 disable TLS 1.1. Except from the internet website statistics the TLS-1.1 only or as maximum TLS version is not deployed. The sites are either TLS-1.0 max version or they support also TLS-1.2. So this will not make almost any difference and the impact on compatibility will be practically the same as disabling even TLS-1.1. Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1: https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 I guess it all depends on the lifetime of old cheap android devices :P Paul ___ 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/VZAJCPXLWPGNP2JGNZOOVFXILCLBFR5G/
Re: F29 System Wide Change: Strong crypto settings: phase 2
On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote: I think the debate here is whether fedora (and in general operating systems) can afford to be stricter than the browsers. As an OS our attack surface is much larger than the browser setup, and thus it makes sense (to me), to be more careful. Your legacy interaction will also be much larger. Like connecting to your home wifi router's webgui. Can we afford to break a significant part of our users? Of course not, but I think that this change is eventually happening, especially with TLS1.3 expected to be deployed widely, and it seems to me that we only wait to see who will do the first step. I don't think TLS 1.3 will see a wide deployment immediately. Sure, the famous top websites and top browsers will, but enterprises will not. And especially those with any kind of loggin/auditing requirements cannot even allow TLS 1.3 with ephemeral DH on their network. I would personally first try and disable TLS 1.0 in f29 and see how much problems that generates. Then in f30 or f31 disable TLS 1.1. But I suspect fedora itself not to be the problem. The real problems will hit RHEL/CentOS in the enterprise deployments. So even with a success in fedora, I would be very careful with drawing any conclusions for enterprise use. Paul ___ 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/HF6BSBVUYOW5SQZPQ6X3JQHEFVA7N7I7/
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Wed, 2 May 2018, Lennart Poettering wrote: I presume you mean "~/.local" rather than "~/local"? I don't. As my argument goes, hidden directories containing binaries in your path are a bad idea. And it was a bad idea 15 years ago. Note that my home directory seems to only contain ~/.local/share and nothing else, so this hidden binary directory concept seems to have not been in use for 15 years. Storing configs in ~/.local/share seems okay with me, even though it just moves the namespace from ~ to ~/.local with no good reason, while still littering in ~/.??* anyway, but that's another issue. Paul .local/ was introduced and documented in 2003. That's 15 years ago now. Pretty much everybody settled on it these days, and many distributions have clear language suggesting its use. For example, here's the wording from Debian: "Debian does not require that packages conform to the XDGBDS but strongly encourages upstreams to do so. " — https://wiki.debian.org/XDGBaseDirectorySpecification Now, the ~/.local/bin/ thing is mostly just a natural extension of XDG basedir, and many systems have adopted it anyway without this being explicitly written into any spec. So yeah, I think it's about time we just update the spec to its natural extension and to what people already use. I don't think anyone is helped if we introduce yet another directory for this, in particular as the security benefit of using any other path is not universally agreed to. Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Wed, 2 May 2018, Vít Ondruch wrote: User explicitly installed SW into his home directory. Why (s)he needs to override the $PATH in addition to make the SW work? Can you account for all your ~/.??* entries in your home dir? I have several of which I have no clue what it is or why it got there, and I have 25 years of homedir experience. paul@bofh7:~$ ls -al . Display all 271 possibilities? (y or n) So I don't think your "User explicitly installed SW into his home directory" is true, and it is especially not true if software can make use of knowing ~/.bin will be there for it to quietly drop some things in. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Prioritizing ~/.local/bin over /usr/bin on the PATH
On Wed, 2 May 2018, Lennart Poettering wrote: It's already there. And it is XDG complaint. The question here is about order (what takes priority). Can you point me to the XDG specification that requires it ? It was mentioned by Lenart on the bug, but he later clarified his comment[1]. So this came up again recently here: https://lists.freedesktop.org/archives/xdg/2017-August/013938.html (see the full thread) And I even promised to merge the proposed spec addition there, but never actually did that. Maybe I really should now... Adding invisible directories to a user's PATH is putting esthetics over security and is the wrong thing to do. I have no problem with ~/bin/ but feel a bit reserved about ~/local/bin/ as ~/local might not be obvious to the user as an added binary containing directory. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: script to run after hotspot authentication?
On Tue, 24 Apr 2018, Sam Varshavchik wrote: Is there a way to run a custom command after hotspot authentication? You might be able to hook into dhclient. That happens when you obtain an IP address. There is no notification method that I know about that will signal me when the hotspot authentication has happened. This could be seconds or minutes (minutes is when I open my laptop without typing and grab my coffee at the coffee shop :) Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
script to run after hotspot authentication?
Hi, Is there a way to run a custom command after hotspot authentication? Fedora has/had some ways of detecting portals. dnssec-trigger, NetworkManager and Gnome3. I think the current method is supposed to be based on the latter. So I guess the problem that is used is /usr/libexec/gnome-shell-portal-helper Does that signal anything back to NM? It seems the helper itself has no "post" commands it can run. Specifially, I'm trying to solve the problem of IPsec MOBIKE support. When we receive a notification of the new IP address via netlink, the network isn't working yet and our mobike address update request using this new IP address dies in the portal filter. The user authenticats and the captive portal disables the filter, but we no longer receive any update about this event from netlink/kernel. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS
On 01/10/2018 11:18 AM, Robert-André Mauchin wrote: > On mercredi 10 janvier 2018 00:07:11 CET rugk wrote: >> Providing privacy and security for DNS! (especially after dnscrypt is >> discontinued now). >> It would be nice to have this in Fedora. >> >> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby >> GitHub: https://github.com/getdnsapi/stubby >> For distro status see: https://repology.org/metapackage/stubby/versions >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Although upstream has splitted Stubby in a separate repo in August 2017, they > still distribute it along Getdns source. Thus in Fedora, the latest Stubby is > currently installed with the latest release of Getdns. See https:// > src.fedoraproject.org/rpms/getdns/blob/master/f/getdns.spec > > Maybe you could suggest the package maintainer to add a "Provides: stubby" so > it can be found directly. CCing Paul Wouters in that regard. That's a good idea! I'll fire of some new builds with that later today when I fixup the libidn2 handling as well. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CVE-2016-8655, systemd, and Fedora
On Wed, 14 Dec 2016, Scott Schmit wrote: IPsec requires AF_NETLINK (NETLINK_XFRM) to manage the security associations & security policies. libreswan probably also needs to be able to manage the routing for IPsec tunnels (NETLINK_ROUTE[6]). The nature of libreswan is that it allows custom "updown" scripts to be executed, which can do things we don't know beforehand. So any limitation here has to be carefully set. This is why we still allow seccomp to be disabled. For instance we don't use IPC, but some database client in updown might use it. The original RFCs for IPv6 mandated support for IPsec, but that's no longer required as of RFC 6434. Nothing else popped out at me as necessary for IPv6, but it's probably a moot point given XFRM. So "RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK" is probably enough? :) Unless the updown scripts uses a ping command, which is not uncommon for people to do :) Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CVE-2016-8655, systemd, and Fedora
On Mon, 12 Dec 2016, Lennart Poettering wrote: Note that I wonder if restricting address families really belongs in systemd. Why isnt this a libcap-ng capability? That way my software can support this without depending on systemd. hu? libcap-ng is a library to manage Linux process capabilities. RestrictAddressFamilies= is a unit file setting, all you have to do enable it in the unit files of your choice, and the service it runs then loses access to a specific AF_xyz family (or all but a specific one). It's implementation is based on Linux seccomp, a kernel facility entirely unrelated to Linux process capabilities. Oh, I didn't realise it used seccomp. Never mind then. Those who implemented something using libseccomp I guess could do this also independently of systemd. And there's no talk of having to "depend" on systemd for this to work. If you ship a systemd unit file in your package (and, quite frankly you have to if your package contains a service of some kind, this is Fedora after all), then all you need to do is add a line RestrictAddressFamilies= to it. I was talking with my (libreswan) upstream hat on. In general, we try and support things independent of kernel or OS. Ideally, you'd ship such a unit file upstream. But if you don't want your stuff tainted by the horrible idea of shipping systemd unit files upstream, then it's totally enough to make this change downstream in the RPM. Yes, we auto-detect systemd and ship service fils there too. And even support systemd native things like sd_notify() when available :P Of course, you can also set up seccomp filters yourself, in your daemon, in C code, by using libseccomp. It's great if you do We do. that's totally possible, and can be functionality-wise entirely equivalent. The only difference is: systemd makes all of this trivially easy to use, by making this a single-line change in a unit file without involving C hacking. For us (libreswan) it probably makes less sense to restrict address family in the daemon. Our daemon just listens to UDP 500/4500, so it would never be affected by any other kind of address families. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CVE-2016-8655, systemd, and Fedora
On Mon, 12 Dec 2016, Matthew Miller wrote: Question 1: How can we take advantage of this feature in specific? We could bulk file a bunch of bugs. Or, what about turning on some more restrictive defaults (AF_INET AF_INET6 AF_UNIX) on some flag day in Rawhide, and having services which have different needs add exceptions to their own unit files (either more or less restrictive). I don't see the use of a flag day. Everyone can (and should) implement it in their services file and people can file bug reports for those that do not? Question 2: What about *other* systemd security features? The blog post mentions restricting namespaces as an upcoming feature, and there are other existing ones which we are not using systemically — like PrivateTmp, ProtectSystem, etc. How can we take better advantage of these? Same? Note that I wonder if restricting address families really belongs in systemd. Why isnt this a libcap-ng capability? That way my software can support this without depending on systemd. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 5 Dec 2016, Michael Catanzaro wrote: On Mon, 2016-12-05 at 09:05 -0500, Paul Wouters wrote: That is incorrect in my experience. When I go to coffee shops, my iphone shows the portal page, but my laptop shows the TLS cert invalid thing. Oh wow. I didn't know that. Feels like time to give up Anything captive portal does feel that way, although there is some hope on the horizon with the IETF captive portal working group that is trying to make this a little easier and more standarized. https://datatracker.ietf.org/wg/capport/charter/ So what's your recommendation, just ignore all TLS errors and accept that anybody can intercept your credentials for the portal? It could be a problem because AFAIK some portals are using Google credentials for authentication nowadays. I don't know much about that With certificate transparency becoming mandatory, the number of bogus self signed certs and certs signed for bogus made up domains should decrease as browsers will just refuse to load these. So I do think we will see a move where if they use certificates, it will actually have to be a valid one chained to a valid public root CA, which means the DNS name has to be a real valid FQDN and not some made up goo. But we are not there yet. So I think a warning might be appropriate. Credential passing is hard. If done right, the user would only use something OAUTH like where it is a challenge/response that the portal will have to relay via the real authentication servers. But if they will just put up a "sign in with XXX" and a user/password box, likely many users will just give them their full credentials anyway. I doubt any green URL bar, padlock or us giving warnings will do anything about that :( Right now, the situation leads me to having to close the gnome window which only displays "TLS certificate invalid" or some text like that, and still use my firefox and a new tab/window to get through the captive portal. In which case we are exposing the full firefox with all my privacy settings and cookies to the captive portal, instead of (what I hope to be) some "private window" gnome web browser that has no access to any of my personal data. So I'd rather see the gnome window ignoring the TLS error and proceeding. Yeah, I actually filed a bug for this a while back: https://bugzilla.gnome.org/show_bug.cgi?id=750941 Or a cached page? It's been happening to me on f24 for a few weeks now. Paul Um... yeah maybe, I don't see any code in the portal helper to disable caching at all. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775639 Thanks for filing those! Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sun, 4 Dec 2016, Michael Catanzaro wrote: On Sun, 2016-12-04 at 16:39 -0500, Paul Wouters wrote: That is a different issue. And indeed I see it as well, and was quite surprised at them checking the TLS validity of a captive portal page. We have no plans to stop doing this, because that's how all other browsers and operating systems work. It shouldn't be any problem because such portals would not work for anyone on any system. That is incorrect in my experience. When I go to coffee shops, my iphone shows the portal page, but my laptop shows the TLS cert invalid thing. But in this specific case with the gnome-shell portal helper, there seems to have been a problem because we tried to load an https:// URI rather than an http:// one, which isn't going to work under a captive portal as the portal can't replace the page. I really do not completely understand what the actual bug here was, and nobody seems to have figured it out, but it seems that for whatever unknown reason some captive portals decide not to intercept our load of http://www.gnome.or g. That URI recently became a redirect to https://www.gnome.org, so the portal helper performs the redirect and then the portal does intercept the load of https://www.gnome.org, and that's why you get a TLS error. It's really weird; I don't know why the portal would do that. Moreover the issue affected some users, but not others, with the exact same captive portal, using the exact same version of Fedora; we had this issue at GUADEC. Maybe the redirect is cached by WebKit on certain systems so it only works if you haven't visited http://www.gnome.org before in the portal helper...? Anyway, we have "fixed" this by changing it to load http://nmcheck.gnome.org which never redirects to HTTPS. I haven't heard any complaints about this since then, so I think it's good, but the change is in gnome-shell-3.22.2-2.fc25 which is very recent so let's wait and see. Yes. That is why I specifically requested that the fedora hotspot page never chage their output and never send a redirect. Using the main page of gnome was a bad fit. Note you should also ensure that nmcheck.gnome.org has a cache lifetime of 0 seconds to it. I have that on top of the bug where it just shows me the gnome page instead of the actual captive portal page. This really requires a separate bug report against gnome-shell. Probably a race condition somewhere, maybe the last redirect and NetworkManager connectivity check occurs just before we get connectivity back. Unfortunately this is an undermaintained component that is not very likely to be fixed without a volunteer. Or a cached page? It's been happening to me on f24 for a few weeks now. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sun, 4 Dec 2016, Kevin Fenzi wrote: On Fri, 2 Dec 2016 21:42:07 -0600 Eric Sandeen wrote: On 12/2/16 7:10 PM, Paul Wouters wrote: Fedora runs a captive portal check page at: http://fedoraproject.org/static/hotspot.txt It used to return "OK\n". Now it returns "OK" without the newline. Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? Looking at archive.org, I do see the newline in: https://web.archive.org/web/20150616184630/https://fedoraproject.org/static/hotspot.txt but not in: https://web.archive.org/web/20160213221103/http://fedoraproject.org/static/hotspot.txt Indeed it seems the changes made on 2015-12-15 removed the newline. ;( Sorry about that. I can put it back since it seems like NetworkManager's portal detection doesn't care, or just leave it off now since it's been that way for around a year? I guess leave it as is. But it would be good if we can find out what happened, and fix the process. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sat, 3 Dec 2016, Langdon White wrote: Wouldn't it make more sense to be checking for status 200? Checking for content on the page seems fragile in general. Who says a stolen page wouldn't return status 200? Also, and perhaps related, I filed a bug[1] about captive portals that seems to have some attention. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362449 That is a different issue. And indeed I see it as well, and was quite surprised at them checking the TLS validity of a captive portal page. I have that on top of the bug where it just shows me the gnome page instead of the actual captive portal page. Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? That is my guess. I've pushed an update for geome (a tool to tell you your location based on IP address) which does a captive portal check to give a more meaningful error if a captive portal prevents it from working. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora captive portal page changed output :(
Fedora runs a captive portal check page at: http://fedoraproject.org/static/hotspot.txt It used to return "OK\n". Now it returns "OK" without the newline. This caused at least the geome tool (from the geome package) to return a false positive and abort, telling the user to first authenticate to the hotspot. I'm pushing a fix now for geome to allow either one of these outputs. Other packages using the hotspot detection page might have been similarly broken. Paul ps. Not sure if related or not, my gnome portal detection is no longer showing real captive portal pages, but instead just shows me a gnome window. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24, small backward steps
On Tue, 13 Sep 2016, Ralf Corsepius wrote: This is a truly awful experiance from POV of a Fedora user filing bugs :-( We've set a silent trap for them with no warning of the fact that their bug reports are going to be ignored until Fedora EOL procedure closes them :-( One lesson I have learnt in Fedora, is that filing bugs reports against packages owned by certain people equals to sending bugs to /dev/null. IMHO, Fedora should consider to take disciplinary measures against these people. And get less packagers? It would be useful if package co-owners would automatically get added to the bugzilla bug, instead of only the package owner. Most packages don't have dedicated aliases for that. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24, small backward steps
On Fri, 9 Sep 2016, Adam Williamson wrote: 2. fingerprint identification: The laptop has a fingerprint reader and it works fine. However I prefer not to use it. The user set up specifies that fingerprint login is disabled. However whenever I am asked for a password the fingerprint reader blinks until I swipe a finger over it (even after using a password). No fingerprint is registered. This is different than F23 where it never blinked. This you should probably file a bug on (against, I guess, gnome-shell? But it depends a lot on the answer to my second question below...), but with a bit more detail. What exactly do you mean by "The user set up specifies that fingerprint login is disabled" - what "user set up" are you referring to exactly? When exactly does this happen - more detail on "whenever I am asked for a password". Thanks! This happened to me too. I did not enable fingerprint based logins (since half a dozen governments have my fingerprints) and whenever I open my laptop or unlock the screensaver using a password, the green fingerprint LED starts blinking. This did not happen on f23. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Why GUI software update tool is broken for me
> On Jun 15, 2016, at 12:51, Stephen Gallagher wrote: > Traditionally, we've assumed a greater level of understanding for those who > use > CLI tools as opposed to GUI tools. It's expected that if someone is using DNF > directly, it's because they know what they are doing (and what risks that > carries). I'm not going to comment on whether that assumption is correct or > not, Let me then. The original poster said they stopped using the gui tool not because of a different skill level but because they don't want to be forced into a reboot now. I do the same. A pop up interrupts me and I'm busy. I probably forget. Now my system is sure to be out of date. Services should be smart enough to restart if one of their dependant libraries updates as a security update. Don't we have a super competent new fancy init system for these kind of things now? Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Imaginary single quotes in ls ?
On Mon, 6 Jun 2016, bendem wrote: Are you using an alias like ls="ls --quoting-style=shell"? Not knowingly. Whatever I got, I got it from systems default. And yes this is an f-24 install. using a gnome-term if it matters. Paul On 06/06/2016 05:53 PM, Paul Wouters wrote: paul@thinkpad:/tmp/test$ touch foo bar baz paul@thinkpad:/tmp/test$ touch "touch and go" paul@thinkpad:/tmp/test$ ls -l total 0 -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 bar -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 baz -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 foo -rw-rw-r--. 1 paul paul 0 Jun 6 11:49 'touch and go' This is very misleading, as it appears the filename actually contains single quotes. And I tried and failed to fix it using \ Oddly enough, ls > out does not show this behaviour, so I suspect this is some kind of "feature". I would be in favour of disabling this feature, Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Imaginary single quotes in ls ?
paul@thinkpad:/tmp/test$ touch foo bar baz paul@thinkpad:/tmp/test$ touch "touch and go" paul@thinkpad:/tmp/test$ ls -l total 0 -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 bar -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 baz -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 foo -rw-rw-r--. 1 paul paul 0 Jun 6 11:49 'touch and go' This is very misleading, as it appears the filename actually contains single quotes. And I tried and failed to fix it using \ Oddly enough, ls > out does not show this behaviour, so I suspect this is some kind of "feature". I would be in favour of disabling this feature, Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Fri, 3 Jun 2016, Lennart Poettering wrote: You are redefining the meaning of (a graphical) logout. It simply means another user can use the mouse, keyboard and screen of this device. It makes no statement on whether the machines resources are shared or not. Actually, with logind, current kernel, current X11 and/or wayland there's a very clear statement on sharing devices: logind will ensure that only the fg session can access the various evdev and DRM devices, and will suspend access for all sessions not currently in the fg. Similar, ACLs for a couple of other device nodes are patched depending on the fg session (but only for DRM and evdev the ongoing connection of bg users is suspended, as there's no concept of a generic revoke() in the Linux kernel, but only DRM and evdev-specific mechanisms). Locking this down properly, so that background sessions or even non-console logins don't get access to your devices has been something various folks from various communities have been working on for a while. So yeah, sessions (as defined by logind) are a security concept already, and they will make sure that only the right users get access to the devices at the right times. That's great. It has however, absolutely nothing to do with backgrounded processes, and their interpretation of good vs evil by systemd. No one is saying when a graphical session ends, you cannot reclaim the devices required for the next graphical session to start. No one is saying you cannot protect physical devices from graphical or network logins. What it is offered now is garbage collection of the global process list, and people are stating systemd does not have the required to knowledge to successfully perform that task - and therefore should not try. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
> On Jun 1, 2016, at 09:48, Lennart Poettering wrote: > > Any scheme that relies on unprivileged programs "being nice" doesn't > fix the inherent security problem: after logout a user should not be > able consume further runtime resources on the system, regardless if he > does that because of a bug or on purpose. You are redefining the meaning of (a graphical) logout. It simply means another user can use the mouse, keyboard and screen of this device. It makes no statement on whether the machines resources are shared or not. It allows you to kill anything that has to do with the user controlling the screen, keyboard and mouse but the killing should be limited to those processes. And then we are back at "just fix those broken processes". As others pointed out, the security feature does not really apply if the user is allowed to use any and all resources while logged in. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Thu, 2 Jun 2016, Lennart Poettering wrote: Well. Let's say you are responsible for the Linux desktops of a large security-senstive company (let's say bank, whatever), and the desktops are installed as fixed workstations, which different employees using them at different times. They log in, they do some "important company stuff", and then they log out again. Now, it's a large company, so it doesn't have the closest control on every single employee, and sometimes employees leave the company. Sometimes even the employees browse to the wrong web sites, catch a browser exploit and suddenly start runing spam bots under their user identity, without even knowing. This all has nothing to do with individual processes on machines. If you are a big bank you better well detect rogue processes using up CPU on your install base. In all of these cases you really want to make sure that whatever the user did ends – really ends – by the time he logs out. No you don't. you are creating simplistic world views that are not there. As others have said, the only simple case of killing processes is those with no use when the user is gone - that is locally started windowing applications. Really, we need to fix gnome and gdm and stuff that lingers where the problem is. We don't need systemd to kill my 200 gdm lockscreen binaries that eventually run me out of resources to unlock my screen. We need gdm to see its bugs and fix it. This is really just one example. This model I think really needs to be the default everywhere. People aren't agreeing with you. So making it a default seems like a bad idea. People do seem to agree on "obviously broken windoing apps" that are left lingering. Why can't we just let those get killed? On desktops and on servers: unless the admin permitted it explicitly, there should not be user code running. no, user code may be running everywhere as long as it does not affect the purpose or policies of the machines. Such policies are not written by filenames of binary files. If you allow your intern user access to a webserver to quickly check our the resource consumption of some service that doesn't mean that he shall be allowed to run stuff there forever, just because he once had the login privilege for the server. And even more: after you disabled his user account and logged him out, he really should be gone. apart from your use case taking up 4 lines, which seems like a difficult policy to code into applications (remember you would also need to be able to code the reverse of that policy) the only thing I do agree with you here is that unlisted uids/gids might be fair game to shoot. But one has to wonder how well that works in the case of network outages where a NIS server or something is temporarilly unavailable and you start shooting legitimate processes. Yes, UNIX is pretty much a swiss cheese: it's really hard to secure a system properly so that somebody who once had access won't have access anymore at a later point. However, we need to start somewhere, and actually defining a clear lifecycle is a good start. But your definition is already running foul with just a handful of software developers and it will cause large unexpected problems in the real world. For example, a decade ago at a najor airline, they had their core database automatically deleted each night. turns out an overeager cronjob deletes all "core" files that crashed applications left all over the servers. To me, systemd shooting processes is not different. If you are that concerned about processes, you need a strict security policy on what proccesses you allow to be _started_, not trying to fix your mistakes afterwards by shooting. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Sun, 29 May 2016, Chris Murphy wrote: On Fri, May 27, 2016 at 5:03 PM, Paul Wouters wrote: If there is a systematic problem of badly written code leaving orphaned code running when a user logs out, then that broken code should be fixed instead of adding another layer of process management. systemd is not capable of interpreting the user's intent. That isn't working. Users are constantly running into restart and shutdown delays. Troubleshooting this to find out what process is holding things up is totally non-obvious. Identifying the process is half the problem, and then getting it fixed and released to Fedora can be months, by which time some other process is affected. Taking a shotgun isn't going to help that. Actually, if "bad code upstream" is the problem, you can just wait on all of that code starting to tell systemd they want to linger to avoid getting shot by systemd for doing something wrong. So this whole thing becomes another abstraction layer that serves no purpose, and just causes collateral damage. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Fri, 27 May 2016, Chris Murphy wrote: It seems to me systemd should be able to know the difference between a program that's zombie or unresponsive but isn't doing anything or is unresponsive but is doing something; and if not then some way for programs to say "hey wait just a minute, I need to clean things up" or whatever, rather than just abruptly killing them. That invention is otherwise known as "unix signals". systemd should not be the process police. If there is a systematic problem of badly written code leaving orphaned code running when a user logs out, then that broken code should be fixed instead of adding another layer of process management. systemd is not capable of interpreting the user's intent. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: pidgin, was Re: Orphaned Packages in branched (2016-05-03)
On Mon, 9 May 2016, Jan Synacek wrote: I got a few of these warnings in the last few weeks and I'd like those to stop :) Is there any interest in supporting SILC? It's an old encryption chat protcol that I never used or never heard of someone using. Do the pidgin maintainers want to take the package on, or recompile pidgin without silc support so we can get pidgin of the death list? I've disabled silc support. Awesome, thanks! Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
pidgin, was Re: Orphaned Packages in branched (2016-05-03)
On Tue, 3 May 2016, opensou...@till.name wrote: libsilcorphan, cicku, nosnilmot 9 weeks ago Depending on: libsilc (12), status change: 2016-02-26 (9 weeks ago) pidgin (maintained by: jsynacek, itamarjp, jskarvad, mcrha, nosnilmot) libpurple-2.10.12-2.fc24.i686 requires libsilc-1.1.so.2, libsilcclient-1.1.so.3 pidgin-2.10.12-2.fc24.src requires libsilc-devel = 1.1.10-15.fc24 [ list of pidgin plugins including the one I maintain ] I got a few of these warnings in the last few weeks and I'd like those to stop :) Is there any interest in supporting SILC? It's an old encryption chat protcol that I never used or never heard of someone using. Do the pidgin maintainers want to take the package on, or recompile pidgin without silc support so we can get pidgin of the death list? Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: mod_rewrite rule please? admin.fedoraproject.org/updates/packagename/ ?
On Mon, 21 Dec 2015, Michael Cronenworth wrote: On 12/21/2015 01:19 PM, Paul Wouters wrote: Could we have a mod_rewrite rule for bodhi.fedoraproject.org/updates/packagename ? One already existed. Have you not tried it? https://bodhi.fedoraproject.org/updates/libreswan I had in the past, but not recently. Thanks to whoever added it :) Paul ps. now if we get admin.fp.org -> bodhi.fp.org it will be perfect :) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
mod_rewrite rule please? admin.fedoraproject.org/updates/packagename/ ?
Hi, I really miss the simple URL lookup to find links to the last few package builds of a certain package. Eg for libreswan, I could use: https://admin.fedoraproject.org/updates/libreswan/ Now I have to go search around and type in a package name, eg: https://bodhi.fedoraproject.org/updates/?packages=libreswan Could we have a mod_rewrite rule for bodhi.fedoraproject.org/updates/packagename ? Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/14/2015 04:26 PM, Oron Peled wrote: >>> 2. dbus: >>>* The local DNS server would send specific DBUS signal (e.g: >>> net.dnsseq.InsecureDNSReply). >>>* A desktop process would listen on these signals and show proper >>> desktop notification. >> >> But these solutions can quickly become a denial of service through popups. > > Good point, but that could be mitigated at both ends: > * The local DNS server can apply a "rate-limit" for these DBus signals. > * Also, the display don't have to use desktop "notifications". >Alternatively, it can be implemented as a single process that listen to >these signals and show one popup with minimal info (global warning, >with a possible list of latest problematic domains). All these dnssec validation errors would be equally invisible if the system used 8.8.8.8 because google would also ServFail these since they do DNSSEC. > Those DNS deployments are good for general DNSSEC technology validation. > > They have nothing to do with the problem I pointed: > * They do not test the crazy DNS world *inside* NAT'ed networks. > * In these private networks is where most bad DNS setups exists. > * This is the environment that the new Fedora DNS setup will likely > encounter. The only simple solution here is the "trusted network zone" where the user explicitly states they trust their local server. This is something NetworkManager should expose to the user - possibly on first connect. > factoid: In a medium corporation I know (few thousands desktops/servers > across ~5 timezones), > they still use internal domains like "foobar.local" (which > practically kill > great technologies like mDNS). > This is pretty obvious as ".local" was considered > *best-practice* > by some Microsoft Active Directory setups when this corporation was > small. I have no problem breaking those kind of setups. >> We've gone out of our way to try and be nice to existing DNS >> deployments, but at some point you got to treat the wound, cause some pain >> and fix things. > > I agree, but still think doing it in *two steps* would be beneficial for both > Fedora and DNSSEC. > > First make it default and analyze the backlash (which won't be fatal, as it's > only warnings) > Than make it "enforcing" and force the pain (after you already have clear > notification mechanisms that are *familiar* to the end-users). 20 years of DNS has taught me no one ever fixes any DNS until it is causing an outage. > My proposal does not "just postpone" -- Let's make it Fedora-24 default, > but *warn* about bad replies instead of *rejecting* them -- this would give us > valuable information. People will click away the warnings until they upgrade to F-25. >> Really, the biggest issue people fear is their split view DNS. Which is >> easilly solved by extending >> the concept of firewalld zones into Network Manager, and always use broken >> DNS forwarders on >> "trusted networks". > > Hmmm... "easily solved" is not "solved": > * Has this "biggest issue" really been solved? Do we have this NM > integration? I don't know. I don't think the integration with firewalld/NM uses the same concept of "zones". >Does it show in "nm-applet" (I avoid bringing up KDE which I personally > use, >or other desktops) > * What other issues we don't know, simply because this Fedora setup hasn't > been *widely* deployed? I'd be more sympathetic to this if we haven't gone through major things like /usr move already :P Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/12/2015 09:11 PM, Oron Peled wrote: > On Friday 11 December 2015 09:09:28 Paul Wouters wrote: >> On 12/09/2015 06:02 PM, Oron Peled wrote: >>> Why don't we plan this feature in two stages: >>> * Fedora 24: turn it on by default, but *keep using results* from bad DNS >>> servers, >>>just issue a user-visible warning, possibly with a link to a page with >>> friendly >>>explanation and suggestions for further action. > > I'll answer both Paul and Reindl which replied "there's no safe and clean way > to solve that"... > >> DNS lookups don't have users like web browsers. > > First, that's only partially correct: > * The client (resolver) normally *does* have a user (the uid of the process > calling the resolver library). > * But after that, your are correct that the caller identity is gone. > > Still, IMO, the goal to warn users can be achieved quite easily. Two examples > from the top of my head. > 1. log + notify: >* The information may be logged with special prefix (or special field via > sd-journal). >* Users would have a small desktop service that would monitor for these > messages and notify about them. You can do that logging using tools like dnssec-system-tray pointing to the unbound log file. > 2. dbus: >* The local DNS server would send specific DBUS signal (e.g: > net.dnsseq.InsecureDNSReply). >* A desktop process would listen on these signals and show proper desktop > notification. But these solutions can quickly become a denial of service through popups. >> I have been running this setup since Fedora 17. Breakage is not that bad. > > Hmmm... even if all of us, fedora-devel subscribers, would run this > it's still a far cry from a full release cycle of Fedora: the problem with bad DNS deployments is that it keeps becoming a bigger house of cards until it actually fails to work, similarly how raided disks that write a log message that one of the two disks is failing usually gets found when the second disk failed. >* large-numbers: millions of machines would reveal much more varied > use-cases > than what a 500-1000 machines of "fedora-devel" people can show. google dns, verisign dns and many large DNS deployments already validate and break setups of people using 8.8.8.8 manually. We've gone out of our way to try and be nice to existing DNS deployments, but at some point you got to treat the wound, cause some pain and fix things. > So my hunch feeling is still: make F24 with DNSSEC by default, but not > "enforcing". Than, F25 will enforce DNSSEC validation. That just postpones the hurt for 6 months. We've already had a few of these cycles. As I said, I run this since fedora 17. Really, the biggest issue people fear is their split view DNS. Which is easilly solved by extending the concept of firewalld zones into Network Manager, and always use broken DNS forwarders on "trusted networks". Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/09/2015 06:02 PM, Oron Peled wrote: > Why don't we plan this feature in two stages: > * Fedora 24: turn it on by default, but *keep using results* from bad DNS > servers, >just issue a user-visible warning, possibly with a link to a page with > friendly >explanation and suggestions for further action. DNS lookups don't have users like web browsers. I have been running this setup since Fedora 17. Breakage is not that bad. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/09/2015 01:04 PM, Debarshi Ray wrote: > On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote: >> On 04.12.2015 15:57, Lennart Poettering wrote: >>> How do other popular desktop/consumer OSes deal with this? Windows, MacOS, >>> iOS, Android, ChromeOS? Does any of them do client-side DNSSEC validation by >>> default and how are they dealing with this issue? >> >> I'm not able to answer this question. > > That is troubling. :( > > Since this is likely to break networking on a lot of client-side systems, I > would have expected you to do this research before submitting it as a System > Wide Change. We did. We are the First at undertaking this at an OS level. If the others proceed they will run in the exact same issue. The problem of broken and badly designed DNS setups is, is that they only go away when it finally breaks down. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Mon, 7 Dec 2015, Florian Weimer wrote: Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better solve this quickly with an update, even if no one actually will update their router :( Well, AVM could just register fritz.box and leave it unsigned, which solves the problem for us. If my fritz.box is 192.168.1.254 and yours is 192.168.1.1, what would you want the AVM registered domain fritz.box to return as A record? One of us will break regardless, unless the fritz box hijacks all port 53 to push it through its preprocessor its fake .box domain. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fwd: Re: F24 System Wide Change: Default Local DNS Resolver (fwd)
(resending - looks like mty @redhat.com is not subscribed) On 12/07/2015 04:48 AM, Tomas Hozza wrote: So, here's a question: in germany "Fritzbox" wifi routers are very popular. Their configuration page is reachable under the "fritz.box" pseudo-domain from inside their wifi network, and all other systems on the network are also eachable below this domain under their DHCP-configured hostnames. It implements a DNS proxy otherwise, only synthesizing A/ RRs for *.box. Now, one can certainly argue that this is borked, since the manufacturer doesn't own the ".box" domain, but discussing this is pretty pointless, as the fact that this is what is deployed in probably half of the homes in Germany... Well, there is going to be a very interesting lawsuit about damage then because in a few months .box will be live run by a Hong Kong company called "NS1 Limited" https://www.icann.org/resources/agreement/box-2015-11-12-en .box Registry Agreement 12 Nov 2015 On 12 November 2015, ICANN and NS1 Limited, entered into a Registry Agreement under which NS1 Limited, operates the .box top-level domain. [] Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better solve this quickly with an update, even if no one actually will update their router :( We can make some web page available that will explain how to configure unbound with an override, but I guess it will be a different IP for everyone? Assuming your fritz.box is 192.168.1.1 you can do: echo 'local-data: "fritz.box. 3600 IN A 192.168.1.1"' > /etc/unbound/local.d/fritz.box.conf Of course you can also use /etc/hosts Also I am pretty sure other routers form other manufacturers do the same thing. Now, if we default to DNSSEC validation soon, does this mean people won't be able to configure their wifi routers anymore, or reach other systems on their home networks anymore, because the NSEC/NSEC3 RRs in the root domain claim .box does not exist? Don't they work when you use http://192.168.1.1/ ? What's your strategy there? Why do you think DNSSEC is worth breaking pretty much everybody's network? Note that Fritzbox is not a random crappy router, it's probably of the better products you can find. See above. It's going to get broken anyway. Actually, this could be a security nightmare if someone registers fritz.box and will start receiving connections for IP address that give them their router passwords! I think we could extend the module with an option to configure list of domains for which you would like to fallback to the local resolvers, even if the answer was SECURE. This could be used for the non-existing or "abused" TLDs. That only works if .box is not delegated. Unfortunately, it will be very soon. Initially it will resolve to 127.0.53.53 when the TLD is brought up. So hopefully that will cause people to safely see the failure mode. Only after the domain has launched fully will someone be able to possibly register fritz.box maliciously. Note that IETF is thinking about reserving some of such domains as private [3], so once it is standardized, it could be done for these automatically. Actually DNS servers will either fail those queries, or they will be targeted at the global blackhole running via AS112 I don't think there is any universal or even right solution to this. Once you start doing such hacks, there is a very thin line when you are starting to degrade the security gained by using DNSSEC. Worse, we open up ourselves for legal issues if the domain is delegated. How do other popular desktop/consumer OSes deal with this? Windows, MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC validation by default and how are they dealing with this issue? I'm not able to answer this question. It will start failing for people irrespective of DNSSEC. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Mon, 7 Dec 2015, Lennart Poettering wrote: In case this is blocked on the network, Unbound is configured to tunnel the DNS queries to Fedora public infrastructure over TCP (80, 443) or SSL (443), in which case this is similar to the first situation, when Unbound forwards queries to the resolvers, but does the validation locally. Ahum. This is another deal-breaker. It's really wrong to simply ignore local DNS servers. Just because my local company DNS server doesn't do DNSSEC it's in *no way* OK to make it impossible for me to resolve local names. You *have* to use the local DNS servers by default, even if they are crap. You can't, thanks to hotels and coffeeshops. If your DHCP supplied DNS servers work, then these will be used as forwarders, and you can have your own zone, provided you are not squatting on the namespace of someone else and it will work fine. If you don't you break pretty much half of the setups. For example, with such a Fedora installation I couldn't even print anymore in my local network, This feature should not affect .local, so you should be able to find your printer fine? I couldn't access my NAS anymore, and not reconfigure my router. I couldn't connect to stereo's internal web page, and neither to my internet radio's internal web page. And that's just my little home network. In a company network it's *way* worse... If you use your own domain name for that, all of it will still work. And even without FQDN if you put the right search domains in DHCP. It's completely OK to gracefully degrade to non-DNSSEC DNS if the local DNS server cannot do it. No it is not. coffee shop, hotel network.. The idea of forwarding DNS queries to Fedora servers sounds completely non-sensical to me... Given the port numbers I assume that's even HTTP? No it is raw DNS on port 80. The fedora DNS servers are a "last ditch" effort. If that is needed in your network, you have accumulated several deficiencies you should fix: - don't use broken DNS servers (in other words, yum|dnf update on your dns server) - don't block port 53 to the internet - don't screw up UDP 53 fragments or TCP port 53, or drop >512byte DNS packets If you do all of that, you deserve broken DNS, and I only feel sorry that house of cards did not come down sooner to help you. Do you really think that Fedora is capable and willing to handle all that traffic? It is expected to be extremely rare this is needed. When the IETF drafts for DNSoverTLS are implemented (eg on 8.8.8.8) we suspect it will never be needed again. Are you aware of the infrastructure Google is investing to keep that 8.8.8.8 server up and running? Even if Fedora user's are a tiny tiny fraction of the number of 8.8.8.8 users, the processing power it takes for dealing with HTTPS requests is a multitude of what the 8.8.8.8 requests take... It's TLS without any validation. It's just to get through stupid networks blocking legitimate traffic AND having a DNSSEC-broken (years old!) DNS server running. DNS and DNSSEC are designed to scale, with all its caching, forwarding, offline signing and so on. By then pushing the whole traffic through HTTPS you completely trash all that... It should never happen on networks that normal people build. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Mon, 7 Dec 2015, Matthew Miller wrote: I read your whole post. Those possibilities seem pretty limited, from the point of view of serious regressions in Fedora usability. It isn't that I "like" Fedora being less than technically correct (especially around security-related features), but I don't think we can discount the prevalence of "broken" schemes in the real world. But you gain nothing with waiting. There is no "fix" to wait for. Those stolen domains are broken and they will start to fail. The only difference could be that fedora won't be the first where this breaks on, but I thought "First" was one of our motto's ? I don't really care about that. I care that we pick the solutions that are best for our users. Supporting DNSSEC per default is best for the user. Not enabling DNSSEC is not a serious option. We delayed this feature a few times to ensure we would get better integration with gnome and VPNs so that we could address the _real_ problems. People using stolen or made up domain names is not a use case that can be supported anymore with Secure DNS. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Mon, 7 Dec 2015, Lennart Poettering wrote: Hmm? If I work for a company "Foo Corp" that defined .foocorp as its private TLD, then I won't be able to access servers in that local network until I added .foocorp to a local whitelist Foo Corp should not have done that. If you had picked .hotel or .pizza you would have noticed this already. If you had picked .corp you would soon find your domain blackholed at AS112. Basically, you got away with domain squatting but with DNSSEC this has become indistinguishable from a DNS attack. With DNSSEC validation moving towards to stub, it will just fail. Move your own domains within one of your real legitimate domains, and you have the freedom to do whatever you want. Start moving away from split DNS because that's going to be very hard to support. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/07/2015 04:48 AM, Tomas Hozza wrote: >> So, here's a question: in germany "Fritzbox" wifi routers are very >> popular. Their configuration page is reachable under the "fritz.box" >> pseudo-domain from inside their wifi network, and all other systems on >> the network are also eachable below this domain under their >> DHCP-configured hostnames. It implements a DNS proxy otherwise, only >> synthesizing A/ RRs for *.box. Now, one can certainly argue that >> this is borked, since the manufacturer doesn't own the ".box" domain, >> but discussing this is pretty pointless, as the fact that this is what >> is deployed in probably half of the homes in Germany... Well, there is going to be a very interesting lawsuit about damage then because in a few months .box will be live run by a Hong Kong company called "NS1 Limited" https://www.icann.org/resources/agreement/box-2015-11-12-en .box Registry Agreement 12 Nov 2015 On 12 November 2015, ICANN and NS1 Limited, entered into a Registry Agreement under which NS1 Limited, operates the .box top-level domain. [] Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better solve this quickly with an update, even if no one actually will update their router :( We can make some web page available that will explain how to configure unbound with an override, but I guess it will be a different IP for everyone? Assuming your fritz.box is 192.168.1.1 you can do: echo 'local-data: "fritz.box. 3600 IN A 192.168.1.1"' > /etc/unbound/local.d/fritz.box.conf Of course you can also use /etc/hosts Also I am >> pretty sure other routers form other manufacturers do the same >> thing. Now, if we default to DNSSEC validation soon, does this mean >> people won't be able to configure their wifi routers anymore, or reach >> other systems on their home networks anymore, because the NSEC/NSEC3 >> RRs in the root domain claim .box does not exist? Don't they work when you use http://192.168.1.1/ ? What's your >> strategy there? Why do you think DNSSEC is worth breaking pretty much >> everybody's network? Note that Fritzbox is not a random crappy router, >> it's probably of the better products you can find. See above. It's going to get broken anyway. Actually, this could be a security nightmare if someone registers fritz.box and will start receiving connections for IP address that give them their router passwords! > I think we could extend the module with an option to configure list of domains > for which you would like to fallback to the local resolvers, even if the > answer was SECURE. This could be used for the non-existing or "abused" TLDs. That only works if .box is not delegated. Unfortunately, it will be very soon. Initially it will resolve to 127.0.53.53 when the TLD is brought up. So hopefully that will cause people to safely see the failure mode. Only after the domain has launched fully will someone be able to possibly register fritz.box maliciously. > Note that IETF is thinking about reserving some of such domains as private > [3], > so once it is standardized, it could be done for these automatically. Actually DNS servers will either fail those queries, or they will be targeted at the global blackhole running via AS112 > I don't think there is any universal or even right solution to this. Once you > start doing such hacks, there is a very thin line when you are starting to > degrade > the security gained by using DNSSEC. Worse, we open up ourselves for legal issues if the domain is delegated. >> How do other popular desktop/consumer OSes deal with this? Windows, >> MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC >> validation by default and how are they dealing with this issue? > > I'm not able to answer this question. It will start failing for people irrespective of DNSSEC. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Tue, 1 Dec 2015, Randy Barlow wrote: This sounds overall pretty neat to me! One detail came to my mind: how would this interact with VPN DNS servers? In my experience with VPNs, it's common for them to provide a DNS server that allows internal host resolution to work. Would this local resolver be notified by NM of a new VPN connection so that it knows to use the VPN-provided DNS server for hosts on that particular domain, rather than the usual external records for that same domain? Yes, this already works in most VPN implementations shipped with Fedora. (libreswan/IPsec, vpnc/IPsec, openvpn, and probably openconnect) For IPsec, that support will be extended for IKEv2 in the future too, see https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ The running unbound DNS server will be told to "forward" certain domains to certain IPs of nameservers received during the VPN negotiation. It will remove the forward when the VPN connection goes down. And for those domains, the cache is flushed on each event too, to prevent using stale data that is only used when the VPN is up (or down) Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Tue, 1 Dec 2015, Björn Persson wrote: Tomas Hozza wrote: - dnssec-trigger does not do the Captive Portal detection and handling and we rather rely on NM for the detection and on Gnome Shell for the Portal login Can I assume that users of non-Gnome desktops will also be able to log in to a portal if they want to? If you can do so now, then you will in the future as well? The idea here is that dnssec-trigger will no longer fire up its own portal login page, but leave it to the OS/Desktop. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org
On Mon, 5 Oct 2015, Kevin Fenzi wrote: On Mon, 5 Oct 2015 11:04:40 -0400 Paul Wouters wrote: And openpgpkey-milter :) And put in a TLSA record for their MX :) I don't think it makes much sense for Fedora Infrastructure to get into the business of being a SMTP server provider. Is this something that would help forward the goals of the Fedora Project? If so, how? I wasn't refering to Fedora Infrastructure, but to people running fedora for their mail servers. That said, if we run MX for fedoraproject.org, we should also do that of course :) Paul -- 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: SPF records @fedoraproject.org versus @lists.fedoraproject.org
And openpgpkey-milter :) And put in a TLSA record for their MX :) Paul Sent from my iPhone > On Oct 5, 2015, at 10:58, Michel Alexandre Salim > wrote: > > On a related note to that, it would be great if active Fedora contributors do > get to use an SMTP server with SPF and DKIM set up. > > -- > Michel > >> On Mon, Oct 5, 2015 at 9:47 PM, Marcin Juszkiewicz >> wrote: >> W dniu 05.10.2015 o 16:43, Reindl Harald pisze: >>> well, that people should send their mail from the Fedora servers and >>> not from a wrong configured random MTA allowing random envelope >>> senders >> >> Many of those people send their mail from properly configured MTA allowing >> random envelope senders for authenticated users. >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat
On Fri, 25 Sep 2015, Matthew Miller wrote: On Thu, Sep 24, 2015 at 10:10:40AM +0200, Vít Ondruch wrote: Also, you might consider to ship the precompiled bytecode just optionally, using recommends. On contrary, if you insist on shipping the bytecode, why you don't drop the .py files? I see a lot of duplication all around python packages Wait, we can do that? Why don't we? Everything I see in online discussion is centered on, basically, transparency. But we wouldn't be doing it for obfuscation. The srpms would still be there, and for that matter we could ship the .py files in a subpackage. It's nice to be able to edit the .py for testing without going through hoops or building/installing rpms. It's also nice to be able to read the .py code. That is one reason people use script languages :P Paul -- 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: Disable PulseAudio flat volumes to prevent it from pushing volume level to max
On Mon, 21 Sep 2015, Owen Taylor wrote: Experimenting with GNOME, the model presented to the user seems to be: - Each application's volume control separate goes from 0-100% of the maximum system volume. - Adjusting each application is independent - Modifying the system global volume slider proportionally adjusts the volume of each application - The system global volume slider is always maintained to be at least as much as the maximum of any application Unfortunately, for endusers like me, who want pidgin to not blare out, there isn't a simple user interface to let me select that. Like let's say a right click on the top right volume icon that would show all apps with volume so I can bring pidgin volume down. So as a result, I always end up using the system volume control, and after I play a movie or an mp3, pidgin blares out loudly. So the current system is clearly not working for me. Paul -- 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: bind: CVE-2015-5722 and CVE-2015-5986
On Fri, 4 Sep 2015, Bojan Smojver wrote: According to ISC, these two affect bind 9.10.2 as well (up to P3). There a no new builds (i.e. P4) for F22 of this package that I can see. Does anyone know why? Is there something Fedora specific that prevents these problems in F22 packages? I just built it in rawhide, and it seems fine. I suspect it has just been an "no time" issue. I'll ping Tomas and ask him. Paul -- 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: Cleanup of Upstream Relase Monitoring bugs
On Wed, 2 Sep 2015, Vít Ondruch wrote: 3) Packages are updated, but the bug is kept open I would suggest probably to close the bugs for 1st category, the packages from 2nd category should be orphaned and the packages from 3rd category should not be monitored anymore. Any thoughts? I would keep monitoring for 3) but close onesting bugs that are too old and were clearly forgotten. I prefer to be informed by the monitor script, even if I am a version behind :) I've also just now added comments for all my entries on why these are still not in CLOSED state. Paul Vít [1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Copendate&email1=upstream-release-monitoring%40fedoraproject.org&emailreporter1=1&emailtype1=substring&list_id=1733771&order=changeddate%20DESC%2Cbug_id%20DESC&query_based_on=&query_format=advanced [2] https://fedoraproject.org/wiki/Upstream_release_monitoring -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: perl-Net-DNS-SEC license correction
On Fri, 7 Aug 2015, Petr Šabata wrote: This package's license tag was wrong all along; the license tag will be corrected to `MIT'. Updates are on the way. hm, I had 1.01 packages pending.. Also, the license says GPL+ or Artistic. The README says: Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific prior written permission. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Is that not the artistic license? Paul -- 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: gpg keys of older/newer fedora versions
On Wed, 5 Aug 2015, Neal Gompa wrote: I disagree that including the keys for EOL'd releases counts as "encouraging" people to use old stuff. If someone has a reason to be building RPMs for something way-old, I think it'd be nice for us to keep those GPG keys available for them. Agreed. Paul -- 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: Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners
On Fri, 17 Jul 2015, Chuck Anderson wrote: What doesn't work in your experience with the captive portal stuff? Usually, the dnssec-triggerd captive portal detection pops up a dialog, and when I click "log in" nothing happens. When I click "skip" (sorry I might be forgetting the exact button names) then a captive portal browser pops up (I think this is the normal Gnome or NM one, again not sure). Usually things work fine after logging in there. Yes, the xdg-open command that launches the captive portal login of dnssec-trigger often does not get launched for me either. Usually I already have firefox open, so i go to 1.2.3.4 or something to trigger it. Even without the recent SELinux issues, dnssec-triggerd's captive portal implementation has been iffy. Sometimes it works, and sometimes it doesn't. I think there may be an issue with it trying to launch the captive portal login browser, or timing issues between Gnome/NM and dnssec-triggerd. Yeah, I am not entirely sure what's causing it either. Paul -- 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: gpg keys of older/newer fedora versions
On Fri, 17 Jul 2015, Zbigniew Jędrzejewski-Szmek wrote: [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383] 'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap a Fedora chroot. The only snag is that --nogpg is often recommended, because fedora-repos only provides the GPG keys for the current and next release. It would be convenient (and safe!) to provide keys for past and future releases, so such bootstrapping can be done without either importing the keys manually and/or using --nogpg. I thought I'd ask here first: is there a strong reason *not* to include those keys? I see no reason not to do that. We were also going to put those keys into DNS, pendig some changes of the OPENPGPKEY ietf draft document. Paul -- 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: dnssec-trigger + GNOME + NetworkManager integration
And dnssec-validator.cx for a Firefox/chrome plugin that you can see in action against fedoraproject.org that already deploys this Sent from my iPhone > On Jul 3, 2015, at 10:43, Petr Spacek wrote: > >> On 2.7.2015 17:56, Michael Catanzaro wrote: >>> On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote: >>> this type of attitude? >>> >>> everybody who reads IT news over the past years about CA's issued >>> certificates even for Google knows that a CA signed certificate does >>> not >>> prove anything - the real problem is wehn this happens for Google >>> somebody takes notice and the press writes about it >>> >>> if the same happens for your domain nobody will recognize it >> >> The situation is going to be getting a lot better in the near future, >> though. We're getting to the point where we can start enforcing >> Google's certificate transparency: if your certificate isn't on the >> public audit list, we can simply reject it. That allows individual web >> sites to get an immediate heads-up whenever any fraudulent certificate >> is issued for their site. (And researchers will be looking after the >> most important sites, of course.) That's not going to fix TLS in >> itself, because most sites probably don't care, but if the site does >> care, it will be impossible to issue a browser-trusted certificate for >> the site without that site knowing. (At least, that's my understanding >> of the technology; I haven't researched it thoroughly.) >> >> You're right that OCSP is worthless. GNOME applications don't currently >> perform any certificate revocation; I'm not willing to implement OCSP >> unless Firefox is willing to enforce it, and they aren't. We should >> implement OneCRL, which solves the revocation problem for intermediate >> certificates, but there doesn't seem to be any reasonable solution for >> individual sites yet. OCSP must-staple seems promising. >> >> Of course, we can't have any of these nice features in GNOME unless >> somebody wants to pay for their implementation. (If so, get in touch >> please.) > > For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. > > -- > Petr Spacek @ Red Hat > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 1 Jul 2015, Michael Catanzaro wrote: Date: Wed, 1 Jul 2015 19:26:55 From: Michael Catanzaro To: devel@lists.fedoraproject.org Subject: Re: dnssec-trigger + GNOME + NetworkManager integration On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: That's the same as saying remove the "continue anyway" frmo the browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise it. I guess I prefer a "continue anyway" with brief non-techniacl text, but beggars can't be choosers. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct