Re: google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

On Mon, 4 Mar 2024, Fabio Valentini wrote:


Since this update was stuck and obviously broken, with no response
from Paul in over a week (either here or on the bodhi update), I've
used my provenpackager rights to revert the commits in dist-git and
unpush the stuck update (it failed gating tests, so it never made it
to rawhide repos). This should prevent the broken update from
accidentally getting pushed to Rawhide again, and it gives an
opportunity to re-do the conversion to rpmautospec correctly (i.e.
"rpmautospec convert" to preserve the old changelog) if that is
desirable.


Thanks and sorry for dropping the ball. Last week there were issues
getting the sidetag and this week it got lost in IETF deadline work.

I'll try to pick this up ASAP via the sidetag.

Paul
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

On Wed, 7 Feb 2024, Ben Beasley wrote:


Subject: Re: google-re2 pacakge update and facebook vs google python bindings


I haven't heard back from any of the maintainers.

I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the
first step towards getting python-google-re2 working.

https://src.fedoraproject.org/rpms/re2/pull-request/6

Paul
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

google-re2 pacakge update and facebook vs google python bindings ?

[Paul Wouters]

Hi,

At $dayjob we are running into issues with re2 and python bindings.

Fedora has a fairly old version of re2 with so.9 while upstream is at
so.11. Is there a reason for this? If it is just time, I'd like to
help bumping the package in rawhide.

Originally, facebook creating python bindings for this, which are
packaged in python-fb-re2, but this package is no longer updated
as google're2 now has native python bindings (I think the fb one
was pulled in and maintained and so the fb one is abandoned upsteam)

I'd like to see:

- google-re2 updated to version 2024-02-04
- python3-google-re2 python bindings shipped, providing the fb-re2 package.
- python2-fb-re2 retired

Currently, the google-re2 python bindings do not compile against
the older google-re2 we ship (but that might be a fairly trivial
fix, that would need to be done for the branches anyway)


Added package maintainers to the CC: for additional input.


Again, happy to help if time/effort is the only thing holding
this back. If there are other reasons for this, I'd very much
like to know more. I know there were soname issues in the past.

Packages that would be affected by the soname bump:

loaty
dnsdist
frr
grpc
libarrow
mtxclient
onnxruntime
perl-re-engine-RE2
python3-fb-re2
python3-grpcio
python3-onnxruntime
qt5-qtwebengine
syslog-ng
syslog-ng-opentelemetry

Thanks,

Paul
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

proposal to orphan tcpcrypt

[Paul Wouters]

Hi,

After talking to the debian maintainer of tcpcrypt, we both decided the
best thing is to remove tcpcrypt from the distributions.

- The protocol at the IETF seems have stalled for many years
- The main proponent and implementer sadly passed away years ago
- The website tcpcrypt.org has died a while ago
- The package interferes badly with firewalling tools

If anyone is really objecting, please let me know and be prepared to
become the maintainer in that case.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packager check for F38

[Paul Wouters]

On Wed, 15 Feb 2023, Ben Cotton wrote:


For the curious, here are the stats from today's run:

### Found 2129 users in the packager group. ###
### Found 914 users with no activity in pagure/src.fp.org over the
last year. ###
### Found 845 users which also show no activity in Bodhi over the last year. ###


How many packages depend _only_ on people from this list? Eg are likely
to be unmaintained ?

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up: OpenSSL update

[Paul Wouters]

On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote:


I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37.
I will also push to f38 and rawhide later today.


Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done
in the reverse order?


In fact all the updates landed simultaneously.


Ahh okay, no worries then :)

Thanks for the updates!

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up: OpenSSL update

[Paul Wouters]

On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote:


I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37.
I will also push to f38 and rawhide later today.


Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done
in the reverse order?


This is a security release, it fixes 8 MODERATE CVEs
(https://www.openssl.org/news/secadv/20230207.txt)

I kindly ask you to test the version so it could be rolled up earlier.


I really would hope that testing happens in rawhide before it is pushed
into f36/f37 :(

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Paul Wouters]

On Mon, 12 Sep 2022, Miroslav Suchý wrote:


Do you want to make Fedora 37 better? Please spend 1 minute of your time and 
try to run:



In case you hit dependency issues, please report it against the appropriate 
package.


Seemed fine. I saw two issues related to python azure packages but since
I maintain some that might be self inflected. will double check though
on a stock install.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm with sequoia pgp

[Paul Wouters]

On Fri, 2 Sep 2022, Neal H. Walfield wrote:


Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
work to port it to Sequoia to OpenSSL:


I think this should be considered a blocker for changing gpg backends.


 
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000

Note2: There are lots of reasons to use Sequoia, but one user-visible
reason is improved usability.  When a user imports a certificate,
Sequoia lints it and displays potential issues, or reasons why it
can't be imported:

 
https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174

 $ rpm --import peter-expired-backsig.pgp
 Certificate 251C20A67D942D45:
   Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z
   Certificate does not have any usable signing keys

Whereas before rpm would just say:

 error: peter-expired-backsig.pgp: key 1 import failed.


That seems like a fairly minor point to change backends and crypto
library for and could be something that can be fixed in the current
backend as well?

Of course if upstream rpm is moving, I think fedora should do so as well
to keep in line with upstream, but to me that really does imply not
using nettle but using openssl.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: percona-xtrabackup bundling the kitchen sink in static libs

[Paul Wouters]

On Tue, 23 Aug 2022, Otto Liljalaakso wrote:

The relevant policy is Bundled software policy [1]. Unlike in the past, a 
package does not need a FESCo exception to bundle dependencies. However, the 
requirements of that policy are not being met here: The reason for bundling 
should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should 
be included.


[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/


Thanks for the link. Sadly, the justification would be "because upstream
hardcoded this an errors on any other version", which in itself is
pretty weak. And since it includes boost, which can't easilly be
upgraded between fedora releases, all the older stuff lingers forever.

If the maintainer is not responding, you should invoke the Non-responsive 
maintainer policy [2]. This package has CVE bugs open [3], so most probably 
it should eith be retired, or somebody should start caring for it.


Miro started the non-responsive maintainer process and woke up the
maintainer, but they themselves are also thinking it might be better
to kick it out of fedora.

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

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

percona-xtrabackup bundling the kitchen sink in static libs

[Paul Wouters]

Hi,

I looked at fixing percona-xtrabackup and noticed it is staticly linking
to a bunch of libraries. These .a files are then removed in %install so
they are not shipped. It bundles a bunch of this stuff from its extra/ dir:

duktape  googletest  icu  libcbor  libedit  libevent  libfido2  libkmip  lz4  
protobuf  rapidjson  robin-hood-hashing  zlib  zstd

On top of that, it pins boost to a specific (older!) version and bundles boost
seperate via dist-git / sources :(

I've just fixed it up in the same bad way, making it link to the old
openssl just to get it past F35FailsToInstall for rhbz#1989019. It is
going through rawhide and the branches now. But I think perhaps this
package should be removed from rawhide.

This package clearly breaks a lot of packaging rules, so I was
wondering if there was ever any exception of some kind given to this
package? I will definitely look at $dayjob migrating away from this,
eg see if myhoard or mariabackup can be used instead.

Any feedback would be appreciated, as it seems the maintainer is MIA.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

dnf makecache memory usage increase

[Paul Wouters]

Looks like dnf makecache is uses a lot more memory, causing issues on
smaller systems/containers.

F34:

Metadata cache created.
1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata 162440maxresident)k
144inputs+56outputs (0major+46906minor)pagefaults 0swaps


F35:

Metadata cache created.
29.28user 2.15system 0:49.94elapsed 62%CPU (0avgtext+0avgdata 
841704maxresident)k
184160inputs+497320outputs (181major+425900minor)pagefaults 0swaps

Is this a known issue?

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Paul Wouters]

On Fri, 8 Jul 2022, Kevin Kofler via devel wrote:


But upstream is now under a hostile corporation's control? Can we trust the
most privileged userspace program when it is effectively controlled by a
hostile corporation?


Yes we can, by reading and evaluating the code like we always do. If it
starts to deviate from our needs and requirements, we can change things.

If Fedora was too depending on one person, this change would be good as
in that case we should have diversified these things already before and
now we would be forced to do so if that is problem.

Lennart might not be the easiest person to work with, and I have had
my personal disagreements with him, but he has never been a malicious
person and I don't expect him to suddenly become one.

I wish him luck on his new adventures.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Net-DNS] PR #2: Remove obsolete dependency to Net::DNS::SEC and package tests

[Paul Wouters]

pwouters merged a pull-request against the project: `perl-Net-DNS` that you are 
following.

Merged pull-request:

``
Remove obsolete dependency to Net::DNS::SEC and package tests
``

https://src.fedoraproject.org/rpms/perl-Net-DNS/pull-request/2
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Undoing my screw-up with python-async-timeout

[Paul Wouters]

On Wed, 19 Jan 2022, Miro Hrončok wrote:

It seems the update received negative karma in Fedora 35 -- when that 
happened, you should have immediately disabled autopush to Fedora 34. (I am 
not saying this to rub your nose in it, but rather as an advice for 
future-you and for others as well.)


Yes indeed. I'll pay more attention to that from now on as well.

No, I don't think we need to carry the epoch to F35 and rawhide. Distro 
upgrades happens with distro-sync.


That's what I thought...


 I am looking for some guidance to ensure I don't break things even more
 and I apologise for the extra work that I have and am causing everyone.


My guidance: Open a Pull Request with the revert+epoch and share the link 
here.


Done: https://src.fedoraproject.org/rpms/python-async-timeout/pull-request/2

Thanks,

Paul
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Roman Inflianskas

[Paul Wouters]

On Tue, 26 Oct 2021, Roman Inflianskas via devel wrote:


Subject: Self Introduction: Roman Inflianskas

Dear Fedora Community,My name is Roman Inflianskas.I work at aiven.io (DBaaS 
based on Open-Source technologies) as a Python
Backend Developer, and my motivation for becoming a Fedora maintainer is to 
package software that is used by Aiven so that my
effort had more impact. I contributed to SaltStack, KDE, Taskwarrior, aiogram, 
Vim plugins, LaTeX/LyX style of Russian standard
for research work; packaged some software for openSUSE for myself, etc. My 
personal website is http://roman.inflianskas.ru. In
spare time I like to walk in a beautiful Central Park of Helsinki.I've prepared 
`python-cs` and `python-requests-exoscale-auth`
on my PC. Here is the first ticket: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2017419The person, who 
recommended
people in our company to become Fedora maintainers is Paul Wouters. I'm 
grateful to him for this.Best Regards,
Roman


Welcome Roman! I'm happy to see more Aiven people join our Fedora efforts :)

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Paul Wouters]

On Mon, 12 Jul 2021, Simo Sorce wrote:


SQLite is a general-purpose tool.  Not every use of SHA-1 is
cryptographically relevant.  Most uses in the context of SQLite probably
aren't, so the removal just annoys users for no good reason.


Note that this is a Sqlite decision, from RHEL engineering we only
requested the removal in digital signatures and where integrity
protection is required for security.
Also note that we do not require full removal, just that SHA-1 is not
used unless users intentionally change configuration.


How does this affect users of NSS who have created "default" databases,
eg using certutil -N ?  Do these use SHA1? If so, can they be migrated
to SHA2?  Automatically ?

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[Paul Wouters]

On Mon, 28 Jun 2021, Ben Cotton wrote:


https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec



== Detailed Description ==

OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.


This change makes me a bit nervous, and I'm the author of RFC 8624 that
recommennds not using SHA-1 for DS/CDS records anymore.

https://datatracker.ietf.org/doc/html/rfc8624#section-3.3


Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."


While this is true, the order of where things need to change are:

1 Discourage, but not block, the use of SHA-1. Eg remove it from the default 
set.
2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
3 remove support for SHA-1

This plan assumes we are in phase3. I would say we are in phase2.

Remember, any domain that depends on SHA-1 is going to be more secure
than being marked as insecure because SHA-1 is rejected. This is somewhat
different from like SHA-1 support for authentication where the rejection
of a weaker algorithm forces the use of a stronger algorithm.

The DNSSEC fallback when an algorithm is not supported is to go insecure,
not insist on a more secure SHA-2 that is not there. With DNSSEC,
there is not client-server exchange like with TLS or IPsec. There is
a producer on one end, and a consumer on the other end. The two do not
negotiate crypto parameters.


== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/


I know that a few people believe that shambles can in theory be abused
with DNSSEC, but a lot of people also believe the constrains of DNS
RRsets make this impossible. But even _if_ it is possible, it would
only affect multiple domains that share the same private key that made
the SHA-1 signature. And then we are talking about RRSIG records and
not, as in this proposal, the DS/CDS RDATA content.


Patch the enforcer so that bsha1 is not honored anymore:


I don't think fedora should move faster than upstream opendnssec. I
believe the people at the IETF and the software developers of the DNS
software are more aware of where we are in the migration path than
individual Fedora developers.


== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.


The RRSIG signature is not related to the DS signature. Zone resigning
is something completely different from the DS/CDS records. Those records
are signed by the parent zone, and use whatever algorithm the parent
zone uses, which the child zone cannot dictate.


This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.


The root zone has no DS record, so this statement does not make sense.
The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
that contains a hash of the child's public key, where the hash is created
with SHA-1 or SHA-2.


== User Experience ==

OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.


