|
| 1 | +From bb64c550ae19b08ad4e6d8d26f68c2474cb251e6 Mon Sep 17 00:00:00 2001 |
| 2 | +From: Stefan Metzmacher <metze@samba.org> |
| 3 | +Date: Tue, 19 Jul 2016 16:31:01 +0200 |
| 4 | +Subject: [PATCH] krb5_wrap: provide CKSUMTYPE_HMAC_SHA1_96_AES_* |
| 5 | +MIME-Version: 1.0 |
| 6 | +Content-Type: text/plain; charset=UTF-8 |
| 7 | +Content-Transfer-Encoding: 8bit |
| 8 | + |
| 9 | +MIT only defined this as CKSUMTYPE_HMAC_SHA1_96_AES128, |
| 10 | +while Heimdal has CKSUMTYPE_HMAC_SHA1_96_AES_128. |
| 11 | + |
| 12 | +Signed-off-by: Stefan Metzmacher <metze@samba.org> |
| 13 | +Reviewed-by: Günther Deschner <gd@samba.org> |
| 14 | +--- |
| 15 | + lib/krb5_wrap/krb5_samba.h | 11 +++++++++++ |
| 16 | + 1 file changed, 11 insertions(+) |
| 17 | + |
| 18 | +diff --git a/lib/krb5_wrap/krb5_samba.h b/lib/krb5_wrap/krb5_samba.h |
| 19 | +index 41664f1..2b5e2bb 100644 |
| 20 | +--- a/lib/krb5_wrap/krb5_samba.h |
| 21 | ++++ b/lib/krb5_wrap/krb5_samba.h |
| 22 | +@@ -74,6 +74,17 @@ |
| 23 | + #define CKSUMTYPE_HMAC_MD5 CKSUMTYPE_HMAC_MD5_ARCFOUR |
| 24 | + #endif |
| 25 | + |
| 26 | ++/* |
| 27 | ++ * CKSUMTYPE_HMAC_SHA1_96_AES_* in Heimdal |
| 28 | ++ * CKSUMTYPE_HMAC_SHA1_96_AES* in MIT |
| 29 | ++ */ |
| 30 | ++#if defined(CKSUMTYPE_HMAC_SHA1_96_AES128) && !defined(CKSUMTYPE_HMAC_SHA1_96_AES_128) |
| 31 | ++#define CKSUMTYPE_HMAC_SHA1_96_AES_128 CKSUMTYPE_HMAC_SHA1_96_AES128 |
| 32 | ++#endif |
| 33 | ++#if defined(CKSUMTYPE_HMAC_SHA1_96_AES256) && !defined(CKSUMTYPE_HMAC_SHA1_96_AES_256) |
| 34 | ++#define CKSUMTYPE_HMAC_SHA1_96_AES_256 CKSUMTYPE_HMAC_SHA1_96_AES256 |
| 35 | ++#endif |
| 36 | ++ |
| 37 | + typedef struct { |
| 38 | + #if defined(HAVE_MAGIC_IN_KRB5_ADDRESS) && defined(HAVE_ADDRTYPE_IN_KRB5_ADDRESS) /* MIT */ |
| 39 | + krb5_address **addrs; |
| 40 | +-- |
| 41 | +2.9.3 |
14 commit comments
grahamc commentedon Dec 21, 2016
Is it possible this breaks KDE? I ran git-bisect between this commit (tip of the release branch) and the channel's head (81428dd) and this one is the first bad commit.
Reverting this commit locally seems to have fixed it.
abbradar commentedon Dec 21, 2016
I think this is it, yes. Dolphin, Konsole and presumably other KDE applications don't start with this commit, and don't output any errors to std{out,err} either. No idea what happens (and a little frustrated that a miinor version bump could do that)...
abbradar commentedon Dec 21, 2016
Oh, they are just very slow for some reason. Investigating further...
abbradar commentedon Dec 21, 2016
Well, still no idea what happens. It works for me locally in a VM (but applications start very slow, though they seem to also start slow with this patch reverted -- general VM slowness?). Hydra test failure seems strange (it can't connect to VM but I cannot reproduce this). Locally the test fails to start Dolphin for me (it waits forever for its window to show up).
@ttuegel , maybe you have some ideas?
grahamc commentedon Dec 21, 2016
edolstra commentedon Dec 21, 2016
straceshows that Dolphin is spending a huge amount of time statting icons:On my system, the test does succeed after half an hour or so.
edolstra commentedon Dec 21, 2016
Fix pushed: 3fcbcf2.
grahamc commentedon Dec 21, 2016
ttuegel commentedon Dec 21, 2016
@edolstra This is a consequence of removing the KDE "symlink farms" in favor of extending☹️
XDG_DATA_DIRS. I removed them a while back after our conversation about the excessive size of the symlink farms. The consequence of this change is that every time a KDE application loads an icon, it searches every entry inXDG_DATA_DIRSfor that icon; there are potentially many entries, so this is very slow. And it's not just icons: translations, services... Unfortunately, I see no middle ground between "KDE applications occupy excessive disk space" and "KDE applications are horrendously slow".edolstra commentedon Dec 21, 2016
Maybe in NixOS, we can put
kde5.<app>.unwrappedinenvironment.systemPackages. That way we would have only one symlink tree (/run/current-system/sw), and KDE apps would still work when installed in different contexts by installingkde5.<app>.abbradar commentedon Dec 21, 2016
It's just my 2 cents and I don't even use KDE but I think that leaving things as they currently are is a bad idea, because applications are slow (I waited for a minute for Dolphin to start in a VM; I don't even want to start imagining how long it'd be on a spinning drive!). Using
/run/current-system/swalso feels problematic to me because this leads to namespace pollution, potential conflicts and (most of all) breaks install-as-a-regular-user. For example, I used stand-alone Okular for quite some time because it supports annotations, forms and other advanced PDF features. I moved to Zathura since then but requiring our users to install KDE system-wide to be able to use its apps seems wrong.How much did those symlink trees take?
vcunat commentedon Dec 22, 2016
My experience is usually several seconds on a 5.4krpm notebook drive.
abbradar commentedon Dec 22, 2016
See #21345 -- it turned out that on the host (no VM) times are much better (comparable to yours) for me, but we still can have a substantial improvement. I want to measure times for a VM later (also with symlink farms -- @ttuegel, can you push the patch you talked about somewhere?).
ttuegel commentedon Dec 22, 2016
@abbradar I pushed it to master just now. I thought it should go to master to help with the VM situation. Even if it isn't the whole solution to our problem, it's clear it will be part of the solution.