Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Gordon Messmer]

On 9/29/20 9:18 AM, Lennart Poettering wrote:

So let me ExecSum what I wrote here. For systemd-resolved to become
a high quality DNS solution:

1) Remove custom DNS/DNSSEC resolving code and use a well maintained
DNS library.

"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way. I mean, given that Ubuntu has been enabling
systemd-resolved since quite some time by default I have the suspicion
our codebase is more often deployed IRL than the ones you listed?



Ubuntu enables it by default, but we don't know how many people use it.  
My employer does not.  Our AD domain has a LOT of controllers, due to a 
large number of offices around the world. systemd-resolved couldn't 
handle resolving the A record for our domain, so we had to turn it off.


I believe that was fixed in PR 11993, but that bug was enough to 
convince me very solidly that systemd-resolved should have re-used an 
existing protocol implementation rather than writing another one.


You're right that DNS has of quirks and compatibility issues, and that's 
exactly why writing another protocol implementation is such a poor decision.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-09-30 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/09/30/report-389-ds-base-1.4.4.4-20200929gitdf3a512.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1880278] perl-DBD-Mock-1.57 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1880278

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBD-Mock-1.57-1.fc34   |perl-DBD-Mock-1.57-1.fc34
   |perl-DBD-Mock-1.57-1.fc33   |perl-DBD-Mock-1.57-1.fc33
   ||perl-DBD-Mock-1.57-1.fc32



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-04589065e3 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880040] perl-DBD-Mock-1.56 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1880040

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBD-Mock-1.56-1.fc34   |perl-DBD-Mock-1.56-1.fc34
   |perl-DBD-Mock-1.57-1.fc33   |perl-DBD-Mock-1.57-1.fc33
   ||perl-DBD-Mock-1.57-1.fc32



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-04589065e3 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-090d853dd7   
singularity-3.6.3-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7d1114b762   
xawtv-3.105-2.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

python-regex-2020.9.27-1.el6

Details about builds:



 python-regex-2020.9.27-1.el6 (FEDORA-EPEL-2020-781278de36)
 Alternative regular expression module, to replace re

Update Information:

Update python-regex to the latest release.

ChangeLog:

* Tue Sep 29 2020 Thomas Moschny  - 2020.9.27-1
- Update to 2020.9.27.


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1870746] EPEL8 Branch Request: perl-Test-TempDir

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1870746

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Test-TempDir-0.11-1.el
   ||8
 Resolution|--- |ERRATA
Last Closed||2020-09-30 01:37:17



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-97732a2b90 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870743] EPEL8 Branch Request: perl-Data-Stream-Bulk

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1870743
Bug 1870743 depends on bug 1870746, which changed state.

Bug 1870746 Summary: EPEL8 Branch Request: perl-Test-TempDir
https://bugzilla.redhat.com/show_bug.cgi?id=1870746

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870754] EPEL8 Branch Request: perl-Data-Dumper-Concise

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1870754

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Data-Dumper-Concise-2.
   ||023-12.el8
 Resolution|--- |ERRATA
Last Closed||2020-09-30 01:37:19



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-97732a2b90 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1870745] EPEL8 Branch Request: perl-DBIx-Class

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1870745
Bug 1870745 depends on bug 1870754, which changed state.

Bug 1870754 Summary: EPEL8 Branch Request: perl-Data-Dumper-Concise
https://bugzilla.redhat.com/show_bug.cgi?id=1870754

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1859831



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-707592630e has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-707592630e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-707592630e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1855962] bugzilla can't send non-html email

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1855962



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-53cdcb90d8 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-53cdcb90d8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-53cdcb90d8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1855962] bugzilla can't send non-html email

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1855962



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-707592630e has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-707592630e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-707592630e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1859831



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-53cdcb90d8 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-53cdcb90d8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-53cdcb90d8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1883370] perltidy-20201001 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1883370



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-680bc171eb has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-680bc171eb`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-680bc171eb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1859831

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-ed56800b3e has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-ed56800b3e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed56800b3e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1855962] bugzilla can't send non-html email

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1855962

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-ed56800b3e has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-ed56800b3e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed56800b3e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1883498] perl-Module-Load-0.36 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1883498

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-017a46fd23 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-017a46fd23`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-017a46fd23

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1883370] perltidy-20201001 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1883370

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-14cb2245b0 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-14cb2245b0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-14cb2245b0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1881518] perl-Unicode-Collate-1.28 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1881518



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-b25e451b3f has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-b25e451b3f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b25e451b3f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882884] perl-Lingua-Stem-2.31 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882884

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-2e650a2293 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-2e650a2293`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2e650a2293

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882957] perl-Unicode-Collate-1.29 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882957

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-b25e451b3f has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-b25e451b3f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b25e451b3f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882938] perl-File-Temp-0.2310 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882938

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-4625bcf116 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-4625bcf116`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-4625bcf116

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1865207] perl-IO-Async: FTBFS in Fedora rawhide/f33: Failed test '->failure [3] gives EAI_NONAME or EAI_NODATA'

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1865207

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-IO-Async-0.77-5.fc34   |perl-IO-Async-0.77-5.fc34
   ||perl-IO-Async-0.77-5.fc33
 Resolution|--- |ERRATA
Last Closed||2020-09-30 00:15:09



--- Comment #11 from Fedora Update System  ---
FEDORA-2020-70fc3971f6 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882212] perl-Gnome2-GConf-1.045 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882212

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gnome2-GConf-1.045-1.f |perl-Gnome2-GConf-1.045-1.f
   |c34 |c34
   ||perl-Gnome2-GConf-1.045-1.f
   ||c33
 Resolution|--- |ERRATA
Last Closed||2020-09-30 00:15:07



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-3df61d9478 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882211] perl-Gnome2-Canvas-1.003 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882211

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gnome2-Canvas-1.003-1. |perl-Gnome2-Canvas-1.003-1.
   |fc34|fc34
   ||perl-Gnome2-Canvas-1.003-1.
   ||fc33
 Resolution|--- |ERRATA
Last Closed||2020-09-30 00:15:05



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-453e37a9e1 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1880850] perl-libwww-perl-6.48 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1880850

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.48-1.fc3 |perl-libwww-perl-6.48-1.fc3
   |4   |4
   ||perl-libwww-perl-6.49-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2020-09-30 00:15:01



--- Comment #11 from Fedora Update System  ---
FEDORA-2020-584e685542 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1882183] perl-libwww-perl-6.49 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1882183

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.49-1.fc3 |perl-libwww-perl-6.49-1.fc3
   |4   |4
   ||perl-libwww-perl-6.49-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2020-09-30 00:15:03



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-584e685542 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Neal Gompa]

On Tue, Sep 29, 2020 at 4:29 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
>
> == Summary ==
> Provide .debug_names debug info index for LLDB for clang-built
> binaries using: clang -gdwarf-5 -gpubnames
>
> Debuginfo index significantly accelerates loading of *.debug files by
> debugger. Fedora currently provides ELF section .gdb_index for
> [https://www.gnu.org/software/gdb/ GDB debugger].
> [https://lldb.llvm.org/ LLDB debugger] cannot use .gdb_index (as it is
> missing DIE offsets for more effective processing by LLDB) but LLDB
> can use .debug_names index.
>
> == Owner ==
> * Name: [[User:jankratochvil| Jan Kratochvil ]]
> * Email: jan.kratoch...@redhat.com
>
> == Detailed Description ==
>
> There are currently 3 formats of debug info index:
>
> * .gdb_index: It is currently produced in Fedora by GDB
> (/usr/bin/gdb-add-index), it is a part of rpmbuild process. It is
> compatible with GDB but incompatible with LLDB as it is missing
> essential DIE offsets needed by LLDB due to more effective (faster)
> reading of DWARF by LLDB.
>
> * .debug_names from GDB (augmentation "GDB\x00"): It can be produced
> by GDB (/usr/bin/gdb-add-index -dwarf-5) but its format is
> non-conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
> standard]. LLDB expects DWARF-5 standard compliant .debug_names and
> therefore it is incompatible with this format. It can be expected GDB
> will fix the conformance in the future. Currently GDB .debug_names
> format has no advantage over GDB .gdb_index format.
>
> * .debug_names from clang (augmentation "LLVM0700"): It can be
> produced by clang (clang -gdwarf-5 -gpubnames) for LLDB. It is
> conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
> standard], one can expect GDB will be able to read it in the future.
>
> It would be good to produce index from GCC by GDB and to produce index
> from clang by clang as the compatibility inside the same toolchain is
> best tested and supported. Using index across toolchains (index from
> GDB by LLDB or index from clang by GDB) should theoretically work but
> in practice there exist subtle differences in interpretation of more
> complicated DWARF constructs. It would be best to fix those but that
> will be always an afterthought.
>

Why don't you add an lldb-add-index tool to generate LLVM indexes for
LLDB? Then we just invoke it as part of the buildroot policy setup and
get both GDB and LLDB indexes? This proposal seems to be particularly
destructive to GDB users to favor LLDB.

I personally don't use LLDB for *anything*, since I think it's not a
particularly good debugger right now, and I would not be happy if the
performance of debugging clang-built things with GDB degraded.

>
>
> == Benefit to Fedora ==
> * Faster startup of LLDB debugger using Fedora system *.debug files.
>
> == Scope ==
> * Proposal owners: It affects all clang-built packages generating
> *-debuginfo.rpm.
> * Other developers: none
> * Policies and guidelines: All the needed changes should be done in
> [https://src.fedoraproject.org/rpms/redhat-rpm-config
> redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
> package] can be then retired.
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: The size differences are only for
> *-debuginfo.rpm which is outside of scope of the listed objectives.
>
>
> Currently the change will affect only packages using:
>  %global toolchain clang
> Those are currently only these packages being built by clang and using
> this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
> wine
>
> FIXME: Which other Fedora packages are being built by clang?
>
> == Upgrade/compatibility impact ==
> Existing tools not supporting .debug_names will just ignore the
> additional ELF section. The only issue is current GDB would get
> confused by the clang .debug_names as it expects .debug_names to be in
> its incompatible GDB format - FIXME: Provide a GDB bugfix patch.
>
> Also each *-debuginfo.rpm has to exactly match NVRA of its binary
> package the Fedora change compatibility is not applicable.
>
> == How To Test ==
> GDB should not get affected by the new .debug_names index from clang.
>
> LLDB should load Fedora system *.debug files faster. LLDB
> functionality should not be affected by the index from clang (that is
> a part of LLVM development/testsuite).
>
> "llvm-dwarfdump -debug-names *.debug" should show: Augmentation: 'LLVM0700'
>
> == User Experience ==
> No user visible change. This affects what tools can developers use.
>

Developers are users. Please include what improvements they will get
from this change here.

> == Dependencies ==
> This Change is dependent on how is decided 
> [[Changes/DebugInfoStandardization]].
>

Why? That change is only about dwz, this is about adding indexes for
LLDB to use.

> This Change is dependent on RHEL-5 F-34 feature expected to be filed
> by Mark Wielaard.
>

I assume you mean RHEL-9 here. 

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Michel Alexandre Salim]

On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
> 
[snip]
> 
> It would be good to produce index from GCC by GDB and to produce
> index
> from clang by clang as the compatibility inside the same toolchain is
> best tested and supported. Using index across toolchains (index from
> GDB by LLDB or index from clang by GDB) should theoretically work but
> in practice there exist subtle differences in interpretation of more
> complicated DWARF constructs. It would be best to fix those but that
> will be always an afterthought.
> 
> 
That seems reasonable

[snip]
> 
> Currently the change will affect only packages using:
>  %global toolchain clang
> Those are currently only these packages being built by clang and
> using
> this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
> wine
> 
> FIXME: Which other Fedora packages are being built by clang?
> 
Should this be mentioned as part of some packaging guidelines?
Especially as we expect more packages to use clang in the future.

[snip]
> == Dependencies ==
> This Change is dependent on how is decided
> [[Changes/DebugInfoStandardization]].
> 
> This Change is dependent on RHEL-5 F-34 feature expected to be filed
> by Mark Wielaard.
RHEL-9, not 5?

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Neal Gompa]

On Tue, Sep 29, 2020 at 7:32 PM Jeff Law  wrote:
>
>
> On 9/28/20 8:50 AM, Jan Kratochvil wrote:
> >
> > DWARF standard sometimes makes mistakes, for example .debug_pubnames and
> > .debug_pubtypes were never really usable and DWARF-5 removed them. It may be
> > perfectly possible the DWZ extension of DWARF-5 will be removed in DWARF-6 
> > or
> > future DWARF standards as it turns out it is not worth the format 
> > complexity.
> > That some text has been accepted into the DWARF standard does not mean much.
> Sure.  We all make mistakes and standards bodies are no different. If
> you feel strongly that it was a mistake, then get involved in the
> process and try to correct it.
> >
> > It is all about engineering effort. I agree if the support of DWZ was 
> > trivial
> > (or there were unlimited engineering resources) then DWZ is really better 
> > than
> > -fdebug-types-section (except it would need a DWZ tool with less bugs and
> > better coding practices). But reality shows the DWZ support is not trivial
> > engineering resources for Fedora are very limited and so we have to decide
> > whether the serious effort to support DWZ is better spent on DWZ or on 
> > making
> > the debuggers better/really usable.
> >
> > Given how much you propose DWZ apparently the 3.3% Fedora distribution size
> > increase (if DWZ is dropped) is considered as too much. Obviously if the 
> > size
> > increase was just let's say 0.1% it would be acceptable to drop DWZ - do you
> > agree? So where is your size limit where the years-effort of supporting DWZ 
> > is
> > worth it? I would say my limit would be maybe 20%, far above the 3.3%.
>
> Putting my Red Hat hat on, I get pushback from PM on *any* size
> increases in the RHEL space.   While I often question the technical
> reasons behind why our customers are pushing for marginal (IMO)
> improvements, reality is they care.  As much as we'd like to be in a
> world were a 1% increase in distro size doesn't matter, that's not the
> actual world we live in.
>
> And our RHEL customers absolutey do care about the size of debuginfo
> becuause it affects link times.
>
>
> Anyway, I'll put my Fedora hat back on :-)
>
>

I feel like it's worth giving my perspective here as someone who has
done similar work in other distributions.

Because of how little debuginfo is used *in general*, every bit of
space saving matters. The dwz technology took so long to be adopted
because the rpm support never made it upstream. It took some poking
and prodding to finally get it upstreamed for RPM 4.14, and in doing
so, distros started using it because they were comfortable with
relying on the feature.