So there are two things that really need to be clarified for this
proposal. Is it talking about DS/CDS signature algorithm as per IANA
registry http://www.iana.org/assignments/ds-rr-types, or are we talking
about DNSKEY signature algorithm, that is responsble for signing all
the zone data, that uses a hash algorithm or SHA-1 or better. Based on
the description, I am a bit worried that it is not entirely clear what
the proposed change actually is.

Please feel free to reach out to me directly to talk about this feature
request.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Offering strongswan for (co)maintaining

[Paul Wouters]

On Wed, 31 Mar 2021, Petr Menšík wrote:


strongswan and NetworkManager-strongswan packages were passed to me from
previous maintainer. I admit I have little experience with them and do
not run any service based on them. Because IPSsec is quite complex
technology, I am looking for help with its maintenance. I was always
using OpenVPN based solutions myself, so I guess I am not the best
person as main admin. I would like to transfer main admin to anyone
doing a good job, not not immediately. That is why I haven't orphaned it
already.

I would like to keep commit access for a while, but I would share at
least commit access with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.


I have been maintaining strongswan for the last couple of years now. I use
it regularly at upstream libreswan to run interop testing. I am actively
maintaing strongswan for this. I am also an admin on this package. Pavel
is also an admin but he has not worked on the package in many years.

But orphaning seems a bit dramatic when there is an active maintainer ?  :)

As for NetworkManager-strongswan, I am not an actie user of this, but I
could just pick it up for the community. I see it is two versions
behind, so I'll go and update it. For some reason, src.fp.org does not
want to show me this package, so I cannot see who else has admin/commit
rights (or request admin/commit for it)

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Paul Wouters]

On Wed, 24 Feb 2021, Colin Walters wrote:


It's trickier than that because local caching nameservers can provide real 
benefits in various server scenarios, and also the IoT/edge case (as usual) 
blurs the traditional datacenter/mobile boundary.  (IoT can be servers with 
WiFi)

We ended up enabling resolved in FCOS, although it took a bit because it broke 
OpenShift, see:
https://github.com/openshift/okd-machine-os/pull/15
https://github.com/openshift/machine-config-operator/pull/2377
https://github.com/openshift/okd-machine-os/pull/47
etc.


It's hard to read through those. It's a big nest of issues, fixes and
reverts on adding/removing systemd-resolved. I couldn't figure out
the DNS setup based on these reports.


(It's really complex for OpenShift because we have a split between the host DNS 
and pod DNS which is served by CoreDNS, yet some cases span those, plus some 
on-premise installs differ from cloud/Iaas in this)


I'm confused here too, since AFAIK NM does not support tying queries for
certain domains to certain nameservers, and I was told that NM
configures DNS, not systemd-resolved, so how is that done in this case
then? For VPN, to support split-DNS you ran a full resolver like
unbound that has this support, and does not get configured through NM.

I guess I can't say more unless someone can point me to some
documentation on the DNS deployment details there. However, this
all changes nothing that different systems want to use different
DNS solutions, and making systemd-resolved part of the init package
so it is mandatory to install is not appropriate.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Paul Wouters]

On Tue, 23 Feb 2021, Lennart Poettering wrote:


And yeah, call me a hypocrite, but if I have the choice between having
no Internet at all or using some public DNS servers for DNS, and
leaking a tiny bit of information to those DNS server providers then I
am definitely preferring to have Internet, thank you very much.


In practise, this is not often the case. Almost always, the network will
provide working DNS via DHCP. If not, then the network is severely
broken and hacking up a DNS workaround is likely to fail anyway. Like,
you can't get past hotspot/captive portal.

Newly installed and booted server/cloud images should _really_ use the
DHCP obtained DNS servers. It is very likely their correct functioning
depends on local DNS zones and local resources pointed to by DNS not
available when bypassing the local DNS for public DNS services. It is
also likely that those networks even restrict DNS to only allow their
own DNS servers to be used for security and compliance reasons, and
using public DNS would be a violation of network policy.

The scenario of roaming laptops/phones is completely different from
this. Which is why I have argued for a long time now that
systemd-resolved should not be installed by default on servers or
containers. It adds complexity without any real gain in these
deployments and makes DNS issues harder to troubleshoot.


One could even go further: the privacy level using those public DNS
servers might actually be higher than using the DHCP-provided ones in
many cases, simple because we can use DoT on the former (admittedly
not yet the default in resolved though, but hopefully soon), but
almost never can on the latter, and what's worse the latter are
usually provided by crappy edge networks like Internet Cafés and such
where the fact we send stuff unencrypted is just awful.


I agree with this, but the caveat here is that the solution should take
into account isolating the hotspot/signon network from the OS, and not
mix that into your caches when you later bring up more private/trustworthy
DNS servers. But as I said, I'm fine with the default of
systemd-resolved here, although I would strongly prefer to be able to
not install or remove the package for advanced users like me with
specific DNS and DNSSEC requirements that cannot have systemd-resolved
interfering with the system.


Now, Fedora made its choice here, and I'll accept that, but I still
think it's a bad one, that trades a misunderstood concept of privacy
against a major step forward in userfriendliness. i.e. I am not sure
it's a good choice to limit Fedora's userspace needlessly to people
who can fix their DNS configuration. It's a pretty tiny elite group of
people to be in after all...


It seems to have a price of network administrators having their DNS
broken in a string of different ways resulting in filed bugs at
systemd upstream that takes years to get addressed. It can be argued
that this price is too high for the feature of helping nontechnical
laptop users that stumbled into a broken network.

Meanwhile, applications like firefox are absorbing DNS anyway, adding
another layer in the fight over who gets to configure and process DNS:
DHCP, systemd-resolved, NetworkManager, Gnome, or applications.


(Oh, and I don't appreciate those people at all, who claim that
"resolved sends all DNS lookups" to Google because it's a lie, we
never did that, we only did that in case no better DNS configuration
was available, i.e. as *last* *resort*, one step before giving up
entirely).


This seems contradicting? The last resort method only sends all DNS
queries to google as a last resort? It still means that in 100% of
the cases that the last resort is activated, it sends all traffic to
google? Furthermore, since it hides that this is happening, once
the network is broken, it never gets fixed, and thus leads to the
fallback always kicking in.

If anything, these recurring discussions, and long turnover of
systemd-resolverd bugs show that systemd-resolved should be a choice
and not being pushed as mandatory. And I am fine with saying that for
Workstation or Desktop installs, we lean to the side of userfriendly
and give them systemd-resolved. But it has no place as a default
binary or service on servers, containers or cloud images launched
within actively managed networks.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [dns-sig] Re: split-DNS, resolvconf on Fedora

[Paul Wouters]

On Mon, 22 Feb 2021, Petr Menšík wrote:


Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
in case I don't want it?


In the past I also mentioned this. The overwhelming majority of installs
do not gain any benefit from te systemd-resolved service. Most servers,
containers and even workstations are installed and given DNS
configurations via DHCP, manager by a network administrator.

systemd-resolved addresses a problem with finding printers and resolving
a .box domain for router reconfiguration. And it provides partial
solutions for split-DNS views when VPN's are deployed on laptops.

There is no technical reason why this is not in its own package. There
has been some focussing on reducing minimal installs, and this is a
prime candidate for that. I'm fine with the workstation or desktop
installs bringing this package in by default. But I see only potential
harm from installing it on servers, containers and most virtual machines.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: f33: systemd-resolved hang on ip query

[Paul Wouters]

On Wed, 9 Dec 2020, Dridi Boukelmoune wrote:


So it looks like my initial intuition that there could be a mitigation
of sorts is starting to hold water. The problem now is that clients on
my system using getaddrinfo in a way that was legit until now are now
being DoS'd by systemd-resolved, waiting forever for a reply that is
not coming.


This again leads to a required architecture change. We really need to
have a captive portal namespace, that handles all of this while the
applications still consider the network is down. Once the captive
portal has passed and our internet link is "clean", should this be
bridged into the regular network namespace so applications see the
network as "active". Any state of DNS/browser that was used inside
the captive portal namespace is then destroyed (it is untrusted and
unverifiable data)

That is, only the cpative portal handling code sees these bogus DNS
messages, and no regular applications see this. This would also avoid
any applications from throwing SSL certificate errors because they are
connecting to the network too quickly when the network is still being
in captive mode, and your SSL cert is replaced with the portal SSL cert.
Pidgin is specificaly bad with this, firefox has builtin logic to prevent
all its tabs from reloading in captive portal page clones.

Instead, we have gnome, NM, systemd-resolved, firefox et all fighting
over who and how to handle captive portal authentication.

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

Re: systemd-resolved in a container

[Paul Wouters]

On Wed, 18 Nov 2020, Alexander Bokovoy wrote:


Is there a way to use systemd resolved in a container?


I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.


What is the advantage of running systemd-resolved in a container?

Is that container doing mDNS or LLMNR or a split-dns VPN ?

The whole point of containers is isolation and minimal setups. Pulling
in Base OS components into each container seems a waste of resources?

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

Re: Deprecating SCP

[Paul Wouters]

On Mon, 2 Nov 2020, Jakub Jelen wrote:

Some months ago, I wrote a patch [2] for scp to use SFTP internally (with 
possibility to change it back using -M scp) and ran it through some 
successful testing. The general feedback from upstream was also quite 
positive so I would like to hear also opinions from our users.


I am looking for any kind of feedback from the idea through the usability, 
implementation. Is this something you would like to see in Fedora soon? Do 
you have something against this? Is your use case missing?


This is excellent!

Indeed, most users don't care about the underlying SSH protocol flavour
other than expecting it to be secure. They just want "scp" to work.

Your solution does both. It is a very good example of listening to what
users want and supported users without requiring them to learn a new
command like sftp. I wish more developers had this focus!

I will try it out over the next few days. My personal usecases would be
that it still keeps working with rsync's method of invoking scp and that
we would have sftp enable by default for sshd by default.

Thanks!

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

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

[Paul Wouters]

On Thu, 8 Oct 2020, Michael Catanzaro wrote:


On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters  wrote:

 I agree for two reasons. One, the FESCO decision to postpone making
 systemd-resolvd the default resolver. I would like to ensure this
 change happens properly and securely for f34.


Well it's too late, since we are now in final freeze. FESCo reaffirmed the 
systemd-resolved change just last week


I was not aware of this. I've left a comment in the FESCO issue. It is
unfortunately that the issue provides no information why FESCO made this
decision, other than vote tally about why it rejected it. I would
appreciate it if FESCO would clarify their argumentation for this
decision.

Clearly it is very disappointing to me that we are accepting such a
security and standards compliance degradation, especially without a
plan to address that for f34.

, so it's clearly not going to be 
postponed. I agree that this DNSSEC problem with systemd-resolved is 
unfortunate, and I'm sure the systemd developers would appreciate help fixing 
it.


This assumes the issues reported are seen as bugs and not features by
the systemd developers. I have no seen such agreement on the security
and privacy issues I have reported.

Anyway, the best time to deal with this would have been six months ago, 
when the change was proposed


This was reported 5 years ago in a physical meeting. Scolding me now for
not reporting this 6 months ago is not a proper justification, and in
fact sounds more like victim blaming.

Here is my counter proposal for this f34 feature. It is clearly
now 6 months in advance of f34 that some of us reported a number of
systemd-resolved related problems. Let's get these fixed before adding
new systemd-resolved features in f34.

That is, it is far more appropriate to have a f34 feature of "fix
security and RFC standards comforming bugs in systemd-resolved"
than it is to just add more new features without addressing the previous
feature that has significant security bugs. Even if the main goal of
such a feature is to force the systemd-resolved developers to focus on a
security and privacy commitment before adding new features.

That's why we did this in two parts. F33: systemd-resolved. F34: DoT. We 
could have done them both at once.


It looks like the f33 feature did not get done properly at once, so I am
glad we did not do both features as once. If we do this feature for f34
while there were serious issues reporting in the f33 feature, then
basically we would _still_ be doing these two features at the same time.
So in your own words, you are agreeing with me that the f33 feature
should be cleaned up before doing this f34 scheduled feature.

So yes, put this feature in f35 and create a f34 feature to cleanup the
f33 feature. That would show that the issues we have been reported
are taken seriously and address my concern that moving forward with this
feature will cause my issues to never get addressed.


 Second, we really need any DNS-over-TLS to not break DNSSEC. If we are
 going to outsource validation to a remote endpoint via DNS-over-TLS,
 instead of using the local resolver or the local ISP resolver, then
 data authenticity becomes eveb more important. And DNS-over-TLS only
 provides transport security, not data origin authenticity.


Look, I really don't understand, sorry. How is this in any way related to 
DNSSEC? I think this has zero relation to DNSSEC.


The main use case of DNS-over-TLS is to bypass untrustworthy DNS, which
often means the local DHCP provided DNS of the coffeeshop/hotel. The
importance of doing DNS-over-TLS to your local ISP is pretty minor
compare to the security and privacy conerns raised of the current
systemd-resolved implementation and default configuration.

What Fedora needs is for the DNS resolution to re-stabilize, and to not
add more features while there are several security issues at play.

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

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

[Paul Wouters]

On Thu, 8 Oct 2020, Petr Menšík wrote:


I would like to request pausing any new systemd-resolved features
system-wide, until its current bugs and deficiencies are resolved
sufficiently.


I agree for two reasons. One, the FESCO decision to postpone making
systemd-resolvd the default resolver. I would like to ensure this
change happens properly and securely for f34. I am still trying to
use this setup on my f33 with DNSSEC enabled for systemd-resolved,
and do still seem to have issues that I'm going through to see if
these are related to DNS or not. I feel we should have this working
solidly first, before we are adding more options and features into
the mix.

