Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Mon, 28 Nov 2016 11:51:36 -0500
Nathaniel McCallum  wrote:

> On Mon, Nov 28, 2016 at 3:10 AM, Alexander Bokovoy
>  wrote:
> > On su, 27 marras 2016, Ken Dreyer wrote:  
> >>
> >> On Wed, Nov 23, 2016 at 7:17 AM, Alexander Bokovoy
> >>  wrote:  
> >>>
> >>> Heimdal does not support MS-KKDCP spec, so you are left with
> >>> direct Kerberos communication over port 88/tcp or 88/udp, but
> >>> these are enabled in Fedora infrastructure, yes.  
> >>
> >>
> >> I thought direct Kerberos service was going to be disabled, to
> >> prevent attackers sniffing and brute-forcing the encrypted preauth
> >> timestamp?  
> >
> > This is really a question to Fedora Infra people but last time we
> > discussed, RHEL 6-based clients and alike were not getting MS-KKDCP
> > features backported to older MIT Kerberos versions so to support
> > them, direct access is required.  
> 
> Correct. The Fedora Infrastructure team needs to balance the risk of
> MitM offline dictionary attacks with the need for RHEL6 client access.
> 
> IMHO, there should already be a plan to sunset RHEL6 instances. But I
> can't judge this based upon Fedora's internal needs.

Right, RHEL6 is still a supported client for us, so we are currently
providing access so they can work. 

As soon as something happens to let us drop that direct access we
likely will do so. ;) 

kevin


pgpL1XZbL22jS.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Nathaniel McCallum]

On Mon, Nov 28, 2016 at 3:10 AM, Alexander Bokovoy  wrote:
> On su, 27 marras 2016, Ken Dreyer wrote:
>>
>> On Wed, Nov 23, 2016 at 7:17 AM, Alexander Bokovoy 
>> wrote:
>>>
>>> Heimdal does not support MS-KKDCP spec, so you are left with direct
>>> Kerberos communication over port 88/tcp or 88/udp, but these are enabled
>>> in Fedora infrastructure, yes.
>>
>>
>> I thought direct Kerberos service was going to be disabled, to prevent
>> attackers sniffing and brute-forcing the encrypted preauth timestamp?
>
> This is really a question to Fedora Infra people but last time we
> discussed, RHEL 6-based clients and alike were not getting MS-KKDCP
> features backported to older MIT Kerberos versions so to support them,
> direct access is required.

Correct. The Fedora Infrastructure team needs to balance the risk of
MitM offline dictionary attacks with the need for RHEL6 client access.

IMHO, there should already be a plan to sunset RHEL6 instances. But I
can't judge this based upon Fedora's internal needs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Nathaniel McCallum]

On Mon, Nov 21, 2016 at 10:03 AM, Alexander Bokovoy  wrote:
> On ma, 21 marras 2016, Florian Weimer wrote:
>>
>> On 11/21/2016 01:31 PM, Stephen Gallagher wrote:
>>
>> Thanks for your explanation.
>>
>>> So yes, we have protection against that. FreeIPA (which is backing this
>>> solution) requires preauthentication for all user accounts.
>>
>>
>> “That” meaning offline attacks without intercepted packets.  With
>> intercepted packets, offline attacks are still feasible, right?
>
> Right -- if you get initial exchange in the traditional Kerberos 5.
> We have been working for several years already to reduce these
> possibilities via different means:
> - enablement for HTTPS-based tunnel for Kerberos flows based on
>   MS-KKDCP specification;
>
> - DNS-based announcement of Kerberos MS-KKDCP proxy using DNS URI;
>
> - SPAKE exchange support in MIT Kerberos (slated for 1.15-1.16)
>
> Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
> tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
> automatically with the help of DNS URI. For older clients which don't
> support DNS-based discovery you can configure MS-KKDCP proxy access
> manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
> FEDORAPROJECT.ORG realm. For very old clients that don't support
> MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
> traffic.
>
> Our effort is to get to SPAKE sooner than later.

I'll be working with Robbie Harwood to implement SPAKE in the coming
months. So let me add some clarification here.

1. Like Stephen said, preauth now prevents offline dictionary attack
without interception. This has been true for years.

2. Offline dictionary attack is theoretically possible with MitM
(though is somewhat mitigated by the added timestamp entropy). This
can be further mitigated by using the HTTPS proxy as stated by
Alexander. I am not aware of any successful attacks using this method.

3. SPAKE is a new technique to make this whole problem irrelevant (as
well as provide an implicitly trusted tunnel for 2FA without
additional trust anchors). The draft is available here:
https://tools.ietf.org/html/draft-mccallum-kitten-krb-spake-preauth-00.
A new draft is forthcoming shortly. SPAKE works like a normal
Password-Authenticated Key Exchange, and thus is entirely protected
from offline attacks the same way Diffie-Hellman is. There is already
a 1FA implementation in an upstream branch which we are going to
expand to support 2FA and then merge. The server-side will only land
in newer Fedoras. However, should need arise, we might be able to
backport the client-side as a plugin.  I'm hoping to land this in F26.

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

Re: upcoming build and release developer flag day December 12 2016

[Alexander Bokovoy]

On su, 27 marras 2016, Ken Dreyer wrote:

On Wed, Nov 23, 2016 at 7:17 AM, Alexander Bokovoy  wrote:

Heimdal does not support MS-KKDCP spec, so you are left with direct
Kerberos communication over port 88/tcp or 88/udp, but these are enabled
in Fedora infrastructure, yes.


I thought direct Kerberos service was going to be disabled, to prevent
attackers sniffing and brute-forcing the encrypted preauth timestamp?

This is really a question to Fedora Infra people but last time we
discussed, RHEL 6-based clients and alike were not getting MS-KKDCP
features backported to older MIT Kerberos versions so to support them,
direct access is required.


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

Re: upcoming build and release developer flag day December 12 2016

[Ken Dreyer]

On Wed, Nov 23, 2016 at 7:17 AM, Alexander Bokovoy  wrote:
> Heimdal does not support MS-KKDCP spec, so you are left with direct
> Kerberos communication over port 88/tcp or 88/udp, but these are enabled
> in Fedora infrastructure, yes.

I thought direct Kerberos service was going to be disabled, to prevent
attackers sniffing and brute-forcing the encrypted preauth timestamp?

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

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Fri, 25 Nov 2016 03:19:49 +0100
Kevin Kofler  wrote:

> Peter Robinson wrote:
> > Well the koji web interface itself doesn't use authentication
> > anymore, from a fedpkg PoV there's a lot of complexity with http(s)
> > because it could be proxied or NATed (worst is CG-NAT) so the same
> > connection from the same laptop might not even come via the same
> > IP. Basically what you're describing is exactly what kerberos
> > solves, tokens to authenticate various different connections.  
> 
> My point is, just use SSH instead of HTTP(S) as the transport. You
> could even tunnel HTTP over an SSH tunnel after you let SSH
> authenticate the other end, if you really need an HTTP API. (Not much
> point in using HTTPS over the already encrypted SSH.)

Do you know of any applications at all that use this?

Is there any python code available to setup such authentication? 

Kerberos is used all over the place by lots and lots of groups and has
had many years of auditing and actually you know, exists. 

> > A lot of companies and data security standards explicitly disallow
> > ssh keys because of the fact it's client side pass phrases with no
> > way to enforce a policy so there's no way to tell even if the key
> > has a passphrase.  
> 
> And that is what I like about SSH. :-) I decide the level of security
> I actually need for my key, not somebody else.

Which is fine up until the point someone compromises your machines and
uses your access to mess up everyone else. 
 
> And we already trust SSH authentication for access to dist-git, so I
> don't see why it would not be good enough for Koji as well.

Because it would require a bunch of coding and then we would be a
special little snowflake. 

> > Personally I'd like to see eventually the move to kerberos to
> > replace ssh- keys as it's easier to enforce a minimum policy and
> > manage.  
> 
> Kinit just takes a password, automating it to pick the password from
> any password store or even a plaintext file and then run
> automatically on startup and automatically renew expired tickets is
> not that hard. It will just be a minor annoyance until one of us
> writes the automation tool, and do nothing to enforce any kind of
> policy on us.

No need to invent all this again, you can just use a keytab. 

> The infrastructure really needs to work for us, not against us.

I'm happy to work with anyone to improve things. That said, we don't
have a bunch of developers sitting around waiting to implement people's
ideas, so sometimes we have to say "sorry, no" or "sorry, we can't do
that now, but happy to look at it again later".

I think kerberos is a very good improvement over the current setup.
I hope (most)everyone else does too. 

kevin


pgpa7Ms69n76c.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Kevin Kofler]

Peter Robinson wrote:
> Well the koji web interface itself doesn't use authentication anymore,
> from a fedpkg PoV there's a lot of complexity with http(s) because it
> could be proxied or NATed (worst is CG-NAT) so the same connection
> from the same laptop might not even come via the same IP. Basically
> what you're describing is exactly what kerberos solves, tokens to
> authenticate various different connections.

My point is, just use SSH instead of HTTP(S) as the transport. You could 
even tunnel HTTP over an SSH tunnel after you let SSH authenticate the other 
end, if you really need an HTTP API. (Not much point in using HTTPS over the 
already encrypted SSH.)

> A lot of companies and data security standards explicitly disallow ssh
> keys because of the fact it's client side pass phrases with no way to
> enforce a policy so there's no way to tell even if the key has a
> passphrase.

And that is what I like about SSH. :-) I decide the level of security I 
actually need for my key, not somebody else.

And we already trust SSH authentication for access to dist-git, so I don't 
see why it would not be good enough for Koji as well.

> Personally I'd like to see eventually the move to kerberos to replace ssh-
> keys as it's easier to enforce a minimum policy and manage.

Kinit just takes a password, automating it to pick the password from any 
password store or even a plaintext file and then run automatically on 
startup and automatically renew expired tickets is not that hard. It will 
just be a minor annoyance until one of us writes the automation tool, and do 
nothing to enforce any kind of policy on us.

The infrastructure really needs to work for us, not against us.


As for the other reply:

Stephen John Smoogen wrote:
> Off-list:

Not quite. :-)

> [snip]
> Does that make sense?

No. See my reply to Peter Robinson above.

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

Re: upcoming build and release developer flag day December 12 2016

[Alexander Bokovoy]

On ke, 23 marras 2016, Dave Love wrote:

Is this going to work for those of us who use RHEL, not Fedora (and are
only actually interested in EPEL)?  Also, will it work with Heimdal
clients?  (The Fedora packager stuff is rather hit and miss under EPEL
at the best of times.)