I don't think people realize how scary the debuginfo code actually is
for us "plebs" wanting to support it while having no knowledge or hope
of understanding the depths of it all. It's a very esoteric system.
Most of the distributions were unwilling to pull in an out-of-tree
patch out of fear of being stuck supporting it alone. For RPM
distributions, once it was mainlined, that fear was gone. The Debian
distribution family had the benefit of being able to reimplement the
whole system initially based on how it works in Fedora for them, and
once they did that, it was inherited by that entire branch of Linux
distributions.

I personally worked on enabling advanced debuginfo generation features
in rpm for OpenMandriva when I helped migrate them to RPM 4.14 and
DNF[1]. The only real trouble was with Clang being broken with split
debuginfo+debugsource with Clang/LLVM 7[2], which was fixed after
upgrading to Clang/LLVM 10[3].

The quality of life improvements with advanced rpm debuginfo
generation and dwz have made it tremendously easier for me and others
to be able to ship debuginfo data for more packages. And as developers
*need* that data to be able to... well, debug things, it comes in
handy having it everywhere.

I have also helped with bringing this to other distributions, but I
feel that my story here with OpenMandriva is particularly important
since we seem to be having a tug-of-war between the GCC and LLVM
toolchain teams.

[1]: https://www.openmandriva.org/en/news/article/switching-to-rpmv4
[2]: 
https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/a54ffd78b1eaeb1752cb7894ffdb266fb5b85311
[3]: 
https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/5b432a2d3d1c9c4aefbab04f937aed8b8c4618d8

[...]
>
> > By that LLVM dead DIES reduction talk I wanted to just show apparent nobody
> > cares too much about few percents of the *-debuginfo.rpm size - otherwise it
> > would be already coded/used. Or if there wasn't DWZ Fedora could already
> > switch to DWARF-5 which saves probably more size than DWZ does.
>
> I wasn't even aware we had dead dies.  THat doesn't mean I don't care,
> it just means I wasn't aware.  Others may be aware, but have higher
> priority items on their TODO lists.  Stating that "nobody cares too much
> ..." isn't helpful.
>

For the record, Mark has started 

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jeff Law]

On 9/28/20 8:50 AM, Jan Kratochvil wrote:

On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:

If you want to make -fdebug-types-sections the default you really
should work with the upstream GCC developers to figure out why they
don't want that.

I haven't seen that, according to Richard Biener from GCC
-fdebug-types-section is a normally supported GCC feature:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878#c6
I am aware only of Jakub Jelinek who is against -fdebug-types-section.
I should also state he is the author of DWZ.


-fdebug-types-section a supported option in the sense that it's in the 
compiler and we'll fix bugs in it when we can.  But the GCC community 
doesn't really test that option and it's known to be broken with LTO.  
With the move to LTO for F33 we'd need to fix whatever is broken with 
-fdebug-types-section (and I don't know precisely what that is) before 
we could even consider turning it on.


 Jakub has a ton of experience with debug info generation in GCC as 
well as with the dwarf standardization process and based on those 
experiences he thinks dwz is a technically better solution. You 
disagree.  I would strongly advise against hinting that Jakub is biased 
against -fdebug-types-section simply because he is the author of dwz.  
That just makes you look combative.




If GCC is unable to support such a trivial feature as -fdebug-types-section
then Fedora should really already switch to the standard compiler. It will
come sooner or later anyway. This deviation from standard tools just causes
continuous troubles such as:
[fesco] Issue #2020: Firefox is switching from gcc to clang/llvm
https://pagure.io/fesco/issue/2020#comment-671672


I don't think it argues for that *at all*.  Not even close.


I do think we want to bring GCC and LLVM to parity and remove the Fedora 
policy which favors GCC.  I've still got a TODO to write the actual 
changes for the Fedora packaging guidelines to make that happen.







Trying to override upstream defaults in Fedora without understanding why
upstream decided on the current defaults isn't a good idea IMHO.

You know very well Fedora already overrides upstream GCC defaults a lot:
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection


And, not surprisingly, our team has had significant input on the options 
we're using *and* the GCC implementation of those options.   We make 
recommendations based on our experiences. That same experience would 
lead us to recommending against -fdebug-types-section at this time.







And DWZ is even a project unrelated to GCC so calling for upstream defaults
would really call for dropping DWZ.


Again, I don't see that at all.  dwz is a separate and distinct step in 
the build process.  It's not overriding anything in the compiler at all.








I totally get that it is frustrating if you worked for a long time on a
new feature to support some DWARF constructs for lldb

It is in no way a feature as it does not bring any user visible improvement.
It is only a compatibility with marginally (0.1%) used file format with
disputable benefits.



and your aren't able to get the patches in shape to be accepted upstream.

That is a repeated lie I have never even suggested. LLDB is fine accepting my
DWZ patches. I understand you are used to difficulty of upstreaming patches in
GNU projects but that is not the case of LLVM. In fact LLDB is a completely
different world in accepting patches than GDB where it was taking me even 10+
years to get some patches accepted. For GDB you need to learn first how to do
the ancient ineffective and bug-prone coding practices, force yourself to
really execute them to become a global maintainer and only then you manage to
get patches checked in.

You are repeatedly trying to make it look as the problem is upstreaming DWZ
support. That is not any problem. The problem is the DWZ itself as it just
isn't worth the effort of supporting it in all the consumers.


But -fdebug-types-section isn't a viable alternative right now IMHO.




As I am repeating again and again I just find DWZ too complicated for both
production and consumption for so little gain (size reduction) it achieves.
So before I complicate the LLDB codebase by the DWZ support and make it
a catch-up game for Red Hat, Fedora and others forever (as Apple+Google is
never going to use DWZ and they know why) I am trying by this Change to save
a lot of time for everyone.

The years of engineering time I have already spent on DWZ and the years of
engineering time I will have to spend on its future maintenance and reworks
(for clang DWARF) could be better spent on improving the debugging experience.
We are no 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 17:50 -0400, Neal Gompa wrote:
> On Tue, Sep 29, 2020 at 5:44 PM Michael Catanzaro  
> wrote:
> > On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett 
> > wrote:
> > > To step in here, regulatory compliance is a non optional requirement
> > > around the world.
> > > 
> > > Regulatory compliance applies to everybody in a jurisdiction, there
> > > is no such thing as a “specialized deployment” or environments
> > > where it “will not matter”. Compliance doesn’t care about an
> > > arbitrary freeze.
> > > 
> > > This is not a technical decision.
> > 
> > This is either a very strange misunderstanding, or trolling. I will
> > assume positive intent. Internet RFCs are not regulatory requirements.
> > If you're aware of some government regulation that requires us to
> > forward RRSEC records, I would be very surprised, but please do let us
> > know.
> > 
> 
> Also, in case folks weren't aware, IETF RFCs are *intentionally* not
> described as standards. They are designed to be subject to revision at
> more or less any time. That's why they are titled as a "Request for
> Comments" (or RFC). The fact that they are used as standards
> documentation is sort of the nature of how things developed from an
> era where it was impossible to publish standards for free
> (organizations like the ISO require paying money for standards
> documentation).

Sorry Neal, but this is not correct, in IETF there are several RFC
types:
- standard
- informational
- experimental
- best current practice
etc..

There are *definitely* officially defined by IETF "Standard" RFC, but
not all RFC are standard for sure.

> But this also has the consequence that IETF RFCs do not have a
> requirement to be evaluated in the context of others and determined to
> be fully satisfiable along others. That is, it's possible to have
> mutually exclusive RFCs for a system that you have to implement.

This is true, but much less so for standard RFCs.

> So please keep that in mind when considering discussing DNS.

Always use a grain of salt with *any* standards, even ISO standards are
often made by mandatory and optional parts, and sometimes they are
conflicting too ... and then there are standards from different
organizations that may be in partial conflict as well, welcome to the
world :-)

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proven packager help needed to rebuild packages

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> > Hi,
> > 
> > I'm coordinating rebuilds of packages due to the libevent rebase [1]
> > and I'm having trouble reaching owners of some of the packages. Is
> > there a proven packager willing to help me with the rebuilds?
> > 
> > The rebuilds should be done using the following command:
> > 
> > fedpkg build --target=f34-build-side-30069
> 
> I started the builds now. Unfortunately quite a few have failed.
> In general fedpkg build --target=f34-build-side-30069 --nowait
> seems to take a lot of time, sometimes maybe a minute.
> 
> > The following packages need to be rebuilt. Note that it is expected
> > that 'sems' will fail to build, however I think we should try anyway.
> > 
> > 389-ds-base
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
> BuildError: Error running GIT command "git clone -n 
> https://src.fedoraproject.org/rpms/389-ds-base.git 
> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
>  see checkout.log for details
> 
> I restarted the build, let's see how it does:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545
> 
> > ccnet
> > groonga
> failed with error:
> attempt to use unversioned python, define %__python to /usr/bin/python2 or 
> /usr/bin/python3 explicitly
> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to expand
> error: query of specfile groonga.spec failed, can't parse
> 
> > links
> > lldpd
> > mpris-scrobbler
> > nbd-runner
> > netatalk
> > nsd
> > perl-Event-Lib
> > pgbouncer
> After starting the build I saw that it was already rebuilt:
> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek 
>  - 1.14.0-5
> - Rebuilt for libevent 2.1.12
>  
> * Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
> - Rebuild against new libevent
> 
> An additional build probably doesn't hurt.
> 
> > remctl
> > seafile
> > sems
> > sslsplit
> > sstp-client
> > tmate
> > trickle

They all built after some pushing and prodding, with the exception of sems:

In file included from EarlyAnnounce.cpp:27:
EarlyAnnounce.h:37:10: fatal error: cppconn/driver.h: No such file or directory
   37 | #include 
  |  ^~

I looked online and this file seems to be provided by 
mysql-connector-c++-devel.rpm
in some other places, but not in Fedora. We don't seem to have this library at 
all...
Can someone who knows mysql confirm?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Marius Schwarz]

Am 29.09.20 um 14:38 schrieb Neal Gompa:
> If you're a remote employee, it absolutely is. And especially in this
> pandemic, this kind of thing is now the *default* experience.

Company network - check
Fedora 31 Laptops - check
VPN users - check
Androids - check
Windows Laptops - check
internal dns - check
private domains - check

Not every company network is complicated.

best regards,
Marius
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1823526] bugzilla fails to build with Sphinx 3.0.0

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1823526

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||bugzilla-5.0.6-9.fc33
 Resolution|--- |CURRENTRELEASE
  Flags|needinfo?(emmanuel@seyman.f |needinfo+
   |r)  |
Last Closed||2020-09-29 21:59:58



--- Comment #4 from Emmanuel Seyman  ---
Sorry, I forgot to update here.

I've just released an update of bugzilla on all stable branches. The F33
version was built against sphinx 1:3.2.1-1.fc33


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

F33 beta: where are my Rust packages?

[Artur Frenszek-Iwicki]

I maintain two Rust packages, rust-copydeps [1] and rust-desed [2]. Both were 
built for F33 ([3], [4]) before it branched off for Rawhide (and submitted to 
bodhi ([5], [6])). I gave the F33 beta a spin and when I tried "dnf install 
copydeps desed", I got no matches. Other Rust packages, like rust-exa and 
rust-ytop, install fine.

Was there some change to the Rust packaging process that I missed? If not, why 
are the packages not available?

A.FI.

[1] https://src.fedoraproject.org/rpms/rust-copydeps
[2] https://src.fedoraproject.org/rpms/rust-desed
[3] https://koji.fedoraproject.org/koji/buildinfo?buildID=1572147
[4] https://koji.fedoraproject.org/koji/buildinfo?buildID=1507459
[5] https://bodhi.fedoraproject.org/updates/FEDORA-2020-74b3aa82d5
[6] https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ef745ad6e
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Neal Gompa]

On Tue, Sep 29, 2020 at 5:44 PM Michael Catanzaro  wrote:
>
> On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett 
> wrote:
> > To step in here, regulatory compliance is a non optional requirement
> > around the world.
> >
> > Regulatory compliance applies to everybody in a jurisdiction, there
> > is no such thing as a “specialized deployment” or environments
> > where it “will not matter”. Compliance doesn’t care about an
> > arbitrary freeze.
> >
> > This is not a technical decision.
>
> This is either a very strange misunderstanding, or trolling. I will
> assume positive intent. Internet RFCs are not regulatory requirements.
> If you're aware of some government regulation that requires us to
> forward RRSEC records, I would be very surprised, but please do let us
> know.
>

Also, in case folks weren't aware, IETF RFCs are *intentionally* not
described as standards. They are designed to be subject to revision at
more or less any time. That's why they are titled as a "Request for
Comments" (or RFC). The fact that they are used as standards
documentation is sort of the nature of how things developed from an
era where it was impossible to publish standards for free
(organizations like the ISO require paying money for standards
documentation).

But this also has the consequence that IETF RFCs do not have a
requirement to be evaluated in the context of others and determined to
be fully satisfiable along others. That is, it's possible to have
mutually exclusive RFCs for a system that you have to implement.

So please keep that in mind when considering discussing DNS.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett  
wrote:
To step in here, regulatory compliance is a non optional requirement 
around the world.


Regulatory compliance applies to everybody in a jurisdiction, there 
is no such thing as a “specialized deployment” or environments 
where it “will not matter”. Compliance doesn’t care about an 
arbitrary freeze.


This is not a technical decision.


This is either a very strange misunderstanding, or trolling. I will 
assume positive intent. Internet RFCs are not regulatory requirements. 
If you're aware of some government regulation that requires us to 
forward RRSEC records, I would be very surprised, but please do let us 
know.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Graham Leggett]

On 29 Sep 2020, at 22:04, Michael Catanzaro  wrote:

> On Tue, Sep 29, 2020 at 4:51 pm, Petr Menšík  wrote:
>> Anyway, we might forgive working dnssec validation. What we cannot
>> forgive is lack of DNSSEC information passtrough in 2020.
> 
> I agree this should be fixed. See 
> https://bugzilla.redhat.com/show_bug.cgi?id=1879028.
> 
> However, since this only matters for specialized server deployments, and will 
> not matter for desktop usage or most server deployments, and since the 
> workaround is very easy (just edit /etc/resolv.conf) it's really extreme to 
> suggest it should be a release blocker when we have one week to go before 
> final freeze. That timeframe is way too tight.

To step in here, regulatory compliance is a non optional requirement around the 
world.

Regulatory compliance applies to everybody in a jurisdiction, there is no such 
thing as a “specialized deployment” or environments where it “will not matter”. 
Compliance doesn’t care about an arbitrary freeze.

This is not a technical decision.

Regards,
Graham
—
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 10:58 pm, David Sommerseth  
wrote:

Ubuntu 20.04 has also enabled systemd-resolved
by default, but it seems it has not gone as far as Fedora 33.


Ubuntu has enabled systemd-resolved by default since Ubuntu 16.10, but 
it doesn't use nss-resolve, so getaddrinfo() uses traditional nss-dns 
that reads /etc/resolv.conf. In contrast, Fedora is using nss-resolve 
as recommended by upstream, so getaddrinfo() bypasses /etc/resolv.conf 
and instead talks directly to systemd-resolved.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[David Sommerseth]

On 29/09/2020 17:21, Paul Wouters wrote:
> 
> For the VPN scenario, it is just a little bit more complicated.
> 
> For those with proper standards, such as "Cisco IPsec", L2TP/IPsec",
> the VPN confiuration is dictated by the server to either send all or
> some traffic to the VPN server. If it is not "everything", then these
> VPNs convey 1 domain name and one or more IP's of DNS servers to use
> to resolve that domain.
> 
> For IKEv2 IPsec based VPNs, any number of domain names can be specified
> by the server to be used by the client. When doing split-DNS with DNSSEC
> trust anchors, these can be conveyed and there are strict rules on when
> to allow these to override public DNSSEC trust anchors as per RFC 8598.
> 
> For VPN protocols with no real standard, things are more complicated.
> 
> OpenVPN can do custom things. It all depends on the provisioning. 

As an OpenVPN developer, I can't resist giving a few details here :)

OpenVPN 2.x using the openvpn-client@.service unit files depends entirely on
the OpenVPN configuration.  So you are right here.

OpenVPN 2.x using NetworkManager, will let NetworkManager pick up changes and
apply them accordingly to the abilities of the NetworkManager-openvpn plugin.

OpenVPN 3 Linux can be enabled with systemd-resolved support [0], but
out-of-the-box it will modify /etc/resolv.conf directly.  Enabling
systemd-resolved support, you will get fairly close to a split-DNS setup but
not completely - but this integration is still considered tech-preview and
we're using the v10_beta release to gain more experience with systemd-resolved
across various distributions.  Ubuntu 20.04 has also enabled systemd-resolved
by default, but it seems it has not gone as far as Fedora 33.

Common to all of these alternatives, the VPN server must push DNS options or
the client configuration file must include the appropriate --dhcp-options.


[0]



-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1859831

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-707592630e has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-707592630e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1855962] bugzilla can't send non-html email

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1855962

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-ed56800b3e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed56800b3e

--- Comment #3 from Fedora Update System  ---
FEDORA-2020-53cdcb90d8 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-53cdcb90d8


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1855962] bugzilla can't send non-html email

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1855962

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-ed56800b3e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed56800b3e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1859831



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-ed56800b3e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed56800b3e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

[Peter Robinson]

On Tue, Sep 29, 2020 at 9:41 PM Neal Gompa  wrote:
>
> On Tue, Sep 29, 2020 at 4:30 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
> >
> > == Summary ==
> > Compress Kernel Firmwares to reduce on disk size
> >
> > == Owner ==
> > * Name: [[User:pbrobinson| Peter Robinson]]
> > * Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]
> >
> > == Detailed Description ==
> >
> > Since the linux 5.3 kernel there has been support for loading firmware
> > from xz compressed firmware. The upstream linux-firmware respository
> > is now over 900Mb, not including other kernel firmware that are in
> > Fedora but come from other sources. By compessing the firmware with
> > "xz -C crc32", the only option currently supported in the kernel, we
> > can reduce the ondisk size of the firmware by almost half.
> >
>
> I vaguely recall that there was some effort to add zstd support to
> compress kernel stuff. Could we consider using that for this instead
> of xz? Or is that still only for kernel modules?

ATM the only thing that's upstream is xz hence why that's the only
thing mentioned.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Compress Kernel Firmware (Self-Contained Change)

[Neal Gompa]

On Tue, Sep 29, 2020 at 4:30 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
>
> == Summary ==
> Compress Kernel Firmwares to reduce on disk size
>
> == Owner ==
> * Name: [[User:pbrobinson| Peter Robinson]]
> * Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]
>
> == Detailed Description ==
>
> Since the linux 5.3 kernel there has been support for loading firmware
> from xz compressed firmware. The upstream linux-firmware respository
> is now over 900Mb, not including other kernel firmware that are in
> Fedora but come from other sources. By compessing the firmware with
> "xz -C crc32", the only option currently supported in the kernel, we
> can reduce the ondisk size of the firmware by almost half.
>

I vaguely recall that there was some effort to add zstd support to
compress kernel stuff. Could we consider using that for this instead
of xz? Or is that still only for kernel modules?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Wednesday's FESCo Meeting (2020-09-30)

[Miro Hrončok]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-09-30 14:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Formalize updated policies for what spins can change without asking (and what 
can be changed with FESCo clearance)

https://pagure.io/fesco/issue/2418
APPROVED (+6, 0, -0)

F34 System-Wide Change: Remove support for SELinux runtime disable
https://pagure.io/fesco/issue/2471
APPROVED (+7, 1, -0)

F34 System-Wide Change: Wayland by Default for KDE Plasma Desktop
https://pagure.io/fesco/issue/2472
APPROVED (+4, 1, -0)

= New business =

#topic #2474 F34 System-Wide Change: Rust Crate Packages For Release Branches
https://pagure.io/fesco/issue/2474

#topic #2476 systemd-resolved by default should be deferred to a future release
https://pagure.io/fesco/issue/2476

#topic #2477 Fedora 33 schedule: Is it correct there is only one week between 
Beta and Final Freeze?

https://pagure.io/fesco/issue/2477

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Mark Wielaard]

Hi Jan,

On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> To make DWZ better consumable it needs to have the partial units separately
> parseable. That way they can be shared at IR level and not just at DWARF
> level
> That means:
>  * DW_TAG_partial_unit should have DW_AT_language.
>  * DW_TAG_partial_unit must contain only types (struct/class).
>Currently they contain for example also static constant variables but when
>you parse such independent DW_TAG_partial_unit into which dictionary you
>will register such variable? That makes no sense.

You might want to look at the experiments to do something like that
from Tom de Vries:
https://sourceware.org/pipermail/dwz/2020q1/000579.html
https://sourceware.org/pipermail/dwz/2020q1/000568.html

> It is all about engineering effort. I agree if the support of DWZ
> was trivial (or there were unlimited engineering resources) then DWZ
> is really better than -fdebug-types-section (except it would need a
> DWZ tool with less bugs and better coding practices). But reality
> shows the DWZ support is not trivial engineering resources for
> Fedora are very limited and so we have to decide whether the serious
> effort to support DWZ is better spent on DWZ or on making the
> debuggers better/really usable.

Hacking on dwz and supporting partial units and DWARF supplemential
files in debugger like tools isn't trivial. But it is IMHO also not
such a big effort that we have to drop everything else. Lets see if we
can work together on this.

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Mark Wielaard]

On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote:
> > So, was this compiled by GCC or clang?
> 
> Fedora Koji package:
>   lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64
> 
> GNU GIMPLE 10.2.1 20200916 (Red Hat 10.2.1-4) -m64 -mtune=generic 
> -march=x86-64 -g -g -g -O2 -O2 -O2 -O2 -fno-openmp -fno-openacc 
> -fcf-protection=none -ffat-lto-objects -fexceptions -fstack-protector-strong 
> -fasynchronous-unwind-tables -fstack-clash-protection -fPIC 
> -ffunction-sections -fdata-sections -fltrans -fplugin=annobin

Note that you are using -ffunction-sections together with -flto.
With -flto you don't need -ffunction-sections.

-ffunction sections might cause functions to be dropped by the linker
without updating the DWARF DIEs, causing things like a zero
DW_AT_low_pc.

Just using -flto should not cause such issues.

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 8:01 pm, Lennart Poettering 
 wrote:

So, I defer to Michael here: I didn't actually check what NM opted
there. It might very well be that they default to configuring "." as
routing domain for VPNs.


Yes, this is what happens.

Qualification: it's what should happen, sans bugs. We do have one known 
bug, https://bugzilla.redhat.com/show_bug.cgi?id=1863041, but we only 
know of one affected user, and the NetworkManager developers have 
figured out know how to fix it. This bug probably doesn't affect most 
users (at least it works properly for me).


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F34 Change proposal: DNS Over TLS (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DNS_Over_TLS

== Summary ==
Fedora will attempt to use DNS over TLS (DoT) if supported by
configured DNS servers.

== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: 
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: 

== Detailed Description ==

We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to
protect DNS queries against passive network attackers. An active
network attacker can trivially subvert this protection, but we cannot
make DoT mandatory because other operating systems do not do so and
many (or most?) DNS servers do not support it. DoT will only be used
if the configured DNS server supports it and if it is not blocked by
an active network attacker.

Note that DoT is different from DNS over HTTPS (DoH). In particular,
DoT is not an anti-censorship tool like DoH. It does not look like
regular HTTPS traffic, and it can be blocked by network administrators
if desired, so it should not be a problem for corporate networks.


== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user's ISP
supports DoT. Most probably don't, but users who manually configure a
custom DNS server (e.g. Cloudflare or Google) will automatically
benefit from DNS over TLS.

== Scope ==
* Proposal owners: change meson flags in systemd.spec
* Other developers: N/A (nothing should be required)
* Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (nothing should be required)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope

== Upgrade/compatibility impact ==
DoT will be enabled automatically on upgrade to F34. If DoT is
unsupported, systemd-resolved will fall back to unencrypted DNS, so
there should be no compatibility impact.

== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.

Try using `resolvectl query fedoraproject.org` to see that resolvectl
still works.

Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use
Wireshark to see if your DNS is really encrypted or not.

== User Experience ==
Users should not notice any difference in behavior.

== Dependencies ==
No dependencies.

== Contingency Plan ==

* Contingency mechanism: revert the change
* Contingency deadline: can be done at any time, before F34 beta
freeze would be best
* Blocks release? No
* Blocks product? No

== Documentation ==
See the section `DNSOverTLS=` in the manpage `resolved.conf(5)`

== Release Notes ==
systemd-resolved now enables DNS over TLS (DoT) support by default, in
opportunistic mode. DoT will be used only if supported by your DNS
server, and provides only best-effort encryption to protect against
passive network observers. For compatibility with existing DNS
servers, systemd-resolved will fall back to unencrypted DNS if DoT
does not appear to be supported, reducing the security benefit. If you
wish to manually configure systemd-resolved to prevent fallback to
unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
Note that DoT is different than DNS over HTTPS (DoH) in that it does
not use HTTPS and is therefore easy to distinguish from HTTPS traffic.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

== Summary ==
Compress Kernel Firmwares to reduce on disk size

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]

== Detailed Description ==

Since the linux 5.3 kernel there has been support for loading firmware
from xz compressed firmware. The upstream linux-firmware respository
is now over 900Mb, not including other kernel firmware that are in
Fedora but come from other sources. By compessing the firmware with
"xz -C crc32", the only option currently supported in the kernel, we
can reduce the ondisk size of the firmware by almost half.

== Benefit to Fedora ==

Reduced on disk size of the firmware used by the kernel.

== Scope ==
* Proposal owners:
** Add support upstream to the linux-firmware copy-firmware script to
compess the firmware and create the symlinks to the compressed
firmware
** Enable the upstream support in the Fedora linux-firmware package to
compress the firmware at build time
** Enable compressing firmware in packages that contain firmware used
by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware
** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete)
* Other developers:
** No impact
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

There should be no upgrade impact, the support was added to the
generic firmware loader interface in the kernel.

== How To Test ==

Check devices that need firmware still work. Some devices that need
firmware include:
* GPU drivers such as nvidia, AMD and i915
* Wireless drivers such as those from Intel, Broadcom/Cyprus, TI,
Qualcomm and Marvel
* Wired network interfaces
* Storage drivers
* USB controllers and drivers

== User Experience ==

Generally users should notice little to no difference.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Don't compress kernel firmware
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
N/A


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex

== Summary ==
Provide .debug_names debug info index for LLDB for clang-built
binaries using: clang -gdwarf-5 -gpubnames

Debuginfo index significantly accelerates loading of *.debug files by
debugger. Fedora currently provides ELF section .gdb_index for
[https://www.gnu.org/software/gdb/ GDB debugger].
[https://lldb.llvm.org/ LLDB debugger] cannot use .gdb_index (as it is
missing DIE offsets for more effective processing by LLDB) but LLDB
can use .debug_names index.

== Owner ==
* Name: [[User:jankratochvil| Jan Kratochvil ]]
* Email: jan.kratoch...@redhat.com

== Detailed Description ==

There are currently 3 formats of debug info index:

* .gdb_index: It is currently produced in Fedora by GDB
(/usr/bin/gdb-add-index), it is a part of rpmbuild process. It is
compatible with GDB but incompatible with LLDB as it is missing
essential DIE offsets needed by LLDB due to more effective (faster)
reading of DWARF by LLDB.

* .debug_names from GDB (augmentation "GDB\x00"): It can be produced
by GDB (/usr/bin/gdb-add-index -dwarf-5) but its format is
non-conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
standard]. LLDB expects DWARF-5 standard compliant .debug_names and
therefore it is incompatible with this format. It can be expected GDB
will fix the conformance in the future. Currently GDB .debug_names
format has no advantage over GDB .gdb_index format.

* .debug_names from clang (augmentation "LLVM0700"): It can be
produced by clang (clang -gdwarf-5 -gpubnames) for LLDB. It is
conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
standard], one can expect GDB will be able to read it in the future.

It would be good to produce index from GCC by GDB and to produce index
from clang by clang as the compatibility inside the same toolchain is
best tested and supported. Using index across toolchains (index from
GDB by LLDB or index from clang by GDB) should theoretically work but
in practice there exist subtle differences in interpretation of more
complicated DWARF constructs. It would be best to fix those but that
will be always an afterthought.



== Benefit to Fedora ==
* Faster startup of LLDB debugger using Fedora system *.debug files.

== Scope ==
* Proposal owners: It affects all clang-built packages generating
*-debuginfo.rpm.
* Other developers: none
* Policies and guidelines: All the needed changes should be done in
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
package] can be then retired.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: The size differences are only for
*-debuginfo.rpm which is outside of scope of the listed objectives.


Currently the change will affect only packages using:
 %global toolchain clang
Those are currently only these packages being built by clang and using
this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
wine

FIXME: Which other Fedora packages are being built by clang?

== Upgrade/compatibility impact ==
Existing tools not supporting .debug_names will just ignore the
additional ELF section. The only issue is current GDB would get
confused by the clang .debug_names as it expects .debug_names to be in
its incompatible GDB format - FIXME: Provide a GDB bugfix patch.

