date:20200928

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0920-1.fc34 |0920-1.fc34
   |perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0920-1.fc31 |0920-1.fc31
   ||perl-Module-CoreList-5.2020
   ||0920-1.fc32



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-64dc185f10 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 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200920-1.fc34  |0200920-1.fc34
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200920-1.fc33  |0200920-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200920-1.fc31  |0200920-1.fc31
   ||perl-CPAN-Perl-Releases-5.2
   ||0200920-1.fc32



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-a5b6a25059 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 1880859] perl-CPAN-Perl-Releases-5.20200920 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200920-1.fc34  |0200920-1.fc34
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200920-1.fc33  |0200920-1.fc33
   ||perl-CPAN-Perl-Releases-5.2
   ||0200920-1.fc31



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-55d695d27e has been pushed to the Fedora 31 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 1880857] perl-Module-CoreList-5.20200920 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0920-1.fc34 |0920-1.fc34
   ||perl-Module-CoreList-5.2020
   ||0920-1.fc31
 Resolution|--- |ERRATA
Last Closed||2020-09-29 02:17:21



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-18b12f28fa has been pushed to the Fedora 31 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 8 updates-testing report

2020-09-28 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-11f765300e   
singularity-3.6.3-1.el8
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-17fdec3133   
zeromq-4.3.3-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1790461e43   
chromium-85.0.4183.121-1.el8


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

python-collectd_systemd-0.0.1-0.19.20181018git212cb79.el8
python-tqdm-4.50.0-1.el8

Details about builds:



 python-collectd_systemd-0.0.1-0.19.20181018git212cb79.el8 
(FEDORA-EPEL-2020-c295f33510)
 Collectd plugin to monitor systemd services

Update Information:

* Use LoadUnit rather than GetUnit for stable names
https://github.com/mbachry/collectd-systemd/pull/14

ChangeLog:

* Mon Sep 28 2020 Steve Traylen  - 
0.0.1-0.19.20181018git212cb79
- Backport bug fix for LoadUnit rather than GetUnit




 python-tqdm-4.50.0-1.el8 (FEDORA-EPEL-2020-8a080bf9ac)
 Fast, Extensible Progress Meter

Update Information:

https://github.com/tqdm/tqdm/releases/tag/v4.50.0

ChangeLog:

* Mon Sep 28 2020 Stephen Gallagher  - 4.50.0-1
- Update to 4.50.0
* Wed Jul 29 2020 Fedora Release Engineering  - 
4.47.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

References:

  [ 1 ] Bug #1858165 - python-tqdm-4.50.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858165


___
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 1883370] perltidy-20201001 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/Perl/Perl-Tidy-20201001.tar.gz to
./Perl-Tidy-20201001.tar.gz


-- 
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] New: perltidy-20201001 is available

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

Bug ID: 1883370
   Summary: perltidy-20201001 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perltidy
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 20201001
Current version/release in rawhide: 20200907-1.fc34
URL: http://search.cpan.org/dist/Perl-Tidy/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3553/


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

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.


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

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

2020-09-28 Thread Chuck Anderson

On Mon, Sep 28, 2020 at 03:51:51PM -0500, Michael Catanzaro wrote:
> That's still the case. All this discussion about split DNS is only 
> relevant to the case where the user checks the box "use this connection 
> only for resources on its network" (or imports a VPN profile that 
> selects that automatically). By default, it's not checked, nothing is 
> split, all DNS and routing goes to the VPN.

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

2020-09-28 Thread Richard Shaw

I was able to start a build after installing the updated package, but
running rpkg by itself still produces the same confusing output:

$ rpkg
'Namespace' object has no attribute 'command'

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

2020-09-28 Thread Björn Persson

Lennart Poettering wrote:
>On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
>
>> * Andrew Lutomirski:
>>  
>> > Paul may well have been mixing different things here, but I don't
>> > think you answered the one that seems like the most severe problem:
>> > systemd-resolved removed perfectly valid DNSSEC records that were
>> > supplied by the upstream server.  One might reasonably debate whether
>> > Fedora's default DNS resolver configuration should validate DNSSEC,
>> > but I think it should honor the DO bit in client requests and return
>> > DNSSEC data.  
>>
>> FWIW, this is .  
>
>It's on the TODO list. But this creates probems of its
>own. Propagating DO stuff as is cannot work for LLMNR, mDNS,
>company-scope DNS and so on, i.e. anything that isn't the official
>Internet DNS.

It can work in company-scope if the company has competent network
admins. My local DNS server at home resolves local hostnames to private
IPv4 addresses in the 192.168/16 block. Clients on the Internet see
another view. Both views are DNSsec-signed, and validation works fine.
There's no reason why this setup wouldn't work on a corporate network.
The key is to use a domain that is actually registered to the company,
not some made-up TLD like "internal" or whatever the incompetent
network admins come up with.

>What's worse, resolved would start having a split personality: for
>DO replies we'd propagate the 1:1 upstream responses, while for
>everything else we'd return our own stuff, from our own synthesis,
>sourcing and and son. A local DNS client talking to resolved would see
>a feature set that would be very different depending if you ask with
>or without DO, because if you ask with DO you effectively just talk to
>one of the upstream servers, while without you will speak to
>systemd-resolved.

It would make more sense to select the "personality" based on what
interface the client uses, than based on a DO flag in the query:
Present actual standards-compliant DNS and nothing else on UDP and TCP
port 53, and return your own synthesized stuff to programs that call
getaddrinfo (and through the D-Bus interface I suppose).

Nobody connects to port 53 expecting to get entries from /etc/hosts or
LLMNR. Programs that do this expect only DNS – and they're likely to
expect advanced DNS features to work, because they would have just
called getaddrinfo if they weren't interested in advanced features. It
could even be argued that returning non-DNS data through the DNS
protocol is wrong, but if you can do it without violating DNS standards,
then I don't think it will hurt.

>systemd-resolved is not supposed to be a real DNS *server*.

A real DNS server is however what existing programs expect to find in
/etc/resolv.conf.

>Until we implement the DO-bypass stuff, there's an easy way to bypass
>systemd-resolved for your DNSSEC resolver needs: just symlink
>/run/systemd/resolve/resolv.conf to /etc/resolv.conf (i.e. instead of
>/run/systemd/resolve/stub-resolv.conf). If you do that all local DNS
>clients will use the upstream DNS servers resolved picked up directly,
>bypassing resolved. But of course, if you do that then you also lose
>LLMNR, mdns, all local synthetic records, merging of VPN zones and so
>on. 

When I'm speaking the DNS protocol, then I don't mind "losing" LLMNR,
MDNS and synthetic records, which never existed in DNS to begin with.
It would however be good to have the split DNS feature, and I see no
reason why that wouldn't work with DNSsec. Of course, whether a DO query
gets a useful response depends on how good the respective upstream DNS
servers are.

Björn Persson

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

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



On Mon, Sep 28, 2020 at 2:44 pm, Simo Sorce  wrote:

No, this is wrong, DNS and traffic routing are absolutely disjoint
hitngs, and you cannot assume that DNS ought to work as traffic
routing, because it never did.


Hi Simo,

Apologies for a long reply, but I wanted to try to address at least 
most of your concerns.


I would say that rather than *assuming* how things work, we're 
*defining* it. We have to pick some default behavior, and I think 
splitting DNS is least-likely to subvert user expectations, therefore 
least-likely to lead to privacy mistakes.


Now, we only have one GUI option here: "use this connection only for 
resources on its network." If we want to offer the user the choice of 
whether to split DNS along with routing, well, then we need more than 
one option, and we're really getting into the weeds and probably 
exceeding a reasonable complexity limit for an already-complex network 
configuration dialog. This is a niche use-case IMO -- with the possible 
exception of managed corporate deployments where our defaults do not 
matter, more on that below -- and it's much easier to handle this case 
by letting the user manually specify the DNS server to use for the 
connection, which will now actually work in F33 with systemd-resolved. 
Try this in F32 and all the servers you've configured from various 
network connections all get jumbled together in /etc/resolv.conf, in 
uncertain order, with only the one that's lucky enough to be first 
actually used. Behavior changes based on the order that you connect or 
disconnect your VPNs and DNS winds up going to unexpected places. But 
in F33, it just works, so you can easily configure your DNS exactly as 
you please. So if you want your VPN to get all your DNS but only 
traffic for its own network, you can still do it.



Traditionally you had a locally defined DNS server that would answer
your queries, and for traffic you had routers that would decide where
the traffic go, and there is absolutely no correlation between the 
two.


Actually from the DNS pov, traditionally, what is called "split DNS" 
is

almost a capital sin.
In fact the default *should* be to use a VPN DNS *unless* the user
explicitly tells you it doesn't fully trust the VPN and wants to try 
to

split out the traffic.


That's still the case. All this discussion about split DNS is only 
relevant to the case where the user checks the box "use this connection 
only for resources on its network" (or imports a VPN profile that 
selects that automatically). By default, it's not checked, nothing is 
split, all DNS and routing goes to the VPN.



Multiple VPNs definitely pose a problem, so a proper interface may
allow the user to define a "primary" VPN so that would be the one 
where

you send the bulk of DNS traffic.


Yeah, I suspect we have room for improvement there. But regardless, 
you'll get a sensible result as long as you have no more than one VPN 
for which "use this connection only for resources on its network" is 
not checked. As long as there's only one with that box unchecked, it's 
your primary VPN, and the rest are secondary.


 I don't think it would be smart for employees to voluntarily opt-in 
to

 sending all DNS to their employer anyway...


This statement really needs to be justified at length, in normal
copropate environment the equipment is owned by the company and all 
DNS

traffic *is* expected to go through the VPN so as not to leak your
queries to the internet directly.


In a normal corporate environment, your machines are managed by the 
corporation and may (or may not) be subject to Big Brother 
surveillance, possibly to a much higher degree than just watching your 
DNS. However closely you're being watched, one thing is certain: the 
corporation will configure your DNS for you, however it pleases. Our 
defaults just don't matter, because the corporation will change them. 
It will decide where your DNS goes and where your traffic goes. If it 
wants to get all your DNS but not all your traffic, the configuration 
with systemd-resolved is a little different than it was traditionally, 
but it's not hard to do.


The case where our defaults really matter is for unmanaged systems, 
where the corporation is not configuring your defaults, the computer is 
owned by the end user, and the end user is configuring the VPN but is 
not an expert in DNS or routing or any network-related topics. I'm 
firmly convinced that almost nobody in this case would intentionally 
choose for the corporation to receive DNS but not corresponding 
traffic, because that can only benefit the corporation. There's really 
very few conceivable situations where that benefits the user. I can 
think of only one: you want to resolve an internal domain using the 
corporate DNS server, but don't have a search domain configured for it. 
(In that case, the solution is to manually add a search domain.) The 
much more common case is the corporation finds something it doesn't 
like in employee's

Re: Orphaning qjackctl

2020-09-28 Thread Ankur Sinha

On Mon, Sep 28, 2020 09:37:03 -0700, Fernando Lopez-Lezcano wrote:
> On 9/28/20 1:51 AM, Ankur Sinha wrote:
> > Hi Fernando,
> 
> Hi Ankur,
> 
> > I'm a packager sponsor. I'm happy to take over qjackctl and sponsor
> > Christoph as a co-maintainer to help look after it.
> > 
> > Could you please give me ownership of the package? My FAS is:
> > ankursinha.
> 
> Thank you so much for helping with this! Wonderful!
> I just gave you ownership...

Thanks very much.

Christoph, I've sponsored you to the packager group now. Could you please
login to src.fedoraproject.org and let me know so I can add you as
co-maintainer?

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

On Mo, 28.09.20 10:28, Paul Wouters (p...@nohats.ca) wrote:

> This is better thant it was five years ago. I'm glad some things were
> at least successfully conveyed in the Brno meeting. However, this still
> leaks queries meant for the LAN or VPN onto the wide internet and is

Classic resolv.conf cannot communicate to us where what should be
routed. There's no per-domain syntax.

People have different usecases when they have multiple interfaces with
multiple sets of DNS data around. We cannot guess which one of the two
ifaces is the one to trust without explicit help.

Thing is: your LAN connection might be your trusted home network, or
some untrusted cafe wifi. your VPN connection might be your trusted
home VPN or the VPN to your company where you'd rather not send all
DNS traffic. resolved cannot possibly guess what the trust level of
ifaces and their DNS servers is, and if we'd priorize one clearly over
the other we are likely getting it wrong: if we send all DNS traffic
exclusively to the VPN then you lose resolveability of your local LAN
names, such as the router or print config UI. If we send all DNS
traffic exclusively to the local router's DHCP lease configured DNS
server you'd of course lose the ability to resolve company private
names.

So what did we opt to do? We think that working DNS is better than
non-working DNS: so in absence of any further config info we'll look
up names on all interfaces and use the first positive or the last
negative answer. This behaviour doesn't bother too much with the
security issue, i.e. everyting outside the local laptop is consider
equally trusted or untrusted. But it maximizes the chance that things
just work. And that's a inherently a *good* thing, the thing i care
about the most.

Now, of coruse it would be better to only send to the VPN what really
needs to be sent to the VPN, and conversely send to the local
DHCP-supplied DNS only what shall be sent there. For that we need
routing info. We'll synthesize some from search domains, if they are
configured, but beyond that we require you to configure them manually.

Summary: we support routing if queries, you can configure that
explicitly now, and if you don't you at least have the biggest chance
that things "just work".

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

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

On Mo, 28.09.20 16:39, Florian Weimer (fwei...@redhat.com) wrote:

> * Michael Catanzaro:
>
> > If you're running mail servers or VPN servers, you can probably
> > configure the DNS to your liking, right? Either enable DNSSEC support
> > in systemd-resolved, or disable systemd-resolved. I'm not too
> > concerned about this
>
> What about end users who just enable a VPN client?
>
> My understanding is that the DNS request routing in systemd-resolved
> effectively disables any security mechanisms on the VPN side, and
> instructs most current browsers to route DNS requests to centralized DNS
> servers for all requests (i.e., overriding what came from both the VPN
> and DHCP).

That's not precisely true. resolved maintains DNS server info
per-interface, i.e. your vpn will have one set of servers attached to
them, and your main interface another. We then try to route lookups to
these servers following some logic that tries to make the best of what
is known. Specifically, you can configure "routing" domains for each
iface, which will bind traffic within some domain onto such
interface. If none is configured then this is implicitly populated by
the search domains configured along with the DNS server info, if that
exists. If for some lookup no such routing domain is known then we'll
send traffic to the DNS servers of all interfaces in parallel, using
the first positive/last negative reply.

This emphasizes that DNS lookups should just work, and provides —
unlike nss-dns/resolv.conf — a way how in VPN setups you can route
your lookups explicitly to avoid they leak to the wrong networks.

You can also specify "." as routing domain on some iface btw, which
has the affect of routing all traffic preferable to that iface taking
it away from all others (except those which also have routing domains
configured for the relavant domains).

So, yes, you have tight control where things go, and can configure
this per domain. For example you can tell resolved to route redhat.com
queries to the RH VPN iface, and everything else to internet.

Previously, in the status pre-resolved all you could do is
all-or-nothing. Either everything goes to VPN or all goes to main
iface. (You can get this behaviour by resolved too, via the "."
routing domain if you like).

But it's a bit unfair to claim things where a step back while they are
actually a step forward, since we have the routing infra now.

I have the suspicion the main issue you are having is that we default
to "all in parallel" if in doubt about lookups, while you want "vpn
always wins" if in doubt about lookups. I am think our approach is
more robust which is why we took it.

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: init 5 does not restart NetworkManager

2020-09-28 Thread Samuel Sieb


On 9/28/20 6:52 AM, qmail wrote:

at an init 3 stance, which has NetworkManager active, i start an init 5.
when all is said and done, NetworkManager has been deactivated, IE not 
restarted bec of the settings in NetworkManager.service .


So I have to manually restart NetworkManager.

  Why is this so?


Changing init levels doesn't restart the services.  It only starts or 
stops them to get to the new state.  If NetworkManager is stopped, then 
for some reason it has been specified to be stopped in that run level. 
Nnumeric levels are deprecated though, you should be using "systemctl 
isolate" instead.  I don't know how the numbers are matched to targets now.


# systemctl list-dependencies --reverse NetworkManager
NetworkManager.service
● ├─NetworkManager-wait-online.service
● └─multi-user.target
●   └─graphical.target
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, 2020-09-28 at 12:30 -0500, Michael Catanzaro wrote:
> On Mon, Sep 28, 2020 at 1:20 pm, Chuck Anderson  
> wrote:
> > I thought Fedora was supposed to be First?  How can it be if Fedora
> > chooses to use/configure software by default that is missing critical
> > DNSSEC functionality and breaks DNS standards?
> 
> Well, let's amend that to "first when it's smart to be first." We can't 
> ever *require* DNSSEC validation, because Windows and macOS are not 
> going to do so. They have to be first. I could just as well counter 
> with "How can Fedora be first if it refuses to implement split DNS 
> behavior by default that breaks user expectations and leaks queries to 
> unexpected networks?"

Requiring Validation, and *passing through* requests for DNSSEC records
are *entirely* different things.

> As for just passing along records, see Zbigniew's responses; it's 
> possible to do by default, just not a priority. This is really only 
> interesting for specialized applications like mail servers that live on 
> controlled networks where you know that DNSSEC is not broken, i.e. not 
> relevant for 99% of users. If you're running such applications, it's a 
> one-line change in resolved.conf to enable DNSSEC, not really a big 
> deal. It's annoying to have to edit an extra config file, yes, and we 
> should do better, but I don't think that should derail this change.

It is breaking working systems for people, at the very least it should
be very high on priority, not downplayed to irrelevance (as that is the
route for never fixing it, and having people always disable resolved as
a matter of fact)

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

2020-09-28 Thread Jakub Jelinek

On Mon, Sep 28, 2020 at 08:29:21PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > >   https://whova.com/embedded/session/llvm_202010/1193947/
> > 
> > If you do it on the compiler side, you'll get a lot of those pesky partial
> > units you so hate on the lldb side.
> 
> There are many ways how clang could implement it. I have no idea how is the
> draft implemented but unless you have more information I do not think they
> would use DW_TAG_partial_unit.

There aren't that many ways actually, if no special linker assistence is
required, then the different DIEs need to go into separate units, and
compile units wouldn't be really appropriate, as they should match the
original source TUs.
On the other side, doing this in DWZ should be pretty easy.

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

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

On Mon, 2020-09-28 at 16:59 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > * Andrew Lutomirski:
> > 
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe problem:
> > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > supplied by the upstream server.  One might reasonably debate whether
> > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > but I think it should honor the DO bit in client requests and return
> > > DNSSEC data.
> > 
> > FWIW, this is .
> 
> In an ideal world, we would just implement this missing functionality.
> It's definitely on the TODO list, and there has been some preparatory
> work done, but so far nobody found the time. If this is judged necessary,
> we'll raise the priority of that work. Nevertheless, I don't think it is
> such high priority — the number of people using DNSSEC is not too large,
> and they are generally power-users who understand how to specify a different
> server. So while definitely annoying, I didn't consider this a deal-breaker.
> 
> Zbyszek

Sorry Zbyszek,
but as other said, a *default* resolver that break the standard is
definitely a problem.

As non-default, systemd-resolved may decide to break anything it wants,
but once you decide you want to be the default in a system, then
standard compliance becomes paramount.

Of course systemd-resolved can deviate *optionally*, but the default
needs to be compliant, which means returning all records the client
requests, and resolving all names as the standard requires, and
supporting all record types, etc..

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

2020-09-28 Thread Gordon Messmer


On 9/28/20 11:03 AM, Lennart Poettering wrote:

So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented", plus a log message in syslog with
more info. I'd argue that for the vast majority of users this is
perfectly enough. Because IRL client-side DNSSEC doesn't really exist
outside of some very specific circles of DNS nerds, I guess.



Do you mean, "professionals for whom security is a primary job function?"

As other list members have already been asked to avoid making this 
conversation personal, can we *all* not make it about the people, please?


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

2020-09-28 Thread PGNet Dev

On 9/28/20 11:21 AM, Andrew Lutomirski wrote:
> I would have expected NetworkManager to handle this kind of setup just fine.  
> What went wrong?

getting offtopic, but ... a laundry list.

including broken routes, missed existing unit-file interface dependencies 
particularly once bridges get involved, absolute disfunction with setups 
including shorewall & wireguard, blah blah blah.

and, generally, a stubborn, been-there-done-that view that NM has *no place* on 
my servers &/or workstations.

i'm sure _all_ of it was "bandaid-able" with enough monkeying around.

simply not worth the effort, cost, and uncertainty; i'd already moved 
OS/distros to get away from a flaky network stack (among other issues, of 
course; not the least of which was, ironically, old/dusty systemd version!) ... 
and intransigent 'policy' decisions that came with it.

systemd-networkd with enterprise-grade/fits-my-needs DNS servers/resolvers 
works. very nicely.

fingers-crossed that removing the unwanted/unwelcome cruft remains an easy 
option.

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

2020-09-28 Thread Björn Persson

Zbigniew Jędrzejewski-Szmek skrev:
>On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
>> Hey for those of us in the peanuts gallery watching this play out.. could
>> each of you point out which standards and RFC you are complying too. There
>> are a lot of ones and funny enough.. they don't all agree with each other
>> at times.  
>
>https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
>in this particular case.

That IAB statement isn't itself a standard, but it references several
standards. It even quotes RFC 3397 as saying:

 [2]   Resolve a name that contains any dots by first trying it as an
   FQDN and if that fails, with the local domain name (or
   searchlist if specified) appended.

 [3]   Resolve a name containing no dots by appending with the
   searchlist right away, but once again, no implicit searchlists
   should be used.

The name "dk." contains one dot, while "dk" contains no dots. According
to the quoted rules those two shall be resolved differently. "dk."
shall be treated as a fully qualified domain name. Now people are
saying in this thread that systemd-resolved treats both as local names
and doesn't even try to look them up in DNS. So does systemd-resolved
comply with this standard or not?

Björn Persson

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

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

On Mon, 2020-09-28 at 10:51 -0500, Michael Catanzaro wrote:
> I don't think my description is misleading
> 
> On Mon, Sep 28, 2020 at 5:28 pm, Florian Weimer  
> wrote:
> > * The change disables protection mechanisms built into corporate VPNs
> >   that require them to observe all DNS traffic. Now this may sound
> >   rather weak as far as countermeasures go, but DNS-based mechanisms 
> > are
> >   the only thing you have got if you do not enforce a client-side
> >   approach (ugh, no thanks), or disable split tunneling (i.e., default
> >   route over the VPN; frequently not possible with current VPN usage
> >   levels and virtual company meetings over video link).
> 
> Correct. If you want to observe all DNS traffic, that is no longer 
> possible by default unless you also handle routing all traffic. I'd 
> argue that's a good change. From a system design perspective, that's 
> just how DNS ought to work.

No, this is wrong, DNS and traffic routing are absolutely disjoint
hitngs, and you cannot assume that DNS ought to work as traffic
routing, because it never did.

Traditionally you had a locally defined DNS server that would answer
your queries, and for traffic you had routers that would decide where
the traffic go, and there is absolutely no correlation between the two.

Actually from the DNS pov, traditionally, what is called "split DNS" is
almost a capital sin.
In fact the default *should* be to use a VPN DNS *unless* the user
explicitly tells you it doesn't fully trust the VPN and wants to try to
split out the traffic.

Multiple VPNs definitely pose a problem, so a proper interface may
allow the user to define a "primary" VPN so that would be the one where
you send the bulk of DNS traffic. 

> I don't think it would be smart for employees to voluntarily opt-in to 
> sending all DNS to their employer anyway...

This statement really needs to be justified at length, in normal
copropate environment the equipment is owned by the company and all DNS
traffic *is* expected to go through the VPN so as not to leak your
queries to the internet directly.

>  there's little benefit to 
> the employee, and a lot of downside.

Sorry, but this is quite debatable, and entirely depends on the
relationship between employer and employee among other things. Nothing
you can assert or assume.

>  Importantly, if you're looking in 
> your network settings and you see a checkbox that says "Use this 
> connection only for resources on its network," a reasonable user 
> *expects* that the connection will *really* only be used for resources 
> on its network, not that it will be used for everything except DNS,

This is in fact a good indication of the intention a user have.
I use in some context and not others.

> which randomly goes to who knows where depending on what else you're 
> connected to. Our design must try to avoid this failure case: "Sadly 
> for Distrustful Denise, her employer discovers that she has been making 
> some embarrassing DNS requests that she had expected to go through 
> public-vpn.example.com instead."

This is where you should have a "This is my primary VPN" option, which
means all DNS traffic goes there when it is active.

> Of course, it's still possible to get the old behavior if you really 
> want to, but it will now require custom configuration not available via 
> GUI,

And this is a big problem, you are trying to enhance privacy in one
direction, but failing to do so in the other. This should be considered
a bug, given all the other reasons you gave for the change.

>  and nobody really wants to opt-in to that behavior, so it's not 
> likely to be used except in managed corporate systems.

I do for my corporate laptop, so I think you have incorrectly assessed
the situation.
I would also want to opt-into sending everytihng on the VPN if it were
a privacy-VPN, there MUST be a button that says "use *only* _this_ VPN
for *all* DNS traffic" if you care about user's privacy.

>  If you're using 
> a managed system, you're probably surveilled anyway, so better assume 
> nothing is safe.
> 
> > * There is no real protocol for sharing internal domains, so
> >   systemd-resolved cannot know all of them, and resolving some of them
> >   will fail or receive unexpected resolution results (probably
> >   observable for some jboss.org subdomains for Red Hatters, but I 
> > don't
> >   work in that area, so I don't have a good example at hand).
> 
> Yes, that's true. And there's not currently any good solution to that 
> without resorting to the command line.

And this is a bug.

my 2c,
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:

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


On Mon, 28 Sep 2020, Lennart Poettering wrote:


stuff that doesn't come from classic Internet DNS cannot
possibly be DNSSEC validated.


This statement is incorrect. Please read RFC 8598 and perhaps
read up on the handling of Special Use Domain Names and DNSSEC
validation. No one expects .local to be signed. This is not
an actual problem. You are not unique. Participate at the IETF,
write and implement new RFCs that fix your current issues.


If you expect a full blown DNS server
on port 53 then it's not what systemd-resolved is or strives to be.


For non-local queries, that is exactly what applications expect and depend on.


So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented"


That is not what I see:

paul@thinkpad:~)$ dig +dnssec nohats.ca @127.0.0.53

; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec nohats.ca @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6543
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


I get NOERROR, so you should file another systemd-resolved bug report if
the expected behaviour was NOTIMP.

But even so, DNS libraries getting NOTIMP will just try
to go to the next server listed in resolv.conf but there is only
127.0.0.53, so it fails. So you do not "side step" this issue at all.
Implementing NOTIMP will change nothing.


, plus a log message in syslog with
more info. I'd argue that for the vast majority of users this is
perfectly enough.


