Re: Encrypted DNS in Fedora

[Petr Mensik]

On 11/6/19 7:11 AM, Tomasz Torcz wrote:

On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:

Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :



   I don't agree with centralisation.  You should run your own DoH
endpoint,
using Google's, Cloudflare's or Quad9's servers is a shortcut.


DoH has zero integration and manageability. “It’s not centralized” (but
you have to set manually DoH settings in all apps *or* rely on a
centralized Google DoH whitelist) is an utter joke.


   Setting in all apps? Excuse me?  You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf. Done, you've got DoH set
system-wide, which I believe this thread is about.
   And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.

  (cutting the rest as it's irrelevant)



I agree with one sidenote. It is not required to use DoH for that, DoT 
is enough already. And it cannot contain privacy leaking headers, 
because there are just none in the protocol.


I think dnssec-trigger might be and example. It checks dnssec in current 
resolvers obtained by DHCP. If it does not support it, it uses its own. 
If they are blocked, it uses proxy. Does not know anything about 
encryption, but it might work if tuned a bit.


Problem is, it has already terrible design. It should be driven by 
network manager or something similar. Anyway, I think any encryption 
belongs to the system, not applications. But first, we need some 
system-wide tool prepared for that. Besides dnssec-trigger, there is 
getdns-stubby package. It does not allow simple use of DHCP specified 
resolvers, but it is the best solution for encrypted DNS at the moment.


Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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: Encrypted DNS in Fedora

[Petr Mensik]

Hi Marius,

I maintain BIND and some similar stuff. More or less, there is already 
implementation quite similar to what you have described. Already in 
Fedora: stubby [1]. It has central list of several resolvers and uses 
them in round-robin fashion. Does not make specific order.


However, the most close solution to what is required in coordination 
with DHCP is IMO dnssec-trigger. It has very complicated design 
unfortunately.


Regards,
Petr

1. https://github.com/getdnsapi/stubby

On 11/5/19 3:07 PM, Marius Schwarz wrote:

Am 05.11.19 um 14:21 schrieb Florian Weimer:



ahm.. in which way, does the use of encryption, make a sourcelist for
dns names to ask, obsolete?

Names or servers?

"names of domainnameservers"


nscd i.e. uses resolv.conf as source for the round robin server list.

With encryption, the server address will always be 127.0.0.1 (or
potentially in the future, a UNIX domain socket) because pretty much all
the current DNS client software does not support encryption.  Running a
small local cache has other benefits as well, such as caching server
reachability information.


running a local DNS-Cache does not make so much sense as you may think.

besides the obvious reasons like short daytime usage with poweroff at
the end,
you will run into the same kind of problems, the windows local dnscache had:

It's even harder to debug customers problems, as more caches are involved.

Countless days i had to let users flush their local dns cache, to ensure
they don't connect to something outdated.

DNS is so vital to all services, that you want to have something easy to
maintain and debug, unlike NetworkManager,
which enslaves all users to the default dns names, that came via dhcp.
Last time i checked, it does not support
round robin to increase privacy. NSCD does, and if NM lets it, it's
working good. (had it running)

If someone wants to improve privacy, some rules apply:

a) you don't ask the same server for all your questions ( Round Robin
with thousands of dnscaches world wide)
b) you build a chain of trust ( DNSSEC )
c) the entire chain encrypts the traffic

It would be ok, to have a local resolver handle this for all apps and it
mimics an unencrypted ns on 127.0.0.1:53 .

But the main problem with a+b+c is, it takes a sh*tload of overhead to a
real simple thing AND as with browsers,
has absolutely no value, because the browser will tell anyone between
himself and the target, what he is connecting to.
(see other posting).

Most people won't even gain privacy protection out of it, as outbound
dns is blocked except for the ISPs dns,
the cable/dsl box they use will just send them two dns servers, not
thousands to choose from and
in the end, the browser will give them away anyway.

 From my POV, which supports the DoT as it's a good idea, "why protecting
something, that the last device sabotages anyway?"

Ok, there are more than webpages, but most used services like mail pop
imap, open one connection to a known targetport,
not hard to guess what it is and where it is.  BTW, those clients do 1
dns resolve per day, they won't profit from a local cache ;)

And even if the browser would not give the dn away in SNI or Host: , it
does not make things better, as you can simply ask the internet, which
websites are hosted on a specific ip, and you get a long list of names.
Tracking a users connections makes it always possible to build profiles,
maybe not as precise as with dns data, but good enough.

My conclusion:

DoT and DoH, if not done via a browser, and not done via one single
server, are acceptable and a valid goal for a change inside Fedora,
but they won't help in privacy protection. What is needed to reach this
special goal, takes more than Fedora or Red Hat can provide.

I personally favor DoT as it would make use of the millions of dns
server available on the net. DoH is too centralized to implement for now.