Also each *-debuginfo.rpm has to exactly match NVRA of its binary
package the Fedora change compatibility is not applicable.

== How To Test ==
GDB should not get affected by the new .debug_names index from clang.

LLDB should load Fedora system *.debug files faster. LLDB
functionality should not be affected by the index from clang (that is
a part of LLVM development/testsuite).

"llvm-dwarfdump -debug-names *.debug" should show: Augmentation: 'LLVM0700'

== User Experience ==
No user visible change. This affects what tools can developers use.

== Dependencies ==
This Change is dependent on how is decided [[Changes/DebugInfoStandardization]].

This Change is dependent on RHEL-5 F-34 feature expected to be filed
by Mark Wielaard.

Mass rebuild is not required. Packages inherited from F-33 will just
miss the LLDB index and LLDB will load them more slower.

* .debug_names would need to be updated by DWZ but DWZ does not plan
to support .debug_names (according to Mark Wielaard).
** If DWZ is dropped ([[Changes/DebugInfoStandardization]] gets
approved) then clang can normally produce .debug_names for LLDB.
** If DWZ stays in use ([[Changes/DebugInfoStandardization]] gets
rejected) then there are multiple options. LLDB currently cannot
produce .debug_names (only clang can). GDB currently produces
incompatible .debug_names format.
*** [[Changes/DebugInfoStandardization]] should be applied at least
for clang-built packages, preferred by this proposal.
*** There was an idea DWZ would remove .debug_names. That would
effectively reject this Change and make LLVM Toolchain slower due to a
deficiency of the DWZ tool.
*** 

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Mark Wielaard]

Hi Jan,

On Mon, Sep 28, 2020 at 05:28:57PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> > I do find your statistics per package useful because they show dwz is
> > in general effective by producing at least 20% (more) on-disk size
> > reduction,
> 
> I am ignoring the on-disk size, I always measure just *-debuginfo.rpm size.
> 
> If anyone is concerned about on-disk size then Fedora should have already
> enabled zlib section compression which would reduce the on-disk *.debug size
> by 52.84% for the whole distro. Or even implement zstd section compression
> probably with even bigger size decrease (and even lower performance hit
> already low enough).

I was just discussing that recently with the Hotspot Perf GUI
maintainer. And we concluded that if .debug files would be compressed
then we would need an uncompressed cache somewhere. The issue with
having the on-disk debuginfo files compressed is that for
debugger/tracing/profiling tools it incurs an significant
decompression time delay and extra memory usage. Especially for a
profiling tool that only needs to quickly get a little information it
is much more convenient to be able to simply mmap the .debug file,
check the aranges and directly jump to the correct DIE offset. See
e.g. https://github.com/KDAB/hotspot/issues/115

> So why do you mention the on-disk size now?

Because I believe it is the most important benchmark. The on-disk size
is not just the installed file size, but it is also the in memory size
of the data structures that need to be stored and parsed. So a 20%
smaller on-disk size also (roughly) means 20% less DIEs and abbrevs
that need to be parsed or held into memory.

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F34 Change proposal: DNS Over TLS (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DNS_Over_TLS

== Summary ==
Fedora will attempt to use DNS over TLS (DoT) if supported by
configured DNS servers.

== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: 
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: 

== Detailed Description ==

We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to
protect DNS queries against passive network attackers. An active
network attacker can trivially subvert this protection, but we cannot
make DoT mandatory because other operating systems do not do so and
many (or most?) DNS servers do not support it. DoT will only be used
if the configured DNS server supports it and if it is not blocked by
an active network attacker.

Note that DoT is different from DNS over HTTPS (DoH). In particular,
DoT is not an anti-censorship tool like DoH. It does not look like
regular HTTPS traffic, and it can be blocked by network administrators
if desired, so it should not be a problem for corporate networks.


== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user's ISP
supports DoT. Most probably don't, but users who manually configure a
custom DNS server (e.g. Cloudflare or Google) will automatically
benefit from DNS over TLS.

== Scope ==
* Proposal owners: change meson flags in systemd.spec
* Other developers: N/A (nothing should be required)
* Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (nothing should be required)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope

== Upgrade/compatibility impact ==
DoT will be enabled automatically on upgrade to F34. If DoT is
unsupported, systemd-resolved will fall back to unencrypted DNS, so
there should be no compatibility impact.

== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.

Try using `resolvectl query fedoraproject.org` to see that resolvectl
still works.

Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use
Wireshark to see if your DNS is really encrypted or not.

== User Experience ==
Users should not notice any difference in behavior.

== Dependencies ==
No dependencies.

== Contingency Plan ==

* Contingency mechanism: revert the change
* Contingency deadline: can be done at any time, before F34 beta
freeze would be best
* Blocks release? No
* Blocks product? No

== Documentation ==
See the section `DNSOverTLS=` in the manpage `resolved.conf(5)`

== Release Notes ==
systemd-resolved now enables DNS over TLS (DoT) support by default, in
opportunistic mode. DoT will be used only if supported by your DNS
server, and provides only best-effort encryption to protect against
passive network observers. For compatibility with existing DNS
servers, systemd-resolved will fall back to unencrypted DNS if DoT
does not appear to be supported, reducing the security benefit. If you
wish to manually configure systemd-resolved to prevent fallback to
unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
Note that DoT is different than DNS over HTTPS (DoH) in that it does
not use HTTPS and is therefore easy to distinguish from HTTPS traffic.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

== Summary ==
Compress Kernel Firmwares to reduce on disk size

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org]

== Detailed Description ==

Since the linux 5.3 kernel there has been support for loading firmware
from xz compressed firmware. The upstream linux-firmware respository
is now over 900Mb, not including other kernel firmware that are in
Fedora but come from other sources. By compessing the firmware with
"xz -C crc32", the only option currently supported in the kernel, we
can reduce the ondisk size of the firmware by almost half.

== Benefit to Fedora ==

Reduced on disk size of the firmware used by the kernel.

== Scope ==
* Proposal owners:
** Add support upstream to the linux-firmware copy-firmware script to
compess the firmware and create the symlinks to the compressed
firmware
** Enable the upstream support in the Fedora linux-firmware package to
compress the firmware at build time
** Enable compressing firmware in packages that contain firmware used
by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware
** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete)
* Other developers:
** No impact
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

There should be no upgrade impact, the support was added to the
generic firmware loader interface in the kernel.

== How To Test ==

Check devices that need firmware still work. Some devices that need
firmware include:
* GPU drivers such as nvidia, AMD and i915
* Wireless drivers such as those from Intel, Broadcom/Cyprus, TI,
Qualcomm and Marvel
* Wired network interfaces
* Storage drivers
* USB controllers and drivers

== User Experience ==

Generally users should notice little to no difference.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Don't compress kernel firmware
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
N/A


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex

== Summary ==
Provide .debug_names debug info index for LLDB for clang-built
binaries using: clang -gdwarf-5 -gpubnames

Debuginfo index significantly accelerates loading of *.debug files by
debugger. Fedora currently provides ELF section .gdb_index for
[https://www.gnu.org/software/gdb/ GDB debugger].
[https://lldb.llvm.org/ LLDB debugger] cannot use .gdb_index (as it is
missing DIE offsets for more effective processing by LLDB) but LLDB
can use .debug_names index.

== Owner ==
* Name: [[User:jankratochvil| Jan Kratochvil ]]
* Email: jan.kratoch...@redhat.com

== Detailed Description ==

There are currently 3 formats of debug info index:

* .gdb_index: It is currently produced in Fedora by GDB
(/usr/bin/gdb-add-index), it is a part of rpmbuild process. It is
compatible with GDB but incompatible with LLDB as it is missing
essential DIE offsets needed by LLDB due to more effective (faster)
reading of DWARF by LLDB.

* .debug_names from GDB (augmentation "GDB\x00"): It can be produced
by GDB (/usr/bin/gdb-add-index -dwarf-5) but its format is
non-conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
standard]. LLDB expects DWARF-5 standard compliant .debug_names and
therefore it is incompatible with this format. It can be expected GDB
will fix the conformance in the future. Currently GDB .debug_names
format has no advantage over GDB .gdb_index format.

* .debug_names from clang (augmentation "LLVM0700"): It can be
produced by clang (clang -gdwarf-5 -gpubnames) for LLDB. It is
conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5
standard], one can expect GDB will be able to read it in the future.

It would be good to produce index from GCC by GDB and to produce index
from clang by clang as the compatibility inside the same toolchain is
best tested and supported. Using index across toolchains (index from
GDB by LLDB or index from clang by GDB) should theoretically work but
in practice there exist subtle differences in interpretation of more
complicated DWARF constructs. It would be best to fix those but that
will be always an afterthought.



== Benefit to Fedora ==
* Faster startup of LLDB debugger using Fedora system *.debug files.

== Scope ==
* Proposal owners: It affects all clang-built packages generating
*-debuginfo.rpm.
* Other developers: none
* Policies and guidelines: All the needed changes should be done in
[https://src.fedoraproject.org/rpms/redhat-rpm-config
redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
package] can be then retired.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: The size differences are only for
*-debuginfo.rpm which is outside of scope of the listed objectives.


Currently the change will affect only packages using:
 %global toolchain clang
Those are currently only these packages being built by clang and using
this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
wine

FIXME: Which other Fedora packages are being built by clang?

== Upgrade/compatibility impact ==
Existing tools not supporting .debug_names will just ignore the
additional ELF section. The only issue is current GDB would get
confused by the clang .debug_names as it expects .debug_names to be in
its incompatible GDB format - FIXME: Provide a GDB bugfix patch.

Also each *-debuginfo.rpm has to exactly match NVRA of its binary
package the Fedora change compatibility is not applicable.

== How To Test ==
GDB should not get affected by the new .debug_names index from clang.

LLDB should load Fedora system *.debug files faster. LLDB
functionality should not be affected by the index from clang (that is
a part of LLVM development/testsuite).

"llvm-dwarfdump -debug-names *.debug" should show: Augmentation: 'LLVM0700'

== User Experience ==
No user visible change. This affects what tools can developers use.

== Dependencies ==
This Change is dependent on how is decided [[Changes/DebugInfoStandardization]].

This Change is dependent on RHEL-5 F-34 feature expected to be filed
by Mark Wielaard.

Mass rebuild is not required. Packages inherited from F-33 will just
miss the LLDB index and LLDB will load them more slower.

* .debug_names would need to be updated by DWZ but DWZ does not plan
to support .debug_names (according to Mark Wielaard).
** If DWZ is dropped ([[Changes/DebugInfoStandardization]] gets
approved) then clang can normally produce .debug_names for LLDB.
** If DWZ stays in use ([[Changes/DebugInfoStandardization]] gets
rejected) then there are multiple options. LLDB currently cannot
produce .debug_names (only clang can). GDB currently produces
incompatible .debug_names format.
*** [[Changes/DebugInfoStandardization]] should be applied at least
for clang-built packages, preferred by this proposal.
*** There was an idea DWZ would remove .debug_names. That would
effectively reject this Change and make LLVM Toolchain slower due to a
deficiency of the DWZ tool.
*** 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 10:05 PM, Michael Catanzaro wrote:
> 
> 
> On Tue, Sep 29, 2020 at 4:28 pm, Petr Menšík  wrote:
>> nss-dns is allright. All you need to have is dns server with domain
>> configurable servers.
>>
>> Those are:
>> - unbound (with dnssec-trigger autoconfigured)
>> - dnsmasq
>> - systemd-resolved
>> - probably knot-resolver
>> - bind (not more difficult to reconfigure runtime)
>>
>> Maybe more. It is not about nss, because /etc/resolv.conf does not
>> support any domain:server-ip tuples. It would work better with local
>> cache. resolved is not the only possibility. Just use /etc/resolv.conf
>> set to localhost and confi
> 
> Great, that will work wonderfully for those of us who run our own DNS
> server and configure it to split DNS as we prefer, and who never use
> VPNs, and who own zero laptops. For the rest of the world, nss-dns is
> not alright.
Isn't the whole issue just to have that server configured correctly?
Just omit manual configuration. VPNs are not solved only by resolved.
dnssec-trigger solves it the same way. It needs only integration with NM.

systemd-resolved is also just dns server with few more options. Bundled
into single package with more features, that might have been separate. I
own a laptop, connect VPN everyday and it works just fine. Did you know
dnsmasq can be configured in very similar way?

I think systemd-resolved mixed too many bits together.
> -- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 6:32 pm, Petr Menšík  
wrote:

Are you sure? Can it?


It cannot: https://bugzilla.redhat.com/show_bug.cgi?id=1879028

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Petr Menšík]

On 9/29/20 6:18 PM, Lennart Poettering wrote:
> On Di, 29.09.20 11:21, Paul Wouters (p...@nohats.ca) wrote:
> 
>> No further magic should be needed. The user selects this once when
>> joining a new network.
> 
> This is terrible UI. It was on Windows, and it would be on Linux.
> 
> You shouldn't ask questions people cannot possibly answer
> correctly. There's a reason why Windows remained the only big OS doing
> that... (And do current version still do that even, I think they hid
> it in some secondary menu now, and do not prompt anymore?)
> 
>>> 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?
> 
> resolved is doing just this. Note that with today's DHCP you can have
> many domains listed in the lease.
> 
>> 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.
> 
> We maintain a per-interface cache anyway. If an interface goes down
> its cache ceases to exist altogether. There's no flushing necessary,
> since it just stops existing.
> 
>> 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.
> 
> One example: As mentioned by someone else somewhere in this thread,
> apparently some private jboss domains are only resolvable via RH VPN
> but not listed as search domains in the server-provided VPN config.
> 
>> So let me ExecSum what I wrote here. For systemd-resolved to become
>> a high quality DNS solution:
>>
>> 1) Remove custom DNS/DNSSEC resolving code and use a well maintained
>>DNS library.
> 
> "Custom" is in the eye of the beholder. It appears to me you mean that
> in a derogatory way. I mean, given that Ubuntu has been enabling
> systemd-resolved since quite some time by default I have the suspicion
> our codebase is more often deployed IRL than the ones you listed? I
> mean, maybe I am wrong, but it's certainly not that this is exotic
> stuff as you imply.
Is it relevant here who's the biggest? Ask any vendor of DNS software.
All them would say, don't reinvent the wheel. It's harder than it seems.
Yet you dont listen for 5 years.
> 
> I have the suspicion this is a territorial thing, no? It feels as if
> you believe that DNS clients that people wo are not core members of
> the DNS community are inherently a bad thing, and should go away, and
> leave the real work to the people who actually know how things work,
> right? I got that kind of behaviour once before when people told us to
> just leave service management to the real holy men of UNIX.
May it be because they struggle to make it all working well together,
where you just say this is okay? They struggle with validation and
privacy, you just throw queries to whomever would respond. There were
already said countless issues. You don't want to hear them.
> 
> I mean, let's not forget: last time this came up, 5 years ago, I was
> so fed with dealing with this attitude of yours I just stepped away,
> and stopped pushing for systemd-resolved in Fedora. You and some other
> peeps then had your shot with dnssec-triggerd, but afaiu that didn't
> really go anywhere, we are still at square one, even though "millions
> of dollars" are behind things, as you say.
Because they cared for DNSSEC functionality. Most of implemented in
resolved is already there in dnssec-trigger and unbound. It has to be
admitted, resolved has better integration with NM.
> 
> So we actually have a chance of delivering something now, but you just
> fight against it, just like 5y ago and nothing changed.
They said their arguments 5 years ago and you are still refusing them.
Problems which we failed to solve but you failed as well. But we just
admit our implementation has limitations.