This is again redefining the use cases and pre-selecting the type
of users you wish to support and punting everything not in your use
case to the "you are the advanced user, you know how to work around
this".

I was an enduser with a laptop dead in the water. It did not matter
how advanced I am or not. It should not happen, and the fix is not
for me to read syslog messages, google for documentation and then
manually fix my system. My system should not break.


Because IRL client-side DNSSEC doesn't really exist
outside of some very specific circles of DNS nerds, I guess. Yes, I
dare to suggest that for your typical GNOME/Fedora Workstation it
really doesn't matter.


This is a very outdated view.


I understand that some people want DNSSEC/DO stuff work client side
just like that, and as mentioned we'll add that, but let's not pretend
this was "obvious" and without pitfalls of its own.


I told you five years ago in Brno at a meeting organized to specifically
talk about DNSSEC at the client side these exact same things. Let's not
pretend I and others did not raise these issues then already.


I understand some loud people here consider Internet DNS the true gospel, and 
mDNS and
LLMNR and all kinds of other forms of popular name resolution, local
and remote heresy


As I suggested in previous emails, stop inventing your personal wheel
and go get informed at the IETF about work being done in this space by
the main vendors. I've listed the working groups, the drafts and the
vendors. Raise any issues you think you have with respect to mDNS, LLMNR
and what not. Work with others to define a functional protocol and
implementation. Then push it first in fedora and I will happilly be
dead in the water and report bugs and submit patches.


Until we implement the DO-bypass stuff


It is not acceptable to break all f33+ and rhel9/centos9 servers "until
you implement" whatever it is you need to implement to violate 15+ year
old DNS RFCs at the low priority you assign this bug baesd on your
selective use cases.

This will be my last email in this thread.

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

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

2020-09-28 Thread John M. Harris Jr

On Sunday, September 27, 2020 9:44:13 PM MST Paul Wouters wrote:
> > Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> 
> 
> I was just hit by the first bug in systemd-resolved 4 days after I
> upgraded to fedora33. I will file a bug report for that, but I wanted
> to discuss something more fundamental.
> 
> systemd-resolved has a number of architectural flaws. When these were
> pointed out, bugs are not accepted and closed or ignored. Worse, I
> was told that systemd-resolved would not become the system DNS resolver,
> so I could just choose to not use it.
> 
> Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
> to systemd-resolved. I want to remove it from my system, but I cannot
> because it is not even a sub-package of systemd, it is part of the
> core systemd package. This goes against promises made in the past.
> 
> Not only that, this change apparently "obsoletes" /etc/resolv.conf,
> which is just not acceptable.
> 
> It is my opinion as a long time DNS RFC author and package maintainer
> that systemd-resolved is not a suitable DNS resolver. Downgrading
> DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
> read on:
> 
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> that DNSSEC is now completely disabled. Again, this is completely
> unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
> mail server uses DNSSEC based TLSA records to prevent MITM attacks
> on the STARTTLS layer, which is now completely broken. My IPsec VPN
> server uses dnssec validation using the specified nameserves in
> /etc/resolve.conf that now point to systemd-resolvd that does not
> return DNSSEC records and is completely broken:
> 
> paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
> 
> ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca
> @127.0.0.53
 ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 65494
> ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
> ; OPT=6: 01 02 04 ("...")
> ; OPT=7: 01 (".")
> ;; QUESTION SECTION:
> ;vpn.nohats.ca.   IN  A
> 
> ;; ANSWER SECTION:
> vpn.nohats.ca.10  IN  A   193.110.157.148
> 
> ;; Query time: 143 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
> ;; MSG SIZE  rcvd: 81
> 
> libreswan will see this result as an attack, and fail to resolve DNS names
> in its configuration. My postfix daemon will hold on to mail because
> it cannot get a DNSSEC proof of denial of existence of TLSA records if
> all DNSSEC records are filtered - even for domains that don't use DNSSEC
> because the denial of existence of DNSSEC for a specific domain requires
> the return of DNSSEC records that systemd now does not return.
> 
> I am sorry that I did not follow the fedora list carefully enough to
> notice this feature when it was proposed.
> 
> This change is harmful to network security, impacts existing installations
> depending on DNSSEC security, and leaks private queries for VPN/internal
> domains to the open internet, and prefers faster non-dnssec answers
> over dnssec validated answers.  It fails various types of queries,
> misimplements part of the DNS protocol. Not only according to me, but
> to 20years+ developers of the bind software as well.
> 
> The first mandatory step is to not disable DNSSEC. If I put on my
> security hat, I would actually have to look into filing a CVE for Fedora
> 33.
> 
> A further discussion should happen on the future of systemd-resolved as
> the default Fedora (and later RHEL/CentOS) system resolver.
> 
> Paul

Paul,

This is only a handful of issues with it, and there are many. I tried to bring 
up that replacing /etc/resolv.conf would cause needless trouble, and that 
looking for the comment NetworkManager puts in it wasn't sufficient, but my 
messages were ignored.

Not only will this needlessly break existing configurations, but it will leak 
all of your private queries to Google if you haven't specified a DNS server. 
They hard-coded 8.8.8.8 and 8.8.4.4 into their resolver, and that still isn't 
patched out for Fedora.

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

On Mon, Sep 28, 2020 at 7:51 pm, Vitaly Zaitsev via devel 
 wrote:

Btw, Russian Federation is going to completely block DoT and DoH.
Forcing these technologies to end users will disrupt Internet access 
for

people from such countries.


We can't require it, because most ISPs don't offer it, and Windows and 
macOS don't require it. If other platforms decide to require it, then 
we could do so as well and maybe Russia's evil plan will hopefully be 
subverted? But in the real world, we can't require it. So instead we'll 
do it opportunistic: try DoT if available, and fall back to plaintext 
if not. This provides no protection against an active network attacker, 
but it does protect against passive attackers. And if you want, you can 
change a line in resolved.conf to make it mandatory. (You can try this 
today in F33.)


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

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

On Mon, 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 ?

I mean the whole point of systemd-resolved should be to make things
better including DNSSEC ?

As it was already pointed out it is also reasonably simple to detect if
the local network have bad DNS servers ...

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

On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > https://whova.com/embedded/session/llvm_202010/1193947/
> 
> If you do it on the compiler side, you'll get a lot of those pesky partial
> units you so hate on the lldb side.

There are many ways how clang could implement it. I have no idea how is the
draft implemented but unless you have more information I do not think they
would use DW_TAG_partial_unit.


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

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

On Mo, 28.09.20 11:06, Andrew Lutomirski (l...@mit.edu) wrote:

> Indeed, the problem you're trying to solve is hard.
>
> > systemd-resolved is not supposed to be a real DNS *server*. It's
> > supposed to be a good, combined client for the popular name resolution
> > protocols, and the fact that we also listen on a port 53 is mostly to
> > provide compat with local app code that doesn't go through glibc NSS
> > for its name resolution needs. If you expect a full blown DNS server
> > on port 53 then it's not what systemd-resolved is or strives to be.
>
> Then perhaps you should have a libsystemdresolvedclient and start
> convincing programs that want this behavior to use it.

Oh, we did. It's called "glibc NSS". It's pretty popular, but not
popular enough as name resolution API apparently... I doubt we could
ever be more successful than glibc with any C library I guess.

I figure we come from different generations though: C libraries is not
how you gonna convince Java or Rust or Go peope. In particular as this
is an IPC question anyway, not a language binding question.

We offer our APIs via four ways these days:

1. Via D-Bus
2. Via Varlink
3. Via NSS (through the nss-resolve module, which is ultimately just a
   wrapper around the D-Bus/Varlink thing)
4. Via local DNS stub on 127.0.0.53

As it turns out the latter kinda works everywhere, it's hard to make a
case for everyone to not use it if it works for this stuff. It uses
DNS as local IPC. Which is pretty universal, and just works for almost
everyone.

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

On Mon, Sep 28, 2020 at 11:19 AM PGNet Dev  wrote:

> On 9/28/20 11:03 AM, Lennart Poettering wrote:
> > I have the strong suspicion that the same people who are
> > able to deploy working DNSSEC client side and are educated enough in
> > DNSSEC to know what that even means are also capable of replacing that
> > one symlink in /etc.
>
> i'll start with:  i'm generally a huge use-systemd-*-whenever-possible
> bigot.  aka, NOT an anti-systemd'er.
>
> but, this^ comment, though likely _true_, causes concern for those of us
> out here, in the peanut gallery.
>
> on
>
> as Paul Wouters has repeatedly pointed out ... others' use cases are not
> mine.
>
> and statements such as "It's easy to do using resolvectl" make me ...
> antsy.
>
> forcing use of, or switching by (coming) default, to solutions that cause
> significant breakage to working systems, is bad news. whether or not that
> breakage can be 'easily' worked around.
>
> easy != zero effort / zero cost.
>
> my typical 'small-office install' includes local split-horizon bind9
> implementation, as well as instances of both NSD4/Unbound, multiple VPN
> links, and varied routing for IPv4 & IPv6 dns queries, as well as general &
> specific traffic.  internal services/capabilities include mail, DNSSEC and
> instances of secure DNS (DoT/DoH), geoIP, etc etc.
>
> 'large-office' installs are correspondingly _more_ 'convoluted'.
>
> that said, it all works.  well.
>
> (my) users see/use a static /etc/resolv.conf, with, generally, a single
> nameserver entry.
>
> recent experiments (on F32, admittedly -- *not* yet F33) with
> NetworkManager &/or systemd-resolved here were nightmarish; a seemingly
> endless array of 'gotchas' ...
>
> after trying, and failing, to chase down & completely resolve all the
> problems, the functional solution i landed on was
>
>  (1) disable NetworkManager everywhere (yes, causes some current pain with
> laptops)
>

I would have expected NetworkManager to handle this kind of setup just
fine.  What went wrong?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, 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 ?

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

2020-09-28 Thread PGNet Dev

On 9/28/20 11:03 AM, Lennart Poettering wrote:
> I have the strong suspicion that the same people who are
> able to deploy working DNSSEC client side and are educated enough in
> DNSSEC to know what that even means are also capable of replacing that
> one symlink in /etc.

i'll start with:  i'm generally a huge use-systemd-*-whenever-possible bigot.  
aka, NOT an anti-systemd'er.

but, this^ comment, though likely _true_, causes concern for those of us out 
here, in the peanut gallery.

on

as Paul Wouters has repeatedly pointed out ... others' use cases are not mine.

and statements such as "It's easy to do using resolvectl" make me ... antsy.

forcing use of, or switching by (coming) default, to solutions that cause 
significant breakage to working systems, is bad news. whether or not that 
breakage can be 'easily' worked around.

easy != zero effort / zero cost.

my typical 'small-office install' includes local split-horizon bind9 
implementation, as well as instances of both NSD4/Unbound, multiple VPN links, 
and varied routing for IPv4 & IPv6 dns queries, as well as general & specific 
traffic.  internal services/capabilities include mail, DNSSEC and instances of 
secure DNS (DoT/DoH), geoIP, etc etc.

'large-office' installs are correspondingly _more_ 'convoluted'.

that said, it all works.  well.

(my) users see/use a static /etc/resolv.conf, with, generally, a single 
nameserver entry.

recent experiments (on F32, admittedly -- *not* yet F33) with NetworkManager 
&/or systemd-resolved here were nightmarish; a seemingly endless array of 
'gotchas' ...

after trying, and failing, to chase down & completely resolve all the problems, 
the functional solution i landed on was

 (1) disable NetworkManager everywhere (yes, causes some current pain with 
laptops)
 (2) enable/deploy systemd-networkd everywhere
 (3) disable systemd-resolved everywhere; reset to own-managed, /etc/resolv.conf
 (4) disabled DoH settings in all Firefox instances

it all works, again.

if/until a 'forced switch', &/or new default, works in _our_ use cases -- 
regardless of whether or not they fit into _others_ limited views -- then 
that^^ is my default.

here's hoping that turning "it" all OFF, without breaking 'the rest' of 
systemd*, or F33+, remains functionally doable ...

off

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

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


On Mon, 28 Sep 2020, Marius Schwarz wrote:


It's always a bad idea for a programm to do the dns itself, instead of
using the dns anyone on the host does. You get a inconsistent behaviour
at best, and a security nightmare at worse. DOx in a browser or any other
programm is wrong anyhow.


The software that decided that DNS answers are too security sensitive to
not be validated is now blamed for not trusting the system resolver
after it found said system resolver was untrustworthy.

As John Gilmore used to say, if you can't not trust your friends, who
can you not trust? :)

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

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

On Mo, 28.09.20 19:51, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On 28.09.2020 18:11, Michael Catanzaro wrote:
> > Similarly, system-resolved will allow us to enable DNS over TLS (DoT)
> > systemwide for supported providers. That's not enabled in F33, but I
> > think we should flip the default for F34.
>
> Btw, Russian Federation is going to completely block DoT and DoH.
> Forcing these technologies to end users will disrupt Internet access for
> people from such countries.

I doubt we can force that even if we wanted, even in places that
aren't Russia. The vast majority of DNS servers you see in public
wifi DHCP leases or company DHCP leases can't do DoT.

And then I am pretty sure we should not bypass local DNS server info
willy-nilly.

That said, the "opportunistic" mode we have might be something we want
to turn on by default: in that mode you get DoT if we can but if not
you don't. In Russia you thus typically wouldn't get DoT, but everyone
else would.

Opportunistic mode means vulnerability to downgrade attacks, but I
guess that's still better than nothing, given that the downgrade
attack surface is probably mostly limited to local networks.

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