EPEL builds are coming, according to Patrick.

Heimdal does not support MS-KKDCP spec, so you are left with direct
Kerberos communication over port 88/tcp or 88/udp, but these are enabled
in Fedora infrastructure, yes.

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

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Wed, 23 Nov 2016 11:44:14 +
Dave Love  wrote:

> Is this going to work for those of us who use RHEL, not Fedora (and
> are only actually interested in EPEL)?  

Yes, it should. 

> Also, will it work with
> Heimdal clients?  (The Fedora packager stuff is rather hit and miss
> under EPEL at the best of times.)

Yes it should. 

If you hit bugs please do file them. The intent is that things work for
all still supported RHEL releases as well as Fedora. 

kevin


pgpQsvzA66CrC.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Patrick マルタインアンドレアス Uiterwijk]

> On 11/21/2016 03:51 PM, Patrick  マルタインアンドレアス  Uiterwijk wrote:
> 
> 
> Exactly like that, yes. It isn't present (yet?) on Fedora 25, though I see now
> it's been added to Rawhide.

Right, I dropped the ball there for a bit while testing.
However, I'm building for epel6,epel7,f23,f24,f25 today, so this should go out 
soon.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Dave Love]

Is this going to work for those of us who use RHEL, not Fedora (and are
only actually interested in EPEL)?  Also, will it work with Heimdal
clients?  (The Fedora packager stuff is rather hit and miss under EPEL
at the best of times.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Patrick マルタインアンドレアス Uiterwijk]

> On 11/21/2016 08:07 AM, Vít Ondruch wrote:
> 
> 
> So, it turns out that this doesn't work yet. It's complicated, but there's a
> patch pending for Koji that will make this work. It hasn't landed yet. 
> Hopefully
> that will change before the flag day.

And I'm thrilled to say that my patch to get GSSAPI support into Koji has been 
merged a few hours ago!
Once the Fedora package has been updated (which I hope happens sometime very 
soon), it should all work
magically out of the box. The server side is already live on our staging 
instance, and will go live on production
in the next few days:

[puiterwijk@localhost puiterwijk]$ stg-koji hello
jó napot, puiterwijk!

You are using the hub at https://koji.stg.fedoraproject.org/kojihub
Authenticated via GSSAPI
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Tue, 22 Nov 2016 11:40:12 +0100
Igor Gnatenko  wrote:

> On Nov 22, 2016 10:42 AM, "Vít Ondruch"  wrote:
> >...snip...

> > Hm, I would need to downgrade more packages apparently  I'll
> > wait and hopefully it'll get fixed soon   
> Not really, you hit that bug in dnf about installing local packages.
> Workaround is to create local repo and downgrade from there.

Or just use rpm. 

download the older openssl rpms and: 
sudo rpm -Uvh --oldpackage openssl*.rpm

kevin


pgpgG3dPj1Ldl.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Stephen John Smoogen]

I am unable to use email correctly today. I apologize for the extra email.