best regards,
Marius


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



--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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-gpg-keys not updated yet again

[Petr Mensik]

More below.

On 8/20/19 6:40 PM, Kevin Fenzi wrote:
> On 8/20/19 7:37 AM, Petr Mensik wrote:
>> Hi!
>>
>> I could not find a safe way to upgrade also this time. I found update
>> F32 [1], but not corresponding F31 just adding new key. I am missing
>> update similar to [2], just for F31 that once was Rawhide. It should be
>> version 31-0.5
>>
>> I found and reopened one old bug [3]. I do not think this is just second
>> time.
> 
> Yes, it is that version, but there is not any compose that it exists in
> yet.
> 
>> On 8/19/19 11:32 PM, Kevin Fenzi wrote:
>>> So, a few things to note:
>>>
>>> * fedora-repos was updated for rawhide, however, unfortunately, It had
>>> two extra spaces on the first line... "  " which made gpg consider it
>>> invalid. This is likely the cause of any breakage with rawhide (mock,
>>> containers, copr, etc). This has been fixed in the newest fedora-repos
>>> package for f32/rawhide.
>>>
>>> * There is no f31 repo because we have not yet had a fedora 31 branched
>>> compose finish. So, mirrormanager is pointing people to rawhide. This is
>>> likely the cause of all problems related to f31.
>> I think this is a major point. I could not find update with
>> fedora-repos-31-0.5 signed. Instead, there is 32-0.1 served both by f31
>> updates and rawhide repo. I think there must be first updated GPG keys
>> N, which increases just minor version, not a major one. Major version
>> should be increased only after branching. Unless I am mistaken, rawhide
>> served me 32-0.1 signed by key contained inside. Okay, I had rawhide
>> repo enabled. But even
>> $ dnf --repo=updates --releasever=31 upgrade fedora-gpg-keys
>> did not offer different version. What was worse, both were signed by the
>> same F32 key.
> 
> yes, because both f31 and f32 are currently pointing to f32 (rawhide).
> 
> If we had a f31 compose you would not have hit this. You would update to
> the new f31 version and from there you could upgrade to f32 or stay on f31.
> 
> kevin
> 

I think f32 key should NOT be used until this is fully separated and
compose for older versions exist. Unless that key was leaked somehow,
there is no hurry, right? That hurry makes pain to many people without
justification for it,
I think.

There would always be mass rebuild in later stage of F32, no need to
switch key immediately. I think new key should not be enabled for
signing in new Rawhide until all supported versions have that key in
stable updates repo. That is not yet true now.

I am thinking, is there written guidance how to switch signing key on a
branch? Are we prepared for emergency in case that key was leaked?

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



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

Re: Getting .fc32 packages while trying to follow F31 branch ?

[Petr Mensik]

Hi Adrian,

I think this redirection is cause of breakage on rawhide machines. I
think we must be able to first serve separate repositories. Only then it
can proceed to increase of version in new rawhide.

My point is, n+1 has to be always signed by old key served in fedora and
updates repositories for that version. If next branching from rawhide
should be smooth:

1. new key has to exist in advance
2. n+1 has to keep old key that previous rawhide started with. No
package in fedora or updates or updates-testing repos should contain
package signed by n+2 key. n+2 key (and rawhide) can be used for signing
only after they are separate and n+1 repo is ready. Until that, only n+1
key must be used.

What are use cases when redirects are used? Would it make more sense to
redirect it opposite way, until rawhide is ready?

Hope it makes sense.

Regards,
Petr

On 8/19/19 10:13 PM, Adrian Reber wrote:
> On Mon, Aug 19, 2019 at 11:59:49AM -, Leigh Scott wrote:
>>> There is no f31 repo yet 
>>> https://dl.fedoraproject.org/pub/fedora/linux/development/ so
>>> perhaps mirror-manager is redirecting f31 to rawhide.
>>
>> It is mirror manager doing the redirection to rawhide.
>>
>> https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever=$basearch
> 
> For convenience there are repository redirects from n+1 to rawhide. I
> had to remove them manually and in a few hours mirrormanager should
> point to the correct repositories. If not, please open a ticket.
> 
>   Adrian
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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-gpg-keys not updated yet again

[Petr Mensik]

Hi!

I could not find a safe way to upgrade also this time. I found update
F32 [1], but not corresponding F31 just adding new key. I am missing
update similar to [2], just for F31 that once was Rawhide. It should be
version 31-0.5

I found and reopened one old bug [3]. I do not think this is just second
time.