> 
> The reason systemd-resolved exists and that people have adopted it in
> some distros already and are now doing the same on Fedora is that is
> solves real problems, it improves things. It adds local caching, sane
> per-interface behaviour, makes VPN DNS mostly just work and so on,
> integrates LLMNR/mDNS and other sources of truth 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:28 pm, Petr Menšík  
wrote:

nss-dns is allright. All you need to have is dns server with domain
configurable servers.

Those are:
- unbound (with dnssec-trigger autoconfigured)
- dnsmasq
- systemd-resolved
- probably knot-resolver
- bind (not more difficult to reconfigure runtime)

Maybe more. It is not about nss, because /etc/resolv.conf does not
support any domain:server-ip tuples. It would work better with local
cache. resolved is not the only possibility. Just use /etc/resolv.conf
set to localhost and confi


Great, that will work wonderfully for those of us who run our own DNS 
server and configure it to split DNS as we prefer, and who never use 
VPNs, and who own zero laptops. For the rest of the world, nss-dns is 
not alright.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:51 pm, Petr Menšík  
wrote:

Anyway, we might forgive working dnssec validation. What we cannot
forgive is lack of DNSSEC information passtrough in 2020.


I agree this should be fixed. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1879028.


However, since this only matters for specialized server deployments, 
and will not matter for desktop usage or most server deployments, and 
since the workaround is very easy (just edit /etc/resolv.conf) it's 
really extreme to suggest it should be a release blocker when we have 
one week to go before final freeze. That timeframe is way too tight.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:06 pm, Nikos Mavrogiannopoulos 
 wrote:

It is not an exotic one, but this behavior was in the past considered
a vulnerability (information disclosure) [0]. Are we re-introducing
it? I guess yes, and it can be that the benefits of it outweigh the
vulnerability, but we should be explicit about it in our release
notes.

[0]. CVE-2018-1000135 
https://bugzilla.redhat.com/show_bug.cgi?id=1558238


If all I knew about this was what Lennart just wrote, I would be very 
concerned, because preventing DNS leaks is very important. But Lennart 
is not considering that NetworkManager is not going to configure 
systemd-resolved to operate like this. Lennart's described behavior 
only applies if you give systemd-resolved absolutely no information for 
how to route the DNS. But NetworkManager will not do that, it will do 
the right thing. E.g. if you have one "primary VPN" configured that 
accepts all traffic, your DNS goes to that VPN. It's not going to leak 
DNS queries to your router or to your ISP. If you have a VPN that only 
accepts traffic on its own network, it gets that DNS and not more. This 
is way better than the status quo prior to systemd-resolved where 
unexpected behavior was the norm.


In particular, if you have a VPN that does not select "use this 
connection only for resources on its network," then NetworkManager will 
configure a DNS domain ~. corresponding to the VPN's tun interface. All 
DNS goes there and only there unless it matches another search domain.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 5:21 pm, Lennart Poettering 
 wrote:

Yes, I too would prefer if my regular, non-RH DNS traffic never goes
to RH servers while I am in the VPN, and I can easily configure things
that way. But if I am pretty sure the majority of people probably put
more emphasis "please please work" than on "i'd rather have not
working DNS than have DNS queries end up on RH's DNS servers".


For clarity, if you check the box "Use this connection only for 
resources on its network," then NetworkManager will configure a search 
domain to ensure that non-RH DNS traffic will not go to RH servers. 
Lennart is describing systemd-resolved's default mode of operation on 
systems without NetworkManager, but NetworkManager is default is all 
Fedora editions.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Dan Williams]

On Tue, 2020-09-29 at 15:14 -0400, Simo Sorce wrote:
> On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> > On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  > > > 
> > > wrote:
> > > > I think the VPN plugin and VPN server has some input, no?  All
> > > > the
> > > > VPN
> > > > servers I've used send routes to the VPN client to determine
> > > > which
> > > > traffic the client should send via the VPN.  How does that
> > > > interact
> > > > with "use this connection only for resources on its
> > > > network"?  Does
> > > > the user preference take precendence over the VPN server-
> > > > provided
> > > > routes?  What if the VPN server doesn't send any route other
> > > > than
> > > > 0.0.0.0/0?
> > > 
> > > Good question! So good that I don't know the answer. Yes, the
> > > VPN 
> > > plugin indeed gets to make decision based on configuration pushed
> > > by 
> > > the VPN server. The NetworkManager developers are experts in how
> > > these 
> > > settings interact. I *think* the routes provided by the VPN take 
> > > precedence over the checkbox (but only for routing, not for DNS)?
> > > But 
> > > this would certainly be good to document and explore more fully.
> > 
> > If you check "Use this connection..." then NetworkManager will:
> > 
> > (a) never set the default route through the VPN
> > (b) enable split DNS using the VPN-provided (or manually
> > configured)
> > DNS search domains
> > 
> > If you do not check that box, then the VPN will become the default
> > route and all your non-local traffic will be sent to it.
> > 
> > Unfortunately you cannot rely on VPNs to "do the right thing" and
> > always pass back 0.0.0.0 when it wants all the traffic. Plus the
> > user
> > may not want to pass all traffic to the VPN, regardless of what the
> > VPN
> > wants. If you have a corporate laptop and the company wants all
> > your
> > data to go through the VPN, then that laptop is presumably well-
> > managed 
> > and the IT admin will enforce that "Use this connection..." is
> > unchecked.
> 
> Dan,
> I think that unfortunately we cannot conflate "Use this
> connection..."
> to both decide on packet routing and well as DNS routing.

I'm not disagreeing that in a perfect world we'd actually differentiate
two different things.

But it's been this way for 12+ years with NM and (even though I've been
out of NetworkManager for a long time) I've never seen this much
discussion about the topic. Clearly something has worked for the
majority of users for a long, long time.

But perhaps it's time to evaluate improvements.

> There are definitely VPNs where routing allows only to reach internal
> networks and does not allow passthrough, and at the same time VPN
> expects that all DNS resolution happens through the VPN DNS server as
> they selectively override names so some traffic is routed over VPN
> when
> connected but over the regular internet when not (via DNS views).
> 
> I am not saying this is good or bad, it just is, and if we conflate
> this setting we cannot express that setup, which is common (for
> example
> this is the recommended/required configuration for our RH VPN IIRC).

Sure, those setups are not possible with the binary option we have to
day with NM.

> I am also *not* saying we should have two flags that read the same
> but
> just add "for DNS" in one and "for packets" in the other, as most
> users
> would probably be confused.
> 
> In general I would say that for the common case the default should be
> to send queries to the VPN even if there is packet routing split,
> especially if we are thinking about the "café case" I would
> definitely
> trust more the DNS server via the VPN than the one spoofed by the
> café
> broken wifi.

That is the current default, if you leave "Use this connection..."
unchecked. Of course that also sends your traffic to the VPN, which may
not actually work depending on your VPN config.

> Maybe the way to do this is to provide a different switch that say
> something like "I trust this connection to protect my privacy". Then
> if
> you do not want to trust the DNS provided by the VPN for everything,
> you can toggle that one off (default would be on), and that will
> cause
> split DNS as well based on configured domains.

Well... I trust this connection to protect my privacy in some ways, but
not others. I don't think it's that clear-cut.

I honestly don't expect most users to understand or care about the
difference bewteen split IP routing and split DNS routing. But for
those that do, perhaps there should be additional configuration
possible. That's an RFE for the NM team.

Dan

> WDYT ?
> 
> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> 

Re: Proposal: drop extras-qa from all fedora bugs

[Kamil Paral]

On Tue, Sep 29, 2020 at 6:31 PM Kevin Fenzi  wrote:

> Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> "QA Contact" field set to: extras...@fedoraproject.org.
>
> Bugzilla describes "QA Contact" as:
>
> "The person responsible for confirming this bug if it is unconfirmed,
> and for verifying the fix once the bug has been resolved."
>
> However, also since at least 2007-04-20 emails to that address go to
> /dev/null. (Before that they went to a linux.duke.edu address, so I am
> not sure where they went).
>
> I'd like to propose dropping this from all Fedora bugs.
>
> It's a useless extra email that bugzilla has to generate, network has to
> send and deliver and we have to drop in the bitbucket.
>

+1
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop extras-qa from all fedora bugs

[Andy Mender]

On Tue, 29 Sep 2020 at 18:31, Kevin Fenzi  wrote:

> Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> "QA Contact" field set to: extras...@fedoraproject.org.
>
> Bugzilla describes "QA Contact" as:
>
> "The person responsible for confirming this bug if it is unconfirmed,
> and for verifying the fix once the bug has been resolved."
>
> However, also since at least 2007-04-20 emails to that address go to
> /dev/null. (Before that they went to a linux.duke.edu address, so I am
> not sure where they went).
>
> I'd like to propose dropping this from all Fedora bugs.
>
> It's a useless extra email that bugzilla has to generate, network has to
> send and deliver and we have to drop in the bitbucket.
>
> But, perhaps there's some secret clever use for it I am not aware of?
>
> If you can think of some reason to keep it, speak up. ;)
>
> kevin
>

+1 from me as well. It's good to remove it if it doesn't work,
because it gives an impression that extras...@fedoraproject.org is an
existing group.

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Simo Sorce]

On Tue, 2020-09-29 at 20:01 +0200, Lennart Poettering wrote:
> On Di, 29.09.20 13:56, Simo Sorce (s...@redhat.com) wrote:
> 
> > On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> > > On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> > > 
> > > > Search domains have absolutely nothing to do with routing. Search 
> > > > domains are
> > > > specifically used for resolving non-FQDN to FQDN. This isn't a reliable 
> > > > way to
> > > > see what domains are handled by a VPN, or by any DNS server.
> > > > 
> > > > The Red Hat VPN is a good example of this, as not every internal 
> > > > subdomain is
> > > > in search domains. That's the case for many VPNs, corporate or personal.
> > > 
> > > Please read what I wrote: we have nothing better. And no it's not a
> > > perfectly complete solution, I am aware of that. Configure the routes
> > > explicitly if you want, it's easy, and add the extra domains to the
> > > per-interface route and all will be jolly. If you don't, then things
> > > will still work, but mean that queries that aren't listed in any
> > > search domains will be sent to both the VPN and the main iface DNS,
> > > thus the RH VPN will work perfectly fine — only drawback is that
> > > those internal domains not listed as search domains might be seen on
> > > the internet. But what would expect here happens? If you don't tell us
> > > the routing we cannot do fully perfect routing to your wishes, you
> > > need to give us something.
> > > 
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> > 
> > I see conflicting information here from you and Michael Catanzaro.
> > 
> > You have mentioned quite a few times a fan out and leakage of name
> > searches on all interfaces, while Michael said in response to me that
> > if you do not select the magic option to do split DNS routing that all
> > queries should go to the VPN only, which is it ?
> 
> It might the latter. It's up to NM really: it depends what they tell
> resolved. If they default to associating the "." routing domain with a
> VPN this has the effect that all lookups will be preferably routed
> over that.
> 
> If they don't do that, and define no routing domains, then the
> interface it will be in the regular pool of ifaces where we send stuff
> for which no routing domain is defined anywhere.
> 
> So, I defer to Michael here: I didn't actually check what NM opted
> there. It might very well be that they default to configuring "." as
> routing domain for VPNs.

Ah thanks,
this is good to know, it is hard to figure out what is going on when
there is conflicting information.

If NM does configure resolved this way it is a better option as a default.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  
> > wrote:
> > > I think the VPN plugin and VPN server has some input, no?  All the
> > > VPN
> > > servers I've used send routes to the VPN client to determine which
> > > traffic the client should send via the VPN.  How does that interact
> > > with "use this connection only for resources on its network"?  Does
> > > the user preference take precendence over the VPN server-provided
> > > routes?  What if the VPN server doesn't send any route other than
> > > 0.0.0.0/0?
> > 
> > Good question! So good that I don't know the answer. Yes, the VPN 
> > plugin indeed gets to make decision based on configuration pushed by 
> > the VPN server. The NetworkManager developers are experts in how
> > these 
> > settings interact. I *think* the routes provided by the VPN take 
> > precedence over the checkbox (but only for routing, not for DNS)?
> > But 
> > this would certainly be good to document and explore more fully.
> 
> If you check "Use this connection..." then NetworkManager will:
> 
> (a) never set the default route through the VPN
> (b) enable split DNS using the VPN-provided (or manually configured)
> DNS search domains
> 
> If you do not check that box, then the VPN will become the default
> route and all your non-local traffic will be sent to it.
> 
> Unfortunately you cannot rely on VPNs to "do the right thing" and
> always pass back 0.0.0.0 when it wants all the traffic. Plus the user
> may not want to pass all traffic to the VPN, regardless of what the VPN
> wants. If you have a corporate laptop and the company wants all your
> data to go through the VPN, then that laptop is presumably well-managed 
> and the IT admin will enforce that "Use this connection..." is
> unchecked.

Dan,
I think that unfortunately we cannot conflate "Use this connection..."
to both decide on packet routing and well as DNS routing.

There are definitely VPNs where routing allows only to reach internal
networks and does not allow passthrough, and at the same time VPN
expects that all DNS resolution happens through the VPN DNS server as
they selectively override names so some traffic is routed over VPN when
connected but over the regular internet when not (via DNS views).

I am not saying this is good or bad, it just is, and if we conflate
this setting we cannot express that setup, which is common (for example
this is the recommended/required configuration for our RH VPN IIRC).

I am also *not* saying we should have two flags that read the same but
just add "for DNS" in one and "for packets" in the other, as most users
would probably be confused.

