Re: upcoming build and release developer flag day December 12 2016
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
upcoming build and release developer flag day December 12 2016
Hi All, 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. The support for this has been in fedpkg for awhile, we have not switched the default as once we do any source uploaded with sha256sum will only be able to be verified by a client that supports sha256sum. 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. 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. Disable ssl cert authentication in koji. With the switch to keberos and the change of ssl certificates on the koji and pkgs servers we will be disabling the ability to login to koji using a ssl certificate completely. This change will require new koji client configurations for everyone. Gate rawhide builds. Gating will enable us to sign rawhide builds and switch the rawhide repo to having gpgcheck enabled. In order to achieve everything we have to break end user configurations. All users will need to have new enough versions of fedora-packager, fedpkg, rpkg, koji. the exact versions needed are not yet known as some enhancements are still being worked on. We will be aiming to have everything pushed stable right before the flag day. Some of the changes will not be compatible with the existing setup. We anticipate keeping everyone informed as we move forward about any actions that will need to be taken on the developer side. there is a wiki page at https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 that will be updated as more is known. Not in scope at this point is using kerberos for ssh or other apps supported by infrastructure, though it is not ruled out going forward. If you have any questions please respond here or in #fedora-releng on freenode Thanks Release Engineering and Infrastructure signature.asc Description: This is a digitally signed message part. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