On 8/19/19 11:32 PM, Kevin Fenzi wrote:
> So, a few things to note:
> 
> * fedora-repos was updated for rawhide, however, unfortunately, It had
> two extra spaces on the first line... "  " which made gpg consider it
> invalid. This is likely the cause of any breakage with rawhide (mock,
> containers, copr, etc). This has been fixed in the newest fedora-repos
> package for f32/rawhide.
> 
> * There is no f31 repo because we have not yet had a fedora 31 branched
> compose finish. So, mirrormanager is pointing people to rawhide. This is
> likely the cause of all problems related to f31.
I think this is a major point. I could not find update with
fedora-repos-31-0.5 signed. Instead, there is 32-0.1 served both by f31
updates and rawhide repo. I think there must be first updated GPG keys
N, which increases just minor version, not a major one. Major version
should be increased only after branching. Unless I am mistaken, rawhide
served me 32-0.1 signed by key contained inside. Okay, I had rawhide
repo enabled. But even
$ dnf --repo=updates --releasever=31 upgrade fedora-gpg-keys
did not offer different version. What was worse, both were signed by the
same F32 key.

> 
> * Finally, updates are queued for f29/30/31 to add the f32 key. This
> shouldn't really be that big a deal unless you are running one of those
> and want to update to rawhide, or is there other cases here?
> 
> I think the first 2 items are the ones causing problems, and the third
> is not so urgent as them. Sure, we can add it to the schedule and do it
> in advance, but the other things are the things to really avoid next time.
> 
> kevin
> 
> 
> 
> ___
> 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
> 

1. https://bodhi.fedoraproject.org/updates/FEDORA-2019-12c2cfd23a
2. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7ac161b9d7
3. https://bugzilla.redhat.com/show_bug.cgi?id=1489628

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



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

update-desktop-database in %post snippet

[Petr Mensik]

Hi!

Is it still valid request to add update-desktop-database into %post,
like mentioned by fedora-review tool [1]? Almost at the end of the
comment. I were not able to find any information about it in Package
Guidelines. Should that hint be removed from fedora-review or should be
documentation updated?

Are my eyes too tired to find correct place?

1. https://bugzilla.redhat.com/show_bug.cgi?id=1658153#c85

Regards,
Petr
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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

Re: libunbound SONAME bump

[Petr Mensik]

Unbound is rebuilt on master.

Please bump and rebuild dependent packages.