Second, we really need any DNS-over-TLS to not break DNSSEC. If we are
going to outsource validation to a remote endpoint via DNS-over-TLS,
instead of using the local resolver or the local ISP resolver, then
data authenticity becomes eveb more important. And DNS-over-TLS only
provides transport security, not data origin authenticity.

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

Re: F33 upgrade: dnssec-trigger and Strong Crypto Settings, phase 2

[Paul Wouters]

On Wed, 7 Oct 2020, Dominik 'Rathann' Mierzejewski wrote:


Today, I upgraded one of my machines to F33. Upon first F33 boot I
noticed that the dnssec-triggerd service failed to start. It turns out I
had very old dnssec-trigger keys and certificates ("only" 1536-bit RSA)
generated back in 2014 which no longer passed as acceptable per the
default crypto policy change [1], which requires at least 2048-bit keys.
The work-around is to move away or delete the existing keys and
certificates in /etc/dnssec-trigger and let
dnssec-triggerd-keygen.service generate new ones. After that, the
dnssec-triggerd.service starts successfully. I filed a bug[2] against
dnssec-trigger.


Can dnssec-trigger not work now via a unix domain socket instead of TLS
for its command channel? I know NLnetlabs added that for its other
servers like unbound and nsd that only supported TLS before.

The man page suggests it does not support this yet, but I'm pretty
sure upsteam would accept a patch.

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

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

[Paul Wouters]

On Fri, 2 Oct 2020, Michael Catanzaro wrote:

Hm, thanks for the explanation. I guess the DNS request would indeed be the 
*first* way you lose, because you have to do DNS before you do anything else. 
But you are going to lose immediately after anyway:


* Immediately after you connect to the network, Fedora connects to 
http://fedoraproject.org/static/hotspot.txt to see if you're behind a captive 
portal
* Next, GNOME Software starts checking for updates in the background. You've 
leaked "personal data" to fedoraproject.org again, and also fwupd.


If the locally configured DNS server supports Query Minimalization as
per RFC 7816, at this point you would have only revealed "." or ".org"

If it further supports DNS-over-TLS, and more TLDs will start to support
this, then nothing would be leaked. The world is steadilly moving
towards this. Add encrypted SNI, and you see this improves even more.
That is why governments are actually afraid of the opposite of GDPR
right now. The fear of missing out of seeing DNS/SNI data.

* You open Firefox, it downloads Safe Browsing data from Google. (Admittedly 
this one is probably only behind a European CDN, but maybe Google is having a 
bad day, or maybe IP address logs are sent to the US.)


This argument is that any browsing is a GDPR violation of every browser
and OS. It is not a helpfull discussion, and if worth discussing, it
should be discussed by laywers, not software engineers.

I'm sure my list is missing quite a lot. If your interpretation is correct, 
then I suppose German companies should immediately discontinue use of Fedora, 
and also most other computer operating systems


The goal should always be to do the least amount of personal information
gathering or leaking. Stating "but it leaks over there too" is not a
very strong argument to leak data yourself.

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

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

[Paul Wouters]

On Thu, 1 Oct 2020, Michael Catanzaro wrote:

We are not going to patch out fallback to Cloudflare or Google because it is 
a non-issue. Fallback only happens when you have zero other DNS servers 
configured. When was the last time you connected to a network and there's no 
DHCP, no nothing? The number of users without some other working DNS is 
probably under 0.1%.


DNS discovery is currrently a hot topic at the IETF and there are
various proposals circulating on how a client should behave to find
its best DNS resolver.

Please see the ADD and DPRIVE working groups and their documents. I
posted a few direct links in the last few days already. I think a
mechanism that has been architectured by a wider group of engineers
from a large number of different backgrounds and use cases would be
a more appropriate venue to address this complex policy issue.

Personally, I prefer to prompt the user for permission before deciding
to send their personal data to (mostly US based) entities.

And while the majorit of desktop users _might_ be okay with this implicit
decision, it is always better to confirm that explicitely. You might
think that UI is as bad as the COOKIE popups we now get, but lawyers
disagree with us - whether we like or not that is a universe we live in.

Fruthermore it seems the servers running this will almost always never
want this to happen, as most enterprises these days, especially in
light of TLS 1.3 and encrypted SNI, are more and more reliant on using
the DNS stream as an active firewall.

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

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Paul Wouters]

On Thu, 1 Oct 2020, Neal Gompa wrote:


Essentially, split-horizon DNS setups on Fedora systems become
possible with this change.


As reported by libreswan and openvpn developers already in the last
two days, these are already possible without systemd-resolved and
people have relied on that for years.

We have also seen reports like one where servers in an Active Directory
domain with systemd-resolved have broken DNS due to load issues.

Clearly, there is a case for making systemd-resolved "default with
an option to opt-out". It makes no sense that these deployments
must install and ensure to then disable and keep disabled, the
systemd-resolved daemon.

The argument against this so far has been "it makes things more
complicated". I have asked for specific details on this so we can
talk about potentially addressing those complications and make
everybody happy.

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

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Paul Wouters]

On Wed, 30 Sep 2020, Neal Gompa wrote:


since it's only a
couple of binaries averaging 2MB with a few unit files.



My reply was aimed at Peter saying he'd like to not ship resolved, and
I'm saying that we should *not* do that, because it makes things even
harder and more complicated.


These two statements cannot both we true.

And as I indicated earlier, most server installs have no use for
systemd-resolved. Yes it can be disabled, but we didn't go all the
way to virtual servers and containers to have to install things
we will never use.

So I would like to know more about how this would "make things even
harder and more complicated".

The ask I have is very small. When I install a server via kickstart,
I want to be able to do a minimum install, and that it should be
possible that this does not include systemd-resolved". I have
explained my use case, and I believe it is _very_ common use case.

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

Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

[Paul Wouters]

On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:


the systemd package is getting a systemd-networkd subpackage split out
that will contain systemd-networkd, networkctl, and the associated data files.
This was requested by coreos maintainers: NetworkManager is used and skipping
systemd-networkd allows the installation footprint and potential user confusion
to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.)



The main systemd systemd package Obsoletes the -standalone- packages, so it
should smoothly replace them whenever it is pulled in.


In which package will systemd-resolved be?

With enterprise server deployments, DNS will be managed by the network
via resolve.conf to enterprise DNS servers. These servers tend to have
"bind views" for different category of deployments. These deployments
will have no VPN, no mDNS requirements etc. They also do not need (and
most likely do not want) DNS caching.

I believe it would be useful for kickstart installs to not install
systemd-resolved for these kind of typical server deployments. I think
this is an important use case to support.

For Desktop systems, it could default to installing systemd-resolved. It
could even default to it for all installs including Server, as long as
the administrator has the option to not install it via a kickstart file.

It also allows those Destop users that want to use their own validating
resolvers on the end node to uninstall systemd-resolved.

If there are strong reasons not to split systemd-resolved in its own
package, I would like to better understand these reasons.

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

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

[Paul Wouters]

On Tue, 29 Sep 2020, Lennart Poettering wrote:


"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way.


I went out of my way to compare the systemd-resolved team to te DNS teams
consisting of dozens of full time senior people working 20+ years on
DNS with annual budgets of millions of dollars. I even pointed out these
dedicated people spend weeks per year at dedicated DNS conferences and
the IETF. I did this to specifically show that purely from a resource
based point of view, the systemd-resolved team cannot ever match these
resources. I did this specifically to prevent being seen as derogatory.

As we share the same employer, I encourage you to escalate my
"derogatory behaviour" to our magenement.

I did not read the rest of your email. I will not read or respond to
further emails from you on mailing lists.

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

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

[Paul Wouters]

On Tue, 29 Sep 2020, Petr Menšík wrote:


is there any generic protocol exchanging what (sub)domains should be
targetted to specific DNS server?


The search domains are usually the only signal available and used for
this. RFC 7296 (IKEv2) and split-DNS (RFC 8598) defines the sent domain
name list as having a meaning of INTERNAL_DNS_DOMAIN. So it is no longer
a 'search domain' but officially a "name to resolve via the nameserver's
specified by the VPN". Whether to accept these or not is a local policy,
but usually there is a trust relationship that trusts the VPN server.


I know dnssec-trigger/unbound is able
to send queries only to specified search domains received by DHCP server.


Yes, dnssec-trigger tests the nameservers and when they pass, it calls
calls "unbound-control forward_add". This is similar to what
systemd-resolved has adopted via resolvectl.


Are you aware of any implementation independent way to store domains for
each interface?


There is none that I know of.


I think there should be just single way for connection provider to
specify, which domains should go to its DNS server. Then any split-DNS
capable software (unbound, dnsmasq, systemd-resolved) should just
implement its layer to execute such redirection in runtime. Without
special hooks in connection provider to running DNS stub.


I think using the 'search domain' from DHCP is fine. And the VPN use
cases are clear too. As long as "public network" connections never
target specific domains (eg avoid reconfiguring paypal.com)


I doubt there is already generic interface, but it seems it SHOULD be
created.


These discussions are now happening at the IETF ADD and DPRIVE working
groups. While focused on DoT and DoH, the problem is identical. We might
see a "list of domains to resolve via XXX nameserver" in the near
future. Once that happens, it should be trivial to use that with things
like resolvectl or unbound-control.


Can you point me to your support for unbound?


The support for unbound in libreswan is also really easy, as all the
lifting is done by the unbound daemon/library code. We just relay
the domain list and nameserver IPs to forward_add/delete and flush
the related zone names:

https://github.com/libreswan/libreswan/blob/main/programs/_updown.xfrm/_updown.xfrm.in

If we find a running unbound, we reconfigure it. If we don't find it, we
rewrite resolv.conf and send all queries over the VPN. As I said, I'll
work on adding systemd-resolved support here for the next version of
libreswan.

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

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

[Paul Wouters]

On Tue, 29 Sep 2020, Lennart Poettering wrote:


Well, but how do you determine "local resources"?


This is not the proper question. The proper question is "what are you
trying to do". The .local domain discovery clearly is something meant
to be local.

I assume the real question is: How to convey my custom local network
domain to my local infrastructure. In the old days, it was what DHCP
gave you as domain. If you do that with your own network, then it is
pretty obvious. If you do it differently, you will have to coney this
somehow via configuration. This is why 20 years ago Microsoft added
"zones" to their network configuration. Is this a "home zone" or a "work
zone" or a "public wifi".

So I expect the information of "what is local" to live in
NetworkManager or systemd-networkd via configuration.

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


Corporate networks tend to define local zones. Home wifi routers all
do, too. There's no clear way to know what can go directly to well-known
good DNS servers and what needs to be resolved locally.


Generally, resolve the names from the DHCP obtained domain name with
the DHCP obtained name servers. Yes, this is limited to one domain name,
which might not be ideal, but in general when you connect to a home or
corporate network directly (no VPN) then you should use their DNS
servers regardless. Enterprise is likely blocking port 53 (or DoT or
trying to block DoH) for security reasons. And your home network you
trust?

Most home routers these days allow configuration of a guest network
along with the native home network. For those not requiring services
on the home network, and who just need internet. It is the same as
using a public wifi in a coffeeshop or guest network at an enterprise
network. You might need to authenticate a captive portal and then you
should not trust the network for anything else and ideally only give
it encrypted packets (TLS, DoT to trusted DNS servers, VPN). If no
trusted DNS servers are configured on your device, you have no choice
but to trust their DNS servers.

For what the user deems is a "public wifi", there are simply never
any "local resources" other than an internet uplink to your own
remote resources.

In all the above scenario's, I see no ambiguity on which DNS servers
to use, except when multiple domain names exist within only the LAN,
which is rarely the case.

For the VPN scenario, it is just a little bit more complicated.

For those with proper standards, such as "Cisco IPsec", L2TP/IPsec",
the VPN confiuration is dictated by the server to either send all or
some traffic to the VPN server. If it is not "everything", then these
VPNs convey 1 domain name and one or more IP's of DNS servers to use
to resolve that domain.

For IKEv2 IPsec based VPNs, any number of domain names can be specified
by the server to be used by the client. When doing split-DNS with DNSSEC
trust anchors, these can be conveyed and there are strict rules on when
to allow these to override public DNSSEC trust anchors as per RFC 8598.

For VPN protocols with no real standard, things are more complicated.

OpenVPN can do custom things. It all depends on the provisioning.

WireGuard has nothing related to DNS, it is all hidden in the per-vendor
proprietary provisioning code. Perhaps the "wg-dynamic" userland
protocol will address this. Let's hope they read RFC 8598 for
inspiration to avoid the mistakes of IPsec 20 years ago.

What is important with all of the VPN cases is that you properly flush
the cache when the VPN estalishes and terminates, so avoid having
unreachable IP's in your DNS cache. It's important not to flush other
DNS data to avoid DNS fingerprinting users across different networks.

It seems resolvectl is the API to support this with systemd-resolved.

In short, I don't understand the issue raised here of "How do you
determine local resources".

For each and every domain name in the above scenario it is obvious what
nameserver to send it to. There is never a need to broadcast this over
a mix of public / private DNS servers.


Also, people would react very allergic if we'd start sending all DNS
traffic to google or so.


So this feature has no purpose as far as I can see and is never ever a
good idea, unless the user is specifically told their choice is to
disconnect from a broken network or try to use the broken network with
well known public DNS servers as a last resort.


