Bug#327233: Any movement on this?
Micah == Micah Anderson [EMAIL PROTECTED] writes: Micah Hi, Micah I'm just sending a ping to find out if there has been any Micah movement on this issue. I continue to believe that this is not a security issue and that openssh is wrong to have applied the patch. That doesn't answer the question you asked (Russ has been working on that, not I) but it does argue that perhaps this is not an issue for testing security. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
does your platform support weak symbols? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Michael == Michael Banck [EMAIL PROTECTED] writes: Michael On Thu, Dec 01, 2005 at 05:51:16PM +0100, Michael Banck Michael wrote: I am not sure whether all the Makefile.in's should be modified to have $PTHREAD_LIBS added to the link lines in case the library uses pthread functions (or their k5_ equivalents) or whether we could get away with some hack like [EMAIL PROTECTED]@ @PTHREAD_LIBS@ in config/pre.in, or something system-specific along the aix/hp-ux cases in configure.in, so I am not submitting any patches at this point. Michael As a data point, I successfully built the package by Michael adding @PTHREAD_LIBS@ to the LIBS= line in Michael src/config/pre.in. However, this also means that Michael ldd/objdump shows libpthread dependencies on all the Michael binaries I looked at during a quick check. Right and that would be very bad for Debian. You need to figure out why there are not weak references. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341608: krb5: FTBFS on hurd-i386: Does not link with -lpthread
Michael == Michael Banck [EMAIL PROTECTED] writes: Michael On Thu, Dec 01, 2005 at 01:02:29PM -0500, Sam Hartman Michael wrote: does your platform support weak symbols? Michael Yes, it does. OK. those references should be weak but were not for some reason. I'm not going to be able to debug this because I don't have time and don't have a hurd machine. I'd recommend looking at why the symbols are not being considered weak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307908: openafs-modules: taints kernel
Brian == Brian May [EMAIL PROTECTED] writes: Brian My understanding is this should only happen for closed Brian source modules, and I believe openafs-modules-source is Brian open source. This happens for any non-GPL module. OpenAFS is definitely not GPL although it is open-source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225907: Build failure on Alpha with 2.4.23
So, there are local changes having to do with that test. I forget why, but the sitution is annoying. I'd recommend buinging the alpha kernel with modversions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
xsdg == xsdg [EMAIL PROTECTED] writes: xsdg First, I would appreciate if a warning of some sort showed xsdg up in debconf -- I tend not to look under /usr/share/doc/ xsdg unless I feel I need information in the first place. I believe this would be against debconf policy or would at least be somewhat sketchy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309448: OpenAFS 1.3.81, SMP kernel, make-kpkg
Hi. I have not been paying attention to this issue as much as I would like. Just as an FYI, I'm running 1.3.81 on an SMP powermac g5 with no build or run problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309439: ssh-krb5: .k5login breaks password login
Are you using pam_krb5 for password logins? If so, pam_krb5 also respects .k5login, so it is a feature not a bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276189: OpenAFS and user-mode-linux
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Sam Hartman [EMAIL PROTECTED] writes: So, I agree that we definitely need to support building targeted at /usr/lib/uml. I also believe you need to set up the other way. Russ Ah, now I understand your concerns. Russ How about this: What if having ARCH set to uml changed the Russ sysname, the build infrastructure, the package name, and the Russ recommended kernel image, and one had to set a separate Russ variable (DEBIAN_UML_PATHS, perhaps) to have the kernel Russ module install in /usr/lib/modules? That would let one put Russ the kernel modules in the same place as the Debian package Russ if desired, with a bit of additional hassle, while having Russ other builds produce packages that behave like other module Russ packages and could be installed in the guest OS. I'd be happy with this. I'd be ecstatic about this solution if kernel-package or the TC blessed it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341898: krb5: block migration to testing for now
Russ, how do you feel about the thread on c.p.kerberos about the mutex lock on debian? That seems rather bothersome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#200342: Ideas about #200342? (krb5_locate_kdc is an internal symbol with a incompatible prototype)
Christian == Christian Perrier [EMAIL PROTECTED] writes: Christian Has anyone around an idea about bug #200342. Given its Christian age, it may be over for a very long time. Christian However, I'm completely lacking the required skills to Christian investigate it. Upstream has not exposed an API for this. You could get the prototype to be correct and it would continue to work until upstream makes changes in that area. I do expect more changes to kdc location soon. My preference is to disable this functionality as it does not seem critical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341836: openafs-modules-source: Bug#245015 still valid: Build fails with KSRC defined on commandline
KSRC is not a environment variable, it is a make variable.
So, I'd expect
debian/rules KSRC=foo kdist_image to work
but not
KSRC=foo debian/rules kdist_image.
There's really no harm in making it be an environment variable; I can
replace $(KSRC) with ${KSRC} in debian/rules. Please confirm that
fixes your problem and I'll upload the change and close the bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344190: Please enable gssapi support
package: cvs severity: wishlist Hi. The kerberos libraries are at priority standard and are in a lot of dependency chains. I don't think there is any good reason not to enable gssapi support in cvs. It would be very convenient for some of us. All that needs to happen is: * add libkrb-dev to build-dependes and remove from build-conflicts * replace without-gssapi with with-gssapi in the configure line I'd recommend against adding a new krb4 application in Debian at this time, so I would not turn on krb4. We are trying to convince people to retire krb4 in favor of gssapi and krb5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276189: OpenAFS and user-mode-linux
The part that really does not seem reasonable to me is installing the modules in /usr/lib/uml. It seems that for different configurations you want a module to be installed in the hosted os vs the hosting OS. It seems that you need to support both and the default is unclear to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344543: libkrb53: double free + cache corruption if krb5_get_credentials fails
Can you reproduce with kvno? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276189: OpenAFS and user-mode-linux
That's certainly where uml puts the modules for the uml kernel in Debian. It's not in general where the modules would end up if you build your own kernel. Also, ultimately, the modules end up needing to be accessed within the uml image. I don't see why you wouldn't often want to install a module package in the guest OS and then just use modprobe. So, basically, I agree that for the single debian uml kernel you do tend to want to end up with modules in /usr/lib/uml. However for anything else, I think it matters significantly what you are doing and how you are setting up your guest OS. So, I agree that we definitely need to support building targeted at /usr/lib/uml. I also believe you need to set up the other way. This is really an issue where I'd like the TC to come up with reasonable policy because doing something else for openafs seems undesirable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344543: libkrb53: double free + cache corruption if krb5_get_credentials fails
OK. I think we've linked this to an upstream bug. I think we already have a patch. Let me confirm that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332479: ssh-krb5: 15-second delay connecting to non-kerberos host
Sounds like your system thinks it can get tickets for the non-kerberos host, but some kdc is hanging somewhere. You could edit your krb5.conf either to add a domain realm mapping so the non-kerberos machine is in some obviouly bogus realm. Alternatively you could make sure that the kdc information is correct. In all probability you are hanging on some broken dns server. Either way, this doesn't sound like a bug in ssh-krb5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329686: Processed: Re: Bug#329686: FTBFS: fails to detect libkrb5
Hi. I cannot reproduce this. My desktop is a powerpc machine and I build all my packages (including ones that depend on krb5) on it just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329686: Processed: Re: Bug#329686: FTBFS: fails to detect libkrb5
Martin == Martin Pitt [EMAIL PROTECTED] writes: Martin Hi Sam! Sam Hartman [2005-10-09 16:56 -0400]: Hi. I cannot reproduce this. My desktop is a powerpc machine and I build all my packages (including ones that depend on krb5) on it just fine. Martin Odd. Then why is postgresql-8.0 on powerpc building fine Martin on Ubuntu, but not on the Debian buildds? Do you happen to Martin use a locally built krb5 package on your desktop? Nope. I seem to be running 1.3.6-5, which since it was uploaded by my co-maintainer not me means I'm using a version built on the buildds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315059: Drop KRB4 support from HEIMDAL
Does the krb524 functionality disappear from the KDC if you turn off krb4? If so, that will be a problem for current openafs, although probably not for future openafs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340360: libapache2-mod-auth-kerb: GSSAPI fails with Request is a replay under krb5 1.4.3
Be aware that there is special code to try and disable the replay cache in mod-auth-kerb; it may interact badly with changes in krb5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340360: libapache2-mod-auth-kerb: GSSAPI fails with Request is a replay under krb5 1.4.3
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Sam Hartman [EMAIL PROTECTED] writes: Be aware that there is special code to try and disable the replay cache in mod-auth-kerb; it may interact badly with changes in krb5. Russ I must say that it's tempting to just set KRB5RCACHETYPE to Russ none. Alas, that's probably a bad idea in an Apache Russ module due to the annoying global and inherited nature of Russ environment variables. I would be very tempted to just do that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394519: openafs-modules-source: Cannot authenticate to my cell - pioctl failed
tags 394519 moreinfo severity 394519 normal thanks Hi. Can I get you to try upgrading your openafs-client? Also, can I see the messages displayed in dmesg when openafs loads? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400955: base64 problems authenticating using gssapi
package: libsasl2-modules-gssapi-mit severity: grave justification: package seems not to work at all I get a base64 error authenticating to a system that works fine with a previous version of sasl. To reproduce: apt-get install krb5-user kinit [EMAIL PROTECTED] password: foobarbaz apt-get install cyrus21-clients imtest -m gssapi -u hartmans imap.suchdamage.org You get a base64 decoding error. With the old sasl you should get an authentication failure because testprinc is not allowed to read my mail. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400955: base64 problems authenticating using gssapi
Fabian == Fabian Fagerholm [EMAIL PROTECTED] writes: Fabian On Wed, 2006-11-29 at 15:08 -0500, Sam Hartman wrote: I get a base64 error authenticating to a system that works fine with a previous version of sasl. To reproduce: Fabian [...] You get a base64 decoding error. With the old sasl you should get an authentication failure because testprinc is not allowed to read my mail. Fabian Thanks for the report! Fabian I don't have a Kerberos system to test against right Fabian now. Could you try to pinpoint what's going on here? More Fabian detailed error messages, straces, anything that might help Fabian narrow down where the failure occurs. I'll be happy to try and debug but my time is incredibly limited right now. So, that's why I I did give you a principal and password and sufficient installation instructions to trivially set up a case to reproduce on any Debian box on the open internet. I don't mind if people trying to fix this bug attempt to use my server. I'll delete [EMAIL PROTECTED] after the bug is closed. Since this is a base64 error, I suspect it's probably in the base sasl library not in the gssapi module. I really have only dug around in the guts of Cyrus SASL's GSSAPI module, not the protocol handling etc. That or memory corruption. Fabian Also, what about the case when the authentication should Fabian succeed? Does it succeed or do you get some similar, Fabian unexpected error? Sorry. I really did file a crappy bug report. You get the same base64 error with the new sasl, but you get success authenticating with the old SASL. I believe that the old SASL is correct; using implementations like pine, Apple's mail.app, which are not based on cyrus-sasl also work against imap.suchdamage.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491774: setting package to krb5 krb5-admin-server krb5-user libkrb5-dbg krb5-pkinit libkrb5-dev krb5-kdc-ldap krb5-kdc krb5-rsh-server krb5-ftpd krb5-clients krb5-doc krb5-telnetd libkadm55 libkrb
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # krb5 (1.6.dfsg.4~beta1-4) UNRELEASED; urgency=low # # * Translation updates: #- Swedish, thanks Martin Bagge. (Closes: #487669, #491774) #- Italian, thanks Luca Monducci. (Closes: #493962) # package krb5 krb5-admin-server krb5-user libkrb5-dbg krb5-pkinit libkrb5-dev krb5-kdc-ldap krb5-kdc krb5-rsh-server krb5-ftpd krb5-clients krb5-doc krb5-telnetd libkadm55 libkrb53 tags 491774 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494378: gnome-orca: Fails to read Open office writer styles and formatting panel
Package: gnome-orca Version: 2.22.2-1 Severity: normal Hi. Feel free to reassign to openoffice.org-writer or to jointly assign to gnome-orca and the other package. Upstmream at least seems to have a number of bugs about accessibility of various packages, but I can't tell how you want to handle it for Debian. Gnome-orca cannot read the styles and formatting panel in Open Office. As a result you cannot add a style, apply styles to text, etc. That makes it basically impossible to use opennofice.org-writer in a professional context. As far as I can tell the problem is that the widgets in question simply are not accessible. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (40, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-orca depends on: ii libgail-gnome-module 1.20.0-1GNOME Accessibility Implementation ii libgnome-speech7 1:0.4.19-1 GNOME text-to-speech library ii python 2.5.2-1 An interactive high-level object-o ii python-brlapi3.10~r3724-1+b1 Python bindings for BrlAPI ii python-glade22.12.1-6GTK+ bindings: Glade support ii python-gnome22.22.0-1Python bindings for the GNOME desk ii python-gtk2 2.12.1-6Python bindings for the GTK+ widge ii python-pyatspi 1.22.1-1Assistive Technology Service Provi ii python-support 0.8.4 automated rebuilding support for P Versions of packages gnome-orca recommends: ii gnome-mag 1:0.15.0-1 a screen magnifier for the GNOME d ii wget 1.11.4-1 retrieves files from the web gnome-orca suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494381: gnome-orca: gnome-terminal script has no way to move focus to cursor
Package: gnome-orca Version: 2.22.2-1 Severity: normal A lot of terminal applications have interesting things going on around the cursor. However there's no way once you have moved away from the cursor to ask Orca to get back. Every other screen reader I've used had this feature. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (40, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-orca depends on: ii libgail-gnome-module 1.20.0-1GNOME Accessibility Implementation ii libgnome-speech7 1:0.4.19-1 GNOME text-to-speech library ii python 2.5.2-1 An interactive high-level object-o ii python-brlapi3.10~r3724-1+b1 Python bindings for BrlAPI ii python-glade22.12.1-6GTK+ bindings: Glade support ii python-gnome22.22.0-1Python bindings for the GNOME desk ii python-gtk2 2.12.1-6Python bindings for the GTK+ widge ii python-pyatspi 1.22.1-1Assistive Technology Service Provi ii python-support 0.8.4 automated rebuilding support for P Versions of packages gnome-orca recommends: ii gnome-mag 1:0.15.0-1 a screen magnifier for the GNOME d ii wget 1.11.4-1 retrieves files from the web gnome-orca suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494380: gnome-orca: Fails to deal with gnome-segv
Package: gnome-orca Version: 2.22.2-1 Severity: normal When a Gnome application segfaults and causes gnome-segv to be lunched, orca hangs until gnome-segv is killed. It's particularly bad because it hangs for all applications, not just the one the segfaulted. This is a fairly serious usability issue because the entire session locks up. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (40, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-orca depends on: ii libgail-gnome-module 1.20.0-1GNOME Accessibility Implementation ii libgnome-speech7 1:0.4.19-1 GNOME text-to-speech library ii python 2.5.2-1 An interactive high-level object-o ii python-brlapi3.10~r3724-1+b1 Python bindings for BrlAPI ii python-glade22.12.1-6GTK+ bindings: Glade support ii python-gnome22.22.0-1Python bindings for the GNOME desk ii python-gtk2 2.12.1-6Python bindings for the GTK+ widge ii python-pyatspi 1.22.1-1Assistive Technology Service Provi ii python-support 0.8.4 automated rebuilding support for P Versions of packages gnome-orca recommends: ii gnome-mag 1:0.15.0-1 a screen magnifier for the GNOME d ii wget 1.11.4-1 retrieves files from the web gnome-orca suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494378: Hmm, works better than I thought
so, I had openoffice.org open today and noticed that it actually seems to be trying to read the styles and formatting panel now. I thought I had tried it on another system after doing a full upgrade to lenny a few days ago. However, it's definitely working on my laptop better than it has been in the past. I have recently upgraded my laptop which is probably the cause. I don't have time now to confirm everything is working, but I may close this bug in a day or so as user error. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495056: barnowl: embedding perl needs PERL_SYS_INIT3()
Ah, I understand now. Thanks so much for the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495733: setting package to krb5 krb5-admin-server krb5-user libkrb5-dbg krb5-pkinit libkrb5-dev krb5-kdc-ldap krb5-kdc krb5-rsh-server krb5-ftpd krb5-clients krb5-doc krb5-telnetd libkadm55 libkrb
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # krb5 (1.6.dfsg.4~beta1-4) unstable; urgency=low # # * Translation Updates: # - Dutch, Thanks Vincent Zweije, Closes: #495733 # package krb5 krb5-admin-server krb5-user libkrb5-dbg krb5-pkinit libkrb5-dev krb5-kdc-ldap krb5-kdc krb5-rsh-server krb5-ftpd krb5-clients krb5-doc krb5-telnetd libkadm55 libkrb53 tags 495733 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487113: Limited scope
package barnowl severity 487113 important thanks It turns out this bug is only effecting two users, and happens fairly rarely so it is not RC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451867: emacspeak: fails to find url load file; install fails
Package: emacspeak Version: 26.0-1 Severity: serious emacs21 -batch -q -no-site-file -eval '(setq vc-handled-backends nil)' -l /usr/share/emacs21/site-lisp/emacspeak/lisp/emacspeak-load-path.el -l /usr/share/emacs21/site-lisp/emacspeak/lisp/emacspeak-loaddefs.el -l /usr/share/emacs21/site-lisp/emacspeak/lisp/emacspeak-cus-load.el -f batch-byte-compile emacspeak-url-template.el While compiling toplevel forms in file /usr/share/emacs21/site-lisp/emacspeak/lisp/emacspeak-url-template.el: !! File error ((Cannot open load file url)) Perhaps you meant to depend on w3-url-e21? -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable'), (200, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages emacspeak depends on: ii emacs21 21.4a+1-5.1 The GNU Emacs editor ii emacsen-common 1.4.17 Common facilities for all emacsen ii make 3.81-3 The GNU version of the make util ii perl 5.8.8-12Larry Wall's Practical Extraction ii tcl8.4 8.4.16-3Tcl (the Tool Command Language) v8 ii tclx8.4 8.4.0-1 Extended Tcl (TclX) - shared libra emacspeak recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311689: ssh-krb5: protocol error talking to Solaris 10 sshd
I'm not really sure either side is at fault here. It seems like you're failing to get credentials for host/[EMAIL PROTECTED] for some reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311574: krb5-config: package config script chokes on hyphens in krb5.conf keys
I will do this. Thanks for the report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311772: pam_unix.so: logs unknown usernames, thus possibly logging passwords typed too early
That's certainly not how it should work Are you sure you are not using the audit option to pam_unix? Without that option I see: Jun 3 13:59:06 cz login[4777]: (pam_unix) check pass; user unknown Jun 3 13:59:06 cz login[4777]: (pam_unix) authentication failure; logname=hartmans uid=0 euid=0 tty=pts/2 ruser= rhost= Jun 3 13:59:10 cz login[4777]: FAILED LOGIN (1) on `pts/2' FOR `UNKNOWN', User not known to the underlying authentication module Jun 3 13:59:11 cz login[4777]: (pam_unix) bad username [] (Note that logname=hartmans refers to the logname in the environment of login, *not* to the unknown user I tried to log in as.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292837: pam: Please use a newer version of Berkeley DB
I'm happy to move to db4 post-sarge if the upgrade issues are dealt with. The problem is that if you are using userdb (which I don't think is used often), logins will fail until your database is converted. Your database will not be in a particularly standard place so postinst will not be able to easily find it. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296331: openafs-modules-source: I made the modules_image but when installing it complains:
Typically this means your kernel sources do not match the kernel you are actually running. OTher possible problems include a mismatch in module utilities, compilers etc. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295887: openafs-client: minor bug in init.d startup script
This patch looks broken. Are you sure you actually have the openafs client enabled on your system? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
severity 300775 wishlist tags 300775 -security thanks Hi. I've explicitly decided not to upgrade PAM for sarge. I had also decided when 0.77 came out that I didn't see a good reason to take it. Taking a new pam release is a painful process. That said, I'm looking for people to help with PAM. Would you be interested? Are you familiar with pam enough to help try and merge in a new release? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300904: ssh-krb5: writes an error messgae: free(): invalid pointer 0x80688ab!
Interesting. I don't see this at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300823: libpam-modules: pam_mail module prevents login with blocked NFS
Matt == Matt Johnston [EMAIL PROTECTED] writes: Matt The pam_mail module attempts to perform stat() of the mail Matt location. If the mail location is NFS mounted and that Matt server is unavailable, logins as any user (root included) Matt will hang indefinitely (hampering attempts to umount the NFS Matt mount etc). Matt A solution would probably be alarm(10); before the stat() Matt call in pam_mail.c I'm a bit concerned by having a library muck with signal handling state, but I agree this is probably the best that can be done. I'd be happy to look at a patch for this; I doubt I'll get to it myself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300823: libpam-modules: pam_mail module prevents login with blocked NFS
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve On Sat, Mar 26, 2005 at 08:34:59PM -0500, Sam Hartman Steve wrote: Matt == Matt Johnston [EMAIL PROTECTED] writes: Steve It seems to me that it would be better to fix this in the Steve mount options for the NFS mount in question... Hmm. Actually, will a signal even interrupt an NFS read? It may well be that is the only solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297781: openafs: OpenAFS 1.3.79 release, supposedly fixes many Linux 2.6 bugs, 1.3.75 doesn't compile under 2.6.11
I have 1.3.79 packages at svn://ia.mit.edu/openafs/branches/experimental I need to work out some last details and upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297585: openafs-modules-source: fails to build with bison grammar error
tags 297585 woody -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298920: please make libkrb53 priority 'standard', since nfs-utils depends on it
Jeroen == Jeroen van Wolffelaar [EMAIL PROTECTED] writes: Jeroen On Thu, Mar 10, 2005 at 12:50:35PM -0500, Chip Salzenberg Jeroen wrote: Package: ftp.debian.org Severity: normal The current unstable nfs-utils (1.0.7-1) builds nfs-common to depend on libkrb53 for NFSv4 support. Since nfs-common is priority 'standard', libkrb53 should also be at least priority 'standard'. Jeroen I just changed libevent1 and libkrb53 to standard on Jeroen request of Steve Langasek. I'd like to express my reservations about having nfs-utils depend on krb5. Prior to MIT Kerberos 1.4 there is no public interface for extracting the gss context information nfs-utils needs from a Kerberos gss context. AS such, nfs-utils uses internal structures of MIT Kerberos subject to change without notice. Especially since I wasn't talked to before this happens I'm going to have fairly limited sympathy if changes in krb5 break nfs-utils. There is a public interface added for the benefit of nfs-utils in MIT Kerberos 1.4. Unfortunately I'd recommend against taking 1.4 at this time. First, it would require a shlib bump. Second, it's proven to be a relatively unstable release; 1.4.1 is much better but not out yet. In practice this would only be a problem if I needed to backport some upstream fix to 1.3.x and so it's probably not that big of an issue. However I think it is generally a good idea to talk to a maintainer before depending on unpublished internal interfaces of their package that have been known to change frequently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289358: Delete principal file upon purge
Jan-Benedict == Jan-Benedict Glaw [EMAIL PROTECTED] writes: Jan-Benedict If you're not keen with that, maybe doing it like Jan-Benedict postgres would do: debconf there asks if you want to Jan-Benedict keep the database files even at real purge time... That works for me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
Javier == Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Javier On Thu, Mar 24, 2005 at 08:49:01PM -0500, Sam Hartman Javier wrote: severity 300775 wishlist tags 300775 -security Javier ^ Why this? PAM 0.76 is indeed Javier vulnerable to the issues fixed in 0.78 Someone pointed out in mail to this bug that Debian is not vulnerable to these issues because of local patches. Hi. I've explicitly decided not to upgrade PAM for sarge. I had also decided when 0.77 came out that I didn't see a good reason to take it. Taking a new pam release is a painful process. Javier Yes, it might be painful, but fixing bugs is also Javier important and these releases are primarily bug-fix Javier releases. That said, I'm looking for people to help with PAM. Would you be interested? Are you familiar with pam enough to help try and merge in a new release? Javier I can help out, I am not extremely familiar with PAM but Javier wouldn't mind jumping in and helping you with this Javier release. Since sarge's base is frozen maybe an upload to Javier experimental with 0.78 plus patches would be best right Javier now and have it move into sid as soon as sarge is PAM is maintained in a subversion repository on alioth. I can give you write access to that repository if you're sufficiently familiar with subversion etc. I'd recommend importing PAM 0.78's upstream and then looking at each of the debian local patches and seeing whether they should be maintained, dropped or modified.
Bug#300823: libpam-modules: pam_mail module prevents login with blocked NFS
Matt == Matt Johnston [EMAIL PROTECTED] writes: Matt On Mon, Mar 28, 2005 at 06:30:28PM -0500, Sam Hartman wrote: Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve It seems to me that it would be better to fix this in the Steve mount options for the NFS mount in question... Hmm. Actually, will a signal even interrupt an NFS read? It may well be that is the only solution. Matt The nfs(5) manpage implies that it will interrupt when Matt signalled if mounted with the 'intr' option. I don't believe Matt that mounting with 'soft' would be desirable (the mount(8) Matt manpage advises against it), so the alarm() would still be Matt needed? I think that applies to the mount not to operations against the mount. I can see Steve's point here though; we don't want to add nfs-specific logic to everything. Arguably the filesystem should be responsible for presenting a usable interface in the case of network problems. However I can see your point from a practical standpoint. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298920: please make libkrb53 priority 'standard', since nfs-utils depends on it
Chip == Chip Salzenberg [EMAIL PROTECTED] writes: Chip According to Sam Hartman: However I think it is generally a good idea to talk to a maintainer before depending on unpublished internal interfaces of their package that have been known to change frequently. Chip I packaged nfs-utils, but had little to do with the coding. Chip I assumed that the upstream NFS maintainers (of which I am Chip one only in the most technical sense) knew what they were Chip doing. Apparently they were interested in immediate Chip functionality and were willing to take the hit when the APIs Chip they are using change. So, no worries. -- Chip Salzenberg Chip - a.k.a. - [EMAIL PROTECTED] Open Source is not an excuse to Chip write fun code then leave the actual work to others. I've been thinking about this more. I think that the current state is OK provided you're ready to work with me in a post-sarge transition to krb5 1.4. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
I hate to be a pain in the ass, but it is going to be very difficult for me to take a huge .diff.gz that applies all the debian patches. That's hard to audit, hard to understand and not well documented. I'm happy to give you access to the repository so you can work on a branch and try to get things in shape, but you'll need to make reasonably small commits with good commit logs. I want to make it clear that I do appreciate the effort you've put in. However I think having pam work is critical and so I think we need to work on the package using good software engineering methodology. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303944: openafs-client: please mention configuring chunksize
The upstream rc file and config file actually auto-detect a reasonable configuration. It would be neat if someone merged those changes back to the debian packages. I can't just use the upstream rc script because it tries to load the kernel module manually rather than using modprobe and found that not to work as well as one might like. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304040: openafs-client: fails to stop afs-client
Hi. Again, it works for me. Hopefully we'll find some more people that have this problem and we can start to understand why it works on some machines and not others. My machine is a ppc64 box; I see you are running i686. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305298: ssh-krb5: password authentication does not use pam
I'd certainly expect pam to be used for all password validation. If that's not true please give me info on how to reproduce. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305389: Fwd: Bug#305389: bad argument to modprobe for SMP kernel in /etc/init.d/openafs-client script
I'm thinking this may be a csail-specific lossage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244754: Should we arrange the move of limits.conf(5) to libpam-modules?
No, there is not a limits.conf manpage in pam upstream; there is a readme that could become a manpage. If that happened, dropping limits.conf from shadow would be useful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203222: libpam-modules: Can't change expired password with NIS
Understood. I am sorry that NIS is so broken. I just don't have time to support NIS. I do believe upgrading to 0.78 post-sarge is important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304933: openafs-krb5: FTBFS: asetkey.c:80: error: too few arguments to function `afsconf_AddKey'
Andreas == Andreas Jochens [EMAIL PROTECTED] writes: Andreas This bug can now be reproduced in a current i386/testing Andreas environment (openafs version 1.3.81-3 is now in sarge). Oops yeah. This is not so good. I will need to deal with this post haste. I should get to it in the next day or so. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305389: Fwd: Bug#305389: bad argument to modprobe for SMP kernel in /etc/init.d/openafs-client script
I'm expecting Karl to deal with this bug. He has a strong interest in making this work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#88906: /afs goes ENOTDIR eventually, on first client+server install before reboot
Russ, I'm fairly sure this hasn't been fixed. It was discussed recently on zephyr. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307555: krb5-config: need default_keytab_name in libdefaults section
I don't understand why this is needed. That's fairly clearly the default keytab that sshd will use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#275472: Support for kerberos in ssh
I'd like to ask that you not enable gssapi support for the ssh package. The problem is that there is a key exchange method that has not yet been accepted upstream that you probably want if you want Kerberos support. Having the ssh package do some but not all of the desired Kerberos support would be confusing to users. I'm not sure I know of anyone working on getting this patch accepted upstream. All the involved parties are just too busy. The other option is to maintain the key exchange patch as a Debian local patch. I think that's something to consider for the sarge+1 time frame, but I'd rather see how bad the openssh 3.9 port is before deciding it will be easy to do and actually trying to convince you that you want to maintain a patch that large.;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290405: confusing error message in log when ssh as root with no passwd
Brian == Brian Sammon [EMAIL PROTECTED] writes: Brian The bug reported in #248133 appears to have resurfaced, and Brian since I'm too late to reopen it, here goes: When I try to Brian ssh into the machine as root when root has no password (and Brian shadow passwords are disabled), the error in the logfile is Brian (pam_securetty) access denied: tty 'ssh' is not secure Brian and gives no hint that the error is occuring because the Brian root password is not set. This is not the same as #248133. IN that bug, there was an error logged even though there was a password set. In your configuration the error is actually correct. If you were logging in from a secure terminal, you would be allowed in even without a password since no password is set for the user. It is the tty check that is preventing your login. Compare the behavior if you change nullok_secure to nullok in /etc/pam.d/common-auth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290807: Please conflict with old perl libs
package: libsvn0 severity: serious justification: breaks other software version: 1.1.1-2 Please conflict with the 1.0.9 libsvn-core-perl. In practice it does not work with this version of the library. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296835: openafs-modules-source: Fails to build with kernel-source-2.6.10
svn://ia.mit.edu/svn-debian/openafs/branches/experimental contains packages that work against 2.6.10. I'm not happy with the server packages; there is a horrible bug that tends to take out windows clients in sufficiently large cells. I'm not sure whether I'm going to upload these packages. - --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439039: libkrb5-dev: libkrb5.a missing in newer packages
Andrew == Andrew Gray [EMAIL PROTECTED] writes: Andrew Package: libkrb5-dev Version: 1.6.dfsg.1-6 Severity: Andrew important Andrew The 1.6 versions of libkrb5-dev do not include libkrb5.a. Yes. It's going to be really challenging to fix this. Upstream basically does not support building static libraries and depends on plugins. It's not entirely clear how the plugins would be able to get to symbols in libkrb5.a if it were provided. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435427: krb5-config: add master_kdc and domain_realm mapping
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Package: krb5-config Version: 1.17 Severity: normal Russ With MIT Kerberos 1.6, sometimes odd things happen if one Russ doesn't have a domain_realm mapping for the local realm in Russ places where things previously worked. We also don't want Russ to rely on DNS for the realm mapping if we can avoid it. Russ Perhaps when referrals are fully there, this won't be Russ needed, but in the meantime I think it makes sense to prompt Russ the user for a domain_realm mapping. I really think this sounds like a bad idea. Can we discuss things that break but that worked previously. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435427: krb5-config: add master_kdc and domain_realm mapping
OK. A lot of this looks like issues finding the right key for a service key. It seems like fixing the library code there is a better fix than including a domain_realm entry. In particular how much of r19598 would help? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444938: pkinit does not belong in libkrb53
Yeah. I'm expecting the upstream 1.6.3 release today or tomorrow. I can upload that with a new package for pkinit and that will close this bug. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444938: pkinit does not belong in libkrb53
package: libkrb53 severity: serious version: 1.6.dfsg.3~beta1-1 This version should not move into testing until pkinit.so moves into a package other than libkrb53. Probably the README needs to be updated as well. I expect to make an upload in a week or so that moves pkinit into its own package; once that clears new this bug goes away. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423679: dpkg-dev: dpkg-shlibdeps fails when libraries of multiple architectures are in the path
Hi. I just wanted to acknowledge that I had received your mail and will reproduce on current i386 or close the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445063: krb5-config: default realm detection through DNS?
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve Package: krb5-config Version: 1.17 Severity: minor Steve The krb5-config package chooses a default value for the Steve host's default realm based on the output of the Steve dnsdomainname command. Steve This is not always the correct value. Steve http://tools.ietf.org/id/draft-ietf-krb-wg-krb-dns-locate-02.txt, Steve which AIUI is the same draft that specifies the Kerberos Steve SRV records, describes how to declare a Kerberos realm for Steve a given domain name using a TXT record. Actually, no. That's a dead, expired draft. The SRV records are specified by RFC 4120. Steve If such a text Steve record is available that matches the hostname, would it be Steve reasonable for krb5-config to use this value as a default Steve instead of the dnsdomainname? I think so. Especially in something that was only executed once. Note that the default realm of a host doesn't really have to do so much with the domain realm mapping. The draft you cite is actually more discussing domain realm mapping although I do believe it tries to conflate in default realm. However assuming that default realm and domain realm mapping happen to work out to be the same is a good initial guess. Before MIt Kerberos 1.6 the default realm was reasonably unimportant from a security standpoint. However I'd want to redo the analysis because the referrals code may change this. Either way I think making that guess in krb5-config would be a fine idea. I'm not sure how to do that only with essential packages though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445063: krb5-config: default realm detection through DNS?
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ SRV records can pose similar problems, but people don't seem Russ as worried about them. I'm not sure if that's because the Russ analysis of what an attacker can do with a SRV record is Russ less confusing or just because SRV records are very useful Russ and widely used. At least in the case of Kerberos, there is no security problem with the SRV record. All KDCs in a given realm are trusted the same level. The SRV record lets you find the KDCp. However you can make sure it is the right KDC because you and that KDC share a secret. It's potentially possible that someone spoofing DNS could cause you to try and authenticate to the wrong KDC. That would give the attacker an opportunity to mount a dictionary attack against your password. However if your password is strong, the attacker should not get a significant advantage from this. The TXT records are more dangerous. Especially in situations where you have a cross-realm relationship with not very trusted realms it can open up significant attacks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445059: krb5-config: please autodetect krb5 SRV records and suppress debconf question
Again, do you know how to do this with essential packages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445059: krb5-config: please autodetect krb5 SRV records and suppress debconf question
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Sam Hartman [EMAIL PROTECTED] writes: Again, do you know how to do this with essential packages? Russ I'm fairly sure that you can't without something really Russ scary like a compiled preinst. I expect you'd need to Russ pre-depend on at least bind9-host. Or move the Russ configuration to postinst, but that's kind of eh. I didn't think pre-depends were satisfied at configure time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Interesting. Do you end up getting tickets for the host service or just a tgt? Is any error logged on the Kerberos KDC? Does the sasl sample pass the hostname into the sasl library? Many mechanisms such as digest-md5 and cram-md5 will mostly work without a hostname passed in, but gssapi requires it. I rather assume the sample got that right because I'd actually expect that CMU often tests with gssapi. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404365: RFC 4380 advice to improve reliability of Teredo relays breaks clients behind Linux NATs in common configurations
package: miredo severity: important version: 1.0.4-1 Tags: upstream justification: Debian's Teredo implementation does not particularly work with Debian's NAT implementation [I've copied the Miredo author because this really seems more an upstream issue than an Debian issue. I've copied Christian because he may find this interesting and because he may want to consider what the appropriate implementation advice is for future implementations.] Section 5.4.1 of RFC 4380 suggests that to improve reliability Teredo relays MAY send a bubble directed at the mapped IPV4 address even when they do not believe they are behind a non-cone NAT. Unfortunately, if you have a client behind a Linux NAT and you receieve a bubble to the mapped IPV4 address before the client sends the bubble towards the relay, then Linux allocates the wrong mapped port, and the bubble sent to the relay is rejected because its mapped port does not match the teredo address. If you do not send the bubble to the mapped IPV4 address then things work fine. As a consequence, getting clients behind Linux NATs to work with relays behind non-cone NAT is challeging. I think the best you can do is wait to send the bubble to open your side of the NAT until the client has sent its bubble. If you're both behind Linux, well, you didn't really want connectivity did you? Proposed solution: Miredo should gain an option to suppress the optional bubble to the mapped IPV4 address when the cone bit is clear and the relay is not behind a NAT. We may want to consider whether the advice in RFC 4380 should be qualified with an explanation about this problem. Someone should yell at the Linux ip_conntrack people until they suck les. I really don't know how to report Linux kernel bugs effectively so I'd appreciate help with that part. Details: Linux uses ip_conntrack to track connection state . This connection state is used for NAT bindings among other things. Consider a simple Linux NAT with the following rule in the nat table and no rules in other tables: iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE In other words NAT outbound packets from 10.0.0/24. Here's what happens when a client behind the nat attempts to open a session to port 143 on 2002:4519:c41c:2:216:3eff:fe5d:302f 03:43:41.410918 IP xx.xx.xx.xx.3545 65.54.227.124.3544: UDP, length: 66 # to teredo server 03:43:43.238943 IP 69.25.196.28.32780 xx.xx.xx.xx.3545: UDP, length: 40 # optional bubble from relay 03:43:43.239436 IP xx.xx.xx.xx 69.25.196.28: icmp 76: xx.xx.xx.xx udp port 3545 unreachable #Gee, we didn't have a mapping for that 03:43:43.326584 IP 65.54.227.124.3544 xx.xx.xx.xx.3545: UDP, length: 48 #Here comes the bubble via the server 03:43:43.335244 IP xx.xx.xx.xx.1024 69.25.196.28.32780: UDP, length: 40 #And here comes the bubble from the client to the relay #Notice we got the wrong port outbound 03:43:47.485564 IP xx.xx.xx.xx.3545 65.54.227.124.3544: UDP, length: 66 #retry 03:43:49.355222 IP 69.25.196.28.32780 xx.xx.xx.xx.3545: UDP, length: 40 03:43:49.355455 IP xx.xx.xx.xx 69.25.196.28: icmp 76: xx.xx.xx.xx udp port 3545 unreachable #And we still don't love the relay What's causing us to get the wrong outbound port? Let's look at our connection tracking tables (/proc/net/ip_conntrack) looking for 69.25.196.28: udp 17 3 src=69.25.196.28 dst=xx.xx.xx.xx sport=32780 dport=3545 packets=4 bytes=272 [UNREPLIED] src=xx.xx.xx.xx dst=69.25.196.28 sport=3545 dport=32780 packets=0 bytes=0 mark=0 use=1 udp 17 3 src=10.0.0.25 dst=69.25.196.28 sport=3545 dport=32780 packets=4 bytes=272 [UNREPLIED] src=69.25.196.28 dst=xx.xx.xx.xx sport=32780 dport=1024 packets=0 bytes=0 mark=0 use=1 The first line tells the horror story. Linux sees an incoming locally destined UDP packet. It creates connection tracking state for remote IP 69.25.196.28 from the teredo relay to the teredo client on the local system. Even though this packet generates an ICMP error because there is no socket listening on the local system for that port, the connection state is retained. so, then, when the client tries to send it cannot obtain public port 3545 because there is existing connection state. So, it is assigned a new port and Teredo doesn't work. I really hope that this Linux behavior is against draft-ietf-behave-nat-udp because it's certainly anti-social. So, what do things look like if we introduce a blackhole route near the relay to prevent the bubble from the relay to the mapped address From reaching the Linux box? We will remove this route after the client has had a chance to create NAT state. 04:18:03.174279 IP xx.xx.xx.xx.3545 65.54.227.124.3544: UDP, length: 66 04:18:05.131731 IP 65.54.227.124.3544 xx.xx.xx.xx.3545: UDP, length: 48 04:18:05.140466 IP xx.xx.xx.xx.3545 69.25.196.28.32780: UDP, length: 40 04:18:09.255394 IP xx.xx.xx.xx.3545 65.54.227.124.3544: UDP, length: 66 04:18:13.311655 arp who-has 148.64.166.189 tell xx.xx.xx.xx
Bug#413926: wordpress: Should not ship with Etch
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Dividing by years gives: Anthony CVEs Earliest Years CVEs/Year Anthony 43 2004 3 14.3 wordpress 63 2002 5 12.6 phpbb2 37 2004 Anthony 3 12.3 moodle 46 2002 5 9.2 bugzilla 45 2001 6 7.5 Anthony phpmyadmin Viewed this way, wordpress definitely appears to have one of the /highest/ rates of security holes for webapps of its class. Anthony 14 bugs per year versus 12 for moodle and phpbb2 doesn't Anthony seem that big a difference to me. Anthony I'm not sure that bug counts like this are really useful Anthony though -- they don't measure the severity of the Anthony problems, and could be indicative of popular code that's Anthony being regularly fixed as much as low quality code that's Anthony being regularly broken. While I'm not on the TC, I'd like to second the point here that looking at bug counts here isn't really the right picture. I work on MIt Kerberos for my day job. We get a lot of complaints that MIT Kerberos has a worse security track record than Heimdal because we've had more security advisories. However almost all these security advisories are from code inspection and auditing not from exploits. We could (but ethically will not) just ignore these issues or try and slip them into future releases to try and improve our security track record. However, without knowing whether similar auditing is going on against other products, or knowning how many people are looking, number of security incidents per time may not be a good description of how buggy code is. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409977: keyutils-lib: violates policy by not including soname in package
package: keyutils-lib severity: serious version: 1.2-1 justification: policy 8.1 Policy 8.1 requires that the shared library soname be in the package. keyutils-lib should be renamed libkeyutils1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410314: aklog regression in behavior with Kerberos 1.6
package: openafs-krb5 Version: 1.4.2-3 Kerberos in experimental will return null realm names for krb5_get_realm_of_host when no domain_realm mapping exists. That's fine but aklog assumes that it knows the realm. You actually want to try afs/cell@ (null realm) because if your kdc has referrals this is good. But if your kerberos supports this behavior and if you get a null realm you want to fall back to cell as realm or to first component of db server removed from db server as realm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422687: libkrb53 1.6.dfsg.1-2 causes crash in SSH
tags 422687 help thanks This is most strange. The input_token to that call should be a pointer, not 0x1. I definitely cannot reproduce the problem you are seeing either using password auth, kerberos auth or a combination. I've tried both on amd64 and i386. Can I get you to try running sshd -d -d -d and including that log output in the bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422687: libkrb53 1.6.dfsg.1-2 causes crash in SSH
thanks
Date: Tue, 08 May 2007 10:37:38 -0400
In-Reply-To: [EMAIL PROTECTED] (Jon DeVree's message of
Tue, 8 May 2007 03:20:41 -0400)
Message-ID: [EMAIL PROTECTED]
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Ah. I think I have an idea here.
First, I'd strongly recommend pam_krb5 instead of
KerberosAuthentication in sshd_config.
But I believe I can fix the problem you're seeing there too.
If you get a chance to try the following patch it would be
appreciated. If you aren't sufficiently familiar building Debian
packages I'll try to upload this reasonably soon.
Index: src/include/k5-int.h
===
--- src/include/k5-int.h(revision 19537)
+++ src/include/k5-int.h(revision 19538)
@@ -1048,9 +1048,9 @@
#define KRB5_GET_INIT_CREDS_OPT_SHADOWED 0x4000
#define krb5_gic_opt_is_extended(s) \
-(((s)-flags KRB5_GET_INIT_CREDS_OPT_EXTENDED) ? 1 : 0)
+((s) ((s)-flags KRB5_GET_INIT_CREDS_OPT_EXTENDED) ? 1 : 0)
#define krb5_gic_opt_is_shadowed(s) \
-(((s)-flags KRB5_GET_INIT_CREDS_OPT_SHADOWED) ? 1 : 0)
+((s) ((s)-flags KRB5_GET_INIT_CREDS_OPT_SHADOWED) ? 1 : 0)
typedef struct _krb5_gic_opt_private {
Index: src/lib/krb5/krb/gic_opt.c
===
--- src/lib/krb5/krb/gic_opt.c (revision 19537)
+++ src/lib/krb5/krb/gic_opt.c (revision 19538)
@@ -206,8 +206,18 @@
oe = krb5int_gic_opte_alloc(context);
if (NULL == oe)
return ENOMEM;
-memcpy(oe, opt, sizeof(*opt));
-/* Fix these -- overwritten by the copy */
+
+if (opt)
+memcpy(oe, opt, sizeof(*opt));
+
+/*
+ * Fix the flags -- the EXTENDED flag would have been
+ * overwritten by the copy if there was one. The
+ * SHADOWED flag is necessary to ensure that the
+ * krb5_gic_opt_ext structure that was allocated
+ * here will be freed by the library because the
+ * application is unaware of its existence.
+ */
oe-flags |= ( KRB5_GET_INIT_CREDS_OPT_EXTENDED |
KRB5_GET_INIT_CREDS_OPT_SHADOWED);
Property changes on: .
___
Name: svk:merge
- 122d7f7f-0217-0410-a6d0-d37b9a318acc:/local/krb5/branches/krb5-1-6:20009
304ed8f4-7412-0410-a0db-8249d8f37659:/my-branches/kdb-config:339
dc483132-0cff-0310-8789-dd5450dbe970:/branches/ccapi:18199
dc483132-0cff-0310-8789-dd5450dbe970:/branches/referrals/trunk:18581
dc483132-0cff-0310-8789-dd5450dbe970:/trunk:18744
+ 122d7f7f-0217-0410-a6d0-d37b9a318acc:/local/krb5/branches/krb5-1-6:20016
304ed8f4-7412-0410-a0db-8249d8f37659:/my-branches/kdb-config:339
dc483132-0cff-0310-8789-dd5450dbe970:/branches/ccapi:18199
dc483132-0cff-0310-8789-dd5450dbe970:/branches/referrals/trunk:18581
dc483132-0cff-0310-8789-dd5450dbe970:/trunk:18744
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423679: dpkg-dev: dpkg-shlibdeps fails when libraries of multiple architectures are in the path
Package: dpkg-dev Version: 1.13.25 Severity: normal I have an i386 system with both i386 and amd64 libraries in /etc/ld.so.conf. This is useful because it makes it easier to run amd64 binaries. Modern ld.so will just skip libraries of architecture that conflict with the executable. However, dpkg-shlibdeps runs objdump, which complains if the format is unrecognized. So, dpkg-shlibdeps always fails on my system because it finds /lib64/libc.so.6 before /lib/libc.so.6. dpkg-dev should handle libraries of conflicting architecture exactly the same way as ld.so. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.17-3 The GNU assembler, linker and bina ii cpio 2.6-17 GNU cpio -- a program to manage ar ii dpkg 1.13.25package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules 5.8.8-7Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-6high-quality block-sorting file co ii gcc [c-compiler] 4:4.1.1-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-5The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.3-7The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-21 The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428195: krb5: [debconf_rewrite] Debconf templates review
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Christian Perrier [EMAIL PROTECTED] writes: Template: krb5-admin-server/newrealm Type: note _Description: Setting up a Kerberos Realm This package contains the administrative tools required to run the Kerberos master server. . However, installing this package does not automatically set up a Kerberos realm. This can be done later by running the 'krb5_newrealm' command. . Please also read the /usr/share/doc/krb5-kdc/README.KDC file and the administration guide found in the krb5-doc package. Russ Oh, and while we're reviewing this -- is this note debconf Russ note abuse? I didn't remove it the last time I changed the Russ templates, but I wasn't sure. Perhaps it is note abuse, biut I think in this instance it significantly improves the usability of the package. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413838: gss_set_allowable_enctypes has no effect
Hi. gss_set_allowable_enctypes does correctly set the fields in the krb5_context that should control which enctypes are requested. The problem though is that krb5_get_credentials gets a ticket with session keys outside this restriction. so, something broke in respecting enctype restrictions. A temporary work around is to make sure that the nfs/server_name key only has des-cbc-crc enctypes. I.E. ktadd -e des-cbc-crc:normal nfs/[EMAIL PROTECTED] You should actually do that anyway because your server does not support other encryption types. But gss_set_allowable_enctypes should work correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413838: Not an RC bug
severity 413838 important retitle 413838 krb5_set_default_tgs_enctypes fail to work tags 413838 upstream thanks This is not RC. There is a workaround: configure the nfs server correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421939: cyrus-sasl2-mit: build against newer Berkeley DB
I don't think cyrus-sasl2-mit is still in the distribution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426483: krb5-clients: krb5-send-pr missing
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Mark Eichin [EMAIL PROTECTED] writes: Package: krb5-clients Version: 1.4.4-7etch1 Severity: normal According to http://web.mit.edu/kerberos/mail-lists.html krb5 bugs should be submitted with krb5-send-pr. I suggest either actually including it in some package, *or* if you prefer for these bugs to go through debian, to have a krb5-send-pr installed that says that (or runs reportbug appropriately, or something.) (I'd kind of prefer the former, but that may not actually be right for the package...) Russ I think the web page is actually the problem here and should Russ be fixed, although Sam can speak to this better than I. The Russ version of send-pr that comes with krb5 has /tmp file Russ vulnerabilities, so it would need some work before shipping Russ it with the Debian pacakge (see Bug#278271). Help me understand why you care about /tmp vulnerabilities in krb5-send-pr. It's not an application that you expect to be run in an automated manner and it seems very hard to usefully exploit. Russ send-pr is partly a left-over from when MIT Kerberos was Russ using GNATS for bug tracking and they've since switched to Russ RT. It still works (I think -- I haven't used it in a long Russ time, and I see a bug was just filed upstream saying it Russ didn't work properly for at least one person), in that it Russ creates a bug in RT and does prompt for some useful Russ information, but my understanding was that most people were Russ creating bugs these days by just mailing them directly to Russ the RT address. But maybe the prompting from send-pr is Russ still useful. I think it is. I think we'd rather people file things with send-pr so fields in the bug get populated and the version reported gets set. However I think that for Debian bugs should go through reportbug. In principle I don't have a problem with adding a krb5-send-pr that suggests reportbug. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413838: Probably a bug in setting the allowable enctypes
Based on the bug report, what seems to be happening is that the client is managing to negotiate an AES context even though the code calls set_allowable_enctypes to limit the context to only supporting des. So you get a CFX context on the server, which doesn't actually support CFX, so things lose. As it turns out, the client doesn't support CFX either, so things would have failed there in a few functions calls. Now, there's a question about whether this is a bug in Kerberos or the nfs-utils code. Signs point to a kerberos bug. The major thing that has changed in this area is the addition of the mechglue layer in 1.6.1. It's possible that even for a krb5 credential, this routine doesn't do the right thing. Alternatively' it's possible that nfs's expectations about what a glue layer does are wrong and the bug is on the nfs side. I think this will be fairly easy to walk through this in a debugger and see what's going on. I'll do that before unleashing 1.6.1 on unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331172: Please add support for specifying dsp device
package: libflite1, eflite severity: wishlist I notice that both eflite and flite open /dev/dsp directly (as a hard-coded string in the sources). That makes it challenging to use eflite as a speech server for screen reading with one sound card and to use /dev/dsp for music or other sound effects. It would be great if this could be an environment variable or something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327272: libpam-modules: pam_issue.so causes double free or corruption error in glibc
Thanks for reporting this. I will try and reproduce and debug but would love it if someone else gets to this before I do. I'm definitely busy this evening and will try to get to this tomorrow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327233: CAN-2005-2798: GSSAPI credentials inadvertantly exposed through improper delegation
Micah == Micah Anderson [EMAIL PROTECTED] writes: Micah Package: openssh-krb5 Severity: important Tags: security Micah CAN-2005-2798[1] reads: Micah sshd in OpenSSH before 4.2, when GSSAPIDelegateCredentials Micah is enabled, allows GSSAPI credentials to be delegated to Micah clients who log in using non-GSSAPI methods, which could Micah cause those credentials to be exposed to untrusted users or Micah hosts. Micah Since GASSAPI features are enabled in openssh-krb5/ssh-krb5 Micah and the source package tends to use older gassapi source, Micah so it is likely these binaries are vulnerable. Could someone explain to me why this is a problem? I actually use this as a feature regularly. If you don't want the other end of the connection to have your credentials, why are you shoving them over the wire. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314699: pam: pam_unix's pam_sm_acct_mgmt return values don't jive w/ what the pam docs say
Thanks for the report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315622: same thing happens if kdc cannot be reached
I'm not at all sure what to do about this bug. I understand the problem but have no idea where it can be fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#213316: Heimdal and MIT alternatives
Looking through this bug log I noticed a question from Russ about using alternatives for basically all of krb5-user. I'm certainly open to exploring it. The options are rather different beyond the really basic commands, so people might sometimes get unexpected behavior, but I think that's not unusual for alternatives. I don't think I have time to accomplish this, but it sounds potentially interesting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484371: krb5: Please consider enabling some hardening features
What does -DFOURTIFY_SOURCE=2 actually do? I'll definitely look into stack protection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482681: krb5 - NEWS file does not match documentation
Bastian == Bastian Blank [EMAIL PROTECTED] writes:
Bastian On Sat, May 24, 2008 at 10:05:26AM -0700, Russ Allbery
Bastian wrote:
NEWS.Debian is correct. The documentation predates referral
support. Thanks, I'll work on getting this fixed, hopefully
for the next upstream release.
Bastian I was not able to find that in the code, but some parts
Bastian of the old behaviour seems to be still there:
Bastian | $ kvno host/$somehost@ | kvno: KDC returned error
Bastian string: PROCESS_TGS while getting credentials for
Bastian host/$somehost@ | $ klist | Default principal:
Bastian [EMAIL PROTECTED]
Bastian |
Bastian | Valid starting Expires Service principal | 06/03/08
Bastian 15:13:13 06/04/08 01:13:13 krbtgt/[EMAIL PROTECTED]
Bastian | renew until 06/04/08 15:13:11 | 06/03/08 15:15:26
Bastian 06/04/08 01:13:13 krbtgt/[EMAIL PROTECTED] | renew until
Bastian 06/04/08 15:13:11
Bastian log: | TGS_REQ [...]: UNKNOWN_SERVER: authtime
Bastian 1212498967, [EMAIL PROTECTED] for
Bastian host/[EMAIL PROTECTED], Server not found in Kerberos
Bastian database | TGS_REQ [...]: ISSUE: authtime 1212498967,
Bastian etypes {rep=18 tkt=18 ses=18}, [EMAIL PROTECTED] for
Bastian krbtgt/[EMAIL PROTECTED]
Bastian After trying to find the principal in the default realm,
Bastian it seems to use the old behaviour and tries to find a
Bastian trust path to the domain derived realm. The domain_realm
Bastian section in the config is empty.
The news file talks about a change in how servers find their own keys,
not about the client side behavior. It's true that the client side
behavior has changed, but the ideal is that if your KDC does not
return referrals then the only client-side difference you should see
is some null realms in klist output. We have not quite reached that
ideal yet. However the server behavior has changed regarding where a
server expects to find its key in a keytab, prompting the news entry.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
