Bug#291498: ssh-krb5: package description has a spurious 'p' character
tags 291498 pending thanks Thanks much. Fixed in my svn and in the next upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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#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
>>>>> "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#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#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#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#305389: bad argument to modprobe for SMP kernel in /etc/init.d/openafs-client script
> "Jason" == Jason Rennie <[EMAIL PROTECTED]> writes: Jason> On 4/19/05, Russ Allbery <[EMAIL PROTECTED]> wrote: >> If you use the modules that are built with the package in >> Debian, the module will be named correctly. Making this change >> would break interoperability between openafs-client and the >> modules built from openafs-modules-source. Jason> Ah, sorry for the bug-less bug report. Jason> Though, I have to say it seems like bad behavior for the Jason> package to have made the name change without any Jason> notification to the installer that modules would need to be Jason> recompiled... Wait, are you saying that you had something working with a previous version of the package that broke with the new version or are you saying that you had something working with upstream that broke with the package? -- 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#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#293077: krb5-admin-server: new upstream version (1.4)
Are you going to be the maintainer of the nfsv4 utilities? Has Citi actually released something that will work with stock krb5 1.4 yet? --Sam -- 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#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#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#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#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#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#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#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. I cannot reproduce this. unmounting afs seems to work OK for me. Information on when it works vs when it does not is appreciated. -- 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#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#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#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#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 0
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#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#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#264231: libapache2-mod-auth-kerb patch proposal
Hi. I've been fairly busy and while I've had time to mostly keep up with my packages I have not had time to look at enhancements. I'll try to get a chance to look at your patch within a week. --Sam -- 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#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#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#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#413926: wordpress: Should not ship with Etch
> "Anthony" == Anthony Towns 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#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#385259: quoted_chars support seems broken
package: rdiff-backup I tried backing up my home directory onta a vfat filesystem. rdiff-backup seems like it has quoted chararacter support that should have dealt with this. However there was a file in my home directory with multiple * characters in the name. Only one of these was quoted. So rdiff-backup executed a rename system call with a destination file name including *, which failed on the vfat filesystem. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385039: doesn't restart on upgrade (uses --exec with --stop)
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> Ryan Murray <[EMAIL PROTECTED]> writes: Russ> I'm working on this for unstable right now by converting the Russ> init scripts to use LSB. Russ> Once I finish that, I'll look at producing a new version for Russ> stable. So, I'd like to understand the bug a bit better before we go and produce an update for stable. I just confirmed that when I install the 1.4.4~beta1-1 krb5kdc, whatever existing kdc is stopped and the new kdc binary ends up running. I also confirmed that if I: * cp /usr/sbin/krb5kdc /usr/sbin/krb5kdc.new * mv /usr/sbin/krb5kdc.new /usr/sbin/krb5kdc # change the inode /etc/init.d/krb5kdc restart I end up with a new KDC. I'm all for LSB-style initscripts, so I don't mind the change to unstable. But I want to actually understand what issue we're fixing before issuing an update for stable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385039: doesn't restart on upgrade (uses --exec with --stop)
If this patch works at all, it should be fine. I'd recommend a minor fix to the security patch if you are doing a stable update: r18438 | tlyu | 2006-08-15 15:27:08 -0400 (Tue, 15 Aug 2006) | 6 lines ticket: 4137 * src/clients/ksu/main.c (sweep_up): Don't check return value of krb5_seteuid(0), as it is not harmful for it to fail, and it will fail after setuid(target_user). Correct error message. -- 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#395015: openafs-krb5: kinit + aklog succeeds but the /afs access does not work (works with afslog from heimdal-clients)
severity 395015 normal thanks Other people are not seeing this; I seriously doubt it is grave. Make sure your openafs kernel module and openafs-client package are both upgraded to 1.4.2-2 Try that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#604925: "No such file or directory": /usr/lib/krb5/plugins/authdata
> "Helmut" == Helmut Grohne writes: Helmut> On Thu, Nov 25, 2010 at 02:56:46PM +0100, Helmut Grohne wrote: >> Running strace on ssh revealed the almost immediately before >> emiting the "Unspecified GSS failure. Minor code may provide >> more information\nNo such file or directory\n" it tries to open a >> directory /usr/lib/krb5/plugins/authdata which does not exist on >> my system (and is not contained in any package). Helmut> Actually this seems unrelated. When I create the missing Helmut> directory (as empty directory) the visible behaviour is not Helmut> changed in any way. So the "No such file or directory" Helmut> message does not seem to originate from some system call, Helmut> but from some userspace deciding that this is the right Helmut> message. Yes, this is unrelated. We don't have any authdata plugins in Debian so we don't create the directory. Nothing should care though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
tags 604925 moreinfo severity 604925 normal thanks I'm guessing the no such file or directory is probably spurious. What's probably happening is that something in libkrb5 or libgssapi_krb5 is returning -1 in a context where the library belives it is a system call that sets errno. However that's not setting errno for some reason and you're 're left with whatever happens to be in errno. I'll admit that this particular failure baffles me. I'm not seeing this myself nor am I seeing other reports so it's probably something specific to your environment. Is your server keyed with a DES key? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
OK. I have no idea what's going on here. If I were approaching this I'd step through things in the client and server until I found the problem. So, I'm kind of shooting in the dark here. Kerberos 1.9 includes a tracing facility that could help with issues like this, but Kerberos 1.9 is not even in sid yet much less squeeze. Is the default realm on your ssh server set to the realm in which it has its host keys? Do things change if you add a domain_realm entry to your ssh server mapping it into the realm where its key exists? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
OK. The way in which the principal is determined changed between krb5 1.8 and 1.6. In 1.8 the system searches through all the keys in the keytab looking for a key that successfully decrypts a ticket. The server name sent in the ticket over the network is ignored (at least by sshd) and only the key in the keytab's name is used. So, if you had a key in your keytab with principal name host/a.com and the same key as host/b.com, then 1.8 and 1.6 might have different ideas about what the request was actually from. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
The 1.9 packages just made their way into experimental. I'd expect that I'd expect aptitude -t experimental install libkrb5-3 libgssapi-krb5-2 would work and not bring any scary dependencies in. If it does look scary, rebuild the experimental packages for squeeze. Then you need to set KRB5_TRACE in the environment to some file that sshd can write to. Note that may be kind of tricky as I suspect sshd sanitizes its environment. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
When I've found myself trying to avoid normative language in situations like this I end up with statements like: It is important that all packages support smoothe upgrades from Wheezy to Jessie , even when the system is booted with sysvinit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library
The krb5 libraries include read and write support for the krb5.conf format, which is very similar but not identical to ini. I would be entirely happy with the response that: 1) the krb5 profile library should be used only for modifying Kerberos configs 2) supporting the ABI that your application expects is worth having multiple libraries in debian that can do the same thing. Also, libconfuse seems to read ini files. I don't know if it can write them. This message is random information; it is *not* an objection to packaging of iniparser. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737133: rm: krb5-appl -- ROM obsolete by kerberos ssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package: ftp.debian.org Hi. After discussion on debian-devel, I've decided to remove krb5-appl. One of the comaintainers dropped out, and after discussion we realized that we weren't using the package, there are better alternatives in the community, and discussion on debian-devel suggests few if any other people are using it either. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLqYPgACgkQ/I12czyGJg8OCACgr0bq6+wIlRMHSnjHEbgTMN7s odAAoJ+vkX6i0Xcci961zXM7tb+E5rwp =WHhB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723144: sasl2-bin: saslauthd infinite loop inside sendto_kdc.c at function service_fds
control: reassign 723144 libkrb5-3 control: found 723144 krb5/1.10.1+dfsg-5 control: forcemerge 694988 723144 Yep, that's a krb5 bug all right. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
control: subscribe -1 > "Charles" == Charles Plessy writes: Charles> The 3.0 (native) format is useful when packaging a work Charles> that is developped and distributed in a Git repository. Charles> Please leave us this possibility. Let me describe the use case I have which is an expansion on the above. I have a bunch of software that I perform daily builds for out of version control (git in my case but the issue applies to other vcs as well). The software does have upstream versions but is not stable enough that upstream release tarballs are useful to anyone. Honestly at this point, I'm not sure anyone will ever find upstream tarballs useful; anyone who is likely to want to build this from source probably has a copy of git and can checkout a tag. There is a packaging branch and an upstream branch. Changes made on the packaging branch increment the debian revision; changes made on the ustream branch eventually involve an increment to the upstream version. Things get dumped into a Debian reprepro repository, and into Ubuntu PPAs. Eventually, things will get stable enough that I'll upload to a PPA. Prior to that, I need a way to build a Debian package including source from a directory without an upstream tar ball. 3.0(git) is not a reasonable option because archive management programs have very little support for it, and because package download tools probably aren't well tested with it. I'm happy to entertain other options rather than 3.0(native) but my requirements are: * support for upstream version * support for debian revision * No need to have upstream sources available to dpkg-buildpackage prior to running it * No need to maintain .orig.tar.gz artifacts produced by dpkg-source and keep the checksums of these artifacts consistent between packages with the same upstream versions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
>>>>> "Andreas" == Andreas Beckmann writes: Andreas> On 2014-02-05 10:57, Sam Hartman wrote: >> tarballs useful; anyone who is likely to want to build this from >> source probably has a copy of git and can checkout a tag. Andreas> Such a tag corresponds to an upstrema version? yes. >> I'm happy to entertain other options rather than 3.0(native) but >> my requirements are: >> >> * support for upstream version * support for debian revision >> >> * No need to have upstream sources available to dpkg-buildpackage >> prior to running it >> >> * No need to maintain .orig.tar.gz artifacts produced by >> dpkg-source and keep the checksums of these artifacts consistent >> between packages with the same upstream versions. Andreas> All this sounds like it can be done with git-buildpackage Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set in Andreas> debian/gbp.conf. And maybe dpkg-source Andreas> --single-debian-patch. no, that means I have to maintain the artifact (namely the .orig.tar.gz). The archive software (both reprepro and dak were I to use that) require that the .orig.tar.gz not change checksums. I don't want my build machines to be able to push back to my master repository. Nor do I want to have to release upstream versions if I lose state on my build machines. So this violates my requirements because I have to maintain an artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum never changes. Also, using git-buildpackage is difficult. The build is done by sbuild, which does not call git-buildpackage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
> "Neil" == Neil Williams writes: That makes sense and I do something similar as appropriate. Even so, I do not wish to maintain the upstream tarball as a maintained artifact. There are cases where packaging release releases are made. Maintaining pristine-tar commits for daily builds is a worse solution than 3.0(native) or not including source packages in the resulting Debian archive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
> "Bernhard" == Bernhard R Link writes: As I mentioned I have a packaging branch and an upstream branch. I wish to use debian revisions to reflect packaging changes. It's slightly more complex than changes to debian directory involve a debian revision change; changes to other things involve a upstream version change. As an example I produce both RPMs and Debs. Just as I don't want to increment the upstream version number because of a spec file change, I don't want to increment the upstream version number because I updtaded build-depends in debian/control. Especially when the debian directory isn't even on the upstream master branch. Incrementing the upstream version number (which appears in configure.ac among other places) so I could make changes to files that don't even appear on that branch is an undesirable work flow. I guess I could have a debian upstream version number that differed from the actual upstream version number. That seems undesirable from a user expectations standpoint as well as potentially impacting things in unexpected ways. The bug claims that it is a violation of policy to use 3.0(native) without a.orig.tar.something. I'm actually failing to find that in policy at all. I'm finding some SHOULD level recommendations, but certainly not MUST level recommendations, I can think of reasons why a maintainer might want to voiolate those shoulds. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Please clarify L options with regard to interfaces
Hi. There seems to be a significant conflict within the TC about what the L options mean. Speaking as a maintainer who could be affected by this and as someone who would sponsor a GR to override one interpretation butnot another, I'd request that the TC clarify what it means with the next ballot options. * Colin said that it would be OK to depend on a stable interface such as logind-208 provided that multiple implementations could exist. * Ian said that this dependency would not be OK. I'd like the ballot options to clarify: 1) Whether these interface dependencies are acceptable 2) Whether they are acceptable in cases where there is only one implementation. I'd request the TC consider the following question although I'm not sure going into this level of detail on the ballot is appropriate: 3) If we are using virtual packages to define interfaces, what should the dependency look like? Would you want a raw virtual dependency such as gnome-shell depends on logind-208? If so, isn't that kind of not how we currently recommend things? Or a concrete dependency like systemd|logind-208? If so, please make sure that if such interface dependencies are permitted your policy text actually permits the dependency. Thanks for your consideration, --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Call for votes on init system resolution
> "Ian" == Ian Jackson writes:
Ian> Anthony Towns writes ("Re: Bug#727708: Call for votes on init
Ian> system resolution"):
>> It's really pretty terrible to actively use FD to try to block
>> options that aren't your favourite. Honestly, I would have
>> expected the tech ctte to be able to come to a consensus on a set
>> of proposals considered reasonable by all the members, and accept
>> whatever a majority decided. I'd certainly hope that tech ctte
>> members won't tactically change their vote to try to hack the
>> process.
I'm a bit confused by this. i've always thought ranking options you
consider bad enough that you'd rather have another option to work with
people and discuss the options than see that option pass. I think by
ranking FD above something you dislike, you should commit to actively
participate in a discussion if FD wins.
However, "I think this option is unacceptable, and so I'd rather discuss
more than decide it," seems like an entirely reasonable use of FD, not
something terrible at all.
I find the votes expressed by TC members entirely consistent with their
stated verbal positions, and if anything people seem to be using FD
conservatively, probably indicating a strong desire to be done with this
process.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Please clarify L options with regard to interfaces
> "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well. Hmm, I am reading Ian as against 3. I request that TC members work with Ian on the wording of L he has just proposed to make his stance clear. For my part if the TC were to adopt DL or UL as Ian just proposed I would not actually understand what policy we had adopted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Please clarify L options with regard to interfaces
>>>>> "Sam" == Sam Hartman writes: >>>>> "Colin" == Colin Watson writes: Colin> I think Ian and I are agreed that L excludes 1), and permits Colin> 3). On reflection I think I agree that L has to exclude 2) Colin> as well. Sam> Hmm, I am reading Ian as against 3. I'm sorry, I missed the message that was a direct reply to me. I now understand Ian's position to mean that we must not require users to select a certain init system for things to work. Sorry for the extra message and for reading out-of-order -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]
Yeah, I now understand what you mean by L. I'll be writing more in the form of a blog post and probably GR text. I will send a pointer to the TC as I think I may be hitting close to something that Russ may find useful. I'll refrain from trying to convince the TC because you have enough voices there. If Russ or Colin find what I right captures some of what they are saying they can bring it into the discussion. If not it only complicates an impossible mess for me to send lots of mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#402164: it isn't about ldap, just Cyrus 2.1/2.2 and GSSAPI
I agree with russ. Unless someone can get a backtrace with libkrb5-dbg installed, there's not much we can do. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738340: Please rebuild krb5-sync and libauthen-krb5-admin-perl on all arches
package: release.debian.org I'd like to request binary NMUs for krb5-sync and libauthen-krb5-admin-perl on all architectures in order to build against new krb5. The soname for the krb5 admin libraries changed. Thanks, --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738364: krb5-sync FTBFS on armel armhf ia64mips mipsel sparc
package: krb5-sync version: 3.0-1 severity: serious justification: FTBFS I'm surprised this is not already filed, but it seems like it should be. krb5-sync is failing tests (and thus builds) on the above listed architectures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