Yes, resolved implements DNSSEC. But from my experience I can tell you
it's very hard to do in a way resonably compatible with DNS servers
deployed out there in particular edge ones. Things mostly work, but
DNS servers are all broken in different ways, and we can't possibly
test things on all possible cheap wifi hw...


Which is why the DNSSEC validation code should have been left to the
large DNS teams at ISC, NLnetlabs, nic.cz, powerdns, IETF/ICANN
communities etc. For any of the problems that systemd-resolved
claims to have 

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

[Paul Wouters]

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

[Paul Wouters]

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

[Paul Wouters]

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

[Paul Wouters]

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

[Paul Wouters]

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

[Paul Wouters]

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


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

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

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

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


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


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

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

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

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

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

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

[Paul Wouters]

On Mon, 28 Sep 2020, Michael Catanzaro wrote:

If you're running mail servers or VPN servers, you can probably configure the 
DNS to your liking, right? Either enable DNSSEC support in systemd-resolved, 
or disable systemd-resolved. I'm not too concerned about this


You should be concerned about this.

The bar should never be "breaking the system is fine for advanced users"

The signal you are sending me (and others) right now is the wrong
signal. systemd should works for me, the user.

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

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

[Paul Wouters]

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


This change is harmful to network security, impacts existing installations
depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers
over dnssec validated answers.  It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but
to 20years+ developers of the bind software as well.


You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.


If you want to do innovate new things with hotspot detection, the place
to do the protocol work is at the IETF Captive Portal Working Group:

https://datatracker.ietf.org/wg/capport/charter/

Work done there include an architecture docoument:

https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

Captive Portal API: https://tools.ietf.org/html/rfc8908

DHCP and RA options: https://tools.ietf.org/html/rfc8910

These are efforts with big vendor signon. These will be compatible with
new hotspots and work similar to other network devices. This is
preferred over homegrown solutions.


leaks private queries for VPN/internal domains to the open internet


It's a complicated subject, but that statement is not true in general.


It was true when we had a DNSSEC systemd meeting in Brno about five years
ago when I raised it as a privacy issue and was told my use case was
"not valid". And it still seems to be true.

With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw
a major discusison in the security area of IETF (specifically SAAG and
TLS)  to ensure every one (including browser vendors) were okay with
the resulting DNS reconfiguration requirements of VPN servers. This
is especially important now that we are storing certificates as TLSA
records in DNS, storing encrypted SNI in DNS, and the current draft SVCB
and HTTPS service binding DNS records that are used in Apple's IOS14.
These records contain information that must not be vulnerale to spoofing
or rogue DNS server redirection and should be DNSSEC signed.

The designers of systemd-resolved will find it a useful read:

https://tools.ietf.org/html/rfc8598


systemd-resolved uses the servers it is told to use. Sometimes we're not
sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041
for a long discussion.


If that worked, I wouldn't have even found out that my system got
upgraded to systemd-resolved. Clearly this is broken. Furthermore,
I doubt the rhbz will take into account the various risks of
reconfiguring DNS and DNSSEC trust anchors or how to limit certain
forwarders to certain domains. We are not talking about bugs that need
fixing. We are talking about design decisions that I objected to five
years ago that are now starting to cause damage.


and prefers faster non-dnssec answers over dnssec validated answers


Not exactly. It uses a single server, unless the server is deemed non-responsive
and then it switches to the next one one, round-robin. Whether the server
does dnssec or not does not directly factor into this. (Except that if
resolved is configured to require dnssec, it won't want to talk to non-dnssec
servers.) If dnssec is enabled, it shall only accept validated answers.


This is better thant it was five years ago. I'm glad some things were
at least successfully conveyed in the Brno meeting. However, this still
leaks queries meant for the LAN or VPN onto the wide internet and is
still a privacy and security concern. Some of these issues might look
like minor unimportant bugs, but could be life changing for some people.
I recommend the systemd-resolved people look into the Human Rights
Protocol Considerations Research Group (https://irtf.org/hrpc) and its
draft documents.


Please file bugs if something is not working as it should. But please be
detailed, because there are a lot of unstated expectations based on how things
worked in the past that don't necessarily makes sense now.


My servers had functional DNSSEC. After an upgrade they don't. No more
detailed reports are needed. You know what you need to do to address
this bug. I see Florian had already filed a rhbz a few days ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1879028

systemd-resolved should not be a required base system package. You know
what you need to do to fix this as well. If you want to make it part of
the graphical desktop install that is okay. But it must not be included
in server installs.


(Like with the name
servers accessible over vpn: some people think a 

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

[Paul Wouters]

Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved


I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.

systemd-resolved has a number of architectural flaws. When these were
pointed out, bugs are not accepted and closed or ignored. Worse, I
was told that systemd-resolved would not become the system DNS resolver,
so I could just choose to not use it.

Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package. This goes against promises made in the past.

Not only that, this change apparently "obsoletes" /etc/resolv.conf,
which is just not acceptable.

It is my opinion as a long time DNS RFC author and package maintainer
that systemd-resolved is not a suitable DNS resolver. Downgrading
DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
read on:

https://fedoraproject.org/wiki/Changes/systemd-resolved

that DNSSEC is now completely disabled. Again, this is completely
unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
mail server uses DNSSEC based TLSA records to prevent MITM attacks
on the STARTTLS layer, which is now completely broken. My IPsec VPN
server uses dnssec validation using the specified nameserves in
/etc/resolve.conf that now point to systemd-resolvd that does not
return DNSSEC records and is completely broken:

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

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;vpn.nohats.ca. IN  A

;; ANSWER SECTION:
vpn.nohats.ca.  10  IN  A   193.110.157.148

;; Query time: 143 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 28 00:18:32 EDT 2020
;; MSG SIZE  rcvd: 81

libreswan will see this result as an attack, and fail to resolve DNS names
in its configuration. My postfix daemon will hold on to mail because
it cannot get a DNSSEC proof of denial of existence of TLSA records if
all DNSSEC records are filtered - even for domains that don't use DNSSEC
because the denial of existence of DNSSEC for a specific domain requires
the return of DNSSEC records that systemd now does not return.

I am sorry that I did not follow the fedora list carefully enough to
notice this feature when it was proposed.

This change is harmful to network security, impacts existing installations
depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers
over dnssec validated answers.  It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but
to 20years+ developers of the bind software as well.

The first mandatory step is to not disable DNSSEC. If I put on my
security hat, I would actually have to look into filing a CVE for Fedora
33.

A further discussion should happen on the future of systemd-resolved as
the default Fedora (and later RHEL/CentOS) system resolver.

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

Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

[Paul Wouters]

Or just a new option to rpmbuild that skips %check ? 

Sent from my iPhone

> On Jun 5, 2020, at 10:11, Tomas Orsava  wrote:
> 
> Hi,
> I think it would be useful to have a standard way of disabling the running of 
> tests during RPM build (in the %check section of a spec file).
> 
> I see a lot of packages already having %bcond's or other macro definitions to 
> archieve this, but each package has their own way, there's no real standard. 
> Thus you have to first look into the spec, locate the appropriate %bcond or 
> macro name and only then you can disable the tests.
> 
> I would like to propose two approaches:
> 
> (a) Add a *SHOULD* rule to the guidelines that specifies what is the 
> preferred way to conditionalize the tests.
> 
> (b) Or, if that's too strong, mention in the guidelines the common methods 
> that are being used (e.g. %bcond tests and %bcond check) so that new 
> packagers have something to use.
> 
> What do you think?
> Tomas
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Does anybody care about gettext?

[Paul Wouters]

On Fri, 9 Aug 2019, Daniel P. Berrangé wrote:


We can't carry on postponing things indefinitely though - at some point we
have to say enough, and expect a maintainer to actually do some maintaining.


That is an argument to orphan, not an argument to remove the package.
Had gettext been orphaned, people would have noticed without the entire
OS breakage.

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

Re: [HEADS UP] Unannounced soname bump of qrencode

[Paul Wouters]

This was a mistake on my end. I thought I was the owner of the package, but
I think I was only the owner of it back in el6. I assume systemd then
wasn't depending on it. I saw a PR the other day, assumed it was to me as
package owner, and saw no reason to not upgrade since it was long over due.
I didn't realise this would break systemd.

Note, it is a bit worrying that systemd depends on this package, which
wasn't updated in 5 years, and for which the upstream changelog mostly
states "bug fixes".

nirik untagged the package for me. I pinged Zbyszek to coordinate things.
I've reverted the commits for f29 and f30 (no updates were issued for these
branches yet)

Ironically, this seems to not be the first time this happened either. I see
someone else made the exact same mistake in January 2018 and reverted their
changes to the package. So let's see if we can fix this now in rawhide so
it does not happen again in another year.

Paul

On Tue, Jun 25, 2019 at 4:33 PM Miro Hrončok  wrote:

> qrencode was bumped from 3.4.4 to 4.0.2.
>
> It has a bumped soname from libqrencode.so.3 to libqrencode.so.4.
>
> systemd once again cannot be installed and all my packages fail to resolve
> build
> dependencies.
>
> Please, announce those changes and coordinate!
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Paul Wouters]

On Thu, 14 Jun 2018, Tomas Mraz wrote:


On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote:



I don't think TLS 1.3 will see a wide deployment immediately. Sure,
the
famous top websites and top browsers will, but enterprises will not.
And
especially those with any kind of loggin/auditing requirements cannot
even allow TLS 1.3 with ephemeral DH on their network.

I would personally first try and disable TLS 1.0 in f29 and see how
much
problems that generates. Then in f30 or f31 disable TLS 1.1.


Except from the internet website statistics the TLS-1.1 only or as
maximum TLS version is not deployed. The sites are either TLS-1.0 max
version or they support also TLS-1.2. So this will not make almost any
difference and the impact on compatibility will be practically the same
as disabling even TLS-1.1.


Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1:

https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00

I guess it all depends on the lifetime of old cheap android devices :P

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

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Paul Wouters]

On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote:


I think the debate here is whether fedora (and in general operating
systems) can afford to be stricter than the browsers. As an OS our
attack surface is much larger than the browser setup, and thus it makes
sense (to me), to be more careful.


Your legacy interaction will also be much larger. Like connecting to
your home wifi router's webgui.


Can we afford to break a significant part of our users? Of course not,
but I think that this change is eventually happening, especially with
TLS1.3 expected to be deployed widely, and it seems to me that we only
wait to see who will do the first step.


I don't think TLS 1.3 will see a wide deployment immediately. Sure, the
famous top websites and top browsers will, but enterprises will not. And
especially those with any kind of loggin/auditing requirements cannot
even allow TLS 1.3 with ephemeral DH on their network.

I would personally first try and disable TLS 1.0 in f29 and see how much
problems that generates. Then in f30 or f31 disable TLS 1.1. But I
suspect fedora itself not to be the problem. The real problems will hit
RHEL/CentOS in the enterprise deployments. So even with a success in
fedora, I would be very careful with drawing any conclusions for
enterprise use.

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

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Paul Wouters]

On Wed, 2 May 2018, Lennart Poettering wrote:


I presume you mean "~/.local" rather than "~/local"?


I don't. As my argument goes, hidden directories containing binaries
in your path are a bad idea. And it was a bad idea 15 years ago. Note
that my home directory seems to only contain ~/.local/share and nothing
else, so this hidden binary directory concept seems to have not been in
use for 15 years.

Storing configs in ~/.local/share seems okay with me, even though it
just moves the namespace from ~ to ~/.local with no good reason, while
still littering in ~/.??* anyway, but that's another issue.

Paul


.local/ was introduced and documented in 2003. That's 15 years ago
now. Pretty much everybody settled on it these days, and many
distributions have clear language suggesting its use. For example,
here's the wording from Debian:

  "Debian does not require that packages conform to the XDGBDS
  but strongly encourages upstreams to do so. "

  — https://wiki.debian.org/XDGBaseDirectorySpecification

Now, the ~/.local/bin/ thing is mostly just a natural extension of XDG
basedir, and many systems have adopted it anyway without this being
explicitly written into any spec.

So yeah, I think it's about time we just update the spec to its
natural extension and to what people already use. I don't think anyone
is helped if we introduce yet another directory for this, in
particular as the security benefit of using any other path is not
universally agreed to.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Paul Wouters]

On Wed, 2 May 2018, Vít Ondruch wrote:


User explicitly installed SW into his home directory. Why (s)he needs to
override the $PATH in addition to make the SW work?


Can you account for all your ~/.??* entries in your home dir? I have
several of which I have no clue what it is or why it got there, and
I have 25 years of homedir experience.

paul@bofh7:~$ ls -al .
Display all 271 possibilities? (y or n)

So I don't think your "User explicitly installed SW into his home
directory" is true, and it is especially not true if software can
make use of knowing ~/.bin will be there for it to quietly drop some
things in.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Paul Wouters]

On Wed, 2 May 2018, Lennart Poettering wrote:


It's already there. And it is XDG complaint. The question here is about
order (what takes priority).


Can you point me to the XDG specification that requires it ? It was mentioned 
by Lenart on the bug, but he later clarified his comment[1].


So this came up again recently here:

https://lists.freedesktop.org/archives/xdg/2017-August/013938.html

(see the full thread)

And I even promised to merge the proposed spec addition there, but
never actually did that. Maybe I really should now...


Adding invisible directories to a user's PATH is putting esthetics over
security and is the wrong thing to do.