In general I would say that for the common case the default should be
to send queries to the VPN even if there is packet routing split,
especially if we are thinking about the "café case" I would definitely
trust more the DNS server via the VPN than the one spoofed by the café
broken wifi.

Maybe the way to do this is to provide a different switch that say
something like "I trust this connection to protect my privacy". Then if
you do not want to trust the DNS provided by the VPN for everything,
you can toggle that one off (default would be on), and that will cause
split DNS as well based on configured domains.

WDYT ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 16:35 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> > On Mon, 2020-09-28 at 13:32 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > Instructions were already posted by Vitaly, so I won't repeat that 
> > > > > here.
> > > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > > > > the file is autogenerated.
> > > > 
> > > > Which is a terrible idea, as has been previously mentioned.  It really
> > > > only indicates that the file was once touched my NetworkManager, not
> > > > that it is currently managed.
> > > > 
> > > > If often let Anaconda set up a new system witha  NetworkManager-managed
> > > > DHCP and then convert to a legacy network scripts-managed static IP
> > > > later.  This doesn't change the DNS server or domain, so I don't bother
> > > > editing resolv.conf to remove this comment.  I'm relatively certain that
> > > > this is a common pattern.
> > > 
> > > Yeah, that test is far from ideal, but we need something. If you have
> > > a constructive proposal how to improve it, I'm all ears.
> > 
> > Check if Network Manager is actually enabled as well ?
> 
> Makes sense:
> https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3db94a0dfadec?branch=f33
> https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f454533543cec89a79a58?branch=master
> 
> Zbyszek

Nice job,
thanks Zbyszek!

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Disabling armv7hl in ELN

[Josh Boyer]

Hi All,

When originally conceived, ELN followed all architectures that Fedora
builds for.  The intention here was good but we have discovered that
it is causing some burden for maintainers and there is no underlying
reason for this in the Enterprise context.

I've filed https://github.com/fedora-eln/eln/issues/3 to request that
we disable the armv7hl architecture for ELN.  I believe this will help
retain focus and return resources to the Fedora project that can
otherwise be spent making that architecture as vibrant as possible for
community usecases.

Thank you.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proven packager help needed to rebuild packages

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> Hi,
> 
> I'm coordinating rebuilds of packages due to the libevent rebase [1]
> and I'm having trouble reaching owners of some of the packages. Is
> there a proven packager willing to help me with the rebuilds?
> 
> The rebuilds should be done using the following command:
> 
> fedpkg build --target=f34-build-side-30069

I started the builds now. Unfortunately quite a few have failed.
In general fedpkg build --target=f34-build-side-30069 --nowait
seems to take a lot of time, sometimes maybe a minute.

> The following packages need to be rebuilt. Note that it is expected
> that 'sems' will fail to build, however I think we should try anyway.
> 
> 389-ds-base
https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
BuildError: Error running GIT command "git clone -n 
https://src.fedoraproject.org/rpms/389-ds-base.git 
/var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
 see checkout.log for details

I restarted the build, let's see how it does:
https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545

> ccnet
> groonga
failed with error:
attempt to use unversioned python, define %__python to /usr/bin/python2 or 
/usr/bin/python3 explicitly
error: groonga.spec: line 2: Macro %__provides_exclude_from failed to expand
error: query of specfile groonga.spec failed, can't parse

> links
> lldpd
> mpris-scrobbler
> nbd-runner
> netatalk
> nsd
> perl-Event-Lib
> pgbouncer
After starting the build I saw that it was already rebuilt:
* Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek  
- 1.14.0-5
- Rebuilt for libevent 2.1.12
 
* Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
- Rebuild against new libevent

An additional build probably doesn't hurt.

> remctl
> seafile
> sems
> sslsplit
> sstp-client
> tmate
> trickle

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> DNS. Specifically: my router's, my printer's and my NAS' address. And
>>> there are other names only resolvable via RH VPN. systemd-resolved for
>>> the first time gives me a chance for this to just work: it will send
>>> requests to both the RH DNS servers and the local ones, and uses the
>>> first successful reply, or the last failed reply. And that's quite
>>> frankly awesome, because that *never* worked before.
>> Would you please try dnssec-trigger? It does exactly this thing. Unlike
>> resolved, it can do that also with DNSSEC support on client side. But it
>> is not system default.
> 
> Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
> opt-in though.
> 
>> So no, that is not as fresh as you say. Just have to specify subdomains,
>> that should be sent to specific server. Not just trying anyone that
>> works. Mind my privacy, not everyone has to know what am I
>> resolving.
> 
> I move my laptop around, I want something that just works. And I am
> pretty sure that's the same for Fedora: a DNSSEC implementation that
> is opt-out but requires manual config is a no-go.
No-one demands 100% working validation. We just need 100% working DNSSEC
passthru via resolved, so proper validators can ensure results. There
are problems with DNSSEC. Most of them have known solutions. Just
because your café and modem vendor haven't use any of them.

DNSSEC blocking resolver on fully DNSSEC aware network in year 2020 is
NO-GO to me. It is simple, just don't stand in the way.
> 
>>> So sending the requests to all available DNS servers in absence of
>>> better routing info is a great enabler: it makes DNS "just work" for
>>> many cases, including my own, and I doubt it's a particularly exotic
>>> one.
>>
>> It takes privacy from you and make it much worse. Just because it does
>> 'just work'. Wouldn't it make sense to let corporate admins specify,
>> what should be routed there? Do you know enterprise VPN, which is
>> configured by BFU?
> 
> It provides the same privacy guarantees as your solution — as long as
> you tell it the routing domains. The only difference: if you don't
> tell it anything resolved's behaviour "just works", while your
> solution means things do not just work.
It "works", but provides the other party whole information about what I
visit. Did you know this was the reason for invention of DNS over TLS
and DNS over HTTPS? Even with such encrypted channel, you would leak it
out. If that's the price for "I do not know how but it works", then I
say no, thank you.

It it does not know, you can find a way to make it work. When it works
and leaks, you just won't know.
> 
> You know that meme, "It's not DNS. There's no way it's DNS. It was
> DNS"?
"It's not systemd. There's no way it's systemd. It was
systemd"? Ever heard this version?

> I am pretty sure we shouldn't adopt defaults that break for the
> common cases out-of-the-box. Hence, in absence of more explicit
> routing info I am very sure "just works" is better than "just fails".
I have no problem with proper autoconfiguration. Throwing queries to
every connection I have is plain wrong and always was. That's the reason
why others let it fail in this case.
> 
> Yes, the logic does potentially allow more than you#d want onto some
> interfaces, but I don't think a (fake?) sense of "privacy" is a good
> excuse for "let's ship something that cannot work by default".>
> Yes, I too would prefer if my regular, non-RH DNS traffic never goes
> to RH servers while I am in the VPN, and I can easily configure things
> that way. But if I am pretty sure the majority of people probably put
> more emphasis "please please work" than on "i'd rather have not
> working DNS than have DNS queries end up on RH's DNS servers".But you omit 
> easy configuration on RH VPN server, which would just fix
it. Way to autoconfigure the service without special configuration done
by mere mortal.
> 
>>> Key, take-away here:
>>>
>>> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>>>else to local LAN DNS. But that requires explicit routing info to
>>>be configured, we cannot auto-detect this info (beyond some minor
>>>inference from the search domains)
>> Let company configure it via VPN, allow local override for power
>>users.
> 
> VPNs generally do not propagate domain routing info. They do provide
> search domain info, which — as mentioned — we infer routing info
> from. And yes, we of course allow local override.
> 
> So: check and check? (to the level this is possible)
> 
>>> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>>>local might be a workable option. In others this would be
>>>wrong.
>>
>> Can you please be more specific? Example we can 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Tue, Sep 29, 2020 at 4:00 AM Lennart Poettering 
wrote:

> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
>
> > Search domains have absolutely nothing to do with routing. Search
> domains are
> > specifically used for resolving non-FQDN to FQDN. This isn't a reliable
> way to
> > see what domains are handled by a VPN, or by any DNS server.
> >
> > The Red Hat VPN is a good example of this, as not every internal
> subdomain is
> > in search domains. That's the case for many VPNs, corporate or personal.
>
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
>
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.
>

These heuristics seem fairly problematic, but this is solvable.  Fedora has
a considerable amount of influence on GNOME and NetworkManager.  How about
adjusting the UI to actually cover these cases? The idea that the VPN
configuration would go off into the weeds if a new checkbox showed up seems
silly — setting up a VPN is fundamentally a power user operation.

This could all be first class parts of VPN config. There could be a set of
options: use this VPN to look up all DNS domains or use this VPN to look up
the following domains. Each domain in the list could have an optional
indication that the user *also* wants it to be a “search domain” to get the
behavior that a query with no trailing dot will try that domain as a
suffix.  And the behavior of broadcasting queries in parallel to the
non-VPN network should be configurable as well.  As someone who has
configured corporate and personal VPNs, I would have made use of these
options, and my various VPNs would all be configured differently.

Right now we have a situation where the underlying system is quite
configurable, but (in networking and elsewhere) GNOME likes to hide
detailed configuration in gsettings or otherwise make it very hard to
discover.  For things like touchpad config, I respect GNOME’s goal of
keeping it simple even if I disagree. For networking, I think that the
genuinely simple cases (connect to WiFi, use that WiFI) should be
approachable to non-technical users, but setting up something like a VPN is
inherently complex, and trying to hide that complexity makes everything
harder.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Lennart Poettering]

On Di, 29.09.20 13:56, Simo Sorce (s...@redhat.com) wrote:

> On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> > On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> >
> > > Search domains have absolutely nothing to do with routing. Search domains 
> > > are
> > > specifically used for resolving non-FQDN to FQDN. This isn't a reliable 
> > > way to
> > > see what domains are handled by a VPN, or by any DNS server.
> > >
> > > The Red Hat VPN is a good example of this, as not every internal 
> > > subdomain is
> > > in search domains. That's the case for many VPNs, corporate or personal.
> >
> > Please read what I wrote: we have nothing better. And no it's not a
> > perfectly complete solution, I am aware of that. Configure the routes
> > explicitly if you want, it's easy, and add the extra domains to the
> > per-interface route and all will be jolly. If you don't, then things
> > will still work, but mean that queries that aren't listed in any
> > search domains will be sent to both the VPN and the main iface DNS,
> > thus the RH VPN will work perfectly fine — only drawback is that
> > those internal domains not listed as search domains might be seen on
> > the internet. But what would expect here happens? If you don't tell us
> > the routing we cannot do fully perfect routing to your wishes, you
> > need to give us something.
> >
> > Search domains on VPNs are an indicator that these domains are handled
> > by the VPN, that's why we use them also as routing domains. But this
> > doesn't mean it's the *only* routing domains we use. We use the ones
> > you configure, primarily. But since the concept didn't previously exist
> > we make the best from what we have.
>
> I see conflicting information here from you and Michael Catanzaro.
>
> You have mentioned quite a few times a fan out and leakage of name
> searches on all interfaces, while Michael said in response to me that
> if you do not select the magic option to do split DNS routing that all
> queries should go to the VPN only, which is it ?

It might the latter. It's up to NM really: it depends what they tell
resolved. If they default to associating the "." routing domain with a
VPN this has the effect that all lookups will be preferably routed
over that.

If they don't do that, and define no routing domains, then the
interface it will be in the regular pool of ifaces where we send stuff
for which no routing domain is defined anywhere.

So, I defer to Michael here: I didn't actually check what NM opted
there. It might very well be that they default to configuring "." as
routing domain for VPNs.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> > Search domains have absolutely nothing to do with routing. Search domains 
> > are
> > specifically used for resolving non-FQDN to FQDN. This isn't a reliable way 
> > to
> > see what domains are handled by a VPN, or by any DNS server.
> > 
> > The Red Hat VPN is a good example of this, as not every internal subdomain 
> > is
> > in search domains. That's the case for many VPNs, corporate or personal.
> 
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
> 
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.

I see conflicting information here from you and Michael Catanzaro.

You have mentioned quite a few times a fan out and leakage of name
searches on all interfaces, while Michael said in response to me that
if you do not select the magic option to do split DNS routing that all
queries should go to the VPN only, which is it ?

And how do you configure domains that are not provided as search domain
by the VPN so that they automatically are searched for via the VPN (and
flushed at the time) when the VPN comes up?

In split DNS situation fan out is quite bad because you can get
completely different answers, where generally the VPN has the correct
answer for you but the local DNS server will probably win the latency
game ...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop extras-qa from all fedora bugs

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 10:17:51AM -0700, Kevin Fenzi wrote:
> On Tue, Sep 29, 2020 at 07:03:29PM +0200, Pierre-Yves Chibon wrote:
> > On Tue, Sep 29, 2020 at 09:30:45AM -0700, Kevin Fenzi wrote:
> > > Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> > > "QA Contact" field set to: extras...@fedoraproject.org.
> > > 
> > > Bugzilla describes "QA Contact" as: 
> > > 
> > > "The person responsible for confirming this bug if it is unconfirmed,
> > > and for verifying the fix once the bug has been resolved."
> > > 
> > > However, also since at least 2007-04-20 emails to that address go to
> > > /dev/null. (Before that they went to a linux.duke.edu address, so I am
> > > not sure where they went). 

Should we be so hasty? If has worked well without causing any problems
for so many years.

> > > I'd like to propose dropping this from all Fedora bugs. 
> > > 
> > > It's a useless extra email that bugzilla has to generate, network has to
> > > send and deliver and we have to drop in the bitbucket. 
> > > 
> > > But, perhaps there's some secret clever use for it I am not aware of?
> > > 
> > > If you can think of some reason to keep it, speak up. ;) 
> > 
> > +1 for me. Just to be sure, bugzilla doesn't require such contact to be set?
> 
> I tested that on partner-bugzilla and it didn't care if it was unset. 
> 
> I guess the quiet way to do this is just modify the sync script so it
> drops it from all packages for new bugs, then if we want later go back
> and remove it from existing bugs if we want to. 
> 
> kevin