On Mon, 28 Sep 2020, Michael Catanzaro wrote:

Well, let's amend that to "first when it's smart to be first." We can't ever 
*require* DNSSEC validation, because Windows and macOS are not going to do 
so.


https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-01.html

That draft has a Microsoft and Apple co-author on it.

It states for example:

There are several methods that can be used to discover and validate a 
resolver designation:
* Discovery using SVCB DNS records (Section 3.1), and validation using 
DNSSEC

This document is precisely to discover DNSSEC (and DNS encryption)
services reliably so that DNSSEC validation can be turned on by default.

Can you cite the documentation for your statement that these two vendors
are not working on enabling DNSSEC validation?

They have to be first. I could just as well counter with "How can Fedora 
be first if it refuses to implement split DNS behavior by default that breaks 
user expectations and leaks queries to unexpected networks?"


How about systemd-resolved people join the IETF draft process, so that
they can still influence the protocols while they are being designed, so
that it can be made to work with systemd-resolved properly? There are a
dozens of long time seasonsed DNS architects and programmers at the IETF
working on this problem now. Join their effort.

As for just passing along records, see Zbigniew's responses; it's possible to 
do by default, just not a priority. This is really only interesting for 
specialized applications like mail servers that live on controlled networks 
where you know that DNSSEC is not broken, i.e. not relevant for 99% of users.


Please stop filtering out the use cases you don't like.

Besides that, what percentage of desktops / laptops uses Linux versus
what percentage of servers use Linux? I would strongly argue the case
is quite the reverse. Linux desktop uses are 0.00% and Linux on servers
is like 99.99%

If you're running such applications, it's a one-line change in resolved.conf 
to enable DNSSEC, not really a big deal. It's annoying to have to edit an 
extra config file, yes, and we should do better, but I don't think that 
should derail this change.


If systemd-resolved was only installed on Linux desktops, you would have
a much stronger argument. But right now it is part of the same package as
/sbin/init.

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

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

On Mon, Sep 28, 2020 at 11:07 AM Lennart Poettering 
wrote:

> On Mo, 28.09.20 13:20, Chuck Anderson (c...@alum.wpi.edu) wrote:
>
> > On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > > * Andrew Lutomirski:
> > > >
> > > > > Paul may well have been mixing different things here, but I don't
> > > > > think you answered the one that seems like the most severe problem:
> > > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > > supplied by the upstream server.  One might reasonably debate
> whether
> > > > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > > > but I think it should honor the DO bit in client requests and
> return
> > > > > DNSSEC data.
> > > >
> > > > FWIW, this is .
> > >
> > > In an ideal world, we would just implement this missing functionality.
> > > It's definitely on the TODO list, and there has been some preparatory
> > > work done, but so far nobody found the time. If this is judged
> necessary,
> > > we'll raise the priority of that work. Nevertheless, I don't think it
> is
> > > such high priority — the number of people using DNSSEC is not too
> large,
> > > and they are generally power-users who understand how to specify a
> different
> > > server. So while definitely annoying, I didn't consider this a
> deal-breaker.
> >
> > DNSSEC is not meant for power-users, and it doesn't require specifying
> > "a different server".
> >
> > I thought Fedora was supposed to be First?  How can it be if Fedora
> > chooses to use/configure software by default that is missing critical
> > DNSSEC functionality and breaks DNS standards?
>
> DNSSEC doesn't really work client-side IRL. The DNS servers typical
> clients talk to generally do not implement what you need, and if they
> do not correctly. This means if you have a great network admin who set
> everything up right it might work, but DNSSEC on a laptop that moves
> around and connects to a WLAN here, and another WLAN there and a third
> WLAN over there is just a nightmare.
>
> If the other big OSes would enable DNSSEC client-side by default
> things might change, but neither Windows nor MacOS or Android do.
>
>
The old unbound-resolveconf actually worked quite well when I played with
it.  The only problem I had was that I couldn't load google.com from one
particular network.  Upon a bit of investigation, I discovered that the ISP
was maliciously replacing the A records for google.com with its own servers
to inject JavaScript.  So unbound-resolveconf's behavior was arguably
correct.  A better solution might have been to pop up some kind of
notification like "your network is attempting to tamper with google.com.
You can use the tampered version of google.com at your own risk by
following these instructions, or you could try to access the real google.com
by doing this other thing".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 10:05 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > After reading https://github.com/systemd/systemd/issues/8967, I really
> > don't think that systemd-resolved's benefits outweigh its harms as a
> > default resolver for Fedora.  If someone wants to write a
> > libfriendlydnsresolver and encourage/patch programs to use it instead of
> > using glibc's resolver or reading resolv.conf, then that could be debated
> > on its merits.  But the actual contents of /etc/resolv.conf should follow
> > the relevant standards, and systemd-resolved does not.
> >
> > Perhaps systemd-resolved could change its mind and decide to comply with
> > all relevant standards.  But until then, it seems inappropriate to me for
> > it to be the default in Fedora.
>
> Pfff, now I'm confused. Here is a case where systemd-resolved implements
> the
> standard, and some people were unhappy because they were relying on sloppy
> implementations which don't follow the RFC. Nevertheless, we added an
> opt-in
> switch to make this work. (Since this feature mostly matters in "special"
> setups like k8s, where you need to do a lot of local setup anyway,
> requiring
> a one-line option seems to be reasonable).
>

I agree that the "tld." case is probably unusual, and I didn't personally
know that anyone had an actual website set up like this until today, but as
someone who has configured DNS zones, I did know that it was valid to
attach records to a TLD.  And, indeed, loading https://dk./ on Firefox on
Fedora 32 works!

I'm reminded of
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver.  That
change, as I recall, didn't end up accepted because it ran into a bunch of
corner cases and (at least at the time) didn't solve them all adequately.
I don't recall its proponents ever arguing that the corner cases were
*wrong*, though.  In contrast, for some reason, the proponents of
systemd-resolved are telling us that the corner cases aren't bugs, are
arguing that the plainly written text in the standards are somehow not the
standards, and are kindly offering to add non-default options to make
systemd-resolved do what it should do by default.

Sorry, but it really seems that systemd-resolved is not ready for prime
time.

To be clear, I personally do not like the model of having each client
application manage its own communication with the network's resolver (i.e.
what happens today when /etc/resolve.conf mentions whatever nameserver was
provided by DHCP), but I think that a better solution needs to be very well
thought through and to honor the expectation that whatever is in
/etc/resolv.conf actually follows the standards.  Programs that use the
glibc name resolution APIs or that use UDP via their favorite library are
not human beings who can be retrained to do things better -- they are
programs that were written to various manpages, standards, etc, and when
one of them asks getaddrinfo(3) to resolve "dk.", they don't mean "do
whatever the systemd-resolved authors thought this should do"; they meant
"resolve dk. as per POSIX and the RFCs.  Similarly, if a program submits a
perfectly valid EDNS query asking for DNSSEC data (note: I mean DO -- I'm
not referring to the AD bit or to any sort of server-side validation),
then, if the network supports DNSSEC, the result should include the
requested data.

If Fedora 33 is going to violate these assumptions, along with whatever
else might be broken that various people on this thread have alluded to,
IMO it should have an extremely good reason to do so.  I haven't seen one
yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 11:04 AM Lennart Poettering 
wrote:

> On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
>
> > * Andrew Lutomirski:
> >
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe problem:
> > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > supplied by the upstream server.  One might reasonably debate whether
> > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > but I think it should honor the DO bit in client requests and return
> > > DNSSEC data.
> >
> > FWIW, this is .
>
> It's on the TODO list. But this creates probems of its
> own. Propagating DO stuff as is cannot work for LLMNR, mDNS,
> company-scope DNS and so on, i.e. anything that isn't the official
> Internet DNS.
>
> systemd-resolved is not a traditional DNS server after all. It is a
> client to classic DNS, MulticastDNS, LLMNR, local definitions from
> /etc/hosts, synthetic records such as _gateway, localhost and the
> local hostname and similar, and then exposes the combination to
> clients. It also is capable of (limited) merging of DNS zones from
> different sources (think: you have a VPN connection with some zones
> the official internet doesn't have). Only one of these backends has a
> concept of DNSSEC + DO: classic DNS talking to upstream Internet DNS
> servers. Thus exposing DO to clients is a bit weird, it suggests
> clients could validate whatever we return with DNSSEC, but that isn't
> doable, stuff that doesn't come from classic Internet DNS cannot
> possibly be DNSSEC validated. So we'd have to have a weird split: for
> some domains we could propagate DO stuff, but for others we simply
> have to block out, because the requests simply doesn't make sense for
> it. What's worse, resolved would start having a split personality: for
> DO replies we'd propagate the 1:1 upstream responses, while for
> everything else we'd return our own stuff, from our own synthesis,
> sourcing and and son. A local DNS client talking to resolved would see
> a feature set that would be very different depending if you ask with
> or without DO, because if you ask with DO you effectively just talk to
> one of the upstream servers, while without you will speak to
> systemd-resolved. I can tell you from implementing much of
> systemd-resolved: dealing with a server that in some conditions acts
> like X and in other conditions like Y is super annoying. Many many
> home routers act like that: they synthesize records for the admin UI,
> which work very differently protocol-wise then talking to proper
> public Internet.
>

Indeed, the problem you're trying to solve is hard.


>
> systemd-resolved is not supposed to be a real DNS *server*. It's
> supposed to be a good, combined client for the popular name resolution
> protocols, and the fact that we also listen on a port 53 is mostly to
> provide compat with local app code that doesn't go through glibc NSS
> for its name resolution needs. If you expect a full blown DNS server
> on port 53 then it's not what systemd-resolved is or strives to be.
>

Then perhaps you should have a libsystemdresolvedclient and start
convincing programs that want this behavior to use it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mo, 28.09.20 13:20, Chuck Anderson (c...@alum.wpi.edu) wrote:

> On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different things here, but I don't
> > > > think you answered the one that seems like the most severe problem:
> > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > supplied by the upstream server.  One might reasonably debate whether
> > > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > > but I think it should honor the DO bit in client requests and return
> > > > DNSSEC data.
> > >
> > > FWIW, this is .
> >
> > In an ideal world, we would just implement this missing functionality.
> > It's definitely on the TODO list, and there has been some preparatory
> > work done, but so far nobody found the time. If this is judged necessary,
> > we'll raise the priority of that work. Nevertheless, I don't think it is
> > such high priority — the number of people using DNSSEC is not too large,
> > and they are generally power-users who understand how to specify a different
> > server. So while definitely annoying, I didn't consider this a deal-breaker.
>
> DNSSEC is not meant for power-users, and it doesn't require specifying
> "a different server".
>
> I thought Fedora was supposed to be First?  How can it be if Fedora
> chooses to use/configure software by default that is missing critical
> DNSSEC functionality and breaks DNS standards?

DNSSEC doesn't really work client-side IRL. The DNS servers typical
clients talk to generally do not implement what you need, and if they
do not correctly. This means if you have a great network admin who set
everything up right it might work, but DNSSEC on a laptop that moves
around and connects to a WLAN here, and another WLAN there and a third
WLAN over there is just a nightmare.

If the other big OSes would enable DNSSEC client-side by default
things might change, but neither Windows nor MacOS or Android do.

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

On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:

> * Andrew Lutomirski:
>
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that were
> > supplied by the upstream server.  One might reasonably debate whether
> > Fedora's default DNS resolver configuration should validate DNSSEC,
> > but I think it should honor the DO bit in client requests and return
> > DNSSEC data.
>
> FWIW, this is .

It's on the TODO list. But this creates probems of its
own. Propagating DO stuff as is cannot work for LLMNR, mDNS,
company-scope DNS and so on, i.e. anything that isn't the official
Internet DNS.

systemd-resolved is not a traditional DNS server after all. It is a
client to classic DNS, MulticastDNS, LLMNR, local definitions from
/etc/hosts, synthetic records such as _gateway, localhost and the
local hostname and similar, and then exposes the combination to
clients. It also is capable of (limited) merging of DNS zones from
different sources (think: you have a VPN connection with some zones
the official internet doesn't have). Only one of these backends has a
concept of DNSSEC + DO: classic DNS talking to upstream Internet DNS
servers. Thus exposing DO to clients is a bit weird, it suggests
clients could validate whatever we return with DNSSEC, but that isn't
doable, stuff that doesn't come from classic Internet DNS cannot
possibly be DNSSEC validated. So we'd have to have a weird split: for
some domains we could propagate DO stuff, but for others we simply
have to block out, because the requests simply doesn't make sense for
it. What's worse, resolved would start having a split personality: for
DO replies we'd propagate the 1:1 upstream responses, while for
everything else we'd return our own stuff, from our own synthesis,
sourcing and and son. A local DNS client talking to resolved would see
a feature set that would be very different depending if you ask with
or without DO, because if you ask with DO you effectively just talk to
one of the upstream servers, while without you will speak to
systemd-resolved. I can tell you from implementing much of
systemd-resolved: dealing with a server that in some conditions acts
like X and in other conditions like Y is super annoying. Many many
home routers act like that: they synthesize records for the admin UI,
which work very differently protocol-wise then talking to proper
public Internet.

systemd-resolved is not supposed to be a real DNS *server*. It's
supposed to be a good, combined client for the popular name resolution
protocols, and the fact that we also listen on a port 53 is mostly to
provide compat with local app code that doesn't go through glibc NSS
for its name resolution needs. If you expect a full blown DNS server
on port 53 then it's not what systemd-resolved is or strives to be.

So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented", plus a log message in syslog with
more info. I'd argue that for the vast majority of users this is
perfectly enough. Because IRL client-side DNSSEC doesn't really exist
outside of some very specific circles of DNS nerds, I guess. Yes, I
dare to suggest that for your typical GNOME/Fedora Workstation it
really doesn't matter.

I understand that some people want DNSSEC/DO stuff work client side
just like that, and as mentioned we'll add that, but let's not pretend
this was "obvious" and without pitfalls of its own. I understand some
loud people here consider Internet DNS the true gospel, and mDNS and
LLMNR and all kinds of other forms of popular name resolution, local
and remote heresy, but I think we just have to agree to disagree here:
i am interested in a *client* solution that speaks the big protocols
deployed today, that supports talking to company-scope DNS servers,
and that's not just DNS but also Microsoft-style LLMNR and Apple-style
mDNS.

Until we implement the DO-bypass stuff, there's an easy way to bypass
systemd-resolved for your DNSSEC resolver needs: just symlink
/run/systemd/resolve/resolv.conf to /etc/resolv.conf (i.e. instead of
/run/systemd/resolve/stub-resolv.conf). If you do that all local DNS
clients will use the upstream DNS servers resolved picked up directly,
bypassing resolved. But of course, if you do that then you also lose
LLMNR, mdns, all local synthetic records, merging of VPN zones and so
on. If you do things like this, then resolved will work like a
re-implementation of the "resolvconf" tool that Debian and FreeBSD
have, not more (it does provide a command line compatible binary for
that btw). I have the strong suspicion that the same people who are
able to deploy working DNSSEC client side and are educated enough in
DNSSEC to know what that even means are also capable of replacing that
one symlink in /etc.

Lennart

--
Lennart Poettering,

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

2020-09-28 Thread Vitaly Zaitsev via devel

On 28.09.2020 18:11, Michael Catanzaro wrote:
> Similarly, system-resolved will allow us to enable DNS over TLS (DoT)
> systemwide for supported providers. That's not enabled in F33, but I
> think we should flip the default for F34.

Btw, Russian Federation is going to completely block DoT and DoH.
Forcing these technologies to end users will disrupt Internet access for
people from such countries.

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

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

2020-09-28 Thread Robbie Harwood

Zbigniew Jędrzejewski-Szmek  writes:

> On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
>> Zbigniew Jędrzejewski-Szmek  writes:
>> 
>> > Pfff, now I'm confused. Here is a case where systemd-resolved
>> > implements the standard, and some people were unhappy because they
>> > were relying on sloppy implementations which don't follow the RFC.
>> 
>> Yes, welcome to software development!
>> 
>> Sometimes people care about the standard and sometimes the standard
>> isn't helpful.  You can bemoan it, or belittle the users as you are
>> doing here, but *that's how it is*.
>
> I agree, but I was replying to a mail which said that systemd-resolved does
> not follow the standard. In *this* particular case, that complaint is off
> target.
>
>> The only way you can find out which
>> approach to take is to *figure out what the people in the space
>> expect*.  In other words, it requires human contact and understanding of
>> the problems - not just guessing in a vacuum.
>
> There is more than one space... and different people have different
> expectations. What systemd-resolved was doing seems the appropriate
> thing for 90% of cases, but we also implemented an opt-in for the
> other behaviour. So I don't think you're being fair when you're saying
> "[I] bemoan it, or belittle the users", since I implemented the opt-in and
> I didn't even say anything about the users.

Then I have misinterpreted your intent in the opening of your email -
"Pfff" struck me as dismissive, and this was compounded by your
statement that "some people were unhappy".  I see this was not your
intent and withdraw that criticism.

Thanks,
--Robbie


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

2020-09-28 Thread Erich Eickmeyer



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?

-- 
Erich Eickmeyer
Maintainer
Fedora Jam

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

2020-09-28 Thread Marius Schwarz

Am 28.09.20 um 17:56 schrieb Paul Wouters:
>
>> Because DNSSEC is a disaster area and if you try and use it
>> on random networks you're going to get failed lookups on a
>> reasonable number - it's fine if you're on a known network
>> with decent upstream servers but once you start going out
>> and using random WiFi hotspots and things it's a very
>> different story.
>
> And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
> being deployed. And why browsers are, contrary to Michael Catanzaro's
> wrong claim, overriding the system DNS already. See Mozilla's TRR
> program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
> Google's chrome https://www.chromium.org/developers/dns-over-https
>

It's always a bad idea for a programm to do the dns itself, instead of
using the dns anyone on the host does. You get a inconsistent behaviour
at best,
and a security nightmare at worse. DOx in a browser or any other
programm is wrong anyhow.

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

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

On Mon, Sep 28, 2020 at 1:20 pm, Chuck Anderson  
wrote:

I thought Fedora was supposed to be First?  How can it be if Fedora
chooses to use/configure software by default that is missing critical
DNSSEC functionality and breaks DNS standards?


Well, let's amend that to "first when it's smart to be first." We can't 
ever *require* DNSSEC validation, because Windows and macOS are not 
going to do so. They have to be first. I could just as well counter 
with "How can Fedora be first if it refuses to implement split DNS 
behavior by default that breaks user expectations and leaks queries to 
unexpected networks?"


As for just passing along records, see Zbigniew's responses; it's 
possible to do by default, just not a priority. This is really only 
interesting for specialized applications like mail servers that live on 
controlled networks where you know that DNSSEC is not broken, i.e. not 
relevant for 99% of users. If you're running such applications, it's a 
one-line change in resolved.conf to enable DNSSEC, not really a big 
deal. It's annoying to have to edit an extra config file, yes, and we 
should do better, but I don't think that should derail this change.


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

2020-09-28 Thread Chuck Anderson

On Mon, Sep 28, 2020 at 05:26:50PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> > Zbigniew Jędrzejewski-Szmek  writes:
> > 
> > > Pfff, now I'm confused. Here is a case where systemd-resolved
> > > implements the standard, and some people were unhappy because they
> > > were relying on sloppy implementations which don't follow the RFC.
> > 
> > Yes, welcome to software development!
> > 
> > Sometimes people care about the standard and sometimes the standard
> > isn't helpful.  You can bemoan it, or belittle the users as you are
> > doing here, but *that's how it is*.
> 
> I agree, but I was replying to a mail which said that systemd-resolved does
> not follow the standard. In *this* particular case, that complaint is off
> target.

How is systemd-resolved compliant with this requirement of RFC 3397 section 4:

 [2]   Resolve a name that contains any dots by first trying it as an
   FQDN and if that fails, with the local domain name (or
   searchlist if specified) appended.

when it does not resolve "dk." via DNS?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

2020-09-28 Thread Neal Gompa

On Mon, Sep 28, 2020 at 1:20 PM Chuck Anderson  wrote:
>
> On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different things here, but I don't
> > > > think you answered the one that seems like the most severe problem:
> > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > supplied by the upstream server.  One might reasonably debate whether
> > > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > > but I think it should honor the DO bit in client requests and return
> > > > DNSSEC data.
> > >
> > > FWIW, this is .
> >
> > In an ideal world, we would just implement this missing functionality.
> > It's definitely on the TODO list, and there has been some preparatory
> > work done, but so far nobody found the time. If this is judged necessary,
> > we'll raise the priority of that work. Nevertheless, I don't think it is
> > such high priority — the number of people using DNSSEC is not too large,
> > and they are generally power-users who understand how to specify a different
> > server. So while definitely annoying, I didn't consider this a deal-breaker.
>
> DNSSEC is not meant for power-users, and it doesn't require specifying
> "a different server".
>
> I thought Fedora was supposed to be First?  How can it be if Fedora
> chooses to use/configure software by default that is missing critical
> DNSSEC functionality and breaks DNS standards?

DNSSEC is broken by design for most users. For example, I literally
cannot use it because my corporate VPN does not provide DNSSEC support
because the DNS server software doesn't support it. If I didn't know
what to look for, I'd just say Fedora is broken. Same goes for DoT and
DoH.


-- 
真実はいつも一つ！/ 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

On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > Pfff, now I'm confused. Here is a case where systemd-resolved
> > implements the standard, and some people were unhappy because they
> > were relying on sloppy implementations which don't follow the RFC.
> 
> Yes, welcome to software development!
> 
> Sometimes people care about the standard and sometimes the standard
> isn't helpful.  You can bemoan it, or belittle the users as you are
> doing here, but *that's how it is*.

I agree, but I was replying to a mail which said that systemd-resolved does
not follow the standard. In *this* particular case, that complaint is off
target.

> The only way you can find out which
> approach to take is to *figure out what the people in the space
> expect*.  In other words, it requires human contact and understanding of
> the problems - not just guessing in a vacuum.

There is more than one space... and different people have different
expectations. What systemd-resolved was doing seems the appropriate
thing for 90% of cases, but we also implemented an opt-in for the
other behaviour. So I don't think you're being fair when you're saying
"[I] bemoan it, or belittle the users", since I implemented the opt-in and
I didn't even say anything about the users.

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

On Mon, Sep 28, 2020 at 6:56 pm, Tomasz Torcz  
wrote:

This link second time… there's a lot of text, but no example of
configuration file for split dns.  Is it because end user cannot 
easily

configure split dns permanently?


You can configure custom DNS servers per-network in NetworkManager 
settings. This will actually work as expected now, unlike in F32. 
There's no single file to configure this, since it's a per-connection 
setting and NetworkManager stores configuration in separate files for 
each connection.


If you don't want split DNS, just don't check "use this connection only 
for resources on its network" when creating the VPN. (By default, VPNs 
still get all traffic, so split DNS is actually only used if you check 
that box, or configure custom DNS servers.)


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

2020-09-28 Thread clime

On Mon, 28 Sep 2020 at 19:17, Richard Shaw  wrote:
>
> On Mon, Sep 28, 2020 at 9:26 AM clime  wrote:
>>
>> On Mon, 28 Sep 2020 at 14:44, Richard Shaw  wrote:
>> >
>> > I haven't seen anything obvious in the mailing list lately so maybe it's 
>> > just me?
>> >
>> > $ rpkg
>> > 'Namespace' object has no attribute 'command'
>>
>> Hello,
>>
>> What are versions of rpkg and python3-rpkg in your system? By the way,
>> do you use that command for something actually?
>
>
> $ rpm -qa | grep rpkg
> python3-rpkg-1.61-1.fc32.noarch
> rpkg-2.7-5.fc32.noarch
> rpkg-common-1.61-1.fc32.noarch
>
> $ rpkg build NBEMS-testing
> __init__() got an unexpected keyword argument 'kojiconfig'
>
> That's when I tried running it by itself to see what would happen.

Ah, okay, that was a problem with recent changes to the python3-rpkg
library. I have pushed an update fixing this today
(https://bodhi.fedoraproject.org/updates/FEDORA-2020-44457c00e8).

clime

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

2020-09-28 Thread Chuck Anderson

On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > * Andrew Lutomirski:
> > 
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe problem:
> > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > supplied by the upstream server.  One might reasonably debate whether
> > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > but I think it should honor the DO bit in client requests and return
> > > DNSSEC data.
> > 
> > FWIW, this is .
> 
> In an ideal world, we would just implement this missing functionality.
> It's definitely on the TODO list, and there has been some preparatory
> work done, but so far nobody found the time. If this is judged necessary,
> we'll raise the priority of that work. Nevertheless, I don't think it is
> such high priority — the number of people using DNSSEC is not too large,
> and they are generally power-users who understand how to specify a different
> server. So while definitely annoying, I didn't consider this a deal-breaker.

DNSSEC is not meant for power-users, and it doesn't require specifying
"a different server".

I thought Fedora was supposed to be First?  How can it be if Fedora
chooses to use/configure software by default that is missing critical
DNSSEC functionality and breaks DNS standards?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
> On Mon, 28 Sep 2020 at 13:05, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > > After reading https://github.com/systemd/systemd/issues/8967, I really
> > > don't think that systemd-resolved's benefits outweigh its harms as a
> > > default resolver for Fedora.  If someone wants to write a
> > > libfriendlydnsresolver and encourage/patch programs to use it instead of
> > > using glibc's resolver or reading resolv.conf, then that could be debated
> > > on its merits.  But the actual contents of /etc/resolv.conf should follow
> > > the relevant standards, and systemd-resolved does not.
> > >
> > > Perhaps systemd-resolved could change its mind and decide to comply with
> > > all relevant standards.  But until then, it seems inappropriate to me for
> > > it to be the default in Fedora.
> >
> > Pfff, now I'm confused. Here is a case where systemd-resolved implements
> > the
> > standard, and some people were unhappy because they were relying on sloppy
> > implementations which don't follow the RFC. Nevertheless, we added an
> > opt-in
> > switch to make this work. (Since this feature mostly matters in "special"
> > setups like k8s, where you need to do a lot of local setup anyway,
> > requiring
> > a one-line option seems to be reasonable).
> >
> 
> Hey for those of us in the peanuts gallery watching this play out.. could
> each of you point out which standards and RFC you are complying too. There
> are a lot of ones and funny enough.. they don't all agree with each other
> at times.

https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
in this particular case.

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

[Bug 1883265] perl-File-HomeDir-1.006 is available

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-09-28 17:16:50



--- Comment #3 from Tom "spot" Callaway  ---
perl-File-HomeDir-1.006-1.fc34 built in rawhide.


-- 
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: rpkg broke?

2020-09-28 Thread Richard Shaw

On Mon, Sep 28, 2020 at 9:26 AM clime  wrote:

> On Mon, 28 Sep 2020 at 14:44, Richard Shaw  wrote:
> >
> > I haven't seen anything obvious in the mailing list lately so maybe it's
> just me?
> >
> > $ rpkg
> > 'Namespace' object has no attribute 'command'
>
> Hello,
>
> What are versions of rpkg and python3-rpkg in your system? By the way,
> do you use that command for something actually?
>

$ rpm -qa | grep rpkg
python3-rpkg-1.61-1.fc32.noarch
rpkg-2.7-5.fc32.noarch
rpkg-common-1.61-1.fc32.noarch

$ rpkg build NBEMS-testing
__init__() got an unexpected keyword argument 'kojiconfig'

That's when I tried running it by itself to see what would happen.

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

2020-09-28 Thread Stephen John Smoogen

On Mon, 28 Sep 2020 at 13:05, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > After reading https://github.com/systemd/systemd/issues/8967, I really
> > don't think that systemd-resolved's benefits outweigh its harms as a
> > default resolver for Fedora.  If someone wants to write a
> > libfriendlydnsresolver and encourage/patch programs to use it instead of
> > using glibc's resolver or reading resolv.conf, then that could be debated
> > on its merits.  But the actual contents of /etc/resolv.conf should follow
> > the relevant standards, and systemd-resolved does not.
> >
> > Perhaps systemd-resolved could change its mind and decide to comply with
> > all relevant standards.  But until then, it seems inappropriate to me for
> > it to be the default in Fedora.
>
> Pfff, now I'm confused. Here is a case where systemd-resolved implements
> the
> standard, and some people were unhappy because they were relying on sloppy
> implementations which don't follow the RFC. Nevertheless, we added an
> opt-in
> switch to make this work. (Since this feature mostly matters in "special"
> setups like k8s, where you need to do a lot of local setup anyway,
> requiring
> a one-line option seems to be reasonable).
>

Hey for those of us in the peanuts gallery watching this play out.. could
each of you point out which standards and RFC you are complying too. There
are a lot of ones and funny enough.. they don't all agree with each other
at times.


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

2020-09-28 Thread Robbie Harwood

Zbigniew Jędrzejewski-Szmek  writes:

> Pfff, now I'm confused. Here is a case where systemd-resolved
> implements the standard, and some people were unhappy because they
> were relying on sloppy implementations which don't follow the RFC.

Yes, welcome to software development!

Sometimes people care about the standard and sometimes the standard
isn't helpful.  You can bemoan it, or belittle the users as you are
doing here, but *that's how it is*.  The only way you can find out which
approach to take is to *figure out what the people in the space
expect*.  In other words, it requires human contact and understanding of
the problems - not just guessing in a vacuum.

Thanks,
--Robbie

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

HEADS-UP: Side-tag updates in Bodhi

2020-09-28 Thread Mattia Verga via devel

I just want to inform / remind that pushing side-tags updates in Bodhi 
for releases composed by Bodhi itself (F31, F32 and F33) is currently 
slightly broken. The update gets created, but it's never really pushed 
to testing and remains in "pending" state.

This will hopefully be fixed in the next Bodhi release (the fix has 
already been merged into master branch), but for the moment you need to 
manually set the request to push the update to testing.
This can be done, after the update has been created, by webUI, selecting 
"actions -> push to testing" from the top right menu next to the update 
title (in the update view page), or by CLI, with something like `bodhi 
updates request UPDATE-ALIAS testing` (where update alias is something 
like "FEDORA-2020-1eaffe0013").

I have just pushed some of those stuck updates to testing, in the hope 
to have made something pleasant.

Mattia

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

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

On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> After reading https://github.com/systemd/systemd/issues/8967, I really
> don't think that systemd-resolved's benefits outweigh its harms as a
> default resolver for Fedora.  If someone wants to write a
> libfriendlydnsresolver and encourage/patch programs to use it instead of
> using glibc's resolver or reading resolv.conf, then that could be debated
> on its merits.  But the actual contents of /etc/resolv.conf should follow
> the relevant standards, and systemd-resolved does not.
> 
> Perhaps systemd-resolved could change its mind and decide to comply with
> all relevant standards.  But until then, it seems inappropriate to me for
> it to be the default in Fedora.

Pfff, now I'm confused. Here is a case where systemd-resolved implements the
standard, and some people were unhappy because they were relying on sloppy
implementations which don't follow the RFC. Nevertheless, we added an opt-in
switch to make this work. (Since this feature mostly matters in "special"
setups like k8s, where you need to do a lot of local setup anyway, requiring
a one-line option seems to be reasonable).

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

On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> * Andrew Lutomirski:
> 
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that were
> > supplied by the upstream server.  One might reasonably debate whether
> > Fedora's default DNS resolver configuration should validate DNSSEC,
> > but I think it should honor the DO bit in client requests and return
> > DNSSEC data.
> 
> FWIW, this is .

In an ideal world, we would just implement this missing functionality.
It's definitely on the TODO list, and there has been some preparatory
work done, but so far nobody found the time. If this is judged necessary,
we'll raise the priority of that work. Nevertheless, I don't think it is
such high priority — the number of people using DNSSEC is not too large,
and they are generally power-users who understand how to specify a different
server. So while definitely annoying, I didn't consider this a deal-breaker.

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

2020-09-28 Thread Tomasz Torcz

On Mon, Sep 28, 2020 at 10:05:09AM -0500, Michael Catanzaro wrote:
> [1] https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS

  This link second time… there's a lot of text, but no example of
configuration file for split dns.  Is it because end user cannot easily
configure split dns permanently?

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 9:27 AM Andrew Lutomirski  wrote:

> On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>> >
>> > >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
>> >
>>
>> > paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
>> >
>> > ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @
>> 127.0.0.53
>> > ;; global options: +cmd
>> > ;; Got answer:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
>> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>> >
>> > ;; OPT PSEUDOSECTION:
>> > ; EDNS: version: 0, flags: do; udp: 65494
>> > ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
>> > ; OPT=6: 01 02 04 ("...")
>> > ; OPT=7: 01 (".")
>> > ;; QUESTION SECTION:
>> > ;vpn.nohats.ca.   IN  A
>> >
>> > ;; ANSWER SECTION:
>> > vpn.nohats.ca.10  IN  A   193.110.157.148
>> >
>> > ;; Query time: 143 msec
>> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
>> > ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
>> > ;; MSG SIZE  rcvd: 81
>> >
>> > libreswan will see this result as an attack, and fail to resolve DNS
>> names
>> > in its configuration. My postfix daemon will hold on to mail because
>> > it cannot get a DNSSEC proof of denial of existence of TLSA records if
>> > all DNSSEC records are filtered - even for domains that don't use DNSSEC
>> > because the denial of existence of DNSSEC for a specific domain requires
>> > the return of DNSSEC records that systemd now does not return.
>> >
>> > I am sorry that I did not follow the fedora list carefully enough to
>> > notice this feature when it was proposed.
>> >
>> > This change is harmful to network security, impacts existing
>> installations
>> > depending on DNSSEC security, and leaks private queries for VPN/internal
>> > domains to the open internet, and prefers faster non-dnssec answers
>> > over dnssec validated answers.  It fails various types of queries,
>> > misimplements part of the DNS protocol. Not only according to me, but
>> > to 20years+ developers of the bind software as well.
>>
>> You're mixing a few different things here. We decided to not enable
>> DNSSEC in resolved with this change, at least initially. For most
>> users, DNSSEC is problematic because various intermediary DNS servers
>> found in hotspots and routers don't support DNSSEC properly, leading
>> to hard-to-debug validation failures. DNSSEC support in resolved can
>> be enabled through resolved.conf. This may be a reasonable thing to do in
>> an environment where the configured dns servers are known to support
>> dnssec
>> properly.
>>
>
> Paul may well have been mixing different things here, but I don't think
> you answered the one that seems like the most severe problem:
> systemd-resolved removed perfectly valid DNSSEC records that were supplied
> by the upstream server.  One might reasonably debate whether Fedora's
> default DNS resolver configuration should validate DNSSEC, but I think it
> should honor the DO bit in client requests and return DNSSEC data.
>
> Could the F33 default be changed to at least forward DNSSEC data to
> clients that ask for it?
>
> (My personal view is that either this should happen or that
> systemd-resolved-as-default should be reverted for F33, but I'm not on
> FESCo.)
>

I should add:

After reading https://github.com/systemd/systemd/issues/8967, I really
don't think that systemd-resolved's benefits outweigh its harms as a
default resolver for Fedora.  If someone wants to write a
libfriendlydnsresolver and encourage/patch programs to use it instead of
using glibc's resolver or reading resolv.conf, then that could be debated
on its merits.  But the actual contents of /etc/resolv.conf should follow
the relevant standards, and systemd-resolved does not.

Perhaps systemd-resolved could change its mind and decide to comply with
all relevant standards.  But until then, it seems inappropriate to me for
it to be the default in Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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



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


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

2020-09-28 Thread Fernando Lopez-Lezcano


On 9/28/20 1:51 AM, Ankur Sinha wrote:

Hi Fernando,


Hi Ankur,


I'm a packager sponsor. I'm happy to take over qjackctl and sponsor
Christoph as a co-maintainer to help look after it.

Could you please give me ownership of the package? My FAS is:
ankursinha.


Thank you so much for helping with this! Wonderful!
I just gave you ownership...


rpms / qjackctl
Created 3 years ago
Maintained by ankursinha


It would be great if the program could be upgraded to 0.6.3 to begin 
with... :-)


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

* Andrew Lutomirski:

> Paul may well have been mixing different things here, but I don't
> think you answered the one that seems like the most severe problem:
> systemd-resolved removed perfectly valid DNSSEC records that were
> supplied by the upstream server.  One might reasonably debate whether
> Fedora's default DNS resolver configuration should validate DNSSEC,
> but I think it should honor the DO bit in client requests and return
> DNSSEC data.

FWIW, this is .

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


On Mon, Sep 28, 2020 at 12:14 pm, Paul Wouters  wrote:

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.


It *can* be configured for either case. It will do whatever you tell it 
to.


Our GUI network settings don't expose the ability to send DNS to a 
different network, but systemd-resolved itself does. So if you want to 
see your employees' DNS, go ahead and configure it! It's easy to do 
using resolvectl. We're just not going to make it easy for people to 
shoot themselves in the foot by providing a GUI setting for this. 
Almost nobody has a personal requirement to send non-employer DNS to 
their employer. Nobody woke up today and thought "oh no, I sure hope my 
employer knows how much time I spent today watching Kim Kardashian." 
The network configuration is complex enough already. Many users will 
have no clue what "use this connection only for resources on its 
network" means. Now we have to have separate GUI buttons to allow using 
the connection for DNS, but not for routing? That's just too complex, 
so relegating it to command line is appropriate.



See my previous email with respect to RFC 8598. There is a standard
for this. We supported this in libreswan with unbound before we even
forked from openswan, 10 years ago. I had also patched openvpn when 
Red

Hat swithced VPN service type but it seems that patch got lost along
the way.


I've never heard of IKEv2 or this RFC, but reading just the abstract, I 
guess it's a layer *above* systemd-resolved. You would probably want 
NetworkManager to implement this if it doesn't already, and then push 
appropriate configuration to systemd-resolved. I add some ??? question 
marks because I only read the abstract ???


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:

> 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. Importantly, if you're looking in
> your network settings and you see a checkbox that says "Use this 
> connection only for resources on its network," a reasonable user
> *expects* that the connection will *really* only be used for resources 
> on its network, not that it will be used for everything except DNS,
> which randomly goes to who knows where depending on what else you're 
> connected to. Our design must try to avoid this failure case: "Sadly
> for Distrustful Denise, her employer discovers that she has been
> making some embarrassing DNS requests that she had expected to go
> through public-vpn.example.com instead."

Eh, for a corporate laptop (which is not physically connected to the
corporate network due to present circumstances), I do expect that DNS is
handled by the corporate DNS servers.  I would also like to route all
network traffic over the corporate VPN, but as I tried to explain, that
is just not feasible at the moment.  I also don't see how this is a
trust issue for a *corporate* laptop used for work purposes.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
> >
> > >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> >
>
> > paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
> >
> > ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @
> 127.0.0.53
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags: do; udp: 65494
> > ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
> > ; OPT=6: 01 02 04 ("...")
> > ; OPT=7: 01 (".")
> > ;; QUESTION SECTION:
> > ;vpn.nohats.ca.   IN  A
> >
> > ;; ANSWER SECTION:
> > vpn.nohats.ca.10  IN  A   193.110.157.148
> >
> > ;; Query time: 143 msec
> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
> > ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
> > ;; MSG SIZE  rcvd: 81
> >
> > libreswan will see this result as an attack, and fail to resolve DNS
> names
> > in its configuration. My postfix daemon will hold on to mail because
> > it cannot get a DNSSEC proof of denial of existence of TLSA records if
> > all DNSSEC records are filtered - even for domains that don't use DNSSEC
> > because the denial of existence of DNSSEC for a specific domain requires
> > the return of DNSSEC records that systemd now does not return.
> >
> > I am sorry that I did not follow the fedora list carefully enough to
> > notice this feature when it was proposed.
> >
> > This change is harmful to network security, impacts existing
> installations
> > depending on DNSSEC security, and leaks private queries for VPN/internal
> > domains to the open internet, and prefers faster non-dnssec answers
> > over dnssec validated answers.  It fails various types of queries,
> > misimplements part of the DNS protocol. Not only according to me, but
> > to 20years+ developers of the bind software as well.
>
> You're mixing a few different things here. We decided to not enable
> DNSSEC in resolved with this change, at least initially. For most
> users, DNSSEC is problematic because various intermediary DNS servers
> found in hotspots and routers don't support DNSSEC properly, leading
> to hard-to-debug validation failures. DNSSEC support in resolved can
> be enabled through resolved.conf. This may be a reasonable thing to do in
> an environment where the configured dns servers are known to support dnssec
> properly.
>

Paul may well have been mixing different things here, but I don't think you
answered the one that seems like the most severe problem: systemd-resolved
removed perfectly valid DNSSEC records that were supplied by the upstream
server.  One might reasonably debate whether Fedora's default DNS resolver
configuration should validate DNSSEC, but I think it should honor the DO
bit in client requests and return DNSSEC data.

Could the F33 default be changed to at least forward DNSSEC data to clients
that ask for it?

(My personal view is that either this should happen or that
systemd-resolved-as-default should be reverted for F33, but I'm not on
FESCo.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Sep 28, 2020 at 11:11:31AM -0500, Michael Catanzaro wrote:
> hardcoded list of providers that support DoH. So I believe I'm
> correct to say that only Firefox is doing that... and we have
> already patched Firefox to not do that.

Just for clarity since it confused me: configured by default, not patched.


-- 
Matthew Miller

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

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


On Mon, 28 Sep 2020, Michael Catanzaro wrote:

Anyway, if you don't like this heuristic, we could decide to always delete 
/etc/resolv.conf.


You will break all software linked against libunbound that uses the
ub_ctx_resolvconf() function. Most users of libunbound will use this,
because firewalls might prevent UDP 53 packets going out from anything
but the configured system resolver. It also then uses and gets use of
the system's DNS cache.

The only other alternative I can think of would be to leave 
it unchanged, such that upgraded systems don't get fully migrated to 
systemd-resolved, but that's not a good option.


I do not think systemd-resolved is ready for prime time, even unrelated
to the specific split DNS and DNSSEC case. A number of bugs have been
closed that affect DNS resolving despite DNS experts reporting this
as violating RFC standards and breaking things. For example:

https://github.com/systemd/systemd/issues/8967

Not migrating everything to systemd-resolved per default would not be the
worst solution.

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

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

On Mon, Sep 28, 2020 at 11:11 am, Michael Catanzaro 
 wrote:
Florian just linked to that same chromium.org page as evidence that 
Chrome is not ignoring system DNS. :) Indeed, if you read the page, 
they're only using DNS over HTTPS (DoH) if system DNS matches a 
hardcoded list of providers that support DoH.


Hm, I guess your point remains though, because if Chrome does decide to 
do its own DNS after it sees that your default DNS matches one of the 
whitelisted providers, then of course trying to resolve hostnames that 
need to be resolved by a different DNS is going to fail. E.g. if your 
corporate VPN is configured to be used only for resources on its 
network, I imagine it would fail.


Anyway, nothing we can do about that at the system level, other than 
promote secure system DNS so applications don't have to do it 
themselves with these hacks. I'll start typing up a change proposal to 
enable DNS over TLS.


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

On Mon, 28 Sep 2020, Michael Catanzaro wrote:

I don't think it would be smart for employees to voluntarily opt-in to
sending all DNS to their employer anyway... there's little benefit to the
employee, and a lot of downside.

Again, it is not up to systemd to limit valid use cases.

Perhaps Listen or read to Paul Vixie, father of many Bind software releases:

https://www.youtube.com/watch?v=ZxTdEEuyxHU

https://www.theregister.com/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_feature_becomes_a_standard/

There are use cases for and against routing all DNS over your VPN. If
systemd wants to play system resolver, it needs to be able to be
configured for either use case. You don't get to limit our use cases.

network settings and you see a checkbox that says "Use this connection only
for resources on its network," a reasonable user *expects* that the
connection will *really* only be used for resources on its network, not that
it will be used for everything except DNS, which randomly goes to who knows
where depending on what else you're connected to. Our design must try to
avoid this failure case: "Sadly for Distrustful Denise, her employer
discovers that she has been making some embarrassing DNS requests that she
had expected to go through public-vpn.example.com instead."

See my previous email with respect to RFC 8598. There is a standard
for this. We supported this in libreswan with unbound before we even
forked from openswan, 10 years ago. I had also patched openvpn when Red
Hat swithced VPN service type but it seems that patch got lost along
the way.

Of course, it's still possible to get the old behavior if you really want to,
but it will now require custom configuration not available via GUI

Again, this mentality of "power users can fend for themselves" and "only
our own use cases matter".

, and nobody really wants to opt-in to that behavior

Some people like using a "DNS firewall", or have their VPN admins
require it. Don't map use cases only on your own desired use cases.
I can't really stress this enough, as it is constantly coming up
within systemd projects.

* There is no real protocol for sharing internal domains, so
systemd-resolved cannot know all of them, and resolving some of them
will fail or receive unexpected resolution results (probably
observable for some jboss.org subdomains for Red Hatters, but I
don't
work in that area, so I don't have a good example at hand).

Yes, that's true. And there's not currently any good solution to that without
resorting to the command line.

See above. libreswan IPsec VPNs has supported this for 10+ years. No
commandline required.

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

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



On Mon, Sep 28, 2020 at 11:56 am, Paul Wouters  wrote:

And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
being deployed. And why browsers are, contrary to Michael Catanzaro's
wrong claim, overriding the system DNS already. See Mozilla's TRR
program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
Google's chrome https://www.chromium.org/developers/dns-over-https


Florian just linked to that same chromium.org page as evidence that 
Chrome is not ignoring system DNS. :) Indeed, if you read the page, 
they're only using DNS over HTTPS (DoH) if system DNS matches a 
hardcoded list of providers that support DoH. So I believe I'm correct 
to say that only Firefox is doing that... and we have already patched 
Firefox to not do that.


Similarly, system-resolved will allow us to enable DNS over TLS (DoT) 
systemwide for supported providers. That's not enabled in F33, but I 
think we should flip the default for F34.



What we do not need is systemd-resolved making up its own incompatible
and unsuspected protocols.


Now I'm lost. What are you talking about...?

Better standardization for captive portals seems good, but I'm not sure 
what this has to do with the systemd-resolved change?


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

2020-09-28 Thread Tom Hughes via devel


On 28/09/2020 16:56, Paul Wouters wrote:

On Mon, 28 Sep 2020, Tom Hughes via devel wrote:


On 28/09/2020 15:57, Marius Schwarz wrote:

 Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:

 DNSSEC support in resolved can be enabled through resolved.conf.

 Why isn't that the default, if this resolver can do it?


Because DNSSEC is a disaster area and if you try and use it
on random networks you're going to get failed lookups on a
reasonable number - it's fine if you're on a known network
with decent upstream servers but once you start going out
and using random WiFi hotspots and things it's a very
different story.


And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
being deployed. And why browsers are, contrary to Michael Catanzaro's
wrong claim, overriding the system DNS already. See Mozilla's TRR
program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
Google's chrome https://www.chromium.org/developers/dns-over-https


They solve very different problems though - they secure that
single hop but they don't verify the actual contents of the
records which are then resolved. They also break rather important
things like split horizon DNS on corporate networks. Hell even
my home network has split horizon, which is why I publish the
special record to stop firefox doing DoH.

I mean excuse me for being sceptical about the wisdom of the
likes of google trying to capture the world's DNS traffic by
baking their resolvers into chrome...


The real solution to the requirement for following spoofed DNS answers
to login to captive portals is to have a container with the "uplink"
and a sandboxed browser inside it handling the captive portal. Once
the captive portal part is done, you either use the network's DNS
server, or the user provided one. And maybe change it based on
testing the given DNS server in some way, using one of the ADD IETF
protocols. And only then mark the network as "up" to all other
applications. Or if the user prefers, only use the local DNS for
portal authentication and once there is a clean internet link, use
DoH or DoT to a known truted (non-coffeeshop) DNS server.


Spoofed DNS is one thing, but even once you're connected they
often manage to filter out critical data.

What I do know is that even on the personal and corporate networks
where I manage DNS and where I control everything systemd-resolved
is the first thing I've found where I've been happy to turn on
validation of DNSSEC without expecting things to break regularly.

I spent literally years periodically trying to turn on validation
in bind and quickly giving up again because it's so shockingly bad.

That's not so say systemd-resolved is perfect, it's not that long
since I provided a patch for it to fix a DNSSEC issue after all, but
it's pragmatic approach seems to be doing better than any of the
other things I have tried, be that bind, unbound, dnssec-trigger
or whatever.

Tom

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

Re: Orphaning qjackctl

2020-09-28 Thread Ankur Sinha

On Mon, Sep 28, 2020 09:51:10 +0100, Ankur Sinha wrote:
> Hi Fernando,
> 
> I'm a packager sponsor. I'm happy to take over qjackctl and sponsor
> Christoph as a co-maintainer to help look after it.
> 
> Could you please give me ownership of the package? My FAS is:
> ankursinha.

Or, you can orphan it and I'll pick it up---less work :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

On Mon, Sep 28, 2020 at 12:04:27PM -0400, Matthew Miller wrote:
> > Hm, I'm pretty sure this is a Firefox-specific issue, right?
> > Fedora's Firefox is patched to use system DNS, so it shouldn't
> > matter for us. I'm not aware of any other browser that ignores
> Is this actually the case? I can't find such a patch in 
> https://src.fedoraproject.org/rpms/firefox/tree/master
> but maybe I'm just not looking in the right place.

Ah, got it:

$ grep trr *
firefox-redhat-default-prefs.js:pref("network.trr.mode",5);


-- 
Matthew Miller

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

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

On Mon, Sep 28, 2020 at 10:34:07AM -0500, Michael Catanzaro wrote:
> Hm, I'm pretty sure this is a Firefox-specific issue, right?
> Fedora's Firefox is patched to use system DNS, so it shouldn't
> matter for us. I'm not aware of any other browser that ignores

Is this actually the case? I can't find such a patch in 
https://src.fedoraproject.org/rpms/firefox/tree/master
but maybe I'm just not looking in the right place.

-- 
Matthew Miller

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

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

On Mon, Sep 28, 2020 at 11:56:28AM -0400, Paul Wouters wrote:
> And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
> being deployed. And why browsers are, contrary to Michael Catanzaro's
> wrong claim, overriding the system DNS already. See Mozilla's TRR
> program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
> Google's chrome https://www.chromium.org/developers/dns-over-https

Can we please be careful to not make this personal? It's getting a little
heated. I'm all for technical discussion, but let's not make it about the
people please?


-- 
Matthew Miller

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

2020-09-28 Thread Neal Gompa

On Mon, Sep 28, 2020 at 11:57 AM Paul Wouters  wrote:
>
> On Mon, 28 Sep 2020, Tom Hughes via devel wrote:
>
> > On 28/09/2020 15:57, Marius Schwarz wrote:
> >>  Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:
> >>>  DNSSEC support in resolved can be enabled through resolved.conf.
> >>  Why isn't that the default, if this resolver can do it?
> >
> > Because DNSSEC is a disaster area and if you try and use it
> > on random networks you're going to get failed lookups on a
> > reasonable number - it's fine if you're on a known network
> > with decent upstream servers but once you start going out
> > and using random WiFi hotspots and things it's a very
> > different story.
>
> And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
> being deployed. And why browsers are, contrary to Michael Catanzaro's
> wrong claim, overriding the system DNS already. See Mozilla's TRR
> program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
> Google's chrome https://www.chromium.org/developers/dns-over-https
>

Michael is not wrong. We are, in fact, forcing Firefox to respect
system DNS settings in Fedora. But if you use Mozilla's builds, you
will have this problem. Same goes for Chrome/Chromium.




-- 
真実はいつも一つ！/ 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

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.


Anyway, if you don't like this heuristic, we could decide to always 
delete /etc/resolv.conf. The only other alternative I can think of 
would be to leave it unchanged, such that upgraded systems don't get 
fully migrated to systemd-resolved, but that's not a good option.


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

2020-09-28 Thread Jakub Jelinek

On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > A way out of this could be either to use comdat .debug_info etc. sections
> > (but that would result in quite large increase of *.o file sizes), or let
> > the linker or a tool like DWZ discard or simplify such DIEs.
> > I don't see how could you see at compile time that the linker will not
> > choose the particular copy.
> 
> Another option is to use clang which should have such optimization implemented
> soon:
>   https://whova.com/embedded/session/llvm_202010/1193947/

If you do it on the compiler side, you'll get a lot of those pesky partial
units you so hate on the lldb side.

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

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


On Mon, 28 Sep 2020, Tom Hughes via devel wrote:


On 28/09/2020 15:57, Marius Schwarz wrote:

 Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:

 DNSSEC support in resolved can be enabled through resolved.conf.

 Why isn't that the default, if this resolver can do it?


Because DNSSEC is a disaster area and if you try and use it
on random networks you're going to get failed lookups on a
reasonable number - it's fine if you're on a known network
with decent upstream servers but once you start going out
and using random WiFi hotspots and things it's a very
different story.


And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
being deployed. And why browsers are, contrary to Michael Catanzaro's
wrong claim, overriding the system DNS already. See Mozilla's TRR
program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
Google's chrome https://www.chromium.org/developers/dns-over-https

There have been very vocal discussion at the IETF of browsers vendors
vs enterprise vendors on how good/bad DNS reconfigurations are. Some
discovery methods, and a protocol for Adaptive DNS by Apple have been
discussed at the IETF ADD working https://datatracker.ietf.org/wg/add/documents/

The real solution to the requirement for following spoofed DNS answers
to login to captive portals is to have a container with the "uplink"
and a sandboxed browser inside it handling the captive portal. Once
the captive portal part is done, you either use the network's DNS
server, or the user provided one. And maybe change it based on
testing the given DNS server in some way, using one of the ADD IETF
protocols. And only then mark the network as "up" to all other
applications. Or if the user prefers, only use the local DNS for
portal authentication and once there is a clean internet link, use
DoH or DoT to a known truted (non-coffeeshop) DNS server.

What we do not need is systemd-resolved making up its own incompatible
and unsuspected protocols.

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

Reminder: Summer time changes in the next few weeks

2020-09-28 Thread Ben Cotton

As a reminder to the community, we've reached the point in the year
where jurisdictions around the world begin or end summer time. Be sure
to check your recurring meetings on Fedocal[1] to make sure you know
when you're meeting. Some meetings are set to a fixed time UTC and
others are set to a particular time zone.

A global list of time changes is available by country[2] and by
date[3], but here are a few highlights:

4 October — summer time begins in Australia
25 October — summer time ends in the EU and UK
1 November — summer time ends in the US and Canada


[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2020.html
[3] https://www.timeanddate.com/time/dst/2020b.html


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

[Bug 1877409] CVE-2020-14393 perl-dbi: Buffer overflow on an overlong DBD class name

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



--- Comment #5 from Todd Cullum  ---
Marked the CVSS score as 4.4 for products as there would only be a temporary
risk to availability and low risk to data integrity due to binary protections
shipped with the products.


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

2020-09-28 Thread Ian Pilcher


On 9/28/20 8:32 AM, Zbigniew Jędrzejewski-Szmek wrote:

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.


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.

--

 In Soviet Russia, Google searches you!

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


I don't think my description is misleading

On Mon, Sep 28, 2020 at 5:28 pm, Florian Weimer  
wrote:

* The change disables protection mechanisms built into corporate VPNs
  that require them to observe all DNS traffic. Now this may sound
  rather weak as far as countermeasures go, but DNS-based mechanisms 
are

  the only thing you have got if you do not enforce a client-side
  approach (ugh, no thanks), or disable split tunneling (i.e., default
  route over the VPN; frequently not possible with current VPN usage
  levels and virtual company meetings over video link).


Correct. If you want to observe all DNS traffic, that is no longer 
possible by default unless you also handle routing all traffic. I'd 
argue that's a good change. From a system design perspective, that's 
just how DNS ought to work.


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. Importantly, if you're looking in 
your network settings and you see a checkbox that says "Use this 
connection only for resources on its network," a reasonable user 
*expects* that the connection will *really* only be used for resources 
on its network, not that it will be used for everything except DNS, 
which randomly goes to who knows where depending on what else you're 
connected to. Our design must try to avoid this failure case: "Sadly 
for Distrustful Denise, her employer discovers that she has been making 
some embarrassing DNS requests that she had expected to go through 
public-vpn.example.com instead."


Of course, it's still possible to get the old behavior if you really 
want to, but it will now require custom configuration not available via 
GUI, and nobody really wants to opt-in to that behavior, so it's not 
likely to be used except in managed corporate systems. If you're using 
a managed system, you're probably surveilled anyway, so better assume 
nothing is safe.



* There is no real protocol for sharing internal domains, so
  systemd-resolved cannot know all of them, and resolving some of them
  will fail or receive unexpected resolution results (probably
  observable for some jboss.org subdomains for Red Hatters, but I 
don't

  work in that area, so I don't have a good example at hand).


Yes, that's true. And there's not currently any good solution to that 
without resorting to the command line.


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

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


> A way out of this could be either to use comdat .debug_info etc. sections
> (but that would result in quite large increase of *.o file sizes), or let
> the linker or a tool like DWZ discard or simplify such DIEs.
> I don't see how could you see at compile time that the linker will not
> choose the particular copy.

Another option is to use clang which should have such optimization implemented
soon:
https://whova.com/embedded/session/llvm_202010/1193947/


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mon, Sep 28, 2020 at 5:18 pm, Florian Weimer 
> wrote:
>> But the DNS view provided by the Red Hat VPN is what disables the
>> centralized DNS resolvers in browsers in these configurations.  The
>> magic browser probe no longer fails with the change in DNS routing
>> (which the proposal confusingly names “Split DNS”) because it goes
>> out over the public Internet, where it is not filtered, unlike the
>> Red Hat VPN.
>
> Hm, I'm pretty sure this is a Firefox-specific issue, right? Fedora's
> Firefox is patched to use system DNS, so it shouldn't matter for us. 
> I'm not aware of any other browser that ignores system DNS; at least,
> I'm fairly certain Chrome and Epiphany will both never do this.

It seems that you are right about Chromium:

| We have no plans to support this approach. We believe that our
| deployment model is significantly different from Mozilla's, and as a
| result canary domains won't be needed.



However, you wrote earlier that “split DNS” is not available over
nss_dns, so I think Chromium is still impacted because it uses the same
interfaces that nss_dns would use in this mode (i.e., not nss_resolve).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1883265] perl-File-HomeDir-1.006 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-File-HomeDir-1.006-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=52412011


-- 
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 1883265] perl-File-HomeDir-1.006 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1717285
  --> https://bugzilla.redhat.com/attachment.cgi?id=1717285=edit
[patch] Update to 1.006 (#1883265)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

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

2020-09-28 Thread Jakub Jelinek

On Mon, Sep 28, 2020 at 05:15:16PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:42:33 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> > > Finally I am interested in your proposal to implement a different way
> > > to reduce the size of DIE trees by eliminating "unused" DIEs. It is
> > > hard to predict what effect that would have without seeing an
> > > implementation (in theory GCC with LTO would not actually generate
> > > debuginfo for unused functions). But I think that can be done separate
> > > from your proposal and combined with other size reduction techniques.
> > 
> > And note that GCC already does implement
> > -feliminate-unused-debug-{symbols,types} which are enabled by default and
> > are (at least in my eyes) sometimes too aggressive, so by eliminating even 
> > further
> > DIEs the debug experience might be even worse.
> 
> git clone git://git.jankratochvil.net/massrebuild
> ./dwarfredundant 
> lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64/usr/lib/debug/usr/lib64/liblldb.so.11.0.0-11.0.0-0.2.rc3.fc34.x86_64.debug

So, was this compiled by GCC or clang?
If GCC, I don't see how one could end up with low_pc of 0 unless it is a
comdat function where there is a DIE from the TU that actually was selected
by the linker, or some other copy that wasn't selected.
A way out of this could be either to use comdat .debug_info etc. sections
(but that would result in quite large increase of *.o file sizes), or let
the linker or a tool like DWZ discard or simplify such DIEs.
I don't see how could you see at compile time that the linker will not
choose the particular copy.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1883265] New: perl-File-HomeDir-1.006 is available

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

Bug ID: 1883265
   Summary: perl-File-HomeDir-1.006 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-HomeDir
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rob.my...@gtri.gatech.edu, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.006
Current version/release in rawhide: 1.004-9.fc33
URL: http://search.cpan.org/dist/File-HomeDir/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2891/


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

On Mon, Sep 28, 2020 at 5:18 pm, Florian Weimer  
wrote:

But the DNS view provided by the Red Hat VPN is what disables the
centralized DNS resolvers in browsers in these configurations.  The
magic browser probe no longer fails with the change in DNS routing
(which the proposal confusingly names “Split DNS”) because it 
goes out

over the public Internet, where it is not filtered, unlike the Red Hat
VPN.


Hm, I'm pretty sure this is a Firefox-specific issue, right? Fedora's 
Firefox is patched to use system DNS, so it shouldn't matter for us. 
I'm not aware of any other browser that ignores system DNS; at least, 
I'm fairly certain Chrome and Epiphany will both never do this.


Applications will always be able to ignore system DNS should they 
choose to do so


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

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

But Fedora has not enabled transparent zstd filesystem compression for F-33
btrfs by default and nobody enabled zlib for *.debug files (you even
implemented decompressing zlib from *.debug files) so apparently nobody / you
do not care about the on-disk size.

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

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

> "Fedora 33 uses systemd-resolved for name resolution. Most users will
> not notice any difference, but VPN users will benefit from safer 
> defaults that ensure DNS requests are sent to the same network that
> would receive the corresponding traffic, avoiding unexpected DNS leaks 
> or failure to resolve internal domains."

I think this is rather misleading.

* The change disables protection mechanisms built into corporate VPNs
  that require them to observe all DNS traffic.  Now this may sound
  rather weak as far as countermeasures go, but DNS-based mechanisms are
  the only thing you have got if you do not enforce a client-side
  approach (ugh, no thanks), or disable split tunneling (i.e., default
  route over the VPN; frequently not possible with current VPN usage
  levels and virtual company meetings over video link).

* There is no real protocol for sharing internal domains, so
  systemd-resolved cannot know all of them, and resolving some of them
  will fail or receive unexpected resolution results (probably
  observable for some jboss.org subdomains for Red Hatters, but I don't
  work in that area, so I don't have a good example at hand).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo

2020-09-28 Thread stan via devel

Hi,

When building the kernel with perf enabled from the src.rpm
kernel-5.9.0-0.rc6.20200925git171d4ff79f96.17.fc34.src.rpm
I get an error.  There seems to be an error in one of the build
scripts.  This was not a problem in src.rpm for
kernel-5.9.0-0.rc4.20200911git581cb3a26baf.8.fc34.src.rpm

The error seems to be in a script, and looks like a typo,
+ +# perf
/var/tmp/rpm-tmp.bbuLwN: line 499: +#: command not found
error: Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)
Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)

When I look in that temporary file, I find this, with the error line
marked by << error:

###
# DO it...
###

# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT/usr/libexec

cd linux-5.9.0-0.rc6.20200925git171d4ff79f96.17.20200927.fc31.x86_64





BuildKernel bzImage arch/x86/boot/bzImage 1

+# perf    error
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh

  /usr/bin/make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}"
  LDFLAGS="-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"  -C tools/perf V=1
  NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1
  HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=/usr
  PYTHON=/usr/bin/python3 DESTDIR=$RPM_BUILD_ROOT all


I don't know where that script comes from so I haven't corrected it and
run again, but when I turn off perf, the kernel builds and runs just
fine.

Thanks for any insight.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mon, Sep 28, 2020 at 4:39 pm, Florian Weimer 
> wrote:
>> My understanding is that the DNS request routing in systemd-resolved
>> effectively disables any security mechanisms on the VPN side, and
>> instructs most current browsers to route DNS requests to centralized
>> DNS
>> servers for all requests (i.e., overriding what came from both the VPN
>> and DHCP).
>
> No... certainly not. Previously, VPNs only worked properly if you have
> exactly one VPN, and it's configured to receive all traffic. Using a 
> VPN that receives traffic only for resources on its network, or using
> multiple VPNs at once, would result in DNS leaks. In fact, making VPNs 
> work properly is the *only* reason I'm involved in this. I was
> frustrated to see that Fedora sometimes sent my requests for internal 
> Red Hat resources to my public VPN's DNS server instead of Red Hat's
> DNS servers. See [1] for a comparison between previous and new
> behavior.