On 22 November 2016 at 10:14, Stephen John Smoogen  wrote:
> Off-list:
>
> On 22 November 2016 at 01:12, Kevin Kofler  wrote:
>> Dennis Gilmore wrote:
>>> koji authentication will be switching to Kerberos. Koji supports multiple
>>> authentication mechanisms. Fedora infrastructure has set up a freeipa
>>> instance internally that has credential syncing to fas. We are working on
>>> ensuring that gssapi caching is supported so that you can have multiple
>>> TGT's and the ability to work in multiple reams at once. you can get
>>> started today by doing kinit @FEDORAPROJECT.ORG if you move
>>> your ~/.fedora.cert file out of the way authentication will still work.
>>
>> Maybe a crazy idea, but couldn't Koji just use our SSH keys for
>> authenticating somehow? Those just work without any extra setup, they never
>> expire, and unlocking passphrase-protected keys is also an already solved
>> problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that
>> would have to happen is to tunnel the Koji CLI's communication through SSH
>> to koji.fedoraproject.org or to some trusted tunnel server that you can
>> delegate authentication to.
>
> It would be a good idea if we could enforce that the keys were private
> and well kept. However I have had to clean up unencrypted private keys
> from developers so many times on people01 and other servers that I
> would worry that someone making a mistake could cause a problem for
> everyone. [And while I could turn off people's access if I found them
> on people, how do I protect them when they copy them to the university
> server I don't have access to?]
>
> The amount of damage someone getting hold of a key could be large and
> the amount of time to detect it would also be long as there aren't any
> tools to do so. When problems do happen it also brings all sorts of
> social witch hunts (from dealing with this in the past with a project
> set up like that). People think oh its because joe fucked up, but it
> usually turns out that bob fucked up, and the attacker used social
> engineering as bob to become joe. [They then do so again after bob is
> kicked out if the investigation isn't thorough because people want
> action fast.]
>
> In this case if the keys get broken, it is on one group (us in
> infrastructure) who fucked up. We get kicked to the curb and some
> other group can take it over and try again.
>
> That said, having keys like ssh or gpg could work but i believe it
> would take a massive ground up engineering of other processes. [EG if
> we use ssh keys and it turns out there is a fundamental crypto flaw
> that shows up because they aren't engineered for this sort of process
> but it doesn't show up when they are used as ssh keys. ] Does that
> make sense?
>
>
> --
> Stephen J Smoogen.



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

Re: upcoming build and release developer flag day December 12 2016

[Stephen John Smoogen]

Off-list:

On 22 November 2016 at 01:12, Kevin Kofler  wrote:
> Dennis Gilmore wrote:
>> koji authentication will be switching to Kerberos. Koji supports multiple
>> authentication mechanisms. Fedora infrastructure has set up a freeipa
>> instance internally that has credential syncing to fas. We are working on
>> ensuring that gssapi caching is supported so that you can have multiple
>> TGT's and the ability to work in multiple reams at once. you can get
>> started today by doing kinit @FEDORAPROJECT.ORG if you move
>> your ~/.fedora.cert file out of the way authentication will still work.
>
> Maybe a crazy idea, but couldn't Koji just use our SSH keys for
> authenticating somehow? Those just work without any extra setup, they never
> expire, and unlocking passphrase-protected keys is also an already solved
> problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that
> would have to happen is to tunnel the Koji CLI's communication through SSH
> to koji.fedoraproject.org or to some trusted tunnel server that you can
> delegate authentication to.

It would be a good idea if we could enforce that the keys were private
and well kept. However I have had to clean up unencrypted private keys
from developers so many times on people01 and other servers that I
would worry that someone making a mistake could cause a problem for
everyone. [And while I could turn off people's access if I found them
on people, how do I protect them when they copy them to the university
server I don't have access to?]

The amount of damage someone getting hold of a key could be large and
the amount of time to detect it would also be long as there aren't any
tools to do so. When problems do happen it also brings all sorts of
social witch hunts (from dealing with this in the past with a project
set up like that). People think oh its because joe fucked up, but it
usually turns out that bob fucked up, and the attacker used social
engineering as bob to become joe. [They then do so again after bob is
kicked out if the investigation isn't thorough because people want
action fast.]

In this case if the keys get broken, it is on one group (us in
infrastructure) who fucked up. We get kicked to the curb and some
other group can take it over and try again.

That said, having keys like ssh or gpg could work but i believe it
would take a massive ground up engineering of other processes. [EG if
we use ssh keys and it turns out there is a fundamental crypto flaw
that shows up because they aren't engineered for this sort of process
but it doesn't show up when they are used as ssh keys. ] Does that
make sense?


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

Re: upcoming build and release developer flag day December 12 2016

[Igor Gnatenko]

On Nov 22, 2016 10:42 AM, "Vít Ondruch"  wrote:
>
>
>
> Dne 21.11.2016 v 21:52 Patrick マルタインアンドレアス Uiterwijk napsal(a):
> >> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
> >>
> >>
> >> $ KRB5_TRACE=/dev/stderr kinit vondruch(a)FEDORAPROJECT.ORG
> >> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
> >> [8655] 1479746886.252281: Getting initial credentials for
> >> vondruch(a)FEDORAPROJECT.ORG
> >> [8655] 1479746886.252439: Sending request (205 bytes) to
FEDORAPROJECT.ORG
> >> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
> >> [8655] 1479746886.380979: Terminating TCP connection to https
> >> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
> >> [8655] 1479746886.383242: Terminating TCP connection to https
> >> 2610:28:3090:3001:dead:beef:cafe:fed3:443
> >> [8655] 1479746886.754122: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746886.926836: Sending HTTPS request to https
140.211.169.206:443
> >> [8655] 1479746887.331375: HTTPS error receiving from https
> >> 140.211.169.206:443
> >> [8655] 1479746887.333212: Terminating TCP connection to https
> >> 140.211.169.206:443
> >> [8655] 1479746887.594719: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746887.710694: Sending HTTPS request to https
67.219.144.68:443
> >> [8655] 1479746888.330867: HTTPS error receiving from https
67.219.144.68:443
> >> [8655] 1479746888.331797: Terminating TCP connection to https
> >> 67.219.144.68:443
> >> [8655] 1479746888.694098: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746888.862462: Sending HTTPS request to https
67.203.2.67:443
> >> [8655] 1479746889.122858: HTTPS error receiving from https
67.203.2.67:443
> >> [8655] 1479746889.123787: Terminating TCP connection to https
> >> 67.203.2.67:443
> >> [8655] 1479746889.527941: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746889.722994: Sending HTTPS request to https
209.132.181.16:443
> >> [8655] 1479746889.964857: HTTPS error receiving from https
> >> 209.132.181.16:443
> >> [8655] 1479746889.965718: Terminating TCP connection to https
> >> 209.132.181.16:443
> >> [8655] 1479746890.363509: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746890.552022: Sending HTTPS request to https
209.132.181.15:443
> >> [8655] 1479746890.787479: HTTPS error receiving from https
> >> 209.132.181.15:443
> >> [8655] 1479746890.788339: Terminating TCP connection to https
> >> 209.132.181.15:443
> >> [8655] 1479746891.68629: TLS certificate name matched "
id.fedoraproject.org"
> >> [8655] 1479746891.201442: Sending HTTPS request to https
152.19.134.198:443
> >> [8655] 1479746891.711140: HTTPS error receiving from https
> >> 152.19.134.198:443
> >> [8655] 1479746891.711960: Terminating TCP connection to https
> >> 152.19.134.198:443
> >> [8655] 1479746892.55922: TLS certificate name matched "
id.fedoraproject.org"
> >> [8655] 1479746892.214348: Sending HTTPS request to https
66.35.62.162:443
> >> [8655] 1479746892.563662: HTTPS error receiving from https
66.35.62.162:443
> >> [8655] 1479746892.564576: Terminating TCP connection to https
> >> 66.35.62.162:443
> >> [8655] 1479746892.945989: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746893.119732: Sending HTTPS request to https
140.211.169.196:443
> >> [8655] 1479746893.512855: HTTPS error receiving from https
> >> 140.211.169.196:443
> >> [8655] 1479746893.513684: Terminating TCP connection to https
> >> 140.211.169.196:443
> >> [8655] 1479746893.812319: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746893.944132: Sending HTTPS request to https
152.19.134.142:443
> >> [8655] 1479746894.412080: HTTPS error receiving from https
> >> 152.19.134.142:443
> >> [8655] 1479746894.412908: Terminating TCP connection to https
> >> 152.19.134.142:443
> >> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> >> getting initial credentials
> > Downgrade to openssl-1.1.0b:
https://github.com/openssl/openssl/issues/1919
>
> Hm, I would need to downgrade more packages apparently  I'll wait
> and hopefully it'll get fixed soon 
Not really, you hit that bug in dnf about installing local packages.
Workaround is to create local repo and downgrade from there.
>
>
> Vít
> ___
> 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: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 21.11.2016 v 21:52 Patrick マルタインアンドレアス Uiterwijk napsal(a):
>> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
>>
>>
>> $ KRB5_TRACE=/dev/stderr kinit vondruch(a)FEDORAPROJECT.ORG
>> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
>> [8655] 1479746886.252281: Getting initial credentials for
>> vondruch(a)FEDORAPROJECT.ORG
>> [8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG
>> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
>> [8655] 1479746886.380979: Terminating TCP connection to https
>> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
>> [8655] 1479746886.383242: Terminating TCP connection to https
>> 2610:28:3090:3001:dead:beef:cafe:fed3:443
>> [8655] 1479746886.754122: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443
>> [8655] 1479746887.331375: HTTPS error receiving from https
>> 140.211.169.206:443
>> [8655] 1479746887.333212: Terminating TCP connection to https
>> 140.211.169.206:443
>> [8655] 1479746887.594719: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443
>> [8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443
>> [8655] 1479746888.331797: Terminating TCP connection to https
>> 67.219.144.68:443
>> [8655] 1479746888.694098: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443
>> [8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443
>> [8655] 1479746889.123787: Terminating TCP connection to https
>> 67.203.2.67:443
>> [8655] 1479746889.527941: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443
>> [8655] 1479746889.964857: HTTPS error receiving from https
>> 209.132.181.16:443
>> [8655] 1479746889.965718: Terminating TCP connection to https
>> 209.132.181.16:443
>> [8655] 1479746890.363509: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443
>> [8655] 1479746890.787479: HTTPS error receiving from https
>> 209.132.181.15:443
>> [8655] 1479746890.788339: Terminating TCP connection to https
>> 209.132.181.15:443
>> [8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org"
>> [8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443
>> [8655] 1479746891.711140: HTTPS error receiving from https
>> 152.19.134.198:443
>> [8655] 1479746891.711960: Terminating TCP connection to https
>> 152.19.134.198:443
>> [8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org"
>> [8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443
>> [8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443
>> [8655] 1479746892.564576: Terminating TCP connection to https
>> 66.35.62.162:443
>> [8655] 1479746892.945989: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443
>> [8655] 1479746893.512855: HTTPS error receiving from https
>> 140.211.169.196:443
>> [8655] 1479746893.513684: Terminating TCP connection to https
>> 140.211.169.196:443
>> [8655] 1479746893.812319: TLS certificate name matched
>> "id.fedoraproject.org"
>> [8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443
>> [8655] 1479746894.412080: HTTPS error receiving from https
>> 152.19.134.142:443
>> [8655] 1479746894.412908: Terminating TCP connection to https
>> 152.19.134.142:443
>> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
>> getting initial credentials
> Downgrade to openssl-1.1.0b: https://github.com/openssl/openssl/issues/1919

Hm, I would need to downgrade more packages apparently  I'll wait
and hopefully it'll get fixed soon 


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

Re: upcoming build and release developer flag day December 12 2016

[Peter Robinson]

On Tue, Nov 22, 2016 at 6:12 AM, Kevin Kofler  wrote:
> Dennis Gilmore wrote:
>> koji authentication will be switching to Kerberos. Koji supports multiple
>> authentication mechanisms. Fedora infrastructure has set up a freeipa
>> instance internally that has credential syncing to fas. We are working on
>> ensuring that gssapi caching is supported so that you can have multiple
>> TGT's and the ability to work in multiple reams at once. you can get
>> started today by doing kinit @FEDORAPROJECT.ORG if you move
>> your ~/.fedora.cert file out of the way authentication will still work.
>
> Maybe a crazy idea, but couldn't Koji just use our SSH keys for
> authenticating somehow? Those just work without any extra setup, they never
> expire, and unlocking passphrase-protected keys is also an already solved
> problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that
> would have to happen is to tunnel the Koji CLI's communication through SSH
> to koji.fedoraproject.org or to some trusted tunnel server that you can
> delegate authentication to.

Well the koji web interface itself doesn't use authentication anymore,
from a fedpkg PoV there's a lot of complexity with http(s) because it
could be proxied or NATed (worst is CG-NAT) so the same connection
from the same laptop might not even come via the same IP. Basically
what you're describing is exactly what kerberos solves, tokens to
authenticate various different connections.

A lot of companies and data security standards explicitly disallow ssh
keys because of the fact it's client side pass phrases with no way to
enforce a policy so there's no way to tell even if the key has a
passphrase. Personally I'd like to see eventually the move to kerberos
to replace ssh-keys as it's easier to enforce a minimum policy and
manage.

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

Re: upcoming build and release developer flag day December 12 2016

[Jakub Hrozek]

On Mon, Nov 21, 2016 at 07:46:13AM -0500, Stephen Gallagher wrote:
> On 11/21/2016 04:32 AM, Vít Ondruch wrote:
> > 
> > 
> > Dne 20.11.2016 v 02:11 Dennis Gilmore napsal(a):
> >> koji authentication will be switching to Kerberos. Koji supports multiple 
> >> authentication mechanisms. Fedora infrastructure has set up a freeipa 
> >> instance 
> >> internally that has credential syncing to fas. We are working on ensuring 
> >> that 
> >> gssapi caching is supported so that you can have multiple TGT's and the 
> >> ability to work in multiple reams at once.
> 
> 
> See my other email. I think the issue is that we are missing a krb5.conf.d
> snippet to ensure that the FEDORAPROJECT.ORG TGT is used regardless of 
> whichever
> ticket happens to be the current default.
> 
> > 
> > BTW it would be nice, if it works with SSSD somehow and I don't need to
> > use kinit at all.
> > 
> > 
> 
> That is being worked on. I've asked Jakub Hrozek to come talk about the 
> upcoming
> SSSD KCM work (targeted for F26).
> 

If you acquire the ticket through SSSD (so, log in through PAM with your
Fedora password with SSSD configured with auth_provider=krb5) then SSSD
should already be able to renew tickets for you. I haven't tested this
myself yet, though, but I will.

We're also working on a deamon to manage ccaches as described here:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
this would allow even ccaches acquired through kinit to be renewed and
hopefully solve some challenged we've seen with KEYRING ccache.

I've posted a design page for review to sssd-devel, I'll post a link
here, too, as soon as the design is reviewed by other SSSD developers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Kevin Kofler]

Dennis Gilmore wrote:
> koji authentication will be switching to Kerberos. Koji supports multiple
> authentication mechanisms. Fedora infrastructure has set up a freeipa
> instance internally that has credential syncing to fas. We are working on
> ensuring that gssapi caching is supported so that you can have multiple
> TGT's and the ability to work in multiple reams at once. you can get
> started today by doing kinit @FEDORAPROJECT.ORG if you move
> your ~/.fedora.cert file out of the way authentication will still work.

Maybe a crazy idea, but couldn't Koji just use our SSH keys for 
authenticating somehow? Those just work without any extra setup, they never 
expire, and unlocking passphrase-protected keys is also an already solved 
problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that 
would have to happen is to tunnel the Koji CLI's communication through SSH 
to koji.fedoraproject.org or to some trusted tunnel server that you can 
delegate authentication to.

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

Re: upcoming build and release developer flag day December 12 2016

[Alexander Bokovoy]

On ma, 21 marras 2016, Florian Weimer wrote:

On 11/21/2016 04:03 PM, Alexander Bokovoy wrote:


Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
automatically with the help of DNS URI. For older clients which don't
support DNS-based discovery you can configure MS-KKDCP proxy access
manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
FEDORAPROJECT.ORG realm. For very old clients that don't support
MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
traffic.


Shouldn't everyone configure things this way to prevent downgrade 
attacks (which could happen even accidentally due to timeouts and 
things)?

Done in rawhide already -- see fedora-packager package and the reference
Patrick provided in another response.

For Fedora versions before MIT Kerberos 1.13 we cannot do anything. 1.13
was part of Fedora 22, though, so for last two years we have a solution
to the problem.
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 03:51 PM, Patrick  マルタインアンドレアス  Uiterwijk wrote:
>> On 11/21/2016 10:32 AM, Florian Weimer wrote:
>>
>> Yes, as I mentioned elsewhere, we should probably have the fedora-packager 
>> RPM
>> ship with a krb5.conf.d snippet that sets the appropriate values.
> 
> You mean something like 
> http://pkgs.fedoraproject.org/cgit/rpms/fedora-packager.git/commit/?id=b3ab149d144a644f41705e4ec7b5e36a25892e95
>  ?


Exactly like that, yes. It isn't present (yet?) on Fedora 25, though I see now
it's been added to Rawhide.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Igor Gnatenko]

On Mon, Nov 21, 2016 at 5:48 PM, Vít Ondruch  wrote:
>
>
> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
>>
>>>
>  }
> [domain_realm]
>  .fedoraproject.org = FEDORAPROJECT.ORG
>  fedoraproject.org = FEDORAPROJECT.ORG
> ```
>
 But apparently, with this snippet, I can't kinit anymore :/

 ```
 $ kinit vondr...@fedoraproject.org
 kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
 getting initial credentials
>> works for me on Fedora 25. You can provide output from
>> 'KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org' to get
>> further.
>>
>
>
> $ KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org
> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
> [8655] 1479746886.252281: Getting initial credentials for
> vondr...@fedoraproject.org
> [8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG
> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
> [8655] 1479746886.380979: Terminating TCP connection to https
> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
> [8655] 1479746886.383242: Terminating TCP connection to https
> 2610:28:3090:3001:dead:beef:cafe:fed3:443
> [8655] 1479746886.754122: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443
> [8655] 1479746887.331375: HTTPS error receiving from https
> 140.211.169.206:443
> [8655] 1479746887.333212: Terminating TCP connection to https
> 140.211.169.206:443
> [8655] 1479746887.594719: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443
> [8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443
> [8655] 1479746888.331797: Terminating TCP connection to https
> 67.219.144.68:443
> [8655] 1479746888.694098: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443
> [8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443
> [8655] 1479746889.123787: Terminating TCP connection to https
> 67.203.2.67:443
> [8655] 1479746889.527941: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443
> [8655] 1479746889.964857: HTTPS error receiving from https
> 209.132.181.16:443
> [8655] 1479746889.965718: Terminating TCP connection to https
> 209.132.181.16:443
> [8655] 1479746890.363509: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443
> [8655] 1479746890.787479: HTTPS error receiving from https
> 209.132.181.15:443
> [8655] 1479746890.788339: Terminating TCP connection to https
> 209.132.181.15:443
> [8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443
> [8655] 1479746891.711140: HTTPS error receiving from https
> 152.19.134.198:443
> [8655] 1479746891.711960: Terminating TCP connection to https
> 152.19.134.198:443
> [8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443
> [8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443
> [8655] 1479746892.564576: Terminating TCP connection to https
> 66.35.62.162:443
> [8655] 1479746892.945989: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443
> [8655] 1479746893.512855: HTTPS error receiving from https
> 140.211.169.196:443
> [8655] 1479746893.513684: Terminating TCP connection to https
> 140.211.169.196:443
> [8655] 1479746893.812319: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443
> [8655] 1479746894.412080: HTTPS error receiving from https
> 152.19.134.142:443
> [8655] 1479746894.412908: Terminating TCP connection to https
> 152.19.134.142:443
> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> getting initial credentials
https://github.com/openssl/openssl/issues/1919

Solution is to downgrade to openssl-1.1.0b
>
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: upcoming build and release developer flag day December 12 2016

[Patrick マルタインアンドレアス Uiterwijk]

> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
> 
> 
> $ KRB5_TRACE=/dev/stderr kinit vondruch(a)FEDORAPROJECT.ORG
> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
> [8655] 1479746886.252281: Getting initial credentials for
> vondruch(a)FEDORAPROJECT.ORG
> [8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG
> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
> [8655] 1479746886.380979: Terminating TCP connection to https
> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
> [8655] 1479746886.383242: Terminating TCP connection to https
> 2610:28:3090:3001:dead:beef:cafe:fed3:443
> [8655] 1479746886.754122: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443
> [8655] 1479746887.331375: HTTPS error receiving from https
> 140.211.169.206:443
> [8655] 1479746887.333212: Terminating TCP connection to https
> 140.211.169.206:443
> [8655] 1479746887.594719: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443
> [8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443
> [8655] 1479746888.331797: Terminating TCP connection to https
> 67.219.144.68:443
> [8655] 1479746888.694098: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443
> [8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443
> [8655] 1479746889.123787: Terminating TCP connection to https
> 67.203.2.67:443
> [8655] 1479746889.527941: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443
> [8655] 1479746889.964857: HTTPS error receiving from https
> 209.132.181.16:443
> [8655] 1479746889.965718: Terminating TCP connection to https
> 209.132.181.16:443
> [8655] 1479746890.363509: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443
> [8655] 1479746890.787479: HTTPS error receiving from https
> 209.132.181.15:443
> [8655] 1479746890.788339: Terminating TCP connection to https
> 209.132.181.15:443
> [8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443
> [8655] 1479746891.711140: HTTPS error receiving from https
> 152.19.134.198:443
> [8655] 1479746891.711960: Terminating TCP connection to https
> 152.19.134.198:443
> [8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443
> [8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443
> [8655] 1479746892.564576: Terminating TCP connection to https
> 66.35.62.162:443
> [8655] 1479746892.945989: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443
> [8655] 1479746893.512855: HTTPS error receiving from https
> 140.211.169.196:443
> [8655] 1479746893.513684: Terminating TCP connection to https
> 140.211.169.196:443
> [8655] 1479746893.812319: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443
> [8655] 1479746894.412080: HTTPS error receiving from https
> 152.19.134.142:443
> [8655] 1479746894.412908: Terminating TCP connection to https
> 152.19.134.142:443
> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> getting initial credentials

Downgrade to openssl-1.1.0b: https://github.com/openssl/openssl/issues/1919

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

Re: upcoming build and release developer flag day December 12 2016

[Patrick マルタインアンドレアス Uiterwijk]

> On 11/21/2016 10:32 AM, Florian Weimer wrote:
> 
> Yes, as I mentioned elsewhere, we should probably have the fedora-packager RPM
> ship with a krb5.conf.d snippet that sets the appropriate values.

You mean something like 
http://pkgs.fedoraproject.org/cgit/rpms/fedora-packager.git/commit/?id=b3ab149d144a644f41705e4ec7b5e36a25892e95
 ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
>
>>
  }
 [domain_realm]
  .fedoraproject.org = FEDORAPROJECT.ORG
  fedoraproject.org = FEDORAPROJECT.ORG
 ```

>>> But apparently, with this snippet, I can't kinit anymore :/
>>>
>>> ```
>>> $ kinit vondr...@fedoraproject.org
>>> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
>>> getting initial credentials
> works for me on Fedora 25. You can provide output from
> 'KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org' to get
> further.
>


$ KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org
[8655] 1479746886.252240: Resolving unique ccache of type KEYRING
[8655] 1479746886.252281: Getting initial credentials for
vondr...@fedoraproject.org
[8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG
[8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
[8655] 1479746886.380979: Terminating TCP connection to https
2604:1580:fe00:0:dead:beef:cafe:fed1:443
[8655] 1479746886.383242: Terminating TCP connection to https
2610:28:3090:3001:dead:beef:cafe:fed3:443
[8655] 1479746886.754122: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443
[8655] 1479746887.331375: HTTPS error receiving from https
140.211.169.206:443
[8655] 1479746887.333212: Terminating TCP connection to https
140.211.169.206:443
[8655] 1479746887.594719: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443
[8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443
[8655] 1479746888.331797: Terminating TCP connection to https
67.219.144.68:443
[8655] 1479746888.694098: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443
[8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443
[8655] 1479746889.123787: Terminating TCP connection to https
67.203.2.67:443
[8655] 1479746889.527941: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443
[8655] 1479746889.964857: HTTPS error receiving from https
209.132.181.16:443
[8655] 1479746889.965718: Terminating TCP connection to https
209.132.181.16:443
[8655] 1479746890.363509: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443
[8655] 1479746890.787479: HTTPS error receiving from https
209.132.181.15:443
[8655] 1479746890.788339: Terminating TCP connection to https
209.132.181.15:443
[8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org"
[8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443
[8655] 1479746891.711140: HTTPS error receiving from https
152.19.134.198:443
[8655] 1479746891.711960: Terminating TCP connection to https
152.19.134.198:443
[8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org"
[8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443
[8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443
[8655] 1479746892.564576: Terminating TCP connection to https
66.35.62.162:443
[8655] 1479746892.945989: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443
[8655] 1479746893.512855: HTTPS error receiving from https
140.211.169.196:443
[8655] 1479746893.513684: Terminating TCP connection to https
140.211.169.196:443
[8655] 1479746893.812319: TLS certificate name matched
"id.fedoraproject.org"
[8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443
[8655] 1479746894.412080: HTTPS error receiving from https
152.19.134.142:443
[8655] 1479746894.412908: Terminating TCP connection to https
152.19.134.142:443
kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
getting initial credentials



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

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 10:32 AM, Florian Weimer wrote:
> On 11/21/2016 04:03 PM, Alexander Bokovoy wrote:
> 
>> Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
>> tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
>> automatically with the help of DNS URI. For older clients which don't
>> support DNS-based discovery you can configure MS-KKDCP proxy access
>> manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
>> FEDORAPROJECT.ORG realm. For very old clients that don't support
>> MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
>> traffic.
> 
> Shouldn't everyone configure things this way to prevent downgrade attacks 
> (which
> could happen even accidentally due to timeouts and things)?
> 

Yes, as I mentioned elsewhere, we should probably have the fedora-packager RPM
ship with a krb5.conf.d snippet that sets the appropriate values.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Florian Weimer]

On 11/21/2016 04:03 PM, Alexander Bokovoy wrote:


Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
automatically with the help of DNS URI. For older clients which don't
support DNS-based discovery you can configure MS-KKDCP proxy access
manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
FEDORAPROJECT.ORG realm. For very old clients that don't support
MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
traffic.


Shouldn't everyone configure things this way to prevent downgrade 
attacks (which could happen even accidentally due to timeouts and things)?


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

Re: upcoming build and release developer flag day December 12 2016

[Petr Pisar]

On 2016-11-21, Vít Ondruch  wrote:
> From: =?UTF-8?Q?V=c3=adt_Ondruch?= 
>> You mean something like this?
>>
>> ```
>> # rpm -qf /etc/krb5.conf.d/fedoraproject_org
>> fedora-packager-0.5.10.7-4.fc26.noarch
>>
>> # cat /etc/krb5.conf.d/fedoraproject_org
>> [realms]
>>  FEDORAPROJECT.ORG = {
>> kdc = https://id.fedoraproject.org/KdcProxy
>>  }
>> [domain_realm]
>>  .fedoraproject.org = FEDORAPROJECT.ORG
>>  fedoraproject.org = FEDORAPROJECT.ORG
>> ```
>>
>
> But apparently, with this snippet, I can't kinit anymore :/
>
> ```
> $ kinit vondr...@fedoraproject.org
> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> getting initial credentials
>
> $ sudo mv /etc/krb5.conf.d/fedoraproject_org{,.bak}
>
> $ kinit vondr...@fedoraproject.org
> Password for vondr...@fedoraproject.org:
>
> ```
This correct KDC address is obtained from DNS (dig -t SRV
_kerberos._tcp.fedoraproject.org).

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

Re: upcoming build and release developer flag day December 12 2016

[Alexander Bokovoy]

On ma, 21 marras 2016, Florian Weimer wrote:

On 11/21/2016 01:31 PM, Stephen Gallagher wrote:

Thanks for your explanation.


So yes, we have protection against that. FreeIPA (which is backing this
solution) requires preauthentication for all user accounts.


“That” meaning offline attacks without intercepted packets.  With 
intercepted packets, offline attacks are still feasible, right?

Right -- if you get initial exchange in the traditional Kerberos 5.
We have been working for several years already to reduce these
possibilities via different means:
- enablement for HTTPS-based tunnel for Kerberos flows based on
  MS-KKDCP specification;

- DNS-based announcement of Kerberos MS-KKDCP proxy using DNS URI;

- SPAKE exchange support in MIT Kerberos (slated for 1.15-1.16)

Fedora infrastructure uses MS-KKDCP proxy with Fedora certificate to
tunnel Kerberos 5 traffic. If you have recent Fedora, you'll get it used
automatically with the help of DNS URI. For older clients which don't
support DNS-based discovery you can configure MS-KKDCP proxy access
manually by stating 'kdc=https://id.fedoraproject.org/KdcProxy' for
FEDORAPROJECT.ORG realm. For very old clients that don't support
MS-KKDCP (RHEL 6, for example), you are back to use naked Kerberos 5
traffic.

Our effort is to get to SPAKE sooner than later.

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

Re: upcoming build and release developer flag day December 12 2016

[Alexander Bokovoy]

On ma, 21 marras 2016, Vít Ondruch wrote:



Dne 21.11.2016 v 14:18 Vít Ondruch napsal(a):


Dne 21.11.2016 v 14:07 Vít Ondruch napsal(a):

Dne 21.11.2016 v 13:36 Stephen Gallagher napsal(a):

On 11/21/2016 04:24 AM, Tomasz Torcz wrote:

On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:

koji authentication will be switching to Kerberos. Koji supports multiple
authentication mechanisms. Fedora infrastructure has set up a freeipa instance
internally that has credential syncing to fas. We are working on ensuring that
gssapi caching is supported so that you can have multiple TGT's and the
ability to work in multiple reams at once. you can get started today by doing
kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file
out of the way authentication will still work.

  Can you expand (with links to webpages/wiki?) on multiple TGTs support?
At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
realm,
but I lose my primary principal ticket. This means I lose access to my services,
including access to web proxy being my internet gateway.
  What's the trick to have _both_ tickets active – for my organisation and for
Fedora – at the same time?  This is using default Ticket cache: 
KEYRING:persistent:…


You don't lose them (you can see both with `klist -A`). What happens is that the
default ticket is the most recent one you got a TGT for. You can switch the
default ticket back to your other one with `kswitch -p username@REALM`.

We should probably look at an /etc/krb5.conf.d snippet to have the
`fedora-packager` RPM provide that will add a section like:

```
[domain_realm]
  fedoraproject.org = FEDORAPROJECT.ORG
  .fedoraproject.org = FEDORAPROJECT.ORG
  fedorainfracloud.org = FEDORAPROJECT.ORG
  .fedorainfracloud.org = FEDORAPROJECT.ORG
```

This way, no matter which ticket is set to the default, it will route requests
for services in those domains to the FEDORAPROJECT.ORG realm.


You mean something like this?

```
# rpm -qf /etc/krb5.conf.d/fedoraproject_org
fedora-packager-0.5.10.7-4.fc26.noarch

# cat /etc/krb5.conf.d/fedoraproject_org
[realms]
 FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy


Checking this ^^ against documentation, I wonder how this can be correct:

```
kdc - The  name  or  address  of a host running a KDC for that realm.
An optional port number, separated from the hostname by a colon, may be
included.  If the name or address contains colons (for example, if it is
an IPv6 address), enclose it in square brackets to distinguish the colon
from a port separator.  For your computer to be able to communicate with
the  KDC  for  each  realm, this tag must be given a value in each realm
subsection in the configuration file, or there must be DNS SRV records
specifying the KDCs.
```

The documentation is outdated. MS-KKDCP support allows you to specify an
URI that points to the proxy.



Vít


 }
[domain_realm]
 .fedoraproject.org = FEDORAPROJECT.ORG
 fedoraproject.org = FEDORAPROJECT.ORG
```


But apparently, with this snippet, I can't kinit anymore :/

```
$ kinit vondr...@fedoraproject.org
kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
getting initial credentials

works for me on Fedora 25. You can provide output from
'KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org' to get
further.

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

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 08:07 AM, Vít Ondruch wrote:
> 
> 
> Dne 21.11.2016 v 13:36 Stephen Gallagher napsal(a):
>> On 11/21/2016 04:24 AM, Tomasz Torcz wrote:
>>> On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
 koji authentication will be switching to Kerberos. Koji supports multiple 
 authentication mechanisms. Fedora infrastructure has set up a freeipa 
 instance 
 internally that has credential syncing to fas. We are working on ensuring 
 that 
 gssapi caching is supported so that you can have multiple TGT's and the 
 ability to work in multiple reams at once. you can get started today by 
 doing 
 kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert 
 file 
 out of the way authentication will still work.
>>>
>>>   Can you expand (with links to webpages/wiki?) on multiple TGTs support?
>>> At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
>>> realm,
>>> but I lose my primary principal ticket. This means I lose access to my 
>>> services,
>>> including access to web proxy being my internet gateway.
>>>   What's the trick to have _both_ tickets active – for my organisation and 
>>> for
>>> Fedora – at the same time?  This is using default Ticket cache: 
>>> KEYRING:persistent:…
>>>
>> You don't lose them (you can see both with `klist -A`). What happens is that 
>> the
>> default ticket is the most recent one you got a TGT for. You can switch the
>> default ticket back to your other one with `kswitch -p username@REALM`.
>>
>> We should probably look at an /etc/krb5.conf.d snippet to have the
>> `fedora-packager` RPM provide that will add a section like:
>>
>> ```
>> [domain_realm]
>>   fedoraproject.org = FEDORAPROJECT.ORG
>>   .fedoraproject.org = FEDORAPROJECT.ORG
>>   fedorainfracloud.org = FEDORAPROJECT.ORG
>>   .fedorainfracloud.org = FEDORAPROJECT.ORG
>> ```
>>
>> This way, no matter which ticket is set to the default, it will route 
>> requests
>> for services in those domains to the FEDORAPROJECT.ORG realm.
>>
> 


So, it turns out that this doesn't work yet. It's complicated, but there's a
patch pending for Koji that will make this work. It hasn't landed yet. Hopefully
that will change before the flag day.


> You mean something like this?
> 
> ```
> # rpm -qf /etc/krb5.conf.d/fedoraproject_org
> fedora-packager-0.5.10.7-4.fc26.noarch
> 
> # cat /etc/krb5.conf.d/fedoraproject_org
> [realms]
>  FEDORAPROJECT.ORG = {
> kdc = https://id.fedoraproject.org/KdcProxy
>  }
> [domain_realm]
>  .fedoraproject.org = FEDORAPROJECT.ORG
>  fedoraproject.org = FEDORAPROJECT.ORG
> ```
> 

You actually shouldn't need to specify the [realms] section at all, because of
some nice DNS magic. Getting the [domain_realm] section working needs koji to
accept the patch Patrick Uiterwijk mentioned elsewhere in this thread.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 21.11.2016 v 14:18 Vít Ondruch napsal(a):
>
> Dne 21.11.2016 v 14:07 Vít Ondruch napsal(a):
>> Dne 21.11.2016 v 13:36 Stephen Gallagher napsal(a):
>>> On 11/21/2016 04:24 AM, Tomasz Torcz wrote:
 On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
> koji authentication will be switching to Kerberos. Koji supports multiple 
> authentication mechanisms. Fedora infrastructure has set up a freeipa 
> instance 
> internally that has credential syncing to fas. We are working on ensuring 
> that 
> gssapi caching is supported so that you can have multiple TGT's and the 
> ability to work in multiple reams at once. you can get started today by 
> doing 
> kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert 
> file 
> out of the way authentication will still work.
   Can you expand (with links to webpages/wiki?) on multiple TGTs support?
 At the moment, when I use kinit on F25, I get ticket for 
 @FEDORAPROJECT.ORG realm,
 but I lose my primary principal ticket. This means I lose access to my 
 services,
 including access to web proxy being my internet gateway.
   What's the trick to have _both_ tickets active – for my organisation and 
 for
 Fedora – at the same time?  This is using default Ticket cache: 
 KEYRING:persistent:…

>>> You don't lose them (you can see both with `klist -A`). What happens is 
>>> that the
>>> default ticket is the most recent one you got a TGT for. You can switch the
>>> default ticket back to your other one with `kswitch -p username@REALM`.
>>>
>>> We should probably look at an /etc/krb5.conf.d snippet to have the
>>> `fedora-packager` RPM provide that will add a section like:
>>>
>>> ```
>>> [domain_realm]
>>>   fedoraproject.org = FEDORAPROJECT.ORG
>>>   .fedoraproject.org = FEDORAPROJECT.ORG
>>>   fedorainfracloud.org = FEDORAPROJECT.ORG
>>>   .fedorainfracloud.org = FEDORAPROJECT.ORG
>>> ```
>>>
>>> This way, no matter which ticket is set to the default, it will route 
>>> requests
>>> for services in those domains to the FEDORAPROJECT.ORG realm.
>>>
>> You mean something like this?
>>
>> ```
>> # rpm -qf /etc/krb5.conf.d/fedoraproject_org
>> fedora-packager-0.5.10.7-4.fc26.noarch
>>
>> # cat /etc/krb5.conf.d/fedoraproject_org
>> [realms]
>>  FEDORAPROJECT.ORG = {
>> kdc = https://id.fedoraproject.org/KdcProxy

Checking this ^^ against documentation, I wonder how this can be correct:

```
kdc - The  name  or  address  of a host running a KDC for that realm. 
An optional port number, separated from the hostname by a colon, may be
included.  If the name or address contains colons (for example, if it is
an IPv6 address), enclose it in square brackets to distinguish the colon
from a port separator.  For your computer to be able to communicate with
the  KDC  for  each  realm, this tag must be given a value in each realm
subsection in the configuration file, or there must be DNS SRV records
specifying the KDCs.
```

Vít

>>  }
>> [domain_realm]
>>  .fedoraproject.org = FEDORAPROJECT.ORG
>>  fedoraproject.org = FEDORAPROJECT.ORG
>> ```
>>
> But apparently, with this snippet, I can't kinit anymore :/
>
> ```
> $ kinit vondr...@fedoraproject.org
> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> getting initial credentials
>
> $ sudo mv /etc/krb5.conf.d/fedoraproject_org{,.bak}
>
> $ kinit vondr...@fedoraproject.org
> Password for vondr...@fedoraproject.org:
>
> ```
>
>
> Vít
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Florian Weimer]

On 11/21/2016 01:31 PM, Stephen Gallagher wrote:

Thanks for your explanation.


So yes, we have protection against that. FreeIPA (which is backing this
solution) requires preauthentication for all user accounts.


“That” meaning offline attacks without intercepted packets.  With 
intercepted packets, offline attacks are still feasible, right?


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

Re: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 21.11.2016 v 14:07 Vít Ondruch napsal(a):
>
> Dne 21.11.2016 v 13:36 Stephen Gallagher napsal(a):
>> On 11/21/2016 04:24 AM, Tomasz Torcz wrote:
>>> On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
 koji authentication will be switching to Kerberos. Koji supports multiple 
 authentication mechanisms. Fedora infrastructure has set up a freeipa 
 instance 
 internally that has credential syncing to fas. We are working on ensuring 
 that 
 gssapi caching is supported so that you can have multiple TGT's and the 
 ability to work in multiple reams at once. you can get started today by 
 doing 
 kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert 
 file 
 out of the way authentication will still work.
>>>   Can you expand (with links to webpages/wiki?) on multiple TGTs support?
>>> At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
>>> realm,
>>> but I lose my primary principal ticket. This means I lose access to my 
>>> services,
>>> including access to web proxy being my internet gateway.
>>>   What's the trick to have _both_ tickets active – for my organisation and 
>>> for
>>> Fedora – at the same time?  This is using default Ticket cache: 
>>> KEYRING:persistent:…
>>>
>> You don't lose them (you can see both with `klist -A`). What happens is that 
>> the
>> default ticket is the most recent one you got a TGT for. You can switch the
>> default ticket back to your other one with `kswitch -p username@REALM`.
>>
>> We should probably look at an /etc/krb5.conf.d snippet to have the
>> `fedora-packager` RPM provide that will add a section like:
>>
>> ```
>> [domain_realm]
>>   fedoraproject.org = FEDORAPROJECT.ORG
>>   .fedoraproject.org = FEDORAPROJECT.ORG
>>   fedorainfracloud.org = FEDORAPROJECT.ORG
>>   .fedorainfracloud.org = FEDORAPROJECT.ORG
>> ```
>>
>> This way, no matter which ticket is set to the default, it will route 
>> requests
>> for services in those domains to the FEDORAPROJECT.ORG realm.
>>
> You mean something like this?
>
> ```
> # rpm -qf /etc/krb5.conf.d/fedoraproject_org
> fedora-packager-0.5.10.7-4.fc26.noarch
>
> # cat /etc/krb5.conf.d/fedoraproject_org
> [realms]
>  FEDORAPROJECT.ORG = {
> kdc = https://id.fedoraproject.org/KdcProxy
>  }
> [domain_realm]
>  .fedoraproject.org = FEDORAPROJECT.ORG
>  fedoraproject.org = FEDORAPROJECT.ORG
> ```
>

But apparently, with this snippet, I can't kinit anymore :/

```
$ kinit vondr...@fedoraproject.org
kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
getting initial credentials

$ sudo mv /etc/krb5.conf.d/fedoraproject_org{,.bak}

$ kinit vondr...@fedoraproject.org
Password for vondr...@fedoraproject.org:

```


Vít



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 21.11.2016 v 13:36 Stephen Gallagher napsal(a):
> On 11/21/2016 04:24 AM, Tomasz Torcz wrote:
>> On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
>>> koji authentication will be switching to Kerberos. Koji supports multiple 
>>> authentication mechanisms. Fedora infrastructure has set up a freeipa 
>>> instance 
>>> internally that has credential syncing to fas. We are working on ensuring 
>>> that 
>>> gssapi caching is supported so that you can have multiple TGT's and the 
>>> ability to work in multiple reams at once. you can get started today by 
>>> doing 
>>> kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file 
>>> out of the way authentication will still work.
>>
>>   Can you expand (with links to webpages/wiki?) on multiple TGTs support?
>> At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
>> realm,
>> but I lose my primary principal ticket. This means I lose access to my 
>> services,
>> including access to web proxy being my internet gateway.
>>   What's the trick to have _both_ tickets active – for my organisation and 
>> for
>> Fedora – at the same time?  This is using default Ticket cache: 
>> KEYRING:persistent:…
>>
> You don't lose them (you can see both with `klist -A`). What happens is that 
> the
> default ticket is the most recent one you got a TGT for. You can switch the
> default ticket back to your other one with `kswitch -p username@REALM`.
>
> We should probably look at an /etc/krb5.conf.d snippet to have the
> `fedora-packager` RPM provide that will add a section like:
>
> ```
> [domain_realm]
>   fedoraproject.org = FEDORAPROJECT.ORG
>   .fedoraproject.org = FEDORAPROJECT.ORG
>   fedorainfracloud.org = FEDORAPROJECT.ORG
>   .fedorainfracloud.org = FEDORAPROJECT.ORG
> ```
>
> This way, no matter which ticket is set to the default, it will route requests
> for services in those domains to the FEDORAPROJECT.ORG realm.
>

You mean something like this?

```
# rpm -qf /etc/krb5.conf.d/fedoraproject_org
fedora-packager-0.5.10.7-4.fc26.noarch

# cat /etc/krb5.conf.d/fedoraproject_org
[realms]
 FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy
 }
[domain_realm]
 .fedoraproject.org = FEDORAPROJECT.ORG
 fedoraproject.org = FEDORAPROJECT.ORG
```


Vít



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 04:32 AM, Vít Ondruch wrote:
> 
> 
> Dne 20.11.2016 v 02:11 Dennis Gilmore napsal(a):
>> koji authentication will be switching to Kerberos. Koji supports multiple 
>> authentication mechanisms. Fedora infrastructure has set up a freeipa 
>> instance 
>> internally that has credential syncing to fas. We are working on ensuring 
>> that 
>> gssapi caching is supported so that you can have multiple TGT's and the 
>> ability to work in multiple reams at once.


See my other email. I think the issue is that we are missing a krb5.conf.d
snippet to ensure that the FEDORAPROJECT.ORG TGT is used regardless of whichever
ticket happens to be the current default.

> 
> BTW it would be nice, if it works with SSSD somehow and I don't need to
> use kinit at all.
> 
> 

That is being worked on. I've asked Jakub Hrozek to come talk about the upcoming
SSSD KCM work (targeted for F26).



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 04:24 AM, Tomasz Torcz wrote:
> On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
>> koji authentication will be switching to Kerberos. Koji supports multiple 
>> authentication mechanisms. Fedora infrastructure has set up a freeipa 
>> instance 
>> internally that has credential syncing to fas. We are working on ensuring 
>> that 
>> gssapi caching is supported so that you can have multiple TGT's and the 
>> ability to work in multiple reams at once. you can get started today by 
>> doing 
>> kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file 
>> out of the way authentication will still work.
> 
> 
>   Can you expand (with links to webpages/wiki?) on multiple TGTs support?
> At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
> realm,
> but I lose my primary principal ticket. This means I lose access to my 
> services,
> including access to web proxy being my internet gateway.
>   What's the trick to have _both_ tickets active – for my organisation and for
> Fedora – at the same time?  This is using default Ticket cache: 
> KEYRING:persistent:…
> 

You don't lose them (you can see both with `klist -A`). What happens is that the
default ticket is the most recent one you got a TGT for. You can switch the
default ticket back to your other one with `kswitch -p username@REALM`.

We should probably look at an /etc/krb5.conf.d snippet to have the
`fedora-packager` RPM provide that will add a section like:

```
[domain_realm]
  fedoraproject.org = FEDORAPROJECT.ORG
  .fedoraproject.org = FEDORAPROJECT.ORG
  fedorainfracloud.org = FEDORAPROJECT.ORG
  .fedorainfracloud.org = FEDORAPROJECT.ORG
```

This way, no matter which ticket is set to the default, it will route requests
for services in those domains to the FEDORAPROJECT.ORG realm.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/20/2016 08:50 AM, Florian Weimer wrote:
> On 11/20/2016 02:11 AM, Dennis Gilmore wrote:
>> koji authentication will be switching to Kerberos. Koji supports multiple
>> authentication mechanisms. Fedora infrastructure has set up a freeipa 
>> instance
>> internally that has credential syncing to fas. We are working on ensuring 
>> that
>> gssapi caching is supported so that you can have multiple TGT's and the
>> ability to work in multiple reams at once. you can get started today by doing
>> kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file
>> out of the way authentication will still work.
> 
> Unfortunately, I do not know much about Kerberos.
> 
> As far as I understand it, the original Kerberos 5 specification did not 
> protect
> the user password against offline brute-force attacks.  Due to the protocol is
> structured, it is not even necessary for an attacker to intercept any network
> packets; knowledge of the user name is sufficient to obtain data based on 
> which
> you can start cracking the password.
> 
> Will we deploy any protection against that?

That offline attack is basically ancient history. What happened once upon a time
was that the client would just request a TGT (ticket granting ticket) from the
KDC (Key Distribution Center) and get back the resulting TGT immediately, with
the expectation that it was only usable if the user already knew the password.

Nowadays, basically every Kerberos implementation requires preauthentication,
which basically means that before it will send you the TGT, you have to send it
a packet encrypted with the right password. (Often this is something simple like
the current timestamp.) This proves to the KDC that you already know the 
password.

So yes, we have protection against that. FreeIPA (which is backing this
solution) requires preauthentication for all user accounts.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Patrick マルタインアンドレアス Uiterwijk]

> On 2016-11-20, 01:11 GMT, Dennis Gilmore wrote:
> 
> a) Is it possible to have multiple tickets, each from different
> realm? When I do kinit mcepl(a)FEDORAPROJECT.ORG, klist lookslike my
> @REDHAT.COM ticket has been knocked out (i.e., thereis only FPO
> ticket there). Ah, klist -A seems to be theanswer.

Yes, this works, however, koji does not automatically select the right TGT.
As such, you will need to run "kswitch -p $usern...@fedoraproject.org" when you 
go work on Fedora.

I have a patch in koji for GSSAPI support, but that's been idle/awaiting 
upstream review/changes.

> b) We do have to do the Firefox Kerberos-dance anyway
> (https://developer.mozilla.org/en-US/docs/Mozilla/Integrated_authentication),
>right? Somebody should mention that, so I do.

With Firefox 49 and later, the trusted-uris setting is set to https:// by 
default, which means
you don't need to change anything.

> c) Despite doing all this I don’t see myself logged-in to Koji. What
> am I missing?

We have not enabled web login for Koji. I will be looking at that in the near 
future, but that's not
a main goal.
For now, the CLI should work, which you can verify with "koji hello".

> 
> Best,
> 
> Matěj

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

Re: upcoming build and release developer flag day December 12 2016

[Stephen Gallagher]

On 11/21/2016 05:02 AM, Matěj Cepl wrote:
> On 2016-11-20, 01:11 GMT, Dennis Gilmore wrote:
>> you can get started today by doing kinit > username>@FEDORAPROJECT.ORG if you move your ~/.fedora.cert 
>> file out of the way authentication will still work.
> 
> a) Is it possible to have multiple tickets, each from different
> realm? When I do kinit mc...@fedoraproject.org, klist lookslike my
> @REDHAT.COM ticket has been knocked out (i.e., thereis only FPO
> ticket there). Ah, klist -A seems to be theanswer.


Yes, Kerberos now (for the last four or five years) supports multiple TGTs. If
your krb5.conf is set up to map them automatically to domains, you don't need to
do anything special. If not, you can still switch between them with
```
kswitch -p username@REALM
```


> b) We do have to do the Firefox Kerberos-dance anyway
> (https://developer.mozilla.org/en-US/docs/Mozilla/Integrated_authentication),
>right? Somebody should mention that, so I do.

It doesn't sound like we actually need Kerberos to access Koji Web at all, so
this is probably unnecessary.


> c) Despite doing all this I don’t see myself logged-in to Koji. What
> am I missing?

This is discussing the use of Koji through the `koji` CLI (implicitly by way of
fedpkg). I don't think there's been any discussion about logging into the web
interface.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Matěj Cepl]

On 2016-11-20, 01:11 GMT, Dennis Gilmore wrote:
> you can get started today by doing kinit  username>@FEDORAPROJECT.ORG if you move your ~/.fedora.cert 
> file out of the way authentication will still work.

a) Is it possible to have multiple tickets, each from different
realm? When I do kinit mc...@fedoraproject.org, klist lookslike my
@REDHAT.COM ticket has been knocked out (i.e., thereis only FPO
ticket there). Ah, klist -A seems to be theanswer.
b) We do have to do the Firefox Kerberos-dance anyway
(https://developer.mozilla.org/en-US/docs/Mozilla/Integrated_authentication),
   right? Somebody should mention that, so I do.
c) Despite doing all this I don’t see myself logged-in to Koji. What
am I missing?

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 As a rule of thumb, the more qualifiers there are before the name
of a country, the more corrupt the rulers. A country called The
Socialist People's Democratic Republic of X is probably the last
place in the world you'd want to live.
-- Paul Graham discussing (not only) Nigerian spam
   (http://www.paulgraham.com/spam.html)



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Vít Ondruch]

Dne 20.11.2016 v 02:11 Dennis Gilmore napsal(a):
> koji authentication will be switching to Kerberos. Koji supports multiple 
> authentication mechanisms. Fedora infrastructure has set up a freeipa 
> instance 
> internally that has credential syncing to fas. We are working on ensuring 
> that 
> gssapi caching is supported so that you can have multiple TGT's and the 
> ability to work in multiple reams at once.

So what is the status here? Can you elaborate? It does not look like I
can use this now. E.g. this works:

```
$ kinit vondr...@fedoraproject.org
Password for vondr...@fedoraproject.org:

$ fedpkg scratch-build
Your git configuration does not use a namespace.
Consider updating your git configuration by running:
  git remote set-url origin ssh://vondr...@pkgs.fedoraproject.org/rpms/ruby
Building ruby-2.2.6-50.fc23 for f23-candidate
Created task: 16551355
```

But using another TGT does not:

```
$ kinit vondr...@redhat.com
Password for vondr...@redhat.com:

$ klist -A
Ticket cache: KEYRING:persistent:16025:krb_ccache_GGcdkLO
Default principal: vondr...@redhat.com

Valid starting   Expires  Service principal
21.11.2016 10:29:22  21.11.2016 20:29:22  krbtgt/redhat@redhat.com

Ticket cache: KEYRING:persistent:16025:krb_ccache_Bq2ZU0r
Default principal: vondr...@fedoraproject.org

Valid starting   Expires  Service principal
21.11.2016 10:29:04  22.11.2016 10:28:55 
host/koji.fedoraproject@fedoraproject.org
renew until 28.11.2016 10:28:55
21.11.2016 10:28:59  22.11.2016 10:28:55 
krbtgt/fedoraproject@fedoraproject.org
renew until 28.11.2016 10:28:55


$ fedpkg scratch-build
Your git configuration does not use a namespace.
Consider updating your git configuration by running:
  git remote set-url origin ssh://vondr...@pkgs.fedoraproject.org/rpms/ruby
Could not execute scratch_build: (-1765328377, 'Server not found in
Kerberos database')
```

BTW it would be nice, if it works with SSSD somehow and I don't need to
use kinit at all.


Vít



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Tomasz Torcz]

On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
> koji authentication will be switching to Kerberos. Koji supports multiple 
> authentication mechanisms. Fedora infrastructure has set up a freeipa 
> instance 
> internally that has credential syncing to fas. We are working on ensuring 
> that 
> gssapi caching is supported so that you can have multiple TGT's and the 
> ability to work in multiple reams at once. you can get started today by doing 
> kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file 
> out of the way authentication will still work.


  Can you expand (with links to webpages/wiki?) on multiple TGTs support?
At the moment, when I use kinit on F25, I get ticket for @FEDORAPROJECT.ORG 
realm,
but I lose my primary principal ticket. This means I lose access to my services,
including access to web proxy being my internet gateway.
  What's the trick to have _both_ tickets active – for my organisation and for
Fedora – at the same time?  This is using default Ticket cache: 
KEYRING:persistent:…

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[David Howells]

Michael Catanzaro  wrote:

> I have no idea how this fancy Kerberos works or integrates with GNOME,
> but the above is a truism that stands the test of time.

Kerberos integrates fine with KDE's Konqueror.  If I go to a kerberised page
for which I have a TGT, KDE will do the ticket look up automatically.

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

Re: upcoming build and release developer flag day December 12 2016

[Tomas Mraz]

On Ne, 2016-11-20 at 18:47 -0600, Michael Catanzaro wrote:
> 
> Well I fixed all my typos except the two in that quote there. :)
> Maybe
> I am a shitty htypist byt yeah I have to use backspace al ot. Somehow
> I
> tnhink the popelo (oh gosh I am doing really badly here) who
> recommend
> passpharess ()this is embarrassing I can't even get the parentheses
> right) are eithre excellent typists, ro not following their own
> advice
+1
I use muscle memory to type passwords and I actually hate long
passphrases as I am not able to type them fast enough without typos. I
could probably type them if I typed them slowly but that isn't
something I am willing to do.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: upcoming build and release developer flag day December 12 2016

[Michael Catanzaro]

On Sun, 2016-11-20 at 14:06 -0700, Kevin Fenzi wrote:
> Well, this same ticket will hopefully be used to sign you into
> various
> Fedora Infrastructure websites too at some point, so 6 months is way
> too long for that IMHO.

OK I have to bite: I never want to be signed out of websites. If you're
not using a shared computer, why would you want that? It's just
annoying and encourages people to choose lousy memorable passwords.

On Sun, 2016-11-20 at 14:06 -0700, Kevin Fenzi wrote:
> Sure, use whatever you like. pass uses gpg, so if you are using
> gnome-keyring it can cache your passphrase for you, but not sure what
> other integration you mean.

By "integration" I mean: does the tool use the secret service D-Bus API
to get my password for me, so that I don't have to?

On Sun, 2016-11-20 at 14:06 -0700, Kevin Fenzi wrote:
> > I can't type half that many worlds without a typo or two, so that's
> > going to be frustarting. ;) Why would somebody want to type that
> long
> > thing rather than "2016sucked"?
> 
> Because it's much easier to remember and its much less easy to
> crack. 
> You just typed this email without (at least any that I saw) typos. ;)

Well I fixed all my typos except the two in that quote there. :) Maybe
I am a shitty htypist byt yeah I have to use backspace al ot. Somehow I
tnhink the popelo (oh gosh I am doing really badly here) who recommend
passpharess ()this is embarrassing I can't even get the parentheses
right) are eithre excellent typists, ro not following their own
advice

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

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Sun, 20 Nov 2016 14:36:54 -0600
Michael Catanzaro  wrote:

> On Sun, 2016-11-20 at 12:29 -0700, Kevin Fenzi wrote:
> > One question: So, 6 months is long enough for you to use a longer
> > passphrase, but 1 week is not. Where is the line?   
> 
> I don't know. 6 months seemed good to me. What is the security goal
> here?

Well, this same ticket will hopefully be used to sign you into various
Fedora Infrastructure websites too at some point, so 6 months is way
too long for that IMHO. 

> > and Two suggestions: 
> > 
> > 1. Use a password manager? I recommend 'pass' it's quite simple,
> > uses gpg and files in a git repo. Then you fas password is just a
> > 'pass -c fas' away.   
> 
> I already use seahorse because I use Fedora Workstation. There's
> absolutely no way to use different passwords for different services
> without a password manager, so good thing it's built-in to our
> desktop. Does this new system have secret service integration? (I
> doubt it.)

Sure, use whatever you like. pass uses gpg, so if you are using
gnome-keyring it can cache your passphrase for you, but not sure what
other integration you mean. 

> > 2. Use a passphrase you can remember. Isn't:
> > 
> > My FAS password is long, but I can always, always remember it.!
> > 
> > easier to remember than some
> > 
> > jkas63opqp 
> > 
> > string? 
> > 
> > kevin  
> 
> I can't type half that many worlds without a typo or two, so that's
> going to be frustarting. ;) Why would somebody want to type that long
> thing rather than "2016sucked"?

Because it's much easier to remember and its much less easy to crack. 
You just typed this email without (at least any that I saw) typos. ;) 

> Anyway, from 3 minutes of looking into Kerberos it's not clear to me
> whether password strength is actually important, and it is clear I'm
> not qualified to write about it, so I'll shut up now.

I'll stop here too. ;) 

kevin


pgpX8MYiqMS8r.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Michael Catanzaro]

On Sun, 2016-11-20 at 12:29 -0700, Kevin Fenzi wrote:
> One question: So, 6 months is long enough for you to use a longer
> passphrase, but 1 week is not. Where is the line? 

I don't know. 6 months seemed good to me. What is the security goal
here?

> and Two suggestions: 
> 
> 1. Use a password manager? I recommend 'pass' it's quite simple, uses
> gpg and files in a git repo. Then you fas password is just a 'pass -c
> fas' away. 

I already use seahorse because I use Fedora Workstation. There's
absolutely no way to use different passwords for different services
without a password manager, so good thing it's built-in to our desktop.
Does this new system have secret service integration? (I doubt it.)

> 2. Use a passphrase you can remember. Isn't:
> 
> My FAS password is long, but I can always, always remember it.!
> 
> easier to remember than some
> 
> jkas63opqp 
> 
> string? 
> 
> kevin

I can't type half that many worlds without a typo or two, so that's
going to be frustarting. ;) Why would somebody want to type that long
thing rather than "2016sucked"?

Anyway, from 3 minutes of looking into Kerberos it's not clear to me
whether password strength is actually important, and it is clear I'm
not qualified to write about it, so I'll shut up now.

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

Re: upcoming build and release developer flag day December 12 2016

[Mathieu Bridon]

On Sun, 2016-11-20 at 11:14 -0700, Kevin Fenzi wrote:
> On Sun, 20 Nov 2016 11:43:55 +0100
> Mathieu Bridon  wrote:
> > On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote:
> > > We are wanting to write to you all about an important date coming
> > > up. On the 12th of December 2016 we will be making some important
> > > changes that will require changes on every developers machine. In
> > > this case developers means every one that interacts with koji
> > > using authentication
> > > 
> > > lookaside cache checksum hash. currently packages are stored in
> > > lookaside cache using md5sum we will be switching to sha256sum.  
> > 
> > I thought the plan was sha512, did that change?
> 
> I thought we ended up on sha256, but it's been so long since this
> work was ready to go, I admit I don't recall. ;) sha512 is fine with
> me too. 

Last time I worked on this we were still talking about sha512, but it's
possible you (the releng team) changed your mind since it's been a long
time indeed and I haven't followed up since.

Note that the server code expects sha512, not sha256:

https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/di
stgit/files/dist-git-upload.cgi#n120

So some more code would need changed to move to sha256, but I'm not
sure it's worth the effort.


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

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Sun, 20 Nov 2016 13:03:27 -0600
Michael Catanzaro  wrote:

> On Sun, 2016-11-20 at 18:30 +, Tom Hughes wrote:
> > Opening that every six months to copy and paste the password is one 
> > thing but I'm not going to be doing that every day/week, so 
> > realistically that's going to mean switching to a much simpler
> > password 
> > that I can remember.  
> 
> Yup, if I have to type my password then I'm going to set it to
> something short and memorable, same as everybody else. The more often
> you require users to input a password, the less secure the system will
> be.
> 
> I have no idea how this fancy Kerberos works or integrates with GNOME,
> but the above is a truism that stands the test of time.

One question: So, 6 months is long enough for you to use a longer
passphrase, but 1 week is not. Where is the line? 

and Two suggestions: 

1. Use a password manager? I recommend 'pass' it's quite simple, uses
gpg and files in a git repo. Then you fas password is just a 'pass -c
fas' away. 

2. Use a passphrase you can remember. Isn't:

My FAS password is long, but I can always, always remember it.!

easier to remember than some

jkas63opqp 

string? 

kevin


pgpfiQpatqvwC.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Michael Catanzaro]

On Sun, 2016-11-20 at 18:30 +, Tom Hughes wrote:
> Opening that every six months to copy and paste the password is one 
> thing but I'm not going to be doing that every day/week, so 
> realistically that's going to mean switching to a much simpler
> password 
> that I can remember.

Yup, if I have to type my password then I'm going to set it to
something short and memorable, same as everybody else. The more often
you require users to input a password, the less secure the system will
be.

I have no idea how this fancy Kerberos works or integrates with GNOME,
but the above is a truism that stands the test of time.

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

Re: upcoming build and release developer flag day December 12 2016

[Tom Hughes]

On 20/11/16 18:13, Kevin Fenzi wrote:

On Sun, 20 Nov 2016 10:10:17 +
Tom Hughes  wrote:


Bearing in mind that I've never used kerberos before, so I may be
misunderstanding something completely here, a little experimentation
suggests that currently the longest ticket lifetime we can request
with kinit is 24 hours?

It looks like it can be renewed up to a week (well six days, plus the
one day lifetime of the final ticket) but you do have to remember to
keep renewing before the 24 hour expiry is reached.


Correct. Thats the current setting. Note that I think gnome online
accounts auto handles the renewing for you (but I could be
misremembering that) if you are using that.


I long ago gave up on Gnome Online Account as it seems to be utterly 
incapable of remembering anything at all. It's main purpose seemed to be 
constantly throwing up dialogs demanding I reauthenticate to the various 
services I had told it about.


Maybe I'll have to try it again and just not tell it about any of my 
accounts if it still keeps forgetting them.



All of which is something of a change from the current six month
cycle with the client certificates.


True, but getting a new ticket once a week doesn't seem like that big a
deal to me. We can of course adjust it if desired.


Well my problem is that currently my FAS password is a long character 
random string that is known only to my web browser's password manager.


Opening that every six months to copy and paste the password is one 
thing but I'm not going to be doing that every day/week, so 
realistically that's going to mean switching to a much simpler password 
that I can remember.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Sun, 20 Nov 2016 11:43:55 +0100
Mathieu Bridon  wrote:

> Hi,
> 
> On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote:
> > We are wanting to write to you all about an important date coming
> > up. On the 12th of December 2016 we will be making some important
> > changes that will require changes on every developers machine. In
> > this case developers means every one that interacts with koji using
> > authentication
> > 
> > lookaside cache checksum hash. currently packages are stored in
> > lookaside cache using md5sum we will be switching to sha256sum.  
> 
> I thought the plan was sha512, did that change?

I thought we ended up on sha256, but it's been so long since this work
was ready to go, I admit I don't recall. ;) sha512 is fine with me too. 

kevin


pgp3pFl0h0Ckq.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Kevin Fenzi]

On Sun, 20 Nov 2016 10:10:17 +
Tom Hughes  wrote:

> On 20/11/16 01:11, Dennis Gilmore wrote:
> 
> > koji authentication will be switching to Kerberos. Koji supports
> > multiple authentication mechanisms. Fedora infrastructure has set
> > up a freeipa instance internally that has credential syncing to
> > fas. We are working on ensuring that gssapi caching is supported so
> > that you can have multiple TGT's and the ability to work in
> > multiple reams at once. you can get started today by doing kinit
> > @FEDORAPROJECT.ORG if you move your ~/.fedora.cert
> > file out of the way authentication will still work.  
> 
> Bearing in mind that I've never used kerberos before, so I may be 
> misunderstanding something completely here, a little experimentation 
> suggests that currently the longest ticket lifetime we can request
> with kinit is 24 hours?
> 
> It looks like it can be renewed up to a week (well six days, plus the 
> one day lifetime of the final ticket) but you do have to remember to 
> keep renewing before the 24 hour expiry is reached.

Correct. Thats the current setting. Note that I think gnome online
accounts auto handles the renewing for you (but I could be
misremembering that) if you are using that. 
> 
> All of which is something of a change from the current six month
> cycle with the client certificates.

True, but getting a new ticket once a week doesn't seem like that big a
deal to me. We can of course adjust it if desired. 

kevin




pgpajpBt5cs5T.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Florian Weimer]

On 11/20/2016 02:11 AM, Dennis Gilmore wrote:

koji authentication will be switching to Kerberos. Koji supports multiple
authentication mechanisms. Fedora infrastructure has set up a freeipa instance
internally that has credential syncing to fas. We are working on ensuring that
gssapi caching is supported so that you can have multiple TGT's and the
ability to work in multiple reams at once. you can get started today by doing
kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file
out of the way authentication will still work.


Unfortunately, I do not know much about Kerberos.

As far as I understand it, the original Kerberos 5 specification did not 
protect the user password against offline brute-force attacks.  Due to 
the protocol is structured, it is not even necessary for an attacker to 
intercept any network packets; knowledge of the user name is sufficient 
to obtain data based on which you can start cracking the password.


Will we deploy any protection against that?

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

Re: upcoming build and release developer flag day December 12 2016

[Till Maas]

On Sun, Nov 20, 2016 at 11:21:03AM +0100, Tomasz Torcz wrote:

>   What do you mean by above, exactly?  Right now koji certs are signed by
> „Fedora CA”, will those be replaced by certificates signed by universally
> trusted CA?

Yes.

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

Re: upcoming build and release developer flag day December 12 2016

[Mathieu Bridon]

Hi,

On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote:
> We are wanting to write to you all about an important date coming up.
> On the 12th of December 2016 we will be making some important changes
> that will require changes on every developers machine. In this case
> developers means every one that interacts with koji using
> authentication
> 
> lookaside cache checksum hash. currently packages are stored in
> lookaside cache using md5sum we will be switching to sha256sum.

I thought the plan was sha512, did that change?


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

Re: upcoming build and release developer flag day December 12 2016

[Tomasz Torcz]

On Sat, Nov 19, 2016 at 07:11:25PM -0600, Dennis Gilmore wrote:
> 
> Using well known certs for koji.fedoraproject.org arm.koji.fedoraproject.org 
> ppc.koji.fedoraproject.org s390.koji.fedoraproject.org pkgs.fedoraproject.org 
> this is the last step needed to have fedoraproject.org switch to hsts and 
> default to https:// when connecting to any fedora service. It will also 
> remove 
> a lot of questions that new people have when connecting to koji via https.
> 

  What do you mean by above, exactly?  Right now koji certs are signed by
„Fedora CA”, will those be replaced by certificates signed by universally
trusted CA?

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Tom Hughes]

On 20/11/16 01:11, Dennis Gilmore wrote:


koji authentication will be switching to Kerberos. Koji supports multiple
authentication mechanisms. Fedora infrastructure has set up a freeipa instance
internally that has credential syncing to fas. We are working on ensuring that
gssapi caching is supported so that you can have multiple TGT's and the
ability to work in multiple reams at once. you can get started today by doing
kinit @FEDORAPROJECT.ORG if you move your ~/.fedora.cert file
out of the way authentication will still work.


Bearing in mind that I've never used kerberos before, so I may be 
misunderstanding something completely here, a little experimentation 
suggests that currently the longest ticket lifetime we can request with 
kinit is 24 hours?


It looks like it can be renewed up to a week (well six days, plus the 
one day lifetime of the final ticket) but you do have to remember to 
keep renewing before the 24 hour expiry is reached.


All of which is something of a change from the current six month cycle 
with the client certificates.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org