(The above was just a joke, +1 of course.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 10:19 +0200, Lennart Poettering wrote:
> On Mo, 28.09.20 14:29, Simo Sorce (s...@redhat.com) wrote:
> 
> > On Mon, 2020-09-28 at 16:02 +0100, 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.
> > 
> > Surely this is better solved by using DoH toward known good servers for
> > anything but the local resources ?
> 
> Well, but how do you determine "local resources"?

The same way you do now for "routing", if a name is in the search for
an interface it is "local", of course other better methods can come in
the future via better NM integration.

> 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.

This is in contradiction with other mentions about routing here ?

> Also, people would react very allergic if we'd start sending all DNS
> traffic to google or so. I mean, you can't believe how pissed people
> are that we have a fallback in place that if no DNS servers have been
> configured at all or acquired via DHCP we fall back to Cloudflare +
> Google DNS servers.

I would be quite pissed too if you disclosed my DNS lookups to parties
I do not trust with that data, and I definitely do not trust Google DNS
servers as those queries are often hijacked at the local ISP level
exactly because those are known IP addresses.

>  Downstream distros (Debian…) tend to patch that
> fallback out even... I wouldn't want to know what happens if you start
> telling them we should now *prefer* them over local DNS servers, which
> is what you are saying here...

Nah, I am not saying you should use DoT to random servers, it should
still be user configured or discovered through things like DHCP if that
information will ever be populated there.

> > I mean the whole point of systemd-resolved should be to make things
> > better including DNSSEC ?
> 
> 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...
> 
> (One thing I definitely want to add is an option to only do DNSSEC if
> DoT is also done, under the assumption that a DNS server that is good
> enough and new enough to implement the latter also should be able to
> do the former sanely.)

I think this is fine as an option. But let's not mix DNSSEC resolution
with DNSSEC validation, they are very separate things.

> > As it was already pointed out it is also reasonably simple to detect if
> > the local network have bad DNS servers ...
> 
> No, it's not. It's extremely difficult. Cheap wifi router DNS servers
> are broken in so many ways. They return errors in some cases, freeze
> in others, return rubbish in others, or not at all in even others. If
> you ask the wrong questions anything can happen. We pretty carefully
> tests and probe DNS servers but this still comes at the price that on
> a particular bad implementation we might take a long time until we
> figure out that DNSSEC simply is not possible.

I did not mean to trivialize the technical means, but current DNS
libraries tend to do a reasonable job already, you could simply just
use one of them to offload the problem from your shoulders.
There is little value for systemd-resolved to re-implement all of DNS
handling any way, the value is in the central caching and smart
resolving features.

> The simple fact that some DNS servers don't respond at all if you ask
> the "wrong" questions is already a problem: it means you have to wait
> for a timeout (which means super long lookups initially) or do queries
> in parallel. That however is a problem too since other DNS servers
> really don#t like it if you ask them multiple questions at
> once. Bombarding DNS servers with multiple questions all at once and
> see if one "sticks" isn't a workable strategy hence either.
> 
> And then, when you figured out that the local DNS server can do some
> thing but not others, and are happy you will eventually notice that
> many "edge" DNS servers have a split personality: for some domains
> they are just a proxy for the upstream DNS servers and other domains
> they implement things locally, which means the feature set you can
> 

Re: Proposal: drop extras-qa from all fedora bugs

[Kevin Fenzi]

On Tue, Sep 29, 2020 at 07:03:29PM +0200, Pierre-Yves Chibon wrote:
> On Tue, Sep 29, 2020 at 09:30:45AM -0700, Kevin Fenzi wrote:
> > Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> > "QA Contact" field set to: extras...@fedoraproject.org.
> > 
> > Bugzilla describes "QA Contact" as: 
> > 
> > "The person responsible for confirming this bug if it is unconfirmed,
> > and for verifying the fix once the bug has been resolved."
> > 
> > However, also since at least 2007-04-20 emails to that address go to
> > /dev/null. (Before that they went to a linux.duke.edu address, so I am
> > not sure where they went). 
> > 
> > I'd like to propose dropping this from all Fedora bugs. 
> > 
> > It's a useless extra email that bugzilla has to generate, network has to
> > send and deliver and we have to drop in the bitbucket. 
> > 
> > But, perhaps there's some secret clever use for it I am not aware of?
> > 
> > If you can think of some reason to keep it, speak up. ;) 
> 
> +1 for me. Just to be sure, bugzilla doesn't require such contact to be set?

I tested that on partner-bugzilla and it didn't care if it was unset. 

I guess the quiet way to do this is just modify the sync script so it
drops it from all packages for new bugs, then if we want later go back
and remove it from existing bugs if we want to. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 Beta Secure boot issue

[Alex Thomas]

Thought I would try the beta out on my laptop again (had tried it on
test week, but had to revert due to platform.io not working) Getting
error of : " Secure Boot  Image failed to verify with * ACCESS DENIED*
"

It worked on the btrfs test week, so I am unsure what went wrong.

Laptop is Lenovo T440p.

I filed a bug, but the best component I could find was Grub2.

https://bugzilla.redhat.com/show_bug.cgi?id=1883609
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaning 'hub' (the git wrapper for Github)

[Joe Doss]

On 9/29/20 10:44 AM, Rich Megginson wrote:

Is there a plan to package `gh` in Fedora?


https://bugzilla.redhat.com/show_bug.cgi?id=1803302

I am slogging through it slowly.

Joe



--
Joe Doss
j...@solidadmin.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Vít Ondruch]

Dne 28. 09. 20 v 18:03 Michael Catanzaro napsal(a):
> On Mon, Sep 28, 2020 at 10:51 am, Ian Pilcher 
> wrote:
>> I anticipated this question.  I don't have a good proposal for you ...
>> but I believe that it's up to the people advocating/implementing this
>> change to come up with that.  If it isn't possible to automate this
>> change in a reliable way, maybe it shouldn't be automated.
>
> Of course it's impossible. :P The only way to guess whether
> NetworkManager generated the file is to check if it says
> "NetworkManager" at the top. There's no way to be certain.


I think that for the future generations, it could help if NM included
also checksum of the content.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop extras-qa from all fedora bugs

[Pierre-Yves Chibon]

On Tue, Sep 29, 2020 at 09:30:45AM -0700, Kevin Fenzi wrote:
> Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> "QA Contact" field set to: extras...@fedoraproject.org.
> 
> Bugzilla describes "QA Contact" as: 
> 
> "The person responsible for confirming this bug if it is unconfirmed,
> and for verifying the fix once the bug has been resolved."
> 
> However, also since at least 2007-04-20 emails to that address go to
> /dev/null. (Before that they went to a linux.duke.edu address, so I am
> not sure where they went). 
> 
> I'd like to propose dropping this from all Fedora bugs. 
> 
> It's a useless extra email that bugzilla has to generate, network has to
> send and deliver and we have to drop in the bitbucket. 
> 
> But, perhaps there's some secret clever use for it I am not aware of?
> 
> If you can think of some reason to keep it, speak up. ;) 

+1 for me. Just to be sure, bugzilla doesn't require such contact to be set?


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Paul Wouters]

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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 07:27:37AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 28, 2020 at 10:38:27AM -0700, Erich Eickmeyer wrote:
> > 
> > 
> > This entire discussion is generating enough emails per hour to be an IRC
> > discussion. Could we please move this discussion to #fedora-devel or
> > someplace more appropriate?
> 
> Well, not everyone is on IRC, and email is sometimes a better medium for
> longer discussions. 
> 
> Sometimes this list just has a really high volume of emails. ;( 

Yeah. This is a complicated subject. IRC is not good for multi paragraph
questions and answers and clarifications.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote:
> On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-
> Szmek 
> wrote:
> > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> > 
> > > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro
> > > wrote:
> > > 
> > > > You can do this, but again, you need to use the command line.
> > > > E.g. 
> > > > 'resolvectl dns tun0 8.8.8.8'
> > > > 
> > > > We're actually no longer debating how systemd-resolved works;
> > > > rather, 
> > > > we're now debating how NetworkManager chooses to configure 
> > > > systemd-resolved. systemd-resolved just does what it's told to
> > > > do. It's
> > > > 
> > > > actually NetworkManager that decides to split DNS according to
> > > > routing 
> > > > by default as a matter of policy. It could do otherwise if it
> > > > wanted 
> > > > to, but I think this is a good default. Nothing stops you from
> > > > changing
> > > > 
> > > > it though. :)
> > > 
> > > Michael,
> > > By what mechanism does NetworkManager "split DNS according to
> > > routing"? If
> > > it  hasn't already made a request from both your cleartext and
> > > your VPN
> > > connection's DNS servers, it has no way of knowing what network
> > > should be
> > > used to get the right results. Routing and DNS are unrelated.
> > 
> > NetworkManager pushes DNS server configuration (and associated bits
> > like
> > domain search and routing domains) over dbus to resolved. That way
> > it
> > "[tells resolved how to] split DNS according to routing". Of
> > course, after
> > the name has been resolved to an IP address, the packets to that IP
> > address
> > are routed too. So there is "routing" in the sense of deciding
> > which
> > interface is appropriate for a given DNS name and "routing" in the
> > sense of
> > deciding which interface is appropriate for a given IP address.
> 
> It seems that the terminology is fairly confusing, considering it's
> right 
> alongside actual routing configuration.. Okay, so "routing" means
> something 
> wildly different than you'd think with systemd-resolved, got it.
> 
> In most cases, in order to get to a DNS server inside a VPN, your
> packets have 
> to have a route which can reach the IP of that server for that
> interface, 
> which is configured using NetworkManager (or a VPN config file,
> imported into 
> NM). Anyone that understands basic networking will likely be confused
> by this 
> terminology.
> 
> That aside, where in NetworkManager do these "routing domains" get
> specified?

In the connection itself (GUI or CLI), or they come from DHCP or SLAAC
or the VPN.

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"
nmcli con mod rh-openvpn ipv4.never-default true

combined with having a local caching DNS server (or resolved) enabled
will route queries for those search domains only to the VPN-provided
DNS servers.

There are corresponding GUI boxes for these in nm-connection-editor,
GNOME network settings, and KDE.

Dan


> -- 
> John M. Harris, Jr.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> On Mon, 2020-09-28 at 13:32 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Instructions were already posted by Vitaly, so I won't repeat that here.
> > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > > > the file is autogenerated.
> > > 
> > > Which is a terrible idea, as has been previously mentioned.  It really
> > > only indicates that the file was once touched my NetworkManager, not
> > > that it is currently managed.
> > > 
> > > If often let Anaconda set up a new system witha  NetworkManager-managed
> > > DHCP and then convert to a legacy network scripts-managed static IP
> > > later.  This doesn't change the DNS server or domain, so I don't bother
> > > editing resolv.conf to remove this comment.  I'm relatively certain that
> > > this is a common pattern.
> > 
> > Yeah, that test is far from ideal, but we need something. If you have
> > a constructive proposal how to improve it, I'm all ears.
> 
> Check if Network Manager is actually enabled as well ?

Makes sense:
https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3db94a0dfadec?branch=f33
https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f454533543cec89a79a58?branch=master

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> DNS. Specifically: my router's, my printer's and my NAS' address. And
>>> there are other names only resolvable via RH VPN. systemd-resolved for
>>> the first time gives me a chance for this to just work: it will send
>>> requests to both the RH DNS servers and the local ones, and uses the
>>> first successful reply, or the last failed reply. And that's quite
>>> frankly awesome, because that *never* worked before.
>> Would you please try dnssec-trigger? It does exactly this thing. Unlike
>> resolved, it can do that also with DNSSEC support on client side. But it
>> is not system default.
> 
> Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
> opt-in though.

Are you sure? Can it?

# systemctl restart systemd-resolved
$ resolvectl | grep DNSSEC
  DNSSEC setting: allow-downgrade
DNSSEC supported: yes

# delv @127.0.0.53
;; validating ./NS: got insecure response; parent indicates it should be
secure
;; insecurity proof failed resolving './NS/IN': 127.0.0.53#53
;; resolution failed: insecurity proof failed

# delv
; fully validated
.   503266  IN  NS  a.root-servers.net.
.   503266  IN  NS  b.root-servers.net.
.   503266  IN  NS  c.root-servers.net.
.   503266  IN  NS  d.root-servers.net.
.   503266  IN  NS  e.root-servers.net.
.   503266  IN  NS  f.root-servers.net.
.   503266  IN  NS  g.root-servers.net.
.   503266  IN  NS  h.root-servers.net.
.   503266  IN  NS  i.root-servers.net.
.   503266  IN  NS  j.root-servers.net.
.   503266  IN  NS  k.root-servers.net.
.   503266  IN  NS  l.root-servers.net.
.   503266  IN  NS  m.root-servers.net.
.   503266  IN  RRSIG   NS 8 0 518400 2020101205 
2020092904 46594 .
EUNUgwVVvcgdX6JRCPfmhFPuIJW8DZf7ww1hQAgek0GPDT7kc75fER5Z
NpASxPhrTQKentVt/C5ptwa0Z58i8O7XyN6Pu5ZIZrOpG5zV6y0FqLnI
B7L01ugkmTdZIxfqTxbyiTh8hTWspskbAYQrnrSPiotX0+POYlw7ZIwX
R6V7Y2mF48wFclaejrPRQy/ee03QKYyT9nYPahe7i0qnbmvk1JAfDiCw
dR6Aa2hm/RSuW+7nJRqCbeDZZ4mU1lAZDiyUQ1ezAl/HcCCcpBud8iae
DBYFXDX86EP0hXQexpzN5MLUQZuTCIq5Ihz9Vqk0orXmeaZ/k56t/2td /ak8sw==


# rpm -q systemd
systemd-246.6-2.fc34.x86_64

How can I tell it works? Is servfail on dnssec-failed.org enough?

> 
>> So no, that is not as fresh as you say. Just have to specify subdomains,
>> that should be sent to specific server. Not just trying anyone that
>> works. Mind my privacy, not everyone has to know what am I
>> resolving.
> 
> I move my laptop around, I want something that just works. And I am
> pretty sure that's the same for Fedora: a DNSSEC implementation that
> is opt-out but requires manual config is a no-go.
> 
>>> So sending the requests to all available DNS servers in absence of
>>> better routing info is a great enabler: it makes DNS "just work" for
>>> many cases, including my own, and I doubt it's a particularly exotic
>>> one.
>>
>> It takes privacy from you and make it much worse. Just because it does
>> 'just work'. Wouldn't it make sense to let corporate admins specify,
>> what should be routed there? Do you know enterprise VPN, which is
>> configured by BFU?
> 
> It provides the same privacy guarantees as your solution — as long as
> you tell it the routing domains. The only difference: if you don't
> tell it anything resolved's behaviour "just works", while your
> solution means things do not just work.
> 
> You know that meme, "It's not DNS. There's no way it's DNS. It was
> DNS"? I am pretty sure we shouldn't adopt defaults that break for the
> common cases out-of-the-box. Hence, in absence of more explicit
> routing info I am very sure "just works" is better than "just fails".
> 
> Yes, the logic does potentially allow more than you#d want onto some
> interfaces, but I don't think a (fake?) sense of "privacy" is a good
> excuse for "let's ship something that cannot work by default".
> 
> Yes, I too would prefer if my regular, non-RH DNS traffic never goes
> to RH servers while I am in the VPN, and I can easily configure things
> that way. But if I am pretty sure the majority of people probably put
> more emphasis "please please work" than on "i'd rather have not
> working DNS than have DNS queries end up on RH's DNS servers".
> 
>>> Key, take-away here:
>>>
>>> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>>>else to local LAN DNS. But that requires explicit routing info to
>>>be configured, we cannot auto-detect this info 