I have no problem with ~/bin/ but feel a bit reserved about ~/local/bin/
as ~/local might not be obvious to the user as an added binary containing
directory.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: script to run after hotspot authentication?

[Paul Wouters]

On Tue, 24 Apr 2018, Sam Varshavchik wrote:


Is there a way to run a custom command after hotspot authentication?



You might be able to hook into dhclient.


That happens when you obtain an IP address. There is no notification
method that I know about that will signal me when the hotspot
authentication has happened. This could be seconds or minutes (minutes
is when I open my laptop without typing and grab my coffee at the coffee
shop :)

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

script to run after hotspot authentication?

[Paul Wouters]

Hi,

Is there a way to run a custom command after hotspot authentication?

Fedora has/had some ways of detecting portals. dnssec-trigger,
NetworkManager and Gnome3. I think the current method is supposed
to be based on the latter. So I guess the problem that is used is
/usr/libexec/gnome-shell-portal-helper

Does that signal anything back to NM? It seems the helper itself has
no "post" commands it can run.

Specifially, I'm trying to solve the problem of IPsec MOBIKE support.
When we receive a notification of the new IP address via netlink, the
network isn't working yet and our mobike address update request using
this new IP address dies in the portal filter. The user authenticats
and the captive portal disables the filter, but we no longer receive
any update about this event from netlink/kernel.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

[Paul Wouters]

On 01/10/2018 11:18 AM, Robert-André Mauchin wrote:
> On mercredi 10 janvier 2018 00:07:11 CET  rugk wrote:
>> Providing privacy and security for DNS! (especially after dnscrypt is
>> discontinued now).
>> It would be nice to have this in Fedora.
>>
>> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
>> GitHub: https://github.com/getdnsapi/stubby
>> For distro status see: https://repology.org/metapackage/stubby/versions
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Although upstream has splitted Stubby in a separate repo in August 2017, they 
> still distribute it along Getdns source. Thus in Fedora, the latest Stubby is 
> currently installed with the latest release of Getdns. See https://
> src.fedoraproject.org/rpms/getdns/blob/master/f/getdns.spec
> 
> Maybe you could suggest the package maintainer to add a "Provides: stubby" so 
> it can be found directly. CCing Paul Wouters in that regard.

That's a good idea! I'll fire of some new builds with that later today when I 
fixup
the libidn2 handling as well.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Paul Wouters]

On Wed, 14 Dec 2016, Scott Schmit wrote:


IPsec requires AF_NETLINK (NETLINK_XFRM) to manage the security
associations & security policies.  libreswan probably also needs to be
able to manage the routing for IPsec tunnels (NETLINK_ROUTE[6]).


The nature of libreswan is that it allows custom "updown" scripts to be
executed, which can do things we don't know beforehand. So any
limitation here has to be carefully set. This is why we still allow
seccomp to be disabled. For instance we don't use IPC, but some database
client in updown might use it.


The original RFCs for IPv6 mandated support for IPsec, but that's no
longer required as of RFC 6434.  Nothing else popped out at me as
necessary for IPv6, but it's probably a moot point given XFRM.

So "RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK" is
probably enough? :)


Unless the updown scripts uses a ping command, which is not uncommon for
people to do :)

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Paul Wouters]

On Mon, 12 Dec 2016, Lennart Poettering wrote:


Note that I wonder if restricting address families really belongs in
systemd. Why isnt this a libcap-ng capability? That way my software
can support this without depending on systemd.


hu?

libcap-ng is a library to manage Linux process capabilities.

RestrictAddressFamilies= is a unit file setting, all you have to do
enable it in the unit files of your choice, and the service it runs
then loses access to a specific AF_xyz family (or all but a specific
one). It's implementation is based on Linux seccomp, a kernel facility
entirely unrelated to Linux process capabilities.


Oh, I didn't realise it used seccomp. Never mind then. Those who
implemented something using libseccomp I guess could do this also
independently of systemd.


And there's no talk of having to "depend" on systemd for this to
work. If you ship a systemd unit file in your package (and, quite
frankly you have to if your package contains a service of some kind,
this is Fedora after all), then all you need to do is add a line
RestrictAddressFamilies= to it.


I was talking with my (libreswan) upstream hat on. In general, we try
and support things independent of kernel or OS.


Ideally, you'd ship such a unit file upstream. But if you don't want
your stuff tainted by the horrible idea of shipping systemd unit files
upstream, then it's totally enough to make this change downstream in
the RPM.


Yes, we auto-detect systemd and ship service fils there too. And even
support systemd native things like sd_notify() when available :P


Of course, you can also set up seccomp filters yourself, in your
daemon, in C code, by using libseccomp. It's great if you do


We do.


that's totally possible, and can be functionality-wise entirely
equivalent. The only difference is: systemd makes all of this
trivially easy to use, by making this a single-line change in a unit
file without involving C hacking.


For us (libreswan) it probably makes less sense to restrict address
family in the daemon. Our daemon just listens to UDP 500/4500, so it
would never be affected by any other kind of address families.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Paul Wouters]

On Mon, 12 Dec 2016, Matthew Miller wrote:


Question 1: How can we take advantage of this feature in specific? We
could bulk file a bunch of bugs. Or, what about turning on some more
restrictive defaults (AF_INET AF_INET6 AF_UNIX) on some flag day in
Rawhide, and having services which have different needs add exceptions
to their own unit files (either more or less restrictive).


I don't see the use of a flag day. Everyone can (and should) implement
it in their services file and people can file bug reports for those that
do not?


Question 2: What about *other* systemd security features? The blog post
mentions restricting namespaces as an upcoming feature, and there are
other existing ones which we are not using systemically — like
PrivateTmp, ProtectSystem, etc. How can we take better advantage of
these?


Same?