On 10/02/2018 02:15 PM, Petr Mensik wrote:
> Hi!
> 
> I am planning to push new unbound 1.8.0 into rawhide. It changes SONAME
> libunbound.so.2 to libunbound.so.8.
> 
> Dependent packages are:
> asterisk
> getdns
> gnutls-dane
> libreswan
> netresolve-backends-ubdns
> 
> I have prepared COPR repo with new build:
> https://copr.fedorainfracloud.org/coprs/pemensik/unbound/packages/
> 
> asterisk package is failing on rawhide, because it uses /usr/bin/python
> interpreter (bug #1633306). Other packages build fine with it.
> 
> It is already pushed into rawhide but not yet built. I would like to
> build new version on 8th October.
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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

libunbound SONAME bump

[Petr Mensik]

Hi!

I am planning to push new unbound 1.8.0 into rawhide. It changes SONAME
libunbound.so.2 to libunbound.so.8.

Dependent packages are:
asterisk
getdns
gnutls-dane
libreswan
netresolve-backends-ubdns

I have prepared COPR repo with new build:
https://copr.fedorainfracloud.org/coprs/pemensik/unbound/packages/

asterisk package is failing on rawhide, because it uses /usr/bin/python
interpreter (bug #1633306). Other packages build fine with it.

It is already pushed into rawhide but not yet built. I would like to
build new version on 8th October.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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

Re: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> libldns.so.2)

[Petr Mensik]

Hi,

that update was made by me. I am really sorry I completely missed soname
change when preparing that update. What I wanted to fix was that ldns 
package did not build with OpenSSL 1.1. That would require a change
in opendnssec as well. But would not create conflict that would prevent
installing dependent packages.

I know it was really late for such change. I missed also the fact that
opendnssec is required by FreeIPA, so my changes are not as isolated 
as I thought they are.

I promise I will make no such changes in wrong time again.
I will avoid changes that affects other packages, unless I have received
confirmation from their maintainers.

Again, I am sorry for trouble I made.

Petr Menšík

- Original Message -
From: "Adam Williamson" 
To: "Development discussions related to Fedora" 
Cc: tkri...@redhat.com, pemen...@redhat.com
Sent: Friday, March 10, 2017 12:10:19 AM
Subject: Unannounced soname bump (Rawhide and 26): ldns (libldns.so.1 -> 
libldns.so.2)

ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on
2017-03-06. This update bumped the soname from libldns.so.1 to
libldns.so.2 . This soname bump was not announced, as it is supposed to
be, and dependent packages were not rebuilt.

opendnssec depends on libldns and freeipa-server-dns requires
opendnssec, so this resulted in FreeIPA server deployment - which is a
core Fedora Server feature, and in the Alpha release requirements -
breaking on both 26 and Rawhide.

We will now need to go through the blocker process to have the
opendnssec rebuild pulled into Fedora 26 composes, as this unannounced
soname bump landed right before the Alpha freeze.

Other packages that depend on libldns appear to be dnssec-trigger and
netresolve. dnssec-trigger has been rebuilt (but will need to go
through the blocker or FE process to make it into 26 Alpha), netresolve
has not, yet. I will try to rebuild netresolve.

Once again, folks, *please* announce your soname bumps, and co-ordinate 
rebuilds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Packagers - Flag day 2016 Important changes

[Petr Mensik]

That sounds like way to use (sort of) certificates again. With updated realmd 
package I can now save fedora account password into Gnome keyring. But...

I thought about it yesterday, but did not dare to ask. Are not password less 
strong kind of authentication that keys? We have SSH keys, we had generated 
certificates until now. Now only passwords backed by Kerberos. Sure, Kerberos 
is not simple password system sending plaintext over network. Anyway, is there 
planned way to obtain main kerberos ticket for fedoraproject.org by something 
stronger than password?

--
Petr Menšík

- Original Message -
From: "Petr Spacek" 
To: devel@lists.fedoraproject.org
Sent: Wednesday, December 14, 2016 8:34:17 AM
Subject: Re: Packagers - Flag day 2016 Important changes

On 13.12.2016 22:57, Tom Hughes wrote:
> On 13/12/16 21:32, Simo Sorce wrote:
>> On Tue, 2016-12-13 at 18:52 +, Tom Hughes wrote:
>>
>>> The main goal of long random passwords after all is about a combination
>>> of making them hard to brute force and ensuring that every service has a
>>> unique password to guard against credential reuse attacks when one of
>>> the many services everybody has logins for experiences the inevitable
>>> loss of their poorly secured database.
>>>
>>> I always find it somewhat depressing that the more sophisticated a login
>>> system becomes the worse my security on it seems to get because I wind
>>> up having to use weaker passwords. Banks are the classic example because
>>> they rarely have a straightforward password even as one part of their
>>> authentication but anything that means I have to remember a password
>>> hits the same problem.
>>
>> Don't remember it if it bothers you, why do you use a double standard if
>> the password is not sent via browser but through a CLI ?
> 
> It's an interesting question, and the first thing I'd say is that there are
> actually very few passwords that I enter at a CLI at all. Once I've unlocked
> gnome keyring by logging into my laptop or desktop it's mostly only when I
> want to sudo as other things tend to be by ssh public key auth from my 
> keyring.
> 
> I think the threat model is very different as well, at least for me, as the
> environments where I am entering a password for sudo for example are all ones
> which I control and where I know how the password database is stored while for
> web based logins I operate on the basis that I have no idea whether any given
> site has the sense to hash it's passwords or to adequately protect it's user
> database.
> 
> Obviously I'm sure the FAS database is properly protected but the ways of
> working I have developed are based around not assuming that for web logins
> hence why I switched to random passwords and a password manager many years 
> ago.
> 
> Anyway, it looks like like GOA with the realmd fix likely does what I want,
> which is good news.

Theoretically, if you really really want random password and never type it,
you can retrieve keytab for your account. The keytab file can contain e.g.
random 256 bit AES key so you will as safe as you can, assuming no attacker
can gain access to that file (which you assume already).

In Kerberized world this is usually done for machine/service accounts but
technically nothing prevents you from using the same method for your own 
account.

See man page for command ipa-getkeytab from package freeipa-client (or use
command kpasswd).

-- 
Petr Spacek  @  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: Packagers - Flag day 2016 Important changes

[Petr Mensik]

Sure, I am really missing this information written on the wiki page. The secret 
is, they are in the DNS record. If you try 
$ host -t URI _kerberos.fedoraproject.org

you might get it. But some DNS servers seem to have trouble with this record. 
As Red Hat defaults have dns_lookup_realm = false, we need manual 
configuration. I think there are more people like us. I think this should be 
mentioned on https://fedoraproject.org/wiki/Infrastructure/Kerberos:

[realms]
 FEDORAPROJECT.ORG = {
   kdc = https://id.fedoraproject.org/KdcProxy
 }
[domain_realm]
 fedoraproject.org = FEDORAPROJECT.ORG
 .fedoraproject.org = FEDORAPROJECT.ORG


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


- Original Message -
From: "Dave Love" 
To: devel@lists.fedoraproject.org
Sent: Monday, December 12, 2016 5:36:24 PM
Subject: Re: Packagers - Flag day 2016 Important changes

Dennis Gilmore  writes:

> See the general kerberos information at: 
> https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication
> for more details.

I was going to try to authenticate, even if the tools won't work, but
that's missing the fundamental information about how to configure the
realm for clients.  What are the kdc(s) and admin_server (if
admin_server is relevant)?
___
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