But the DNS view provided by the Red Hat VPN is what disables the
centralized DNS resolvers in browsers in these configurations.  The
magic browser probe no longer fails with the change in DNS routing
(which the proposal confusingly names “Split DNS”) because it goes out
over the public Internet, where it is not filtered, unlike the Red Hat
VPN.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[NO ACTION REQUIRED] ELN Module Enablement

2020-09-28 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We wanted to send out a heads-up to let folks know that once Infrastructure
Freeze is lifted this week, we will be enabling modular builds for Fedora ELN.
Once this happens, `platform:eln` will become available as a target for module
builds. For anyone building packages with a BuildRequires of `platform: []`,
building for ELN will happen automatically. If you have an explicit set of
releases you build for, this will be unaffected.

If your modules begin building for ELN, please ignore any output from the
build-system at this time. We are working on infrastructure to enable
automatic rebuilding of the `platform:rawhide` content only when a module
is part of the explicit ELN set, but that portion of the tooling is not yet
available at this time.

* YOU DO NOT NEED TO ADDRESS ISSUES IN ELN MODULES AT THIS TIME *

Our first step here is to ensure that the pipeline is working properly. The
module maintainers are not on the hook at this time for addressing ELN-
specific issues. You also do not need to modify your build scripts to either
explicitly include or exclude ELN builds. Once the tooling becomes more
advanced, you will no longer see ELN builds unless the module in question is
explicitly intended for inclusion.
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl9x/LUACgkQRduFpWgo
bRFcAwv/QeT4X3Q7ltUIx3RYP3LFoCTMOrMTgXn6eewrARBcgDDaBOIZVt7EIrKK
xhIbols9iXiK9lL57fxl7GiMQMkYAvlJtpUy+w/dp6UJj29rPc+SYjo8QKvl5KFm
ewHzb+KSwRhoHWCo2ItxCI0bAbuqc0+PVuxyzlC8bRpv80YrhMYju6b2zg8lY2EW
HPQs2KMyESTn4SwwXuvjUinStVSiPweOGbJEKgsdtNVgaT96Rpgph05uk49gTiUa
AIwJT/kCXmX1k3cHj2/O3CO00+U2dbWCaR3i2sGJjdJ7CIv7cjheBY3fE0SIyhqC
kMlv29ax/fXkhIobDcdJksD94P1E+BhiNogxdJ/1s+V7DYbyCm4V8hGu5ofXhGk1
wSDRYVgWgKK3DlTcIOiqoWYiTFgEaGily7Z9RPX7LkdFyLg1nMWhelw0VpZcTz0a
E+K2k/QEJ+wC+XAfI4Y8PSRbcQfELYEkmOXokFE/jl4PHjwpQG7gAygcjdQWM8Is
HuD2AwPg
=z4z1
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)