Note that I wonder if restricting address families really belongs in
systemd. Why isnt this a libcap-ng capability? That way my software
can support this without depending on systemd.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora captive portal page changed output :(

[Paul Wouters]

On Mon, 5 Dec 2016, Michael Catanzaro wrote:


On Mon, 2016-12-05 at 09:05 -0500, Paul Wouters wrote:

That is incorrect in my experience. When I go to coffee shops, my
iphone
shows the portal page, but my laptop shows the TLS cert invalid
thing.


Oh wow. I didn't know that. Feels like time to give up


Anything captive portal does feel that way, although there is some hope
on the horizon with the IETF captive portal working group that is trying
to make this a little easier and more standarized.

https://datatracker.ietf.org/wg/capport/charter/


So what's your recommendation, just ignore all TLS errors and accept
that anybody can intercept your credentials for the portal? It could be
a problem because AFAIK some portals are using Google credentials for
authentication nowadays. I don't know much about that 


With certificate transparency becoming mandatory, the number of bogus
self signed certs and certs signed for bogus made up domains should
decrease as browsers will just refuse to load these. So I do think we
will see a move where if they use certificates, it will actually have
to be a valid one chained to a valid public root CA, which means the
DNS name has to be a real valid FQDN and not some made up goo.

But we are not there yet. So I think a warning might be appropriate.
Credential passing is hard. If done right, the user would only use
something OAUTH like where it is a challenge/response that the portal
will have to relay via the real authentication servers. But if they
will just put up a "sign in with XXX" and a user/password box, likely
many users will just give them their full credentials anyway. I doubt
any green URL bar, padlock or us giving warnings will do anything
about that :(

Right now, the situation leads me to having to close the gnome window
which only displays "TLS certificate invalid" or some text like that,
and still use my firefox and a new tab/window to get through the
captive portal. In which case we are exposing the full firefox with
all my privacy settings and cookies to the captive portal, instead of
(what I hope to be) some "private window" gnome web browser that has
no access to any of my personal data. So I'd rather see the gnome
window ignoring the TLS error and proceeding.


Yeah, I actually filed a bug for this a while back:

https://bugzilla.gnome.org/show_bug.cgi?id=750941


Or a cached page? It's been happening to me on f24 for a few weeks
now.

Paul


Um... yeah maybe, I don't see any code in the portal helper to disable
caching at all. Bug:

https://bugzilla.gnome.org/show_bug.cgi?id=775639


Thanks for filing those!

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora captive portal page changed output :(

[Paul Wouters]

On Sun, 4 Dec 2016, Michael Catanzaro wrote:


On Sun, 2016-12-04 at 16:39 -0500, Paul Wouters wrote:

That is a different issue. And indeed I see it as well, and was quite
surprised at them checking the TLS validity of a captive portal page.


We have no plans to stop doing this, because that's how all other
browsers and operating systems work. It shouldn't be any problem
because such portals would not work for anyone on any system.


That is incorrect in my experience. When I go to coffee shops, my iphone
shows the portal page, but my laptop shows the TLS cert invalid thing.


But in this specific case with the gnome-shell portal helper, there
seems to have been a problem because we tried to load an https:// URI
rather than an http:// one, which isn't going to work under a captive
portal as the portal can't replace the page. I really do not completely
understand what the actual bug here was, and nobody seems to have
figured it out, but it seems that for whatever unknown reason some
captive portals decide not to intercept our load of http://www.gnome.or
g. That URI recently became a redirect to https://www.gnome.org, so the
portal helper performs the redirect and then the portal does intercept
the load of https://www.gnome.org, and that's why you get a TLS error.
It's really weird; I don't know why the portal would do that. Moreover
the issue affected some users, but not others, with the exact same
captive portal, using the exact same version of Fedora; we had this
issue at GUADEC. Maybe the redirect is cached by WebKit on certain
systems so it only works if you haven't visited http://www.gnome.org
before in the portal helper...? Anyway, we have "fixed" this by
changing it to load http://nmcheck.gnome.org which never redirects to
HTTPS. I haven't heard any complaints about this since then, so I think
it's good, but the change is in gnome-shell-3.22.2-2.fc25 which is very
recent so let's wait and see.


Yes. That is why I specifically requested that the fedora hotspot page
never chage their output and never send a redirect. Using the main page
of gnome was a bad fit. Note you should also ensure that nmcheck.gnome.org
has a cache lifetime of 0 seconds to it.


I have that on top of the bug where it just shows me the gnome page
instead of the actual captive portal page.


This really requires a separate bug report against gnome-shell.
Probably a race condition somewhere, maybe the last redirect and
NetworkManager connectivity check occurs just before we get
connectivity back. Unfortunately this is an undermaintained component
that is not very likely to be fixed without a volunteer.


Or a cached page? It's been happening to me on f24 for a few weeks now.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora captive portal page changed output :(

[Paul Wouters]

On Sun, 4 Dec 2016, Kevin Fenzi wrote:


On Fri, 2 Dec 2016 21:42:07 -0600
Eric Sandeen <sand...@redhat.com> wrote:


On 12/2/16 7:10 PM, Paul Wouters wrote:


Fedora runs a captive portal check page at:

http://fedoraproject.org/static/hotspot.txt

It used to return "OK\n".

Now it returns "OK" without the newline.


Seems like the file date is still well in the past
(2015-12-15) and does not actually contain a newline;
webserver behavior change?


Looking at archive.org, I do see the newline in:
https://web.archive.org/web/20150616184630/https://fedoraproject.org/static/hotspot.txt
but not in:
https://web.archive.org/web/20160213221103/http://fedoraproject.org/static/hotspot.txt

Indeed it seems the changes made on 2015-12-15 removed the newline. ;(

Sorry about that.

I can put it back since it seems like NetworkManager's portal detection
doesn't care, or just leave it off now since it's been that way for
around a year?


I guess leave it as is. But it would be good if we can find out what
happened, and fix the process.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora captive portal page changed output :(

[Paul Wouters]

On Sat, 3 Dec 2016, Langdon White wrote:


Wouldn't it make more sense to be checking for status 200? Checking for content 
on the page seems
fragile in general. 


Who says a stolen page wouldn't return status 200?


Also, and perhaps related, I filed a bug[1] about captive portals that seems to 
have some attention. 



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1362449


That is a different issue. And indeed I see it as well, and was quite
surprised at them checking the TLS validity of a captive portal page.

I have that on top of the bug where it just shows me the gnome page
instead of the actual captive portal page.


  Seems like the file date is still well in the past
  (2015-12-15) and does not actually contain a newline;
  webserver behavior change?


That is my guess. I've pushed an update for geome (a tool to tell you
your location based on IP address) which does a captive portal check
to give a more meaningful error if a captive portal prevents it from
working.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora captive portal page changed output :(

[Paul Wouters]

Fedora runs a captive portal check page at:

http://fedoraproject.org/static/hotspot.txt

It used to return "OK\n".

Now it returns "OK" without the newline.

This caused at least the geome tool (from the geome package) to return
a false positive and abort, telling the user to first authenticate to
the hotspot.

I'm pushing a fix now for geome to allow either one of these outputs.
Other packages using the hotspot detection page might have been
similarly broken.

Paul
ps. Not sure if related or not, my gnome portal detection is no longer
showing real captive portal pages, but instead just shows me a gnome
window.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24, small backward steps

[Paul Wouters]

On Tue, 13 Sep 2016, Ralf Corsepius wrote:


 This is a truly awful experiance from POV of a Fedora user filing bugs :-(
 We've set a silent trap for them with no warning of the fact that their
 bug reports are going to be ignored until Fedora EOL procedure closes
 them :-(


One lesson I have learnt in Fedora, is that filing bugs reports against 
packages owned by certain people equals to sending bugs to /dev/null.


IMHO, Fedora should consider to take disciplinary measures against these 
people.


And get less packagers?

It would be useful if package co-owners would automatically get added to
the bugzilla bug, instead of only the package owner. Most packages don't
have dedicated aliases for that.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Paul Wouters]

On Fri, 9 Sep 2016, Adam Williamson wrote:


2. fingerprint identification:

The laptop has a fingerprint reader and it works fine.  However
I prefer not to use it. The user set up specifies that fingerprint login
is disabled.

However whenever I am asked for a password the fingerprint
reader blinks until I swipe a finger over it (even after using a
password).

No fingerprint is registered.

This is different than F23 where it never blinked.


This you should probably file a bug on (against, I guess, gnome-shell?
But it depends a lot on the answer to my second question below...), but
with a bit more detail. What exactly do you mean by "The user set up
specifies that fingerprint login is disabled" - what "user set up" are
you referring to exactly? When exactly does this happen - more detail
on "whenever I am asked for a password". Thanks!


This happened to me too. I did not enable fingerprint based logins
(since half a dozen governments have my fingerprints) and whenever I
open my laptop or unlock the screensaver using a password, the green
fingerprint LED starts blinking. This did not happen on f23.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Imaginary single quotes in ls ?

[Paul Wouters]

On Mon, 6 Jun 2016, bendem wrote:


Are you using an alias like ls="ls --quoting-style=shell"?


Not knowingly. Whatever I got, I got it from systems default.
And yes this is an f-24 install. using a gnome-term if it matters.

Paul



On 06/06/2016 05:53 PM, Paul Wouters wrote:


 paul@thinkpad:/tmp/test$ touch foo bar baz
 paul@thinkpad:/tmp/test$ touch "touch and go"
 paul@thinkpad:/tmp/test$ ls -l
 total 0
 -rw-rw-r--. 1 paul paul 0 Jun  6 11:48 bar
 -rw-rw-r--. 1 paul paul 0 Jun  6 11:48 baz
 -rw-rw-r--. 1 paul paul 0 Jun  6 11:48 foo
 -rw-rw-r--. 1 paul paul 0 Jun  6 11:49 'touch and go'


 This is very misleading, as it appears the filename actually contains
 single quotes. And I tried and failed to fix it using \

 Oddly enough, ls > out does not show this behaviour, so I suspect this is
 some kind of "feature". I would be in favour of disabling this feature,

 Paul
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Imaginary single quotes in ls ?

[Paul Wouters]

paul@thinkpad:/tmp/test$ touch foo bar baz
paul@thinkpad:/tmp/test$ touch "touch and go"
paul@thinkpad:/tmp/test$ ls -l
total 0
-rw-rw-r--. 1 paul paul 0 Jun  6 11:48 bar
-rw-rw-r--. 1 paul paul 0 Jun  6 11:48 baz
-rw-rw-r--. 1 paul paul 0 Jun  6 11:48 foo
-rw-rw-r--. 1 paul paul 0 Jun  6 11:49 'touch and go'


This is very misleading, as it appears the filename actually contains
single quotes. And I tried and failed to fix it using \

Oddly enough, ls > out does not show this behaviour, so I suspect this is
some kind of "feature". I would be in favour of disabling this feature,

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Paul Wouters]

On Fri, 3 Jun 2016, Lennart Poettering wrote:


You are redefining the meaning of (a graphical) logout. It simply
means another user can use the mouse, keyboard and screen of this
device. It makes no statement on whether the machines resources are
shared or not.


Actually, with logind, current kernel, current X11 and/or wayland
there's a very clear statement on sharing devices: logind will ensure
that only the fg session can access the various evdev and DRM devices,
and will suspend access for all sessions not currently in the
fg. Similar, ACLs for a couple of other device nodes are patched
depending on the fg session (but only for DRM and evdev the ongoing
connection of bg users is suspended, as there's no concept of a
generic revoke() in the Linux kernel, but only DRM and evdev-specific
mechanisms). Locking this down properly, so that background sessions
or even non-console logins don't get access to your devices has been
something various folks from various communities have been working
on for a while.

So yeah, sessions (as defined by logind) are a security concept
already, and they will make sure that only the right users get access
to the devices at the right times.


That's great. It has however, absolutely nothing to do with backgrounded
processes, and their interpretation of good vs evil by systemd.

No one is saying when a graphical session ends, you cannot reclaim the
devices required for the next graphical session to start.

No one is saying you cannot protect physical devices from graphical or
network logins.

What it is offered now is garbage collection of the global process list,
and people are stating systemd does not have the required to knowledge to
successfully perform that task - and therefore should not try.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Paul Wouters]

> On Jun 1, 2016, at 09:48, Lennart Poettering wrote:
> 
> Any scheme that relies on unprivileged programs "being nice" doesn't
> fix the inherent security problem: after logout a user should not be
> able consume further runtime resources on the system, regardless if he
> does that because of a bug or on purpose.

You are redefining the meaning of (a graphical) logout. It simply means another 
user can use the mouse,
keyboard and screen of this device. It makes no statement on whether the 
machines resources are shared or not.   

It allows you to kill anything that has to do with the user controlling the 
screen, keyboard and mouse but the killing should be limited to those 
processes. And then we are back at "just fix those broken processes".

As others pointed out, the security feature does not really apply if the user 
is allowed to use any and all resources while logged in.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Paul Wouters]

On Thu, 2 Jun 2016, Lennart Poettering wrote:


Well. Let's say you are responsible for the Linux desktops of a large
security-senstive company (let's say bank, whatever), and the desktops
are installed as fixed workstations, which different employees using
them at different times. They log in, they do some "important company
stuff", and then they log out again. Now, it's a large company, so it
doesn't have the closest control on every single employee, and
sometimes employees leave the company. Sometimes even the employees
browse to the wrong web sites, catch a browser exploit and suddenly
start runing spam bots under their user identity, without even
knowing.


This all has nothing to do with individual processes on machines. If
you are a big bank you better well detect rogue processes using up CPU
on your install base.


In all of these cases you really want to make sure that whatever the
user did ends – really ends – by the time he logs out.


No you don't. you are creating simplistic world views that are not
there.

As others have said, the only simple case of killing processes is those
with no use when the user is gone - that is locally started windowing
applications. Really, we need to fix gnome and gdm and stuff that
lingers where the problem is. We don't need systemd to kill my 200
gdm lockscreen binaries that eventually run me out of resources to
unlock my screen. We need gdm to see its bugs and fix it.


This is really just one example. This model I think really needs to be
the default everywhere.


People aren't agreeing with you. So making it a default seems like a bad
idea. People do seem to agree on "obviously broken windoing apps" that
are left lingering. Why can't we just let those get killed?


On desktops and on servers: unless the admin
permitted it explicitly, there should not be user code running.


no, user code may be running everywhere as long as it does not affect
the purpose or policies of the machines. Such policies are not written
by filenames of binary files.



If you
allow your intern user access to a webserver to quickly check our the
resource consumption of some service that doesn't mean that he shall
be allowed to run stuff there forever, just because he once had the
login privilege for the server. And even more: after you disabled his
user account and logged him out, he really should be gone.


apart from your use case taking up 4 lines, which seems like a difficult
policy to code into applications (remember you would also need to be
able to code the reverse of that policy) the only thing I do agree with
you here is that unlisted uids/gids might be fair game to shoot. But one
has to wonder how well that works in the case of network outages where a
NIS server or something is temporarilly unavailable and you start
shooting legitimate processes.


Yes, UNIX is pretty much a swiss cheese: it's really hard to secure a
system properly so that somebody who once had access won't have access
anymore at a later point. However, we need to start somewhere, and
actually defining a clear lifecycle is a good start.


But your definition is already running foul with just a handful of
software developers and it will cause large unexpected problems in the
real world.

For example, a decade ago at a najor airline, they had their core
database automatically deleted each night. turns out an overeager
cronjob deletes all "core" files that crashed applications left all
over the servers. To me, systemd shooting processes is not different.

If you are that concerned about processes, you need a strict security
policy on what proccesses you allow to be _started_, not trying to
fix your mistakes afterwards by shooting.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Paul Wouters]

On Sun, 29 May 2016, Chris Murphy wrote:


On Fri, May 27, 2016 at 5:03 PM, Paul Wouters <p...@nohats.ca> wrote:


If there is a systematic
problem of badly written code leaving orphaned code running when
a user logs out, then that broken code should be fixed instead of
adding another layer of process management. systemd is not capable
of interpreting the user's intent.


That isn't working. Users are constantly running into restart and
shutdown delays. Troubleshooting this to find out what process is
holding things up is totally non-obvious. Identifying the process is
half the problem, and then getting it fixed and released to Fedora can
be months, by which time some other process is affected.


Taking a shotgun isn't going to help that. Actually, if "bad code
upstream" is the problem, you can just wait on all of that code
starting to tell systemd they want to linger to avoid getting shot
by systemd for doing something wrong.

So this whole thing becomes another abstraction layer that serves no
purpose, and just causes collateral damage.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Paul Wouters]

On Fri, 27 May 2016, Chris Murphy wrote:


It seems to  me systemd should be able to know the difference between
a program that's zombie or unresponsive but isn't doing anything or is
unresponsive but is doing something; and if not then some way for
programs to say "hey wait just a minute, I need to clean things up" or
whatever, rather than just abruptly killing them.


That invention is otherwise known as "unix signals".

systemd should not be the process police. If there is a systematic
problem of badly written code leaving orphaned code running when
a user logs out, then that broken code should be fixed instead of
adding another layer of process management. systemd is not capable
of interpreting the user's intent.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: pidgin, was Re: Orphaned Packages in branched (2016-05-03)

[Paul Wouters]

On Mon, 9 May 2016, Jan Synacek wrote:


I got a few of these warnings in the last few weeks and I'd like those
to stop :)

Is there any interest in supporting SILC? It's an old encryption chat
protcol that I never used or never heard of someone using.

Do the pidgin maintainers want to take the package on, or recompile
pidgin without silc support so we can get pidgin of the death list?


I've disabled silc support.


Awesome, thanks!

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pidgin, was Re: Orphaned Packages in branched (2016-05-03)

[Paul Wouters]

On Tue, 3 May 2016, opensou...@till.name wrote:


libsilcorphan, cicku, nosnilmot   9 weeks ago



Depending on: libsilc (12), status change: 2016-02-26 (9 weeks ago)
pidgin (maintained by: jsynacek, itamarjp, jskarvad, mcrha, nosnilmot)
libpurple-2.10.12-2.fc24.i686 requires libsilc-1.1.so.2, 
libsilcclient-1.1.so.3
pidgin-2.10.12-2.fc24.src requires libsilc-devel = 
1.1.10-15.fc24


[ list of pidgin plugins including the one I maintain ]

I got a few of these warnings in the last few weeks and I'd like those
to stop :)

Is there any interest in supporting SILC? It's an old encryption chat
protcol that I never used or never heard of someone using.

Do the pidgin maintainers want to take the package on, or recompile
pidgin without silc support so we can get pidgin of the death list?

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: mod_rewrite rule please? admin.fedoraproject.org/updates/packagename/ ?

[Paul Wouters]

On Mon, 21 Dec 2015, Michael Cronenworth wrote:


On 12/21/2015 01:19 PM, Paul Wouters wrote:

 Could we have a mod_rewrite rule for
 bodhi.fedoraproject.org/updates/packagename ? 


One already existed. Have you not tried it?

https://bodhi.fedoraproject.org/updates/libreswan


I had in the past, but not recently. Thanks to whoever added it :)

Paul
ps. now if we get admin.fp.org -> bodhi.fp.org it will be perfect :)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

mod_rewrite rule please? admin.fedoraproject.org/updates/packagename/ ?

[Paul Wouters]

Hi,

I really miss the simple URL lookup to find links to the last few
package builds of a certain package. Eg for libreswan, I could use:

https://admin.fedoraproject.org/updates/libreswan/

Now I have to go search around and type in a package name, eg:

https://bodhi.fedoraproject.org/updates/?packages=libreswan

Could we have a mod_rewrite rule for 
bodhi.fedoraproject.org/updates/packagename ?

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/12/2015 09:11 PM, Oron Peled wrote:
> On Friday 11 December 2015 09:09:28 Paul Wouters wrote:
>> On 12/09/2015 06:02 PM, Oron Peled wrote:
>>> Why don't we plan this feature in two stages:
>>>  * Fedora 24: turn it on by default, but *keep using results* from bad DNS 
>>> servers,
>>>just issue a user-visible warning, possibly with a link to a page with 
>>> friendly
>>>explanation and suggestions for further action.
> 
> I'll answer both Paul and Reindl which replied "there's no safe and clean way 
> to solve that"...
> 
>> DNS lookups don't have users like web browsers.
> 
> First, that's only partially correct:
>  * The client (resolver) normally *does* have a user (the uid of the process 
> calling the resolver library).
>  * But after that, your are correct that the caller identity is gone.
> 
> Still, IMO, the goal to warn users can be achieved quite easily. Two examples 
> from the top of my head.
> 1. log + notify:
>* The information may be logged with special prefix (or special field via 
> sd-journal).
>* Users would have a small desktop service that would monitor for these 
> messages and notify about them.

You can do that logging using tools like dnssec-system-tray pointing to the 
unbound log file.

> 2. dbus:
>* The local DNS server would send specific DBUS signal (e.g: 
> net.dnsseq.InsecureDNSReply).
>* A desktop process would listen on these signals and show proper desktop 
> notification.

But these solutions can quickly become a denial of service through popups.