Proposal: drop extras-qa from all fedora bugs

[Kevin Fenzi]

Since time began (Fedora 7), all fedora bugs in bugzilla have had their
"QA Contact" field set to: extras...@fedoraproject.org.

Bugzilla describes "QA Contact" as: 

"The person responsible for confirming this bug if it is unconfirmed,
and for verifying the fix once the bug has been resolved."

However, also since at least 2007-04-20 emails to that address go to
/dev/null. (Before that they went to a linux.duke.edu address, so I am
not sure where they went). 

I'd like to propose dropping this from all Fedora bugs. 

It's a useless extra email that bugzilla has to generate, network has to
send and deliver and we have to drop in the bitbucket. 

But, perhaps there's some secret clever use for it I am not aware of?

If you can think of some reason to keep it, speak up. ;) 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:23 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:51, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> I am just saying: Fedora cannot be focussed on just working for people
>>> who have a competent company admin and use their laptops in
>>> company networks only. We must have something that works well in
>>> company networks, as in home networks as in cafe wifis and suchlike.
>>>
>>> Client-side DNSSEC only works in a subset of the "competent network
>>> admin" scenario, but not in the cafe wifi scenario or the home lan
>>> scenario.
>> Can you prove this claim somehow?
>>
>> Is there list of cafe wifi scenarios and home lan scenarios, you are
>> referring to?
> 
> I can give you an address of a local Cafe here with a non-working
> DNSSEC. I am pretty sure where you live they have plenty of those
> cafes too.
Define please what is non-working DNSSEC. Does it use few internal
names, which fail to validate? Does it refuse DNSSEC enabled query like
resolved does? Is there any link describing their connection, which
could you share? dig answers, traffic dumps or similar stuff?
> 
> Or German ICE trains public wifi doesn't allow DNSSEC.

What does that mean? Is there any bug/ticket related to it?

What does it reply to dig +dnssec? I have worked few times on Regiojet
here in Czechia. Aside from few connections dropped, it worked just fine.

I think only login web dashboards are frequent reasons for dnssec
failures. After they allow you internet access, it usually works fine
(to me). Could this be also your case?

But I admit I connect most often just by smartphone, which does not have
dnssec enabled. I have it just on my laptop and I never noticed such
problem on it. I will check few myself.

> 
>> With explanation how resolved fixes them if possible?
> 
> Our fix: we do not do DNSSEC by default.
That is incorrect. You do NOT ALLOW DNSSEC by default. Which is big
difference. It even refuses to ask with DNSSEC when I make request for
it. It refuses to pass me unmodified answer. I makes it the most broken
DNS resolver I know about.

Have you tried asking them to fix it?

Note: DNS flag day 2019[1] made guessing due timeouts obsolete.
According to DNS people, it was quite success, misbehaving servers are
quite minimal. It should be enough to resend query with DNSSEC disabled
just on FORMERR response.


> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

1. https://dnsflagday.net/2019/#experts

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  
> wrote:
> > I think the VPN plugin and VPN server has some input, no?  All the
> > VPN
> > servers I've used send routes to the VPN client to determine which
> > traffic the client should send via the VPN.  How does that interact
> > with "use this connection only for resources on its network"?  Does
> > the user preference take precendence over the VPN server-provided
> > routes?  What if the VPN server doesn't send any route other than
> > 0.0.0.0/0?
> 
> Good question! So good that I don't know the answer. Yes, the VPN 
> plugin indeed gets to make decision based on configuration pushed by 
> the VPN server. The NetworkManager developers are experts in how
> these 
> settings interact. I *think* the routes provided by the VPN take 
> precedence over the checkbox (but only for routing, not for DNS)?
> But 
> this would certainly be good to document and explore more fully.

If you check "Use this connection..." then NetworkManager will:

(a) never set the default route through the VPN
(b) enable split DNS using the VPN-provided (or manually configured)
DNS search domains

If you do not check that box, then the VPN will become the default
route and all your non-local traffic will be sent to it.

Unfortunately you cannot rely on VPNs to "do the right thing" and
always pass back 0.0.0.0 when it wants all the traffic. Plus the user
may not want to pass all traffic to the VPN, regardless of what the VPN
wants. If you have a corporate laptop and the company wants all your
data to go through the VPN, then that laptop is presumably well-managed 
and the IT admin will enforce that "Use this connection..." is
unchecked.

Dan

> This is actually at issue in 
> https://bugzilla.redhat.com/show_bug.cgi?id=1863041 where we
> currently 
> wind up doing the wrong thing by default. See e.g. comment #81 where 
> the VPN plugin is constructing routing information to pass to 
> NetworkManager.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-Szmek 
wrote:
> On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> 
> > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro wrote:
> > 
> > > You can do this, but again, you need to use the command line. E.g. 
> > > 'resolvectl dns tun0 8.8.8.8'
> > > 
> > > We're actually no longer debating how systemd-resolved works; rather, 
> > > we're now debating how NetworkManager chooses to configure 
> > > systemd-resolved. systemd-resolved just does what it's told to do. It's
> > > 
> > > actually NetworkManager that decides to split DNS according to routing 
> > > by default as a matter of policy. It could do otherwise if it wanted 
> > > to, but I think this is a good default. Nothing stops you from changing
> > > 
> > > it though. :)
> > 
> > 
> > Michael,
> > By what mechanism does NetworkManager "split DNS according to routing"? If
> > it  hasn't already made a request from both your cleartext and your VPN
> > connection's DNS servers, it has no way of knowing what network should be
> > used to get the right results. Routing and DNS are unrelated.
> 
> 
> NetworkManager pushes DNS server configuration (and associated bits like
> domain search and routing domains) over dbus to resolved. That way it
> "[tells resolved how to] split DNS according to routing". Of course, after
> the name has been resolved to an IP address, the packets to that IP address
> are routed too. So there is "routing" in the sense of deciding which
> interface is appropriate for a given DNS name and "routing" in the sense of
> deciding which interface is appropriate for a given IP address.

It seems that the terminology is fairly confusing, considering it's right 
alongside actual routing configuration.. Okay, so "routing" means something 
wildly different than you'd think with systemd-resolved, got it.

In most cases, in order to get to a DNS server inside a VPN, your packets have 
to have a route which can reach the IP of that server for that interface, 
which is configured using NetworkManager (or a VPN config file, imported into 
NM). Anyone that understands basic networking will likely be confused by this 
terminology.

That aside, where in NetworkManager do these "routing domains" get specified?

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Lennart Poettering]

On Di, 29.09.20 11:21, Paul Wouters (p...@nohats.ca) wrote:

> No further magic should be needed. The user selects this once when
> joining a new network.

This is terrible UI. It was on Windows, and it would be on Linux.

You shouldn't ask questions people cannot possibly answer
correctly. There's a reason why Windows remained the only big OS doing
that... (And do current version still do that even, I think they hid
it in some secondary menu now, and do not prompt anymore?)

> > 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?

resolved is doing just this. Note that with today's DHCP you can have
many domains listed in the lease.

> 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.

We maintain a per-interface cache anyway. If an interface goes down
its cache ceases to exist altogether. There's no flushing necessary,
since it just stops existing.

> 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.

One example: As mentioned by someone else somewhere in this thread,
apparently some private jboss domains are only resolvable via RH VPN
but not listed as search domains in the server-provided VPN config.

> So let me ExecSum what I wrote here. For systemd-resolved to become
> a high quality DNS solution:
>
> 1) Remove custom DNS/DNSSEC resolving code and use a well maintained
>DNS library.

"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way. I mean, given that Ubuntu has been enabling
systemd-resolved since quite some time by default I have the suspicion
our codebase is more often deployed IRL than the ones you listed? I
mean, maybe I am wrong, but it's certainly not that this is exotic
stuff as you imply.

I have the suspicion this is a territorial thing, no? It feels as if
you believe that DNS clients that people wo are not core members of
the DNS community are inherently a bad thing, and should go away, and
leave the real work to the people who actually know how things work,
right? I got that kind of behaviour once before when people told us to
just leave service management to the real holy men of UNIX.

I mean, let's not forget: last time this came up, 5 years ago, I was
so fed with dealing with this attitude of yours I just stepped away,
and stopped pushing for systemd-resolved in Fedora. You and some other
peeps then had your shot with dnssec-triggerd, but afaiu that didn't
really go anywhere, we are still at square one, even though "millions
of dollars" are behind things, as you say.

So we actually have a chance of delivering something now, but you just
fight against it, just like 5y ago and nothing changed.

The reason systemd-resolved exists and that people have adopted it in
some distros already and are now doing the same on Fedora is that is
solves real problems, it improves things. It adds local caching, sane
per-interface behaviour, makes VPN DNS mostly just work and so on,
integrates LLMNR/mDNS and other sources of truth into one thing. If
there was already something doing that we wouldn't have done
resolved. But to my knowledge this doesn't exist. There are solutions
to very specific problems, i.e. resolves for DNS with DNSSEC for
example, but that is just one part of the problem and you cannot just
ignore the rest.

> 2) Maintain a per interface DNS cache using these libraries

We maintain per-interface DNS caches, but with our code.

> 3) Use the above sketched out process to improve your process of
>deciding which interface to send the query to. This is the core
>of what systemd-resolved should give to the user. It is probably
>already pretty close to this when we work on integrating VPN
>supprt.

I understand you love the network "zone" concept. I am not a fan of
the concept, but this doesn't really matter: we provide all the right
IPC APIs to NM and friends to configure per-interface individually
what to do. Hence, if you can convince GNOME and NM to ask people that
zone question 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 23:37 -0700, John M. Harris Jr wrote:
> On Monday, September 28, 2020 12:42:32 PM MST Lennart Poettering
> wrote:
> > On Mo, 28.09.20 12:14, Paul Wouters (p...@nohats.ca) wrote:
> > 
> > 
> > > 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.
> > 
> > Configure "." as "routing domain" on a specific iface and the
> > lookups
> > wil go there preferably. If you put that on your VPN iface this
> > means
> > DNS traffic goes there preferably. If you put that ont he main
> > iface this
> > means DNS traffic goes there preferably.
> > 
> > Ideally you'd use more fine grained routing domains however.
> > 
> > Lennart
> 
> Lennart,
> 
> Is that a NetworkManager setting or a systemd-resolved setting? Is
> that going 
> to be exposed in the GUI, or is it something that gets hidden away?

NM gets "routing domains" for a given connection (eg, network
interface) from a couple different sources:

1) DHCP
2) SLAAC RDNSS
3) VPN
4) manually configured in the connection info, eg:

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"

It passes this information on to resolved or its own local caching DNS
configuration which uses dnsmasq, which both use it for directing
lookups for those domains to the DNS servers detected/configured for
that interface.

Dan

> How does systemd-resolved figure out what domains "should" be sent to
> a given 
> connection's DNS server without some arcane incantation from the
> systemd docs?
> 
> -- 
> John M. Harris, Jr.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 6:41:12 AM MST Lennart Poettering wrote:
> On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> >
> >
> >
> > If you really must send DNS queries to both (which defeats the purpose of
> > 'Split DNS'), then it may be better to just use the DNS server of the VPN
> > when connected to VPN, then only check the LAN interface when the
> > response is NXDOMAIN.
> 
> 
> As mentioned in this thread already: this policy makes sense for some
> cases but not for others.
> 
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.
> 
> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler: it makes DNS "just work" for
> many cases, including my own, and I doubt it's a particularly exotic
> one.

There seems to be some confusion in this thread as to how exactly that works. 
It seems that the individual pushing this change is under the assumption that 
this implements 'Split DNS', that only requests for VPN resources are queried 
from the VPN's DNS server(s).

> Key, take-away here:
> 
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)

Well, we have the routing information, unless the VPN is one flat network. 
However, routing has absolutely nothing to do with DNS. Routing is a layer 
below, and is most likely required for your DNS queries to actually get to the 
DNS server(s) inside the VPN.

> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>local might be a workable option. In others this would be wrong.
> 
> 3. In others routing all DNS traffic via local DNS and nothing via VPN
>might be workable option. In others this would be wrong.
> 
> 4. In all cases where we can't do #1 because we lack the info, and
>don't know whether to do #2 or #3 because it depends on the type of
>VPN use, then sending to everything in parallel and taking the
>first positive reply and the last negative one is the best chance
>to make things "just work".

This seems to be the part where the Change Owner is confused as to how this 
works, which is concerning at best. We need to be very careful when changing 
functionality that is so essential to the way Fedora systems use network 
resources, this is a pretty big change in functionality, and doesn't provide 
'Split DNS', the issue the Change was originally created to solve.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1823526] bugzilla fails to build with Sphinx 3.0.0

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1823526

Charalampos Stratakis  changed:

   What|Removed |Added

  Flags||needinfo?(emmanuel@seyman.f
   ||r)



--- Comment #3 from Charalampos Stratakis  ---
Ping. Any news here?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Paul Wouters]

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: Orphaning 'hub' (the git wrapper for Github)

[Rich Megginson]

On 9/29/20 8:55 AM, Stephen Gallagher wrote:

Upstream is slowly dying out, since the official Github CLI[1] was
announced. The latest upstream release doesn't pass the test suite on
Golang 1.15[2] and I don't have the time to spare these days, so I'm
going to orphan it and let someone else take over.

Is there a plan to package `gh` in Fedora?



[1] https://cli.github.com/
[2] https://github.com/github/hub/issues/2616
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 16:51, Petr Menšík (pemen...@redhat.com) wrote:

> > I am just saying: Fedora cannot be focussed on just working for people
> > who have a competent company admin and use their laptops in
> > company networks only. We must have something that works well in
> > company networks, as in home networks as in cafe wifis and suchlike.
> >
> > Client-side DNSSEC only works in a subset of the "competent network
> > admin" scenario, but not in the cafe wifi scenario or the home lan
> > scenario.
> Can you prove this claim somehow?
>
> Is there list of cafe wifi scenarios and home lan scenarios, you are
> referring to?

I can give you an address of a local Cafe here with a non-working
DNSSEC. I am pretty sure where you live they have plenty of those
cafes too.

Or German ICE trains public wifi doesn't allow DNSSEC.

> With explanation how resolved fixes them if possible?

Our fix: we do not do DNSSEC by default.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org