https://fedorapeople.org/groups/389ds/ci/nightly/2020/09/29/report-389-ds-base-1.4.4.4-20200928gitdf3a512.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1880857
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
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://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
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
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
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
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 --
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
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
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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:
> > > > *
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
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
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
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
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
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
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 --
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
>>
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
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
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,
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
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
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
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
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
> > >
https://bugzilla.redhat.com/show_bug.cgi?id=1883265
Tom "spot" Callaway changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
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
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
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
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
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
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
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
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
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
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
* 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
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
* 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
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
>
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
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
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
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
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
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
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
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
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
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
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.
> >>
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
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
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
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
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
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
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
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
* 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
>>
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
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
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
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
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
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
* 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
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
* 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
>>
-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
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
1 - 100 of 148 matches
Mail list logo