>> I have been running this setup since Fedora 17. Breakage is not that bad.
> 
> Hmmm... even if all of us, fedora-devel subscribers, would run this
> it's still a far cry from a full release cycle of Fedora:

the problem with bad DNS deployments is that it keeps becoming a bigger house 
of cards until
it actually fails to work, similarly how raided disks that write a log message 
that one of the
two disks is failing usually gets found when the second disk failed.

>* large-numbers: millions of machines would reveal much more varied 
> use-cases
>  than what a 500-1000 machines of "fedora-devel" people can show.

google dns, verisign dns and many large DNS deployments already validate and 
break setups of
people using 8.8.8.8 manually. We've gone out of our way to try and be nice to 
existing DNS
deployments, but at some point you got to treat the wound, cause some pain and 
fix things.

> So my hunch feeling is still: make F24 with DNSSEC by default, but not
> "enforcing". Than, F25 will enforce DNSSEC validation.

That just postpones the hurt for 6 months. We've already had a few of these 
cycles. As I said,
I run this since fedora 17.

Really, the biggest issue people fear is their split view DNS. Which is easilly 
solved by extending
the concept of firewalld zones into Network Manager, and always use broken DNS 
forwarders on
"trusted networks".

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/14/2015 04:26 PM, Oron Peled wrote:

>>> 2. dbus:
>>>* The local DNS server would send specific DBUS signal (e.g: 
>>> net.dnsseq.InsecureDNSReply).
>>>* A desktop process would listen on these signals and show proper 
>>> desktop notification.
>>
>> But these solutions can quickly become a denial of service through popups.
> 
> Good point, but that could be mitigated at both ends:
>  * The local DNS server can apply a "rate-limit" for these DBus signals.
>  * Also, the display don't have to use desktop "notifications".
>Alternatively, it can be implemented as a single process that listen to
>these signals and show one popup with minimal info (global warning,
>with a possible list of latest problematic domains).

All these dnssec validation errors would be equally invisible if the system 
used 8.8.8.8 because google would also ServFail these since they do DNSSEC.

> Those DNS deployments are good for general DNSSEC technology validation.
> 
> They have nothing to do with the problem I pointed:
>  * They do not test the crazy DNS world *inside* NAT'ed networks.
>  * In these private networks is where most bad DNS setups exists.
>  * This is the environment that the new Fedora DNS setup will likely 
> encounter.

The only simple solution here is the "trusted network zone" where the user 
explicitly
states they trust their local server. This is something NetworkManager should 
expose
to the user - possibly on first connect.

> factoid: In a medium corporation I know (few thousands desktops/servers 
> across ~5 timezones),
>  they still use internal domains like "foobar.local" (which 
> practically kill
>  great technologies like mDNS).
>  This is pretty obvious as ".local" was considered 
> *best-practice*
>  by some Microsoft Active Directory setups when this corporation was 
> small.

I have no problem breaking those kind of setups.

>> We've gone out of our way to try and be nice to existing DNS
>> deployments, but at some point you got to treat the wound, cause some pain 
>> and fix things.
> 
> I agree, but still think doing it in *two steps* would be beneficial for both
> Fedora and DNSSEC.
> 
> First make it default and analyze the backlash (which won't be fatal, as it's 
> only warnings)
> Than make it "enforcing" and force the pain (after you already have clear
> notification mechanisms that are *familiar* to the end-users).

20 years of DNS has taught me no one ever fixes any DNS until it is causing an 
outage.

> My proposal does not "just postpone" -- Let's make it Fedora-24 default,
> but *warn* about bad replies instead of *rejecting* them -- this would give us
> valuable information.

People will click away the warnings until they upgrade to F-25.

>> Really, the biggest issue people fear is their split view DNS. Which is 
>> easilly solved by extending
>> the concept of firewalld zones into Network Manager, and always use broken 
>> DNS forwarders on
>> "trusted networks".
> 
> Hmmm... "easily solved" is not "solved":
>  * Has this "biggest issue" really been solved? Do we have this NM 
> integration?

I don't know. I don't think the integration with firewalld/NM uses the same 
concept of "zones".

>Does it show in "nm-applet" (I avoid bringing up KDE which I personally 
> use,
>or other desktops)
>  * What other issues we don't know, simply because this Fedora setup hasn't 
> been *widely* deployed?

I'd be more sympathetic to this if we haven't gone through major things like 
/usr move already :P

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/09/2015 06:02 PM, Oron Peled wrote:

> Why don't we plan this feature in two stages:
>  * Fedora 24: turn it on by default, but *keep using results* from bad DNS 
> servers,
>just issue a user-visible warning, possibly with a link to a page with 
> friendly
>explanation and suggestions for further action.

DNS lookups don't have users like web browsers.

I have been running this setup since Fedora 17. Breakage is not that bad.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/09/2015 01:04 PM, Debarshi Ray wrote:
> On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote:
>> On 04.12.2015 15:57, Lennart Poettering wrote:
>>> How do other popular desktop/consumer OSes deal with this? Windows, MacOS, 
>>> iOS, Android, ChromeOS? Does any of them do client-side DNSSEC validation by
>>> default and how are they dealing with this issue?
>> 
>> I'm not able to answer this question.
> 
> That is troubling. :(
> 
> Since this is likely to break networking on a lot of client-side systems, I 
> would have expected you to do this research before submitting it as a System
> Wide Change.

We did. We are the First at undertaking this at an OS level. If the others
proceed they will run in the exact same issue. The problem of broken and
badly designed DNS setups is, is that they only go away when it finally
breaks down.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Lennart Poettering wrote:


Hmm? If I work for a company "Foo Corp" that defined .foocorp as its
private TLD, then I won't be able to access servers in that local
network until I added .foocorp to a local whitelist


Foo Corp should not have done that. If you had picked .hotel or .pizza
you would have noticed this already. If you had picked .corp you would
soon find your domain blackholed at AS112. Basically, you got away with
domain squatting but with DNSSEC this has become indistinguishable from
a DNS attack.

With DNSSEC validation moving towards to stub, it will just fail.

Move your own domains within one of your real legitimate domains, and
you have the freedom to do whatever you want. Start moving away from
split DNS because that's going to be very hard to support.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Matthew Miller wrote:


I read your whole post. Those possibilities seem pretty limited, from
the point of view of serious regressions in Fedora usability. It isn't
that I "like" Fedora being less than technically correct (especially
around security-related features), but I don't think we can discount
the prevalence of "broken" schemes in the real world.


But you gain nothing with waiting. There is no "fix" to wait for. Those
stolen domains are broken and they will start to fail. The only difference
could be that fedora won't be the first where this breaks on, but I
thought "First" was one of our motto's ?


I don't really care about that. I care that we pick the solutions that
are best for our users.


Supporting DNSSEC per default is best for the user. Not enabling DNSSEC
is not a serious option. We delayed this feature a few times to ensure
we would get better integration with gnome and VPNs so that we could
address the _real_ problems.

People using stolen or made up domain names is not a use case that can
be supported anymore with Secure DNS.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Lennart Poettering wrote:


In case this is blocked on the network, Unbound is configured to tunnel
the DNS queries to Fedora public infrastructure over TCP (80, 443) or
SSL (443), in which case this is similar to the first situation, when
Unbound forwards queries to the resolvers, but does the validation
locally.


Ahum. This is another deal-breaker. It's really wrong to simply ignore
local DNS servers. Just because my local company DNS server doesn't do
DNSSEC it's in *no way* OK to make it impossible for me to resolve
local names.

You *have* to use the local DNS servers by default, even if they are
crap.


You can't, thanks to hotels and coffeeshops.

If your DHCP supplied DNS servers work, then these will be used as
forwarders, and you can have your own zone, provided you are not
squatting on the namespace of someone else and it will work fine.


If you don't you break pretty much half of the setups. For
example, with such a Fedora installation I couldn't even print anymore
in my local network,


This feature should not affect .local, so you should be able to find
your printer fine?


I couldn't access my NAS anymore, and not
reconfigure my router. I couldn't connect to stereo's internal web
page, and neither to my internet radio's internal web page. And that's
just my little home network. In a company network it's *way* worse...


If you use your own domain name for that, all of it will still work. And
even without FQDN if you put the right search domains in DHCP.


It's completely OK to gracefully degrade to non-DNSSEC DNS if the
local DNS server cannot do it.


No it is not. coffee shop, hotel network..


The idea of forwarding DNS queries to Fedora servers sounds completely
non-sensical to me...



Given the port numbers I assume that's even HTTP?


No it is raw DNS on port 80.

The fedora DNS servers are a "last ditch" effort. If that is needed in
your network, you have accumulated several deficiencies you should fix:

- don't use broken DNS servers (in other words, yum|dnf update on your dns
  server)
- don't block port 53 to the internet
- don't screw up UDP 53 fragments or TCP port 53, or drop >512byte DNS
  packets

If you do all of that, you deserve broken DNS, and I only feel sorry
that house of cards did not come down sooner to help you.


Do you really think that Fedora is capable and willing to handle all
that traffic?


It is expected to be extremely rare this is needed. When the IETF drafts
for DNSoverTLS are implemented (eg on 8.8.8.8) we suspect it will never
be needed again.


Are you aware of the infrastructure Google is investing
to keep that 8.8.8.8 server up and running? Even if Fedora user's are
a tiny tiny fraction of the number of 8.8.8.8 users, the processing
power it takes for dealing with HTTPS requests is a multitude of what
the 8.8.8.8 requests take...


It's TLS without any validation. It's just to get through stupid
networks blocking legitimate traffic AND having a DNSSEC-broken
(years old!) DNS server running.


DNS and DNSSEC are designed to scale, with all its caching,
forwarding, offline signing and so on. By then pushing the whole
traffic through HTTPS you completely trash all that...


It should never happen on networks that normal people build.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fwd: Re: F24 System Wide Change: Default Local DNS Resolver (fwd)

[Paul Wouters]

(resending - looks like mty @redhat.com is not subscribed)

On 12/07/2015 04:48 AM, Tomas Hozza wrote:


So, here's a question: in germany "Fritzbox" wifi routers are very
popular. Their configuration page is reachable under the "fritz.box"
pseudo-domain from inside their wifi network, and all other systems on
the network are also eachable below this domain under their
DHCP-configured hostnames. It implements a DNS proxy otherwise, only
synthesizing A/ RRs for *.box. Now, one can certainly argue that
this is borked, since the manufacturer doesn't own the ".box" domain,
but discussing this is pretty pointless, as the fact that this is what
is deployed in probably half of the homes in Germany...


Well, there is going to be a very interesting lawsuit about damage then
because in a few months  .box will be live run by a Hong Kong company
called "NS1 Limited"

https://www.icann.org/resources/agreement/box-2015-11-12-en

.box Registry Agreement

12 Nov 2015

On 12 November 2015, ICANN and NS1 Limited, entered into a Registry
Agreement under which NS1 Limited, operates the .box top-level domain. 
[]


Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better
solve this quickly with an update, even if no one actually will update their
router :(

We can make some web page available that will explain how to configure unbound
with an override, but I guess it will be a different IP for everyone? Assuming 
your
fritz.box is 192.168.1.1 you can do:

echo 'local-data: "fritz.box. 3600 IN A 192.168.1.1"' > 
/etc/unbound/local.d/fritz.box.conf

Of course you can also use /etc/hosts

 Also I am

pretty sure other routers form other manufacturers do the same
thing. Now, if we default to DNSSEC validation soon, does this mean
people won't be able to configure their wifi routers anymore, or reach
other systems on their home networks anymore, because the NSEC/NSEC3
RRs in the root domain claim .box does not exist?


Don't they work when you use http://192.168.1.1/  ?

  What's your

strategy there?  Why do you think DNSSEC is worth breaking pretty much
everybody's network? Note that Fritzbox is not a random crappy router,
it's probably of the better products you can find.


See above. It's going to get broken anyway. Actually, this could be a security 
nightmare
if someone registers fritz.box and will start receiving connections for IP 
address that
give them their router passwords!


I think we could extend the module with an option to configure list of domains
for which you would like to fallback to the local resolvers, even if the
answer was SECURE. This could be used for the non-existing or "abused" TLDs.


That only works if .box is not delegated. Unfortunately, it will be very soon.

Initially it will resolve to 127.0.53.53 when the TLD is brought up. So 
hopefully
that will cause people to safely see the failure mode. Only after the domain has
launched fully will someone be able to possibly register fritz.box maliciously.


Note that IETF is thinking about reserving some of such domains as private [3],
so once it is standardized, it could be done for these automatically.


Actually DNS servers will either fail those queries, or they will be targeted
at the global blackhole running via AS112


I don't think there is any universal or even right solution to this. Once you
start doing such hacks, there is a very thin line when you are starting to 
degrade
the security gained by using DNSSEC.


Worse, we open up ourselves for legal issues if the domain is delegated.


How do other popular desktop/consumer OSes deal with this? Windows,
MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
validation by default and how are they dealing with this issue?


I'm not able to answer this question.


It will start failing for people irrespective of DNSSEC.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Mon, 7 Dec 2015, Florian Weimer wrote:


Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better
solve this quickly with an update, even if no one actually will update their
router :(


Well, AVM could just register fritz.box and leave it unsigned, which
solves the problem for us.


If my fritz.box is 192.168.1.254 and yours is 192.168.1.1, what would
you want the AVM registered domain fritz.box to return as A record?

One of us will break regardless, unless the fritz box hijacks all port
53 to push it through its preprocessor its fake .box domain.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On 12/07/2015 04:48 AM, Tomas Hozza wrote:

>> So, here's a question: in germany "Fritzbox" wifi routers are very
>> popular. Their configuration page is reachable under the "fritz.box"
>> pseudo-domain from inside their wifi network, and all other systems on
>> the network are also eachable below this domain under their
>> DHCP-configured hostnames. It implements a DNS proxy otherwise, only
>> synthesizing A/ RRs for *.box. Now, one can certainly argue that
>> this is borked, since the manufacturer doesn't own the ".box" domain,
>> but discussing this is pretty pointless, as the fact that this is what
>> is deployed in probably half of the homes in Germany...

Well, there is going to be a very interesting lawsuit about damage then
because in a few months  .box will be live run by a Hong Kong company
called "NS1 Limited"

https://www.icann.org/resources/agreement/box-2015-11-12-en

.box Registry Agreement

12 Nov 2015

On 12 November 2015, ICANN and NS1 Limited, entered into a Registry
Agreement under which NS1 Limited, operates the .box top-level domain. 
[]


Clearly, fedora cannot be changed to hijack a real domain, so Fritzbox better
solve this quickly with an update, even if no one actually will update their
router :(

We can make some web page available that will explain how to configure unbound
with an override, but I guess it will be a different IP for everyone? Assuming 
your
fritz.box is 192.168.1.1 you can do:

echo 'local-data: "fritz.box. 3600 IN A 192.168.1.1"' > 
/etc/unbound/local.d/fritz.box.conf

Of course you can also use /etc/hosts

 Also I am
>> pretty sure other routers form other manufacturers do the same
>> thing. Now, if we default to DNSSEC validation soon, does this mean
>> people won't be able to configure their wifi routers anymore, or reach
>> other systems on their home networks anymore, because the NSEC/NSEC3
>> RRs in the root domain claim .box does not exist?

Don't they work when you use http://192.168.1.1/  ?

  What's your
>> strategy there?  Why do you think DNSSEC is worth breaking pretty much
>> everybody's network? Note that Fritzbox is not a random crappy router,
>> it's probably of the better products you can find.

See above. It's going to get broken anyway. Actually, this could be a security 
nightmare
if someone registers fritz.box and will start receiving connections for IP 
address that
give them their router passwords!

> I think we could extend the module with an option to configure list of domains
> for which you would like to fallback to the local resolvers, even if the
> answer was SECURE. This could be used for the non-existing or "abused" TLDs.

That only works if .box is not delegated. Unfortunately, it will be very soon.

Initially it will resolve to 127.0.53.53 when the TLD is brought up. So 
hopefully
that will cause people to safely see the failure mode. Only after the domain has
launched fully will someone be able to possibly register fritz.box maliciously.

> Note that IETF is thinking about reserving some of such domains as private 
> [3],
> so once it is standardized, it could be done for these automatically.

Actually DNS servers will either fail those queries, or they will be targeted
at the global blackhole running via AS112

> I don't think there is any universal or even right solution to this. Once you
> start doing such hacks, there is a very thin line when you are starting to 
> degrade
> the security gained by using DNSSEC.

Worse, we open up ourselves for legal issues if the domain is delegated.

>> How do other popular desktop/consumer OSes deal with this? Windows,
>> MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
>> validation by default and how are they dealing with this issue?
> 
> I'm not able to answer this question.

It will start failing for people irrespective of DNSSEC.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Tue, 1 Dec 2015, Randy Barlow wrote:


This sounds overall pretty neat to me! One detail came to my mind: how
would this interact with VPN DNS servers? In my experience with VPNs,
it's common for them to provide a DNS server that allows internal host
resolution to work. Would this local resolver be notified by NM of a new
VPN connection so that it knows to use the VPN-provided DNS server for
hosts on that particular domain, rather than the usual external records
for that same domain?


Yes, this already works in most VPN implementations shipped with Fedora.
(libreswan/IPsec, vpnc/IPsec, openvpn, and probably openconnect)

For IPsec, that support will be extended for IKEv2 in the future too,
see https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/

The running unbound DNS server will be told to "forward" certain domains
to certain IPs of nameservers received during the VPN negotiation. It
will remove the forward when the VPN connection goes down. And for those
domains, the cache is flushed on each event too, to prevent using stale
data that is only used when the VPN is up (or down)

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Tue, 1 Dec 2015, Björn Persson wrote:


Tomas Hozza  wrote:

- dnssec-trigger does not do the Captive Portal detection and handling and
  we rather rely on NM for the detection and on Gnome Shell for the Portal login


Can I assume that users of non-Gnome desktops will also be able to log
in to a portal if they want to?


If you can do so now, then you will in the future as well? The idea here
is that dnssec-trigger will no longer fire up its own portal login page,
but leave it to the OS/Desktop.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Paul Wouters]

And openpgpkey-milter :)

And put in a TLSA record for their MX :)

 Paul

Sent from my iPhone

> On Oct 5, 2015, at 10:58, Michel Alexandre Salim  
> wrote:
> 
> On a related note to that, it would be great if active Fedora contributors do 
> get to use an SMTP server with SPF and DKIM set up.
> 
> -- 
> Michel
> 
>> On Mon, Oct 5, 2015 at 9:47 PM, Marcin Juszkiewicz  
>> wrote:
>> W dniu 05.10.2015 o 16:43, Reindl Harald pisze:
>>> well, that people should send their mail from the Fedora servers and
>>> not from a wrong configured random MTA allowing random envelope
>>> senders
>> 
>> Many of those people send their mail from properly configured MTA allowing 
>> random envelope senders for authenticated users.
>> 
>> -- 
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SPF records @fedoraproject.org versus @lists.fedoraproject.org

[Paul Wouters]

On Mon, 5 Oct 2015, Kevin Fenzi wrote:


On Mon, 5 Oct 2015 11:04:40 -0400
Paul Wouters <p...@nohats.ca> wrote:


And openpgpkey-milter :)

And put in a TLSA record for their MX :)


I don't think it makes much sense for Fedora Infrastructure to get into
the business of being a SMTP server provider. Is this something that
would help forward the goals of the Fedora Project? If so, how?


I wasn't refering to Fedora Infrastructure, but to people running fedora
for their mail servers.

That said, if we run MX for fedoraproject.org, we should also do that of
course :)

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat

[Paul Wouters]

On Fri, 25 Sep 2015, Matthew Miller wrote:


On Thu, Sep 24, 2015 at 10:10:40AM +0200, Vít Ondruch wrote:

Also, you might consider to ship the precompiled bytecode just
optionally, using recommends.

On contrary, if you insist on shipping the bytecode, why you don't drop
the .py files? I see a lot of duplication all around python packages 


Wait, we can do that? Why don't we?

Everything I see in online discussion is centered on, basically,
transparency. But we wouldn't be doing it for obfuscation. The srpms
would still be there, and for that matter we could ship the .py files
in a subpackage.


It's nice to be able to edit the .py for testing without going through
hoops or building/installing rpms.

It's also nice to be able to read the .py code. That is one reason
people use script languages :P

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Paul Wouters]

On Mon, 21 Sep 2015, Owen Taylor wrote:


Experimenting with GNOME, the model presented to the user seems to be:

 - Each application's volume control separate goes from 0-100% of the
   maximum system volume. 
 - Adjusting each application is independent
 - Modifying the system global volume slider proportionally adjusts the
   volume of each application
 - The system global volume slider is always maintained to be at least
   as much as the maximum of any application


Unfortunately, for endusers like me, who want pidgin to not blare
out, there isn't a simple user interface to let me select
that. Like let's say a right click on the top right volume icon that
would show all apps with volume so I can bring pidgin volume down.

So as a result, I always end up using the system volume control, and
after I play a movie or an mp3, pidgin blares out loudly.

So the current system is clearly not working for me.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bind: CVE-2015-5722 and CVE-2015-5986

[Paul Wouters]

On Fri, 4 Sep 2015, Bojan Smojver wrote:


According to ISC, these two affect bind 9.10.2 as well (up to P3).
There a no new builds (i.e. P4) for F22 of this package that I can see.

Does anyone know why? Is there something Fedora specific that prevents
these problems in F22 packages?


I just built it in rawhide, and it seems fine.  I suspect it has just
been an "no time" issue. I'll ping Tomas and ask him.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Cleanup of Upstream Relase Monitoring bugs

[Paul Wouters]

On Wed, 2 Sep 2015, Vít Ondruch wrote:


3) Packages are updated, but the bug is kept open



I would suggest probably to close the bugs for 1st category, the
packages from 2nd category should be orphaned and the packages from 3rd
category should not be monitored anymore. Any thoughts?


I would keep monitoring for 3) but close onesting bugs that are too old
and were clearly forgotten. I prefer to be informed by the monitor
script, even if I am a version behind :)

I've also just now added comments for all my entries on why these are
still not in CLOSED state.

Paul



Vít




[1]
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING_status=POST=Fedora=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Copendate=upstream-release-monitoring%40fedoraproject.org=1=substring_id=1733771=changeddate%20DESC%2Cbug_id%20DESC_based_on=_format=advanced

[2] https://fedoraproject.org/wiki/Upstream_release_monitoring

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: perl-Net-DNS-SEC license correction

[Paul Wouters]

On Fri, 7 Aug 2015, Petr Šabata wrote:


This package's license tag was wrong all along; the license
tag will be corrected to `MIT'.  Updates are on the way.


hm, I had 1.01 packages pending..

Also, the license says GPL+ or Artistic. The README says:

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of the author not be used in advertising
or publicity pertaining to distribution of the software without specific
prior written permission.

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.


Is that not the artistic license?

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gpg keys of older/newer fedora versions

[Paul Wouters]

On Wed, 5 Aug 2015, Neal Gompa wrote:


I disagree that including the keys for EOL'd releases counts as
encouraging people to use old stuff. If someone has a reason to be
building RPMs for something way-old, I think it'd be nice for us to keep
those GPG keys available for them.


Agreed.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gpg keys of older/newer fedora versions

[Paul Wouters]

On Fri, 17 Jul 2015, Zbigniew Jędrzejewski-Szmek wrote:


[In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383]

'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap
a Fedora chroot. The only snag is that --nogpg is often recommended, because
fedora-repos only provides the GPG keys for the current and next release.

It would be convenient (and safe!) to provide keys for past and future releases,
so such bootstrapping can be done without either importing the keys manually
and/or using --nogpg.

I thought I'd ask here first: is there a strong reason *not* to include those 
keys?


I see no reason not to do that. We were also going to put those keys
into DNS, pendig some changes of the OPENPGPKEY ietf draft document.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

[Paul Wouters]

On Fri, 17 Jul 2015, Chuck Anderson wrote:


What doesn't work in your experience with the captive portal stuff?



Usually, the dnssec-triggerd captive portal detection pops up a
dialog, and when I click log in nothing happens.  When I click
skip (sorry I might be forgetting the exact button names) then a
captive portal browser pops up (I think this is the normal Gnome or NM
one, again not sure).  Usually things work fine after logging in
there.


Yes, the xdg-open command that launches the captive portal login of
dnssec-trigger often does not get launched for me either. Usually
I already have firefox open, so i go to 1.2.3.4 or something to
trigger it.


Even without the recent SELinux issues, dnssec-triggerd's captive
portal implementation has been iffy.  Sometimes it works, and
sometimes it doesn't.  I think there may be an issue with it trying to
launch the captive portal login browser, or timing issues between
Gnome/NM and dnssec-triggerd.


Yeah, I am not entirely sure what's causing it either.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnssec-trigger + GNOME + NetworkManager integration

[Paul Wouters]

And dnssec-validator.cx for a Firefox/chrome plugin that you can see in action 
against fedoraproject.org that already deploys this 

Sent from my iPhone

 On Jul 3, 2015, at 10:43, Petr Spacek pspa...@redhat.com wrote:
 
 On 2.7.2015 17:56, Michael Catanzaro wrote:
 On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote:
 this type of attitude?
 
 everybody who reads IT news over the past years about CA's issued 
 certificates even for Google knows that a CA signed certificate does 
 not 
 prove anything - the real problem is wehn this happens for Google 
 somebody takes notice and the press writes about it
 
 if the same happens for your domain nobody will recognize it
 
 The situation is going to be getting a lot better in the near future,
 though. We're getting to the point where we can start enforcing
 Google's certificate transparency: if your certificate isn't on the
 public audit list, we can simply reject it. That allows individual web
 sites to get an immediate heads-up whenever any fraudulent certificate
 is issued for their site. (And researchers will be looking after the
 most important sites, of course.) That's not going to fix TLS in
 itself, because most sites probably don't care, but if the site does
 care, it will be impossible to issue a browser-trusted certificate for
 the site without that site knowing. (At least, that's my understanding
 of the technology; I haven't researched it thoroughly.)
 
 You're right that OCSP is worthless. GNOME applications don't currently
 perform any certificate revocation; I'm not willing to implement OCSP
 unless Firefox is willing to enforce it, and they aren't. We should
 implement OneCRL, which solves the revocation problem for intermediate
 certificates, but there doesn't seem to be any reasonable solution for
 individual sites yet. OCSP must-staple seems promising.
 
 Of course, we can't have any of these nice features in GNOME unless
 somebody wants to pay for their implementation. (If so, get in touch
 please.)
 
 For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698.
 
 -- 
 Petr Spacek  @  Red Hat
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct