Kerberos: Bug or Feature ?
by Ralf Senderek
On the Cryptography mailing list (http://www.metzdowd.com/pipermail/cryptography/2018-May/034150.html)
a question came up, regarding Kerberos' ability to replace passwords in a secure way.
As John Gilmore pointed out, Kerberos on Ubuntu uses the outdated sha-1 hash, so I tried to find out
what Fedora does instead.
What I found confuses me.
In the directory /etc/krb5.conf.d you'll find a file named "crypto-policies" (which is a link actually) with the following
content:
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac
I thought that the entries under permitted_enctypes would limit the cipher-suite that would be acceptable by my
brand-new F28 installation. So I deleted everything except the two cipher-suites I want to allow and changed the
content of this file to:
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
The result (after a fresh reboot) was that authentication to FEDORAPROJECT.ORG shows that still the
sha1 ciphersuite is being used. The same applies to my old F26 installation.
$ klist -e
Ticketzwischenspeicher: KEYRING:persistent:1000:1000
Standard-Principal: senderek(a)FEDORAPROJECT.ORG
Valid starting Expires Service principal
10.05.2018 11:28:27 11.05.2018 11:25:08 HTTP/id.fedoraproject.org(a)FEDORAPROJECT.ORG
erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
10.05.2018 11:28:27 11.05.2018 11:25:08 HTTP/id.fedoraproject.org@
erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
10.05.2018 11:25:14 11.05.2018 11:25:08 krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG
erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Does anyone here know why the Kerberos crypto-policy does not do what it's supposed to do?
Ralf
5 years, 11 months
Review Wanted: boom-boot package
by Marian Csontos
Bug 1576413 - Review Request: boom-boot - boot manager
https://bugzilla.redhat.com/show_bug.cgi?id=1576413
This is relatively simple python3 package, with some gotchas:
- name: boom - it have been already in use in fedora, though the package
is now removed from distro.
- it is not only python3 library, but a CLI tool to manage /boot
entries. It will grow python2 RPM for F28 and EL-6, EL-7.
I am happy to swap review, but I am a newbie, so someone to review my
review would be still welcome.
-- Martian
5 years, 11 months
troubleshooting bluetooth
by Chris Murphy
Problem:
Bluetooth mouse often (every 5-20 minutes) stops working, then
recovers after maybe 30 seconds.
Event has three phases: working, not working, recovery (working). I
have set -d on bluetoothd, but all messages happen once recovery has
happened. There are no kernel messages at the time of disconnect.
https://paste.fedoraproject.org/paste/KV06205Dzeii9MijkQ7OSg/raw
The same thing happens with btmon, there's a 10 second gap. I'm not
sure what the cause of connection timeout is.
< ACL Data TX: Handle 512 flags 0x00 dlen 6
#10027 [hci0] 738.997867
Channel: 73 len 2 [PSM 0 mode 0] {chan 0}
43 47 CG
> HCI Event: Mode Change (0x14) plen 6 #10028 [hci0] 749.003523
Status: Connection Timeout (0x08)
Handle: 512
Mode: Active (0x00)
Interval: 0.000 msec (0x0000)
https://paste.fedoraproject.org/paste/11YsWOiY8UJJmTGQr0EMzg/raw
The same bluetooth mouse works on the same laptop booting Windows 10;
and it also works on a different laptop running macOS. So I'm not sure
what the next troubleshooting step is.
--
Chris Murphy
5 years, 11 months
libxc bump to version 4.1.1, license change LGPLv3 -> MPLv2.0
by Susi Lehtola
Hi,
I'm updating libxc to version 4.1.1 in rawhide. This comes with a soname
change, and will require rebuilds of dependent packages, which should go
smoothly.
The license changes from LGPLv3 to MPLv2.0 in the 4.1 series onward. The
library does not forbid secondary licensing, so it is still GPL compatible.
--
Susi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
5 years, 11 months
config.sub ppc64p7 optimization
by Pavel Raiskup
Hi all,
I have 'perl -pi -e "s/ppc64-\*/ppc64-\* \| ppc64p7-\*/" config.sub' hack in
%prep in some of my packages; without reference to any bug nor upstream
issue. My plan is to drop that hacks - especially in automake.spec which
transitively poisons all 'make dist' tarballs generated on Fedora boxes. The
proper way to do this is IMO:
- propose config.sub change upstream (gnuconfig)
- if any downstream fix is still needed, we should fix 'config.sub' in
redhat-rpm-config - that way any package using %configure automatically
replaces config.sub with fedora friendly version. It used to be done by
e0046a7a16feb5548a9264da, but it got reverted later...
Is that OK way of thinking? Anything new about ppc64p7?
Pavel
5 years, 